Why Solana Simulation Succeeds but the Transaction Fails On-Chain

A practical debugging runbook for state drift, stale blockhashes, account contention and compute differences between simulation and live Solana execution.

Simulation is a snapshot, not a reservation

simulateTransaction evaluates against the state visible to the RPC at that moment. It does not reserve accounts, liquidity, price or compute for the later leader slot. Record simulation slot, node identity and receive time so the result has an explicit freshness boundary.

Compare the exact signed bytes

Rebuilding after simulation can change blockhash, account ordering, lookup-table resolution, compute-budget instructions or signatures. Hash the serialized message and ensure the submitted transaction matches the simulated payload when that is the intended workflow.

Look for state-dependent instructions

AMM reserves, oracle values, token accounts, open orders and program PDAs can change between simulation and execution. Decode the failing instruction index and compare every writable account at the simulation and landing slots.

Treat blockhash expiry separately

A transaction can be logically valid yet expire before inclusion. Persist blockhash, lastValidBlockHeight, submission routes and signature. Do not categorize expiration as a program failure or immediately rebuild an economic action without checking the old signature.

Make the failure reproducible

Store logs, units consumed, replacement blockhash, account keys, inner instructions and custom program error. Replay against a pinned local snapshot or test validator fixture where possible.

Improve your execution pipeline

TierZero builds Solana MEV systems, trading bots and production monitoring. Send a failing signature and architecture description through contact.

Production checklist

Before launch, define ownership, test fixtures, failure states, alerts and a rollback procedure. For a scoped engineering review, use the TierZero project form.