Devnet and Simulation: What Each One Actually Proves

Devnet proves that your code path completes end to end against a real validator. Simulation proves that one specific transaction would succeed against current state on whichever cluster you asked, including mainnet. Neither proves anything about liquidity, competition or fee markets, and running both is cheaper than running either badly.

Two tools, two questions

The confusion is worth naming precisely. A test cluster is a place; simulation is an operation. You can simulate a transaction against mainnet without spending anything, which is the single most useful fact in this article, because it means the safest pre-send check is available against the environment you actually care about.

Devnet answers a question about your program flow: does the sequence of instructions, account creations, retries and state transitions run to completion without a human intervening. Simulation answers a question about a single transaction: would this succeed right now. They are complementary, and teams that use only one usually use only devnet, which is the less informative half.

The clusters and what they are for

Solana runs three public clusters with different purposes, documented in the Anza cluster reference. Mainnet-beta carries real value. Devnet is the application developer's playground, where tokens are issued on request and have no value. Testnet is where validator software releases are exercised, and it is not intended as an application test environment.

The practical consequence is that application testing belongs on devnet or a local validator, not on testnet. Teams sometimes drift onto testnet because it sounds like the testing cluster, then find its behaviour unrepresentative in ways that have nothing to do with their code. Read the cluster's stated purpose before pointing anything at it.

Public endpoints for all three are rate limited and explicitly not for production traffic. If your test hammers a public endpoint and starts receiving HTTP 429 responses, you have discovered something about the endpoint policy rather than about your software, and the fix is a dedicated endpoint rather than a retry loop.

Funding a test wallet

Create a keypair that exists only for testing. Not a copy of anything, not a wallet that has ever held value, and not one you will later reuse on mainnet. This is a hygiene rule rather than a cryptographic one: separating them means a leaked test configuration cannot cost you anything, and test configurations leak constantly through logs, screenshots and shared repositories.

Devnet SOL comes from a faucet, either through the command line client or through the public web faucet. Requests are rate limited per address and per period, which is deliberate and which you should design around rather than fight: script the funding step, keep the required balance small, and reuse the same funded test address across runs rather than creating a new one each time.

What is not on devnet

The gap is larger than most test plans acknowledge. Many production programs are deployed only on mainnet; where a devnet deployment exists it often carries a different program ID, which means your configuration is not the configuration you will run in production. That difference alone has produced a long tail of defects that appear on the first mainnet transaction.

Liquidity is the second gap and the more serious one. A devnet pool holds whatever a developer put there for testing, so price impact, slippage behaviour and route selection all behave in ways that tell you nothing. A swap that completes on devnet has demonstrated instruction correctness, not execution quality.

The third gap is everyone else. There are no competing traders, no priority fee auction of any consequence, and no congestion of the kind that makes mainnet transactions expire. Any criterion about landing rate, fee levels or timing measured on devnet is measuring an empty road.

The devnet checklist

Work through these in order. Each item has a check you can perform and a reason it exists; the order matters because a failure early makes later items uninterpretable.

• Endpoint confirmed. The tool is pointed at a devnet endpoint and you have verified it by querying the cluster rather than by trusting the configuration file. Pointing a test at mainnet by accident is the most expensive configuration error in this category.
• Keypair isolated. The signing key was created for testing, has never held value, and is stored outside the repository.
• Funded and verified. Balance queried after funding, not assumed. Faucet requests can silently fail under rate limiting.
• Program IDs recorded. Every program the flow touches is listed with the ID actually used on devnet, alongside the mainnet ID it will be swapped for. This list is the diff that mainnet will test.
• Account creation exercised. The flow has been run at least once starting from a wallet with no token accounts, so account creation and its rent deposit are inside the tested path rather than outside it.
• Full flow completes. Start to finish, no manual intervention, no step performed by hand because it was easier.
• Second run agrees. The flow completes a second time with the same outcome. Disagreement between two runs is a nondeterminism and outranks every other item on the list.
• Restart tested. The process is killed mid-flow and restarted, and you have recorded what it did on restart rather than assuming it resumed correctly.
• Cleanup verified. Accounts the flow created are accounted for, and any that should be closed are closed, so the next run starts from a known state.
• Evidence written. Signatures, timestamps in UTC and outcomes exist in a file, not only in a terminal.

Item seven deserves its own note. Two identical runs on a test cluster cost almost nothing and catch a class of race condition that is otherwise found on mainnet at full price. A single clean run is compatible with a race that resolved favourably by chance, and chance is not a test result.

What simulation returns

The simulateTransaction method executes a transaction against recent cluster state without committing it. The response carries the pieces a tester needs: an error field that is null on success, the program log lines the execution produced, the compute units consumed, and optionally the post-execution state of accounts you asked about by address.

Two configuration options matter for testing. Signature verification can be turned on to check that the transaction is properly signed, and the recent blockhash can be replaced with a fresh one so a stale blockhash does not cause a spurious failure. Those two options are mutually exclusive, since replacing the blockhash invalidates the signature, and choosing between them is choosing what you are testing.

The log lines are the most useful output and the most ignored. They show which programs were invoked, in what order and at what depth, plus any message the program emitted. A route that quietly changed venue, an instruction that ran twice, or a program invoked that you did not expect are all visible there before any funds move.

Reading compute from a simulation

Every Solana transaction runs inside a compute budget. Instructions are allotted a default number of compute units unless the transaction sets an explicit limit, and there is a hard ceiling per transaction. A transaction that exceeds its budget fails at execution, having paid its fee, which makes compute a real testing concern rather than an optimisation detail.

Simulation reports units consumed, which lets you set the limit from measurement instead of from a guess. The arithmetic below is illustrative. Suppose simulation reports 118,400 units consumed for a swap. Setting a limit of 200,000 leaves generous headroom; setting it at 125,000 leaves roughly six percent, which is thin if the route can change or an extra account creation can appear.

The reason this matters for fees is direct: the priority fee is the compute unit price multiplied by the compute unit limit you requested, not by the units you actually used. At a price of 20,000 micro-lamports per unit, a limit of 200,000 units costs 4,000,000,000 micro-lamports, which is 4,000 lamports, while a limit of 1,400,000 units at the same price costs 28,000 lamports for the same work. Requesting far more than you need is a fee defect that no functional test will surface, and one that the SOL volume bot category has to get right on every transaction because the error is multiplied by the transaction count.

Preflight and when to skip it

When you submit a transaction, the RPC node normally runs a simulation first and rejects the submission if it would fail. That preflight check is why some errors arrive immediately and clearly instead of as a silent non-landing. It is also a round trip, so high-frequency senders sometimes disable it.

Skipping preflight is a legitimate engineering choice and a testing liability. With it disabled, a doomed transaction is broadcast rather than rejected, and you learn about the failure from the absence of a confirmation instead of from an error message. If your tool skips preflight, the acceptance criteria need to cover what happens to transactions that never confirm, because that path is now the normal error path.

Local validator with cloned accounts

The middle ground between devnet and mainnet is a local validator running a copy of real accounts. The Solana command line tools can start a local test validator pointed at a mainnet endpoint and copy named accounts and programs into the local ledger, which lets you exercise the real program against a snapshot of real state, repeatedly, for nothing.

This is the right environment for testing anything that depends on a specific program's behaviour, because the program is the real one. Its limitation is that the snapshot is frozen at the moment you took it: balances do not move, other traders do not exist, and a pool cloned an hour ago has an hour-old state. It is a laboratory, not a market.

Setup is worth scripting rather than performing by hand, both because you will do it repeatedly and because the list of accounts you cloned is part of the test record. A result obtained against a snapshot nobody can reconstruct is not reproducible, and reproducibility is the only property that makes a laboratory useful.

Which defects each layer catches

The last two rows are the honest ending of this article. Nothing in the cheap tier can tell you how the software behaves when block space is contested, which is precisely when trading automation matters most. That question belongs to a sized mainnet rehearsal, and no amount of test-cluster work substitutes for it.

How to write the verdict

The verdict from this layer should be narrow enough to be true. A usable form is: the flow completed twice on devnet against the program IDs listed, restart behaviour was observed and recorded, and every transaction in the flow simulated without error against mainnet state on the stated date. That sentence is defensible and it does not overclaim.

What it must not say is that the tool works. It says that the code path runs and that the transactions were well formed at a moment in time. The next sentence in any honest report is the list of things this layer could not see, which is the last column of the table above, carried forward into the design of the rehearsal that follows.

Questions the desk gets asked