Execution Phase

In the execution phase, a node (typically a validator or sequencer) takes a list of pending transactions from the mempool and executes them against the current state of the blockchain. This involves running the transaction's code—such as a smart contract function call or a simple token transfer—within a deterministic virtual machine like the Ethereum Virtual Machine (EVM). The output is a set of state transitions, which detail changes to account balances, contract storage, and event logs, before any changes are finalized.

This phase is computationally intensive and must be deterministic, meaning that given the same initial state and transaction input, every honest node must compute the exact same resulting state. In architectures like Ethereum's post-merge consensus-execution split, this phase is handled by a dedicated execution client (e.g., Geth, Nethermind), which works in tandem with a consensus client (e.g., Prysm, Lighthouse). The execution client produces an execution payload, which contains the new state root and transaction receipts, for the consensus layer to package into a block.

The execution phase is distinct from and precedes the consensus phase, where validators agree on the canonical ordering and validity of the proposed block. Key outputs of execution, such as the state root and receipts root, are cryptographically committed to the block header, allowing other nodes to verify the correctness of the execution without re-running every transaction. This separation enhances network efficiency and scalability.

In optimistic rollups and zk-rollups, the execution phase occurs off-chain on a separate layer (L2). A sequencer processes transactions and produces a batch with a new state root. In optimistic systems, this result is assumed valid unless challenged (with fraud proofs), while in zk-rollups, a zero-knowledge proof (validity proof) is generated during execution to cryptographically verify the state transition's correctness before posting data to the main chain (L1).

Understanding the execution phase is critical for developers, as it directly impacts gas costs, transaction ordering (MEV), and smart contract performance. Errors in contract logic are manifested here, and the deterministic nature ensures that all nodes can independently validate the network's state, maintaining blockchain integrity without a central authority.

The execution phase is the computational step in a blockchain transaction where the intent of a user's transaction—such as a token transfer, a swap on a decentralized exchange, or a complex DeFi interaction—is processed and applied to the global state. It follows the initial validation and precedes final settlement. During this phase, the Ethereum Virtual Machine (EVM) or another blockchain's execution environment interprets the transaction's data and code, performing calculations, reading from storage, and determining the precise changes to account balances, contract storage, and event logs. This phase is where the actual business logic of a smart contract is run.

Execution occurs within a sandboxed environment defined by the transaction's parameters: the gasLimit, gasPrice, recipient address (to), value, and calldata. The EVM executes opcodes sequentially, each consuming a predefined amount of gas. Key operations include reading from SLOAD, writing with SSTORE, performing arithmetic, and making external calls via CALL or DELEGATECALL. The phase produces an execution trace, a detailed log of every computational step, and a resultant state diff—the set of changes to the blockchain's world state that will be committed if the transaction is valid and does not run out of gas.

A critical outcome of the execution phase is the determination of the gas used and the transaction's success or failure status. If execution completes successfully within the gas limit, the computed state changes are considered valid and are passed to the consensus layer for finalization. If execution fails due to an error (e.g., a failed require() statement) or exhausts the provided gas, all state changes from that execution are reverted, but the sender still pays for the gas consumed up to that point. This revert-and-charge mechanism prevents resource abuse while ensuring atomicity—transactions either succeed completely or have no net effect on state, aside from the gas fee.

The EntryPoint contract is the mandatory, singleton smart contract that acts as the trusted verifier and executor for all ERC-4337 UserOperations. Its primary role in the execution phase is to receive bundled operations from Bundlers, validate them against a set of global rules (e.g., signature and nonce verification), and then coordinate the actual execution of transactions on behalf of smart accounts. By centralizing this logic, it ensures a consistent security model and prevents wallet implementations from bypassing critical checks, making the entire system more secure and gas-efficient for the network.

During execution, the EntryPoint performs a strict, two-phase process: verification and execution. In the verification loop, it calls validateUserOp on each smart account to confirm the UserOperation's validity and that the account has prefunded the EntryPoint for its maximum possible gas costs. Only after all operations in a batch pass verification does the execution loop begin. Here, it calls execute (or similar) on the account contract, transferring the required gas and executing the intended logic. This separation prevents denial-of-service attacks and ensures accounts cannot execute without first proving they can pay.

A critical function of the EntryPoint is gas abstraction and reconciliation. It acts as a gas bank, using the prefunded deposits to pay for the execution. After execution, it calculates the actual gas used, refunds any unused amount to the account's deposit, and compensates the Bundler for the transaction's inclusion cost. This mechanism decouples payment from the native token of the chain, allowing sponsors or the accounts themselves to pay fees in any asset the wallet supports, a core feature of the paymaster system integrated into this phase.

The singleton, upgradeable nature of the EntryPoint is essential for ecosystem-wide upgrades and security fixes. Because all ERC-4337 compliant wallets and infrastructure must interact with the official EntryPoint, improvements or critical patches can be deployed once and benefit the entire ecosystem without requiring users to migrate their smart accounts. This design also simplifies auditing and monitoring, as the security of the execution phase converges on a single, heavily scrutinized contract, rather than being distributed across countless wallet implementations.