When "you will receive 98" is wrong
Many wallets now show a preview before you sign, such as one Token A leaving and 98 Token B arriving. The wallet runs the transaction virtually in advance, which helps a great deal in understanding what you are approving. But the preview is a prediction, not a guarantee.
This guide explains how wallet simulations compute their results and why real execution can differ. It compares in a hypothetical table how the same swap ends under different conditions, and covers what simulations do not show about approvals and malicious contracts, along with what to check before signing.
How a simulation computes results
The eth_call and eth_estimateGas methods described in Ethereum.org's JSON-RPC documentation execute a transaction against current state without including it in a block, returning the result and the gas needed. Wallet simulations work similarly, running the transaction against the state at a particular block and showing balance changes and fees.
The problem is that time passes between the simulation and execution. As Ethereum.org's page on transactions explains, a signed transaction propagates through the network and runs against the state at the moment it is included in a block. If other transactions change prices or balances first, the outcome changes.
A hypothetical swap comparison
The table assumes a swap of one Token A for Token B where the simulation showed 98 and the minimum output was set at 96. It compares outcomes under different execution conditions.
| Situation | Simulated | Actual output | Outcome | Cost to the user |
|---|---|---|---|---|
| No state change | 98 | 98 | Succeeds | Fee |
| A large trade lands first and moves the price | 98 | Computes to 95 | Reverts below minimum | Fee for the failed transaction |
| Trades placed before and after (sandwich) | 98 | 96.1 | Succeeds | About 1.9 worse plus fee |
| Malicious contract detects simulation | 98 | 0, approval abused | Appears to succeed | Risk of losing funds |
A minimum-output setting prevents bad fills, but a transaction that reverts on that check still pays for the gas used.
Why outcomes differ
As Ethereum.org's page on MEV explains, block builders and searchers can see pending transactions and place their own before or after them for profit. In the sandwich case, buying just before a user's swap and selling just after can leave the user filled at the worst price their minimum allows.
Contracts that read values changing with each execution, such as external price feeds, block time, or block number, can also produce different results. A contract whose reward rate changes after a set time might return a different outcome just because the block changed after the simulation.
What simulations do not show
A simulation shows only the result of this transaction. An approval moves no funds at the moment, so its preview looks clean, but the approved contract can later take tokens up to the approved limit at any time. With an unlimited approval, the risk is unlimited too.
Some malicious contracts are built to tell simulations apart from real execution and behave differently in each, looking like a normal swap when simulated and draining funds through another path when executed. A clean preview is no reason to relax with unfamiliar contracts or sites of unclear origin.
Reviewing and revoking old approvals from time to time limits this exposure. Several block explorers offer an approvals page that lists which contracts can still move each of your tokens and lets you reduce the limit to zero.
Checks before signing
Even with a simulation result, check these items.
- Confirm the contract address matches the one in official documentation.
- Check that the token directions and amounts in the preview match the transaction you intend.
- For an approval, check which contract is approved and the limit, and approve only what is needed.
- For a swap, check that the minimum output (slippage tolerance) is sensible and how much a failure would cost in fees.
- If the wallet says the simulation failed or the outcome is unknown, do not sign until you understand why.
Protections and their limits
A minimum-output setting is the most basic way to cap losses from sandwiches or price moves. Set it too loose and you allow bad fills; too tight and transactions fail often, costing fees for nothing.
Sending transactions through private routes that keep them out of the public mempool is another option, but it introduces a different assumption: trust in whoever runs that route. For any protection, understand what it stops and what it does not.
Limits of prediction
The amounts and situations here are hypothetical and illustrate the limits of simulation. Wallets differ in how they simulate, what they display, and when they warn, and results can depend on the RPC provider's data.
When signing, check Ethereum.org's current material and your wallet's official guidance with their dates. This guide does not recommend any transaction or the trading of any token.