Transaction Simulation Before Signing: What a Wallet Preview Can Miss

What the preview actually is

When a wallet simulates a transaction, it executes the call against a copy of blockchain state and reports the result — typically the balance changes that would occur, and sometimes a decoded description of the call. MetaMask describes its standard simulations as “a test run of your transaction” that predicts estimated balance changes so you can see the outcome before submitting.

The copy is the important word. A standard simulation does not create a transaction on the blockchain. The Geth documentation describes eth_call as executing a message call immediately without creating a transaction, and eth_simulateV1 as simulating transactions without creating them. Both can run against a specified block and, optionally, a modified state.

That gives the preview three properties worth keeping separate:

1. It is a prediction, computed from one version of state.
2. It is offchain by default, so nothing about it is binding.
3. It runs with a caller and block context that a real transaction may not share.

Everything a preview can miss follows from one of those three.

The gap between simulated and real state

A simulation answers: what would happen if this transaction executed against block N, in this order, with this gas? The real transaction executes against block N+k, in an order determined by the block builder, with the gas actually forwarded.

Between the preview and the execution, other transactions land. A pool’s reserves change, an oracle updates, a lending market’s utilisation moves, a token’s balance is transferred. Any contract check that depends on those values can flip.

The most common form is a slippage check on a swap. The simulation shows the output at the current pool state. A pending trade executes first, moves the price, and the minimum-output check fails. The transaction reverts. You pay gas and receive nothing.

That is not a malfunction of simulation; it is a correct simulation of a state that no longer exists at inclusion time.

The approval that the balance diff does not show

Balance-diff previews are built around what moves. An approval does not move anything. It grants a right.

Consider a transaction that calls two functions on a contract: an ERC-20 approve for an unlimited amount to a spender, followed by a deposit of 100 USDC.

The preview shows:

That reads as a small, bounded payment. But the approval granted the spender the right to transfer the wallet’s entire USDC balance at any time in the future. If the wallet holds 25,000 USDC, the transaction has authorised access to 250 times the amount the preview showed leaving.

The simulation was accurate about balances. It was silent about authority, because authority is not a balance. This is the same distinction that separates clear signing from blind signing: the question is not only what the bytes do now, but what they authorise later.

The contract that knows it is being watched

MetaMask’s documentation describes the red-pill attack directly. Standard simulations run in a controlled environment, and a malicious contract can detect that environment and respond differently. During simulation it behaves harmlessly — the preview shows a safe outcome — and during real execution it behaves maliciously.

The detection can be as simple as checking the caller’s identity, the gas left, the block number, or whether a particular transaction is present in the block. A simulation is a call, not a signed transaction; the environment differs in ways a contract can observe.

This is why MetaMask introduced what it calls enforced simulations. With that setting, the transaction is simulated and then executed onchain with the simulation conditions enforced: if real execution does not match what was simulated, the transaction reverts. The wallet’s documentation states that enforced simulations add an onchain verification step and a higher network fee.

The distinction matters for how much confidence to place in a preview:

• Offchain simulation tells you what the contract would do under observation.
• Enforced simulation makes behaving differently costly, because divergence reverts the transaction.

Only the second closes the red-pill gap. The first is still useful — it catches mistakes, revert conditions and unexpected balance changes — but it is a different claim.

Where the numbers can be wrong

Fee-on-transfer and rebasing tokens. A balance diff assumes the amount transferred equals the amount received. Some tokens take a fee on transfer, and some rebase balances. The preview may show the nominal amount while the actual credit differs.

Tokens the simulator does not know. MetaMask states that simulations are available for contract interactions and cover ERC-20, ERC-721 and ERC-1155 transfers. A token that does not follow those standards may not appear in the preview at all.

Gas estimation under state change. eth_estimateGas returns an estimate based on current state, and the Geth documentation notes that if no gas limit is specified it uses an upper bound from the pending block. If execution encounters a colder storage slot or a different code path than the estimate assumed, the forwarded gas can be insufficient and the transaction reverts.

Smart accounts and multisigs. If the account executes through a module or a multisig, simulating from the signer’s address may not reproduce the execution context of the account itself.

Cross-chain actions. A bridge deposit can simulate cleanly on the source chain while the credit on the destination chain depends on a relayer, a challenge period or a liquidity pool. The preview covers the part it can see.

Price display. A fiat value shown next to a token is a price feed’s estimate, not a settlement value. It can be stale or absent for a thin market.

A worked example: the cost of a passing simulation

Suppose a swap simulates successfully with a 0.50% slippage tolerance and returns an estimated 1,000 USDC for 0.30 ETH. The transaction is submitted with a gas limit of 180,000 and a gas price of 12 gwei.

• Maximum gas cost = 180,000 × 12 gwei = 2,160,000 gwei = 0.00216 ETH
• The simulation shows the swap succeeding and the 1,000 USDC arriving

Before inclusion, another trade moves the pool and the output falls below the minimum. The transaction reverts on the slippage check.

• USDC received: 0
• ETH spent on gas: up to 0.00216
• The simulation’s balance prediction: wrong, for a reason the simulation could not have known at the time

The lesson is not that simulation failed. It is that the prediction was conditional on state, and the condition changed. The only part of the preview that survives is the part under your control: the call you signed and the limits you set inside it.

A practical reading order

1. Read the decoded call, not only the balance diff. An approval, a setApprovalForAll, a permit, or a change of ownership is a durable grant. These deserve more scrutiny than a transfer of the same nominal size.
2. Check the limits inside the transaction. A minimum-output amount and a deadline are enforced onchain even if the simulation is stale. A transaction with no limit relies entirely on the preview being right.
3. Treat the preview as a lower bound on what can go wrong. It reliably catches obvious reverts and misdirected transfers. It does not reliably catch authority, state dependence or simulation detection.
4. Prefer enforced simulation where it is offered, and accept the extra gas as the price of the stronger claim.
5. Review existing approvals separately. A clean simulation of today’s transaction says nothing about a permission granted last month. The allowance review and revoke guide covers that process, and what a hardware wallet does and does not protect against covers why the signing device cannot fix a bad payload.

How these sources were checked

The description of standard offchain simulation, the red-pill attack, enforced onchain simulation, the revert-on-mismatch behaviour, the supported token standards, the centralized simulation server and the higher fee for added protection all come from the MetaMask Help Center article “What are transaction simulations?”, retrieved 2026-10-24. The descriptions of eth_call and eth_simulateV1, the state override mechanism, the gas-cap parameter and the eth_estimateGas upper-bound note come from the Geth JSON-RPC documentation, retrieved 2026-10-24.

The worked examples are hypothetical arithmetic on stated amounts and fees. The 25,000 USDC balance, the 100 USDC deposit, the 180,000 gas limit and the 12 gwei gas price are illustrative, not observations of any wallet or transaction. Wallet behaviour differs by provider and version; confirm what your own wallet simulates before relying on it.