Elliot Friedman

Founder, Kleidi

T₀ vs T₁: The Simulation Problem

T₀ vs T₁: The Simulation Problem

Transaction simulations make crypto users feel safer. But are they actually? A simulation tells you what to expect from a transaction the moment you click "preview." It includes no guarantees about what will actually happen when your transaction lands on chain.

The gap between simulation and execution is measured in seconds and there are important properties about simulations that allow them to be deceptive. That's enough time for an attacker to change everything.

The Temporal Gap

When you simulate a transaction, your wallet queries the current blockchain state, runs the transaction logic locally, and shows you the expected outcome. This process assumes the world stays frozen between your preview and your signature. It doesn't.

Attackers exploit this in three ways:

State manipulation during signing. In January 2025, Scam Sniffer documented a $460,000 theft where attackers modified contract state during the 30 seconds a user spent reviewing a transaction. The victim's wallet showed a small ETH claim. The actual execution drained everything. The simulation was accurate when generated. It was obsolete by execution.

Front-running with contract upgrades. If you're interacting with an upgradeable contract, your simulation runs against the current implementation. But an attacker with upgrade access can swap the implementation between your signature and execution. Your transaction now runs completely different code than what you thought.

MEV sandwich attacks. Your swap simulation shows acceptable slippage. An MEV bot sees your pending transaction, front-runs it to move the price against you, lets your transaction execute at the worse rate, then back-runs to pocket the difference. jaredfromsubway.eth extracted $34-40 million using this pattern across hundreds of thousands of attacks. Victims' simulations were technically correct for the state that existed before their transactions entered the mempool. Unfortunately for them, the state changed after their transaction was in the mempool and before it landed on chain.

Why ML Scanners Can't Fix This

Machine learning transaction scanners face a fundamental limitation: they analyze transactions at time T₀, but execution happens at time T₁. No model can predict adversarial state changes that occur after the scan. This isn't a data problem, it's a logical impossibility with the current structure of most wallets without pre and post transaction checks.

The attack surface includes patterns that bypass detection entirely:

Code path switching. Contracts can behave differently based on manufactured conditions. Harvest Finance lost $33.8 million when attackers used flash loans to temporarily manipulate oracle prices, causing the contract to execute a different code branch than normal conditions would trigger. The contract code was "correct." The economic assumptions embedded in that code were exploitable under conditions that only existed for a single atomic transaction.

Simulation detection (the "Red Pill" attack). Sophisticated contracts can detect when they're being simulated versus executed on chain. Zengo's security research team found that almost every major simulation implementation they tested was vulnerable to this pattern. The specific bugs they reported were fixed, but the vulnerability class itself is what matters: simulation engines are structurally exposed to detection-based evasion.

The attack exploits "special variables" in Solidity that carry blockchain metadata. Take COINBASE, which returns the current block miner's address. During simulation, there's no real block and no miner, so many implementations used to return the null address (all zeros). A malicious contract checks this value: if COINBASE is zero, behave benignly and show the user a profitable or expected transaction. If COINBASE is non-zero (real execution), take their funds. A more sophisticated version of this attack would involve building a database of the top active addresses in the validator set, if COINBASE is non-zero and not an active validator, go down the safe looking code path.

Zengo demonstrated this against Coinbase wallet users. The simulation showed victims that sending 0.1 MATIC would return 0.016 WETH (roughly $0.1 in, $30 out). On actual execution, victims got nothing. The simulation didn't fail. It was actively weaponized against users. Other red pill candidates include GASPRICE, block timestamps, and transaction fee parameters. Any value that simulators populate with constants rather than realistic data becomes an attack surface.

The fixes are straightforward (use last block's miner for COINBASE, use user-selected fee for GASPRICE), but the vulnerability class is fundamental. Simulation environments will always differ from mainnet in detectable ways. Determined attackers will find those differences.

The spoofing surface is unbounded. The Red Pill attack is one example, but the broader problem is structural. Any difference between simulation environment and mainnet execution becomes an attack vector. Contracts can be upgraded between simulation and execution. Code paths can branch based on storage values that change after your preview. External state from oracles, other contracts, or block data can change conditions. Time-based logic can behave differently if your transaction lands in a later block than expected.

As long as these paths exist, the simulator cannot detect them, and users will never know their preview was meaningless. The attacker doesn't need to find a bug in the simulation software. They just need to find any lever that moves between T₀ and T₁.

What Actually Works

For high-value transactions, you need more than a simulation preview. You need hard guarantees about which storage slots can and cannot be modified that are a part of the transaction being signed. Ledger is doing good work in this space with their EIP geared towards making signing legible.

On-chain enforcement. Policy engines, guards and modules that verify transaction effects at execution time, not simulation time. If the actual storage changes don't match the allowed set, the transaction reverts. No amount of front-running or state manipulation can bypass a check that happens atomically with execution.

Timelock delays. Force a waiting period between transaction submission and execution. This gives you time to detect and respond to state changes. It also makes front-running attacks visible before they can complete.

Human review for threshold transactions. For transactions above a certain value, require manual verification of the exact calldata and expected effects. ML can flag anomalies; humans need to make final calls on significant value transfers.

EIPs Moving in the Right Direction

Several Ethereum Improvement Proposals address pieces of this problem:

EIP-7702 allows EOAs to temporarily delegate to smart contract code, enabling account abstraction patterns without permanent migration. This creates a path toward wallets with built-in transaction validation logic.

EIP-7562 standardizes account abstraction validation rules, making it easier to build wallets that enforce constraints at the protocol level rather than relying on simulation accuracy.

EIP-3074 (now superseded by 7702) introduced the concept of AUTH and AUTHCALL opcodes, letting EOAs authorize contracts to act on their behalf with explicit scope limitations.

EIP-8141 introduces frame transactions, separating validation, execution, and gas payment into distinct programmable phases. Users can define arbitrary signature schemes and validation logic at the protocol level rather than relying on fixed ECDSA. This is a significant step forward for post-quantum readiness and native account abstraction. Arbitrary validation logic, independently succeeding or failing frames, and programmable gas payment through paymasters create new interactions and security considerations the ecosystem hasn't fully mapped yet.

All of these help or have the possibility to help, but they don't solve the core issue. Protocol-level changes take years to deploy. Users holding significant value today need solutions that work with current infrastructure.

Complacency

The real risk isn't that simulations are inaccurate. They're often quite accurate for the state that exists at preview time. The real risk is that users treat simulations as a security guarantee.

They aren't. Never have been, and never will be.

A simulation tells you what the system expects to happen at a point in time T₀ with that chain state. Since your transaction won't have that same state at execution time T₁, the simulation can't guarantee the outcome. On-chain enforcement tells you what the system allows. For transactions where significant value is at risk, you need the latter.

References

Scam Sniffer: Transaction Simulation Spoofing ($460,000 theft, January 2025)

jaredfromsubway.eth MEV Bot ($34-40M extracted, 238K attacks, 106K victims)

Harvest Finance Flash Loan Attack ($33.8M, October 2020)

Zengo Red Pill Attack Research

Ethereum Improvement Proposals