Reading a transaction simulation before you sign

Your wallet used to show a hexadecimal blob and a gas estimate. Now most of them show a summary: this transaction sends 0.4 ETH and receives 1,240 tokens, and your balances change like so. That panel is a transaction simulation, and it is the most useful safety feature added to wallets in years — provided you know what it is telling you and what it cannot.

A transaction simulation is a dry run: it executes your pending transaction against the current chain state without broadcasting it, and reports the resulting balance and permission changes. It is a prediction of outcome, made now, on a state that will have moved by the time the transaction actually runs.

What the panel is telling you

A transaction simulation panel has three sections, and they answer different questions.

Asset changes. What leaves and what arrives. Read this against your intent: if you are buying a token, the outgoing item should be the currency you meant to spend and the incoming item the token you meant to buy, in amounts you recognise.

Permission changes. Approvals granted or modified. This is where the surprises are. A swap needs an approval for the token you are selling — it does not need one for anything else, and it does not need an unlimited amount.

Warnings. Flags raised by the provider: an address associated with reported theft, a token behaving unusually, a contract created recently. These are heuristics, not verdicts.

Judge a transaction simulation against what you expected to happen. A result that matches your intent is reassuring; one that matches the site's description but not your intent is the interesting case.

The reading discipline that matters is that ordering. People check whether the numbers look plausible; the useful check is whether the outcome is the one they came to produce.

What it cannot catch

The limits of a transaction simulation are structural, and each has produced real losses.

Signatures are the big one. A Permit or Permit2 signature costs no gas and does not always pass through the simulation path, which means the very request most likely to drain a wallet may show nothing at all. If you are being asked to sign rather than to transact, do not assume the panel covered it — read the spender and the amount yourself.

Front-running and slippage. A simulation predicting a certain output does not guarantee it. Between simulation and inclusion, other transactions execute, and a sandwich attack works precisely in that gap. Slippage tolerance is what bounds the damage, not the simulation.

Upgradeable proxies. A simulation runs against the implementation live right now. If an admin key can point the proxy elsewhere, the code that eventually runs may not be the code that was simulated.

The practical rule: a clean simulation is one piece of evidence, not clearance. It rules out a class of obvious problems and says nothing about the rest.

Reading it properly, in order

Five checks for reading a transaction simulation, taking about thirty seconds once the habit is formed.

1. Compare against your intent first, before reading the numbers. What did you come here to do? If the panel describes something else — even something that looks harmless — stop.
2. Read outgoing before incoming. Losses come from what leaves. An incoming amount that looks generous is not a reason to accept an outgoing amount you did not intend.
3. Check every permission line. An approval to an unfamiliar spender, or an unlimited amount where a specific one would do, is worth cancelling over. Re-approving costs one transaction.
4. Look for what should be there and is not. A swap with no approval line, when you have never traded that token before, means the approval is coming as a separate request — or was already granted.
5. Treat warnings as stops, not as noise. A flagged address is a low-cost thing to avoid and a high-cost thing to ignore.

Point four is the one that separates careful reading from skimming. Absence is information: a missing step usually means it happened elsewhere, and knowing where is the point.

Where the simulation and the site disagree

Occasionally the transaction simulation describes something other than what the page told you. That gap is the most valuable signal in the whole feature, and it has three common causes.

A mismatched approval. The page offers to swap token A, and the panel shows an approval concerning token B. This is conclusive, and it is the single clearest sign of a malicious front end.

An extra recipient. The outgoing side includes an address that is neither the contract you are interacting with nor one you recognise. Some legitimate flows do route through intermediaries, so this is a reason to stop and check rather than a certainty — but the checking happens before signing, not after.

A different amount. The page says 0.1 and the panel says 0.15, or the incoming figure is materially below the quoted one. Small differences are usually fees and rounding; a difference you can see at a glance is not.

In all three cases the resolution is the same and it costs nothing: reject the transaction, reload the site from a URL you typed yourself rather than one you followed, and try again. If the second attempt from a known-good address produces a panel matching the page, the first one was worth rejecting. If it produces the same mismatch, you have learned something about the site.

What not to do is the part worth stating: do not sign it because the amounts are small enough not to matter. An approval is not bounded by the value of the transaction carrying it, and a small transfer can be the wrapper around a permission that is not small at all.

When the wallet does not simulate

Not every wallet, chain or transaction type produces a transaction simulation, and hardware wallets in particular often show only raw data on their own screen.

Three fallbacks:

• Simulate elsewhere before signing. Independent simulators accept a raw transaction and return the same kind of report, which is worth doing for anything large.
• Read the decoded call. The function name and its arguments are the ground truth. approve(0xabc…, 115792089…) is an unlimited approval regardless of how any interface described it.
• Check the counterparty first. Scanning the contract before you connect — its age, whether its source is verified, what it has interacted with — is available in a tool like Riskira and answers a question the simulation does not: not "what will this do to me" but "what is this thing".

The hardware wallet case deserves emphasis because it inverts the usual advice. The device's small screen showing raw data is the authoritative view — the computer's rich display is the surface an attacker controls, and where the two disagree, the device is right.

Habits that make the panel more useful

Four habits make a transaction simulation more useful, in descending order of value.

Transact from a wallet holding only what is in play. The simulation shows the worst case; a wallet with a small balance bounds it.

Set slippage deliberately. High tolerance turns a predicted outcome into a range you have agreed to accept. Low tolerance fails the transaction instead, which is the cheaper failure.

Simulate the same transaction twice if you paused. State moves. A preview read ten minutes ago describes a chain that no longer exists.

Keep approvals scoped and revoke them. The panel makes new approvals visible; standing approvals from months ago are invisible to it entirely, and they are exercised in exactly the same way.

More on the permission model in web3 security, how labels and warnings are produced in risk analysis, and what a free signature can authorise in crypto scams. The Ethereum JSON-RPC documentation describes the call that simulation is built on, if you want the mechanics.

The short version

A transaction simulation runs your transaction against current state without broadcasting it and reports what would change. Read it against your intent rather than for plausibility, check outgoing before incoming, and read every permission line.

It does not cover most off-chain signatures, cannot account for state changes before inclusion, and simulates whatever code the contract points to right now. Treat a clean result as one piece of evidence — and where a hardware wallet's screen disagrees with the computer's, the device is the one telling the truth.