Security / Trust
How to Read a Solana Transaction Simulation Before Signing
What a wallet's pre-flight simulation checks, what it can and can't protect you from, and how to read one closely enough for it to help.
Most wallets simulate a transaction before they show you the signing prompt. They run it against current chain state without sending it. It's one of the most useful safety checks you have, and one of the most ignored, because it's easy to click past.
What a simulation does
Before you sign, your wallet (or the dApp, depending on the setup) can ask an RPC node to run the transaction against recent chain state and report what would happen, without it happening. That catches errors you'd otherwise find only after paying a fee for a failed transaction: a balance that's too low, a program that rejects the call, an account that doesn't exist yet. Wallets often use the simulation to build their "estimated balance changes" summary too, the readable "you will send X, receive Y" line, if your wallet shows one.
What it protects you from
- Transactions that are certain to fail. Wrong authority, not enough funds or a program rejecting the call all show up in the simulation, before you pay a real fee to find out.
- Amounts that are obviously wrong. If the summary says "-500 SOL" and you expected "-0.5 SOL", stop.
What it doesn't protect you from
Simulation is not a full safety net, and it helps to know exactly where it stops.
- Transactions that are valid and malicious. A simulation confirms that the transaction would run as written. It says nothing about whether what's written is what you want. A disguised transfer or a malicious token approval (see how wallet-drainer contracts work) simulates perfectly well, because it does what it was built to do.
- State that changes before the transaction lands. The simulation uses recent state. If that state changes before your transaction is processed, the result can differ a little. This rarely matters for simple transfers and matters more for time-sensitive DeFi actions.
- What happens later with a permission you grant now. A delegate approval simulates as "this approval succeeds". The simulation can't show what a malicious delegate does with it next week, because that will be a different transaction.
Reading a summary properly
A useful summary shows at least which accounts' balances change and by how much, and for token transfers, which mint and how many units. If your wallet shows this, read every line and not only the total. Check that the direction (sending or receiving) and the destination match what you expected from the button you clicked. If a "claim" button simulates as a net loss for you, stop before you sign anything.
When your wallet shows no summary
Not every wallet or transaction type gets a clean summary. Some wallets show only raw instruction data. In that case, or whenever you want a second opinion, paste the signature or the raw transaction into a decoder for a plain-English breakdown of every instruction and balance change. This works for transactions you've already signed too.
Transaction Inspector decodes any signature into its instructions, program calls and per-account balance changes. The transaction lifecycle docs cover the whole process of building, simulating, signing and confirming.