Introducing Surfpool: A Solana Devnet Alternative

In this post, we’re spotlighting Surfpool, a project from the Helius Startup Launchpad that won first prize at Colosseum’s Radar Hackathon and is making waves in the Solana developer ecosystem. 

We’ll start by breaking down Localnet, Devnet, and Mainnet—their roles, strengths, and pain points—before diving into Surfnet, Infrastructure as Code, and exploring how they unlock a new level of velocity, safety, and confidence for developers working on Solana.

What is Surfpool?

Surfpool is a drop-in replacement for Localnet testing environments, purpose-built to offer the best possible experience for developers building on Solana. It lets developers simulate Solana programs locally using Mainnet accounts that are fetched just in time.

Surfpool also seamlessly introduces Infrastructure as Code (IaC) into Anchor or Pinocchio-based projects, enabling reproducible, auditable, and secure deployments to any Solana network—private or public.

Before understanding how Surfpool improves the Solana development experience, it’s essential to examine the network landscape developers work with today. 

Solana has several clusters—Localnet, Devnet, and Mainnet—each serving a different purpose in the development lifecycle. While these environments are essential, they also come with trade-offs that affect speed, reliability, and confidence when shipping code.

Localnet

Localnet refers to a local instance of the Solana blockchain, typically spun up using the solana-test-validator command. It’s essentially a private blockchain that runs on your machine with no network latency and complete control over the environment.

Popularized by its tight integration with the Anchor framework, Localnet provides a high-fidelity execution of Solana’s runtime, making it ideal for fast iteration and debugging. Developers use it to simulate transactions, validate program logic, squash bugs, reset the state, and iterate.

Localnets are also commonly integrated into continuous integration (CI) pipelines. They allow teams to run automated test suites on every commit, ensuring that changes don’t break existing behavior. This helps maintain code quality and catch regressions early.

However, this isolation is also its biggest limitation. 

Localnet runs in a vacuum: it does not have real-world accounts, access to Mainnet data, or interaction with live ecosystem protocols.

As a result, while it’s perfect for isolated simulation, it falls short for composability testing or end-to-end validation in realistic conditions.

Solana Devnet

Devnet is a public Solana network operated by the Solana Foundation and a few community-run validators. It mirrors the architecture and execution behavior of Mainnet, but without economic risks.

Tokens on Devnet have no real-world value. To get them, developers rely on faucets—public endpoints that dispense small amounts of test tokens for development purposes. 

These faucets are usually rate-limited, and each token often has its own faucet with different rules (Solana Foundation operating the SOL faucet, Circle operating the USDC faucet, etc.), making token basket setup tedious and time-consuming.

Devnet serves as a shared, public staging environment. Developers use it to simulate interactions across programs, test client-side behavior in a live environment, and prepare for Mainnet launches. It’s convenient when working with third-party integrations like oracles, DEXs, or token programs unavailable in Localnet.

Since Devnet RPC endpoints are publicly available, Devnet is also commonly used to develop and debug application frontends. 

Many teams also rely on Devnet for internal testing environments. Larger protocols (e.g., Pyth) sometimes create “sandbox” deployments of their apps on Devnet to facilitate integration testing for other teams.

It’s important to remember that each team defines its own Devnet deployment strategy. Unlike Mainnet, where protocols are generally audited, stable, and up-to-date, Devnet deployments can be outdated, incomplete, or misconfigured.

As a result, composability is limited.

Of course, there are variations. Some teams maintain their own internal Devnet environments for staging and integration testing, while others operate public Devnets to support third-party developers and partners. These custom environments often provide more control, stability, or tailored access than the shared Solana Devnet.

Solana Mainnet-beta

Mainnet is the real deal: the network ingests thousands of adversarial transactions every second, where tokens hold real value, and every mistake can be costly. Unlike Devnet or Localnet, deploying to Mainnet requires rigorous preparation, strict security practices, and high confidence in your code.

Operationally, Mainnet changes everything. 

Deployment keypairs—often held in multisigs or hardware wallets—must be tightly secured, and any issue in your deployment process can have serious consequences. You’re now exposed to real network conditions, including unpredictable traffic, real-world latency, and interactions with live users and assets.

But it also brings the benefits of full composability and integration with every protocol that matters. Mainnet is where your program proves itself—under real pressure, at full scale.

As it turns out, most of the developers we met quickly hit a wall due to Devnet’s limited composability. To move faster or access accurate data, they often start iterating directly on Mainnet, which comes with higher risk, slower iteration cycles, and more operational overhead. Devnet fails to be a meaningful bridge between the two.

Introducing Surfnets

Surfnet gives you the benefits of local-first Localnets while ensuring transactions have access to Mainnet state without syncing a node.

It’s Surfpool’s answer to the limitations of traditional Solana networks: a purpose-built, developer-centric environment that bridges the gap between Localnet and Mainnet.

Surfpool fetches live account data on demand from any RPC of your choice, while isolating and tracking your program’s state locally. This gives you full control, faster iteration, and a faithful simulation environment.

Thanks to this architecture, Surfnet behaves like a lazily forked network, copying state on read and writing changes locally. Like Localnet, it boots instantly and is significantly faster. Surfnet instances are lightweight and can operate on something as cheap as a Raspberry Pi.

By adhering to the canonical RPC contract, Surfpool is de facto compatible with wallets, explorers, and CLI tools that rely on those endpoints.

Surfnet RPC Methods

To further enhance the Solana developer experience, Surfnet introduces a set of RPC methods—called cheatcodes—that let you bend the network rules for faster iteration and better control during simulations. These include:

• surfnet_setAccount: Inject arbitrary account data into the network state.
• surfnet_setTokenAccount: Instantly create token accounts with custom balances and metadata.
• surfnet_setMintAccount: Define or override mint configurations, including supply, decimals, and authorities.

These cheat codes act like superpowers for local development, enabling scenarios that would otherwise require tedious research, manual setup, and involved scripting.

Combined with Mainnet data, cheatcodes give developers unprecedented power. Their local network has full access to real-world context, while allowing them to bend the rules at will, enabling rich, controlled, and highly realistic simulations.

Reproducing this seemingly simple yet straightforward setup on a Localnet would typically take days.

Cheatcode Case Study: The Heist

To show what Surfpool cheatcodes are capable of, we built a faucet we codenamed The Heist.

Why the name? Because it feels like robbing a bank—with zero friction, zero risk, and full control. Instantly fund any account with any token: SOL, USDC, or custom SPLs. No rate limits, no waiting, no third-party services. Just one command and you’re liquid.

Faucets have always been a sore spot for developers—slow, unreliable, and scattered across the ecosystem. With The Heist, we flipped that on its head. It’s fast, local, and built into your Surfnet environment.

This is only possible thanks to Solana’s design. The shared precompiled token program ensures a consistent storage layout across all tokens, making this kind of universal faucet viable. This would not be possible on platforms where token implementations vary widely..

The Heist isn’t just a dev tool—it’s a statement about what fast, clean simulation can unlock.

Crypto Infrastructure as Code (IaC)

Running powerful simulations is just part of the story—Surfpool also introduces Infrastructure as Code to Solana, bringing reproducibility, automation, and security to every deployment, with low overhead for developers.

Crypto Infrastructure as Code (IaC) is a topic that could easily warrant its own dedicated post. Over the years, we’ve built deep expertise in this area through hands-on work with sophisticated protocols like Pyth, Wormhole Core, Circle CCTP, Bitcoin Ordinals, and many others.

At a high level, crypto infrastructure typically consists of three major categories of components:

1. Onchain Infrastructure
2. Signing Infrastructure
3. Offchain Infrastructure

Onchain Infrastructure

This includes program deployments, upgrades, and state migrations. In a well-designed IaC system, smart contracts are deployed through reproducible and auditable processes, ensuring integrity, version control, and traceability.

Signing Infrastructure

Most security failures occur in key management. Rather than relying on insecure local keypairs, production-grade systems use hardware wallets, threshold cryptography, or multisig setups to sign transactions securely and responsibly. 

In a well-designed IaC system, signing infrastructure should be modular and configurable, allowing you to switch from a hardcoded private key to a sophisticated multisig ceremony by simply updating a few configuration lines.

Offchain Infrastructure

This includes everything that surrounds and supports your smart contracts: indexers, state watchers, wallet sentinels, automation scripts, and more. 

These components are often tightly coupled to onchain events and should be treated as code—testable locally, portable, and fully deployable.

Benefits of Crypto Infrastructure as Code

A well-designed IaC system should be statically analyzable. You shouldn’t need to execute any code to understand what it will do.

You should be able to generate a complete execution plan up front, detailing which programs and signers will be involved, which resources will be touched, and how much it will cost.

No JavaScript-based DSLs or opaque shell scripts—just clean, declarative code. It should be composable, easy to maintain, and have a minimal learning curve.

With such a system, developers moving from Localnet to Mainnet should be as simple as swapping the signing infrastructure from a local keypair living on disk to a Squad signer.

It took us months to design and build the stack we call Web3 Runbooks—refining the language, making it simple to use, and making the runtime secure and composable. 

With Surfpool, we aim to make this Runbook technology even more accessible and user-friendly while pushing further boundaries to ensure Solana developers build on the best foundation possible.

By combining Surfnets and Crypto Infrastructure as Code in Surfpool, we’re creating what we believe is the best developer tool in Web3. Developers gain access to a local-first stack and can progressively move toward Mainnet as their protocol matures simply by tweaking their IaC configuration.

To close the loop and get back to networks, it’s worth noting that Surfnets can be defined and managed through Infrastructure as Code. This means developers can easily spin up ephemeral networks, pre-configured with hundreds of accounts already funded with the right token baskets (SOL, USDC, etc) needed to interact with their protocols.

Resources and Documentation

We recommend watching this Solana Changelog episode hosted by Jacob Creech, Head of Developer Relations at the Solana Foundation, for a 45-minute deep dive into Surfpool.

We’re also launching a series of short screencasts to help developers get started with Surfpool in bite-sized, hands-on sessions.

Our complete documentation is available at docs.surfpool.run.

Conclusion

The road ahead is long, but the future is bright. Developers are already showing strong interest in Surfpool, and their feedback fuels our conviction that we’re building something essential.

That said, we’re only scratching the surface. 

Our mission is to make Mainnet simulations indistinguishable from the real thing. 

Today, Surfpool doesn’t yet account for some critical aspects, such as transaction contention and prioritization, or adversarial behaviors such as MEV and sandwich attacks. 

We’re excited about what’s next. Surfpool is already changing how people build on Solana—and we’re committed to pushing it even further.