Before self custody wallets added previews, confirming a transaction meant reading a string of hexadecimal data and trusting that it did what the app said it would. Most people could not read that data, so in practice they were signing blind. Transaction simulation changed that. Instead of asking you to trust a description, a growing number of wallets now run the transaction against a copy of the current chain state first, then show you what actually happened: which tokens moved, in which direction, and by how much, all before you commit to anything real.
What a simulation actually does
A simulation is not a guess or a summary written by the app you are using. It is the same transaction, executed against a recent copy of the blockchain's state, without broadcasting it. Because nothing is submitted, there is no gas fee and no lasting effect. The simulation engine, whether it is built into the wallet or provided by a service like Tenderly or Blockaid, replays every step the transaction would take and records the result: balance changes, token transfers in and out, new approvals granted, and any contract calls made along the way.
That result is what gets turned into the plain language summary you see in the confirmation screen: "You will send 0.5 ETH and receive approximately 1,240 USDC," for example, instead of a wall of unreadable data. Some wallets go further and show a full trace of every internal call the transaction makes, which is useful if you want to dig deeper, though most people only need the top line summary.
Why this matters for swaps and approvals
On a swap, simulation is what lets a wallet tell you the tokens you are about to receive with some confidence, rather than repeating a number a website supplied. If a contract behaves differently than the interface claims, for example returning far less than expected or routing part of the trade somewhere unexpected, a simulation can catch that mismatch before you sign, not after.
Simulation is even more valuable on approvals and permit style signatures, which do not always make it obvious what you are actually authorizing. A well built preview will decode the request and state plainly that a specific contract is being granted permission to spend a specific token, up to a specific amount, or without limit. That single sentence has stopped a meaningful number of approval based thefts, because the request stops looking like routine paperwork and starts looking like what it is.
Security tools built on simulation also cross reference the addresses and contracts involved against lists of known scams and drainers, and will flag a transaction as risky even if the simulated outcome looks technically fine. This is a separate layer from the simulation itself, but the two are usually presented together in the same warning.
What simulation cannot catch
A simulation reflects the chain state at the moment it runs, which is a snapshot, not a guarantee. Between the simulation and the moment your transaction actually confirms, the state can change: someone else's transaction lands first, a pool's price moves, or a limited time approval expires. This is one of the reasons swap interfaces also rely on slippage limits rather than the simulated output alone, a topic covered in more detail in our guide to swap fees and slippage.
Simulation also cannot protect you from a contract that behaves honestly during the preview but was designed to behave differently under conditions the simulation did not trigger, for instance logic that only activates after a certain number of calls or at a specific time. This is rare, but it is why simulation is a strong second check rather than a full guarantee. It also cannot tell you whether a token is scarce, legitimate, or worth anything. A simulation will happily and accurately show you receiving ten million units of a worthless token, because that is exactly what the transaction does. Simulation answers the question "what will this do," not "is this a good idea."
Finally, simulation depends on the transaction actually being simulatable. A small number of contracts behave in ways that are difficult to model outside their exact live environment, and in those cases a wallet may show a partial preview or none at all. Treat a missing or failed simulation as a reason to slow down, not as something to click past.
How to use the preview well
Read the summary before you approve, not after. Check that the token and amount going out match what you expected, and pay particular attention to anything listed as an approval rather than a transfer, since approvals are the part most often abused. If a simulation cannot run, or a wallet warns that it could not fully verify a transaction, treat that as a prompt to double check the site and the contract manually rather than a technicality to dismiss.
Simulation will not replace judgment. It will not warn you about a project with no real use, and it cannot make a bad trade a good one. What it does reliably is turn an unreadable request into a plain statement of what is about to happen to your funds, which is the piece of information every confirmation screen was missing for years.
Sources: Blockaid on transaction verification and blind signing, Tenderly Transaction Preview documentation, Blockaid transaction security overview.