Simulation Phase

The Simulation Phase is the process of virtually executing a transaction against the current state of a blockchain to predict its outcome—including success, failure, gas consumption, and state changes—without broadcasting it to the network. This is performed by running the transaction code in a sandboxed environment, often called a virtual machine or simulator, that mirrors the live network's rules and state. The primary goals are to estimate gas fees, validate logic, and detect potential errors or security vulnerabilities before committing real assets. This phase is essential for developers building dApps and for wallets providing accurate fee estimations and transaction previews to users.

During simulation, the system checks for several critical failure points: insufficient gas (out-of-gas errors), failed smart contract conditions (e.g., require statements), and reverts. It also calculates the precise gas used and any resulting state changes, such as token balances or storage updates. Advanced simulation can model complex interactions, including MEV (Miner/Maximal Extractable Value) opportunities and the impact of pending transactions in the mempool. Tools like Tenderly, Hardhat, and Ganache provide robust simulation environments for development and debugging, allowing developers to test transactions against forked mainnet states.

For end-users, the simulation phase is often invisible but crucial. Wallets like MetaMask use it to generate the familiar transaction confirmation screen, showing the estimated gas cost and predicting potential token approvals or transfers. In the context of rollups and Layer 2 solutions, simulation is used to validate transactions before they are batched and submitted to the base layer (L1), ensuring efficiency and cost-effectiveness. The rise of flashbots and private transaction bundles has also made simulation a key tool for searchers and validators to optimize transaction ordering and profitability.

The simulation phase is a deterministic, read-only execution environment where a blockchain node or client processes a transaction locally to verify its validity and predict its outcome without altering the on-chain state. This process, also known as dry-running a transaction, involves executing the transaction's code against a recent copy of the blockchain's state to check for errors, estimate gas fees, and determine the final state changes. It is a fundamental mechanism for ensuring transaction safety and providing user feedback before broadcast.

During simulation, the node constructs a virtual machine (VM) context identical to the one used for actual execution but with key constraints: all operations are read-only, and any attempted state modifications are tracked in a temporary sandbox. The phase validates critical preconditions such as - sufficient account balance, - correct smart contract logic, - proper authorization (signatures), and - adequate gas for the computation. This prevents users from submitting transactions that are destined to fail, saving on wasted gas fees and network congestion.

For developers and applications, the simulation phase is essential for building reliable user experiences (UX). Wallets use it to provide accurate gas estimates, while decentralized applications (dApps) simulate contract interactions to show users the precise outcome—such as token swap amounts or lending rates—before they sign the transaction. Services like Chainscore's Transaction Simulator formalize this process into an API, offering enhanced debugging, risk scoring, and state diffs by simulating transactions against multiple blockchain forks and future states.

Under the hood, simulation relies on accessing a state provider—a service that supplies the necessary blockchain data (account balances, contract code, storage slots). The fidelity of a simulation depends entirely on the accuracy and freshness of this state data. Advanced simulation tools can also execute "what-if" scenarios, such as simulating a transaction with a higher gas price or at a future block, to model complex DeFi strategies or arbitrage opportunities without financial risk.

The phase is distinct from estimation, which typically only calculates gas, and from static analysis, which reviews code without execution. True simulation executes the bytecode, making it the definitive method for predicting the behavior of Turing-complete smart contracts. Its role is expanding with account abstraction (ERC-4337) and intents-based systems, where complex user operations require robust pre-checking to ensure bundle viability before submission to a mempool or bundler.

The simulation phase is a security and efficiency mechanism in ERC-4337 that allows a Bundler to verify the validity and resource requirements of a UserOperation before committing it to the blockchain. This off-chain dry-run prevents the bundler from paying for gas on operations that will revert, protecting its economic viability. The phase is executed in two distinct steps: first, simulateValidation checks the operation's signature and paymaster validity; second, simulateHandleOp simulates the full execution path, including the target contract call.

The simulateValidation function is the initial guard. It performs static checks on the UserOperation, such as verifying the ECDSA signature or ERC-1271 smart contract signature of the sender, validating the paymaster stake and deposit, and ensuring the operation does not use banned opcodes. Its primary output is a set of gas limits and a validAfter and validUntil timestamp window for the operation. Crucially, this function must be view and cannot statefully modify the blockchain, ensuring the simulation is free and non-invasive.

Following successful validation, the simulateHandleOp function executes a full simulation of the operation's core logic. It calls the EntryPoint contract's internal _validateAndExecute logic in a controlled environment, which in turn calls the sender's smart account for validation and the target contract for execution. This step calculates the precise gas consumption for both validation and execution, identifies any forbidden storage accesses (a key anti-reversion measure), and ensures the paymaster logic functions correctly. The bundler uses these gas estimates to price the operation competitively and safely.

A fundamental rule of the simulation phase is the ban on state changes. Both simulation functions must be view or pure and cannot persist any changes to blockchain state. To enforce this, the EntryPoint uses the STATICCALL opcode during simulation, which will revert if the called code attempts a state modification. Furthermore, the simulation tracks storage accesses; if the real execution later accesses storage outside the pre-declared set, it will revert. This prevents simulation griefing attacks where a contract behaves differently during simulation and actual execution.

The outputs of this phase are essential for the bundler's workflow. The gas limits and timestamps from simulateValidation determine if and when the operation can be bundled. The detailed execution trace from simulateHandleOp provides the data needed to construct a valid handleOps transaction with appropriate gas parameters. By front-running the costs and failure modes, the simulation phase enables a robust and decentralized network of bundlers, which is foundational for the account abstraction ecosystem's security and user experience.