How to Read a Solana Transaction Simulation Before Signing

Most wallets run a simulation before showing you the final signing prompt — a dry-run of the transaction against current chain state, without actually submitting it. It's one of the most useful safety mechanisms available to you, and one of the most commonly ignored, because it's easy to click past without reading.

What a simulation actually does

Before you sign, your wallet (or the dApp, depending on setup) can ask an RPC node to execute the transaction against a recent snapshot of chain state and report what would happen — without it actually happening. This catches errors that would otherwise only surface after you'd already paid a fee and had a failed transaction: an instruction that would fail due to insufficient balance, a program that would reject the call, an account that doesn't exist yet. Simulation is also frequently how a wallet computes the "estimated balance changes" summary it shows you — the human-readable "you will send X, receive Y" line, when a wallet provides one.

What it protects against

• Guaranteed failures. If the transaction would fail outright — wrong authority, insufficient funds, a program-level rejection — simulation catches it before you spend a real fee finding out the hard way.
• Basic sanity on amounts. A simulated balance-change summary showing "-500 SOL" when you expected "-0.5 SOL" is an immediate, visible red flag worth stopping on.

What it does NOT protect against

This is the part worth understanding precisely, because simulation is not a full safety net:

• A transaction that's technically valid but malicious. Simulation confirms the transaction would execute as written — it says nothing about whether "as written" is actually what you want. A disguised transfer or a malicious token-approval instruction (see how wallet-drainer contracts work) simulates perfectly fine, because it's doing exactly what it was built to do.
• State that changes between simulation and submission. Simulation runs against a recent snapshot; if chain state changes meaningfully before your actual transaction lands (rare for simple transfers, more relevant for time-sensitive DeFi actions), the real outcome can differ slightly from what was simulated.
• Future actions from something you're approving now. A delegate approval or a program permission granted today simulates as "this approval succeeds" — it can't simulate what a malicious delegate might do with that approval next week, because that's a separate, future transaction.

Reading one that actually has substance

A useful simulation summary shows, at minimum: which accounts' balances change and by how much, and for token transfers, which mint and how many units. When your wallet provides this, the actual discipline is simple but easy to skip under time pressure: read every line, not just the total, and specifically check that the direction (sending vs. receiving) and the destination match what you expected from the action you took. A "claim" button that simulates as a net negative balance change for you is a direct contradiction worth stopping on immediately, before you sign anything.

When your wallet doesn't show a friendly summary

Not every wallet or every transaction type gets a clean simulated summary — some show only raw instruction data. In that case, or any time you want a second, independent read on a transaction (including one you've already signed and want to understand after the fact), pasting the signature or the raw transaction into a dedicated decoder gives you a plain-English breakdown of every instruction and balance change involved.

Transaction Inspector decodes any signature into its instructions, program calls, and balance deltas per account. Background on the full transaction lifecycle — building, simulating, signing, confirming — is in the transaction lifecycle docs.