Simulation executes a proposed transaction against the node’s selected state without broadcasting it. Inspect the execution error, logs, compute and requested account changes. A successful preview describes that state and configuration; it does not reserve liquidity, prove real signatures when verification is disabled or guarantee later execution.
Use simulation to examine execution before delivery
A transaction can fail because of an incorrect authority, missing account, invalid amount, program check or exhausted compute. Simulation helps locate such problems before broadcasting an actual attempt.
The RPC node evaluates the encoded transaction against its state at the selected commitment. It can report logs, execution error, consumed units and other supported result fields.
The simulation does not commit the proposed account changes to the chain. It also does not reserve the state for your later transaction. A quote, balance or permission can change between preview and execution.
Start with the smallest transaction relevant to your problem. Then add the complete composed path so you test the interaction between instructions, account setup and downstream programs.
Run a read-only Memo example on devnet
The following request contains an unsigned legacy transaction with a zero signature placeholder and a Memo instruction. It uses a public devnet account as the simulated payer. It neither knows that account's key nor authorizes spending from it.
sigVerify is false, and replaceRecentBlockhash asks the node to supply a recent blockhash for simulation. These settings let the example examine execution without a valid payer signature. Do not submit these bytes through sendTransaction.
curl https://api.devnet.solana.com \
+ -H 'Content-Type: application/json' \
+ --data '{"jsonrpc":"2.0","id":2,"method":"simulateTransaction","params":["AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAECDcMIHyIb+qHZ9qk1Lv4DorA7WngltapcFv4Md3HK/+MFSlNamSkhBk0k6HFg2jh8fDW13bySu4HkH6hAQQVEjQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAH1NvbGFuYUJ1bGwgcmVhZC1vbmx5IHNpbXVsYXRpb24=",{"encoding":"base64","commitment":"finalized","replaceRecentBlockhash":true,"sigVerify":false}]}'The request was executed on 7 November 2026. The recorded result had err equal to null and included the Memo text SolanaBull read-only simulation. It consumed 12,599 CU in that observation. New runs can return different context and resource results.
The example tests the simulation interface and log interpretation. It does not deploy your own program or establish that you can sign as the public payer.
Read the final error before individual success messages
Begin with result.value.err. A non-null value means the simulated transaction did not complete successfully under those conditions. Identify the failing instruction and inspect the surrounding logs.
Logs can include nested calls, program messages and local successes before a later failure. A success line from an earlier token transfer does not establish that the transaction's proposed application changes would commit.
Use unitsConsumed to understand measured computation for that run. Compare it with the actual requested budget and the complete path. A larger compute limit affects fee calculation for relevant transaction formats even when fewer units are used.
Where supported and requested, inspect account results, token balance changes and inner instructions. Resolve exact account identities. A readable application label is not enough to verify the recipient or authority.
A recorded read-only devnet simulation
Understand signature and blockhash settings
With sigVerify true, the node checks the transaction's signatures. With it false, a successful simulation does not prove that those signers actually approved the message.
Replacing the recent blockhash changes what is evaluated. It can be useful for an unsigned draft, but it is not verification of the unchanged signed bytes you intend to send. Signature verification and blockhash replacement have compatibility constraints in the method's contract.
For final preflight, inspect the real transaction configuration. Keep cluster, commitment, format support and relevant context coherent with construction and delivery.
Durable nonce transactions have their own validity state. Treating a nonce value as an interchangeable ordinary recent blockhash can produce the wrong diagnostic conclusion.
Diagnose a failed simulation by its boundary
If decoding fails before execution, verify serialization, transaction version and encoding. An account-loading error calls for checking addresses, existence and the selected state. An instruction error needs the actual program's rules.
For an insufficient-funds result, separate the transfer amount, transaction fee and account-creation funding. Token quantity and SOL available for fees are different balances.
For a program constraint failure, check the expected owner, signer, writable status, mint and authority relationship. Increasing compute does not repair an incorrect recipient or missing signature.
For compute exhaustion, inspect the measured path and its loops or nested work. A higher budget can make the path feasible within limits, but should follow measurement rather than replace debugging.
Verify the actual transaction after submission
A swap can simulate successfully and later fail because the pool changed beyond its permitted output bound. A receiving account can change state, and a transaction can miss its validity window.
After signing and sending, track the real signature. Inspect the final execution error and required finality, then read the accepted application state.
Keep the preview, signed message and actual outcome distinct in diagnostics. That record shows whether the problem came from the draft, changing state, delivery or downstream interpretation.
Continue with transaction retries before designing automated delivery, especially when a lost response could lead to a repeated payment.
Common questions
Does simulation charge the simulated fee to the account?
No onchain changes from the simulation are committed. A fee shown in its result is part of the evaluation, not an actual payment from that run.
Does err=null prove the payer signed?
Only signature verification under the appropriate configuration checks signatures. This example deliberately disables it.
Can a successful simulation fail later?
Yes. State, validity and delivery conditions can change before actual execution.
Sources and documentation
Found an error or an outdated detail? Send a correction.