How an ERC-4337 UserOperation gets executed step by step

05 September 2026

You sign a message in your smart wallet. That message is not a transaction. It is a UserOperation, the native unit of ERC-4337. The interface asks for a target contract, calldata, a gas limit, and a signature. You approve. The wallet constructs a structured object. It goes nowhere until a bundler picks it up.

Bundlers maintain a mempool of UserOperations. Not the public txpool. Their own. They check for duplicates. They check for expired timestamps. They run a simulation. Simulation calls your wallet's validateUserOp function. If it reverts, the op is rejected.

Errors here: AA20-not-owner if the signer doesn't match the wallet owner. AA22-wallet-during-constructor if the wallet hasn't finished deploying. AA24-signature-error if the cryptographic check fails. A bundler throws these out. No gas wasted yet.

The bundler next performs a gas estimation. It calls simulateValidation on the EntryPoint contract, running the full validation phase without state changes. The EntryPoint checks that your wallet pays the prefund. Prefund is verificationGasLimit * maxPriorityFeePerGas. If the wallet's deposit in the EntryPoint is too low, the simulation returns AA31-insufficient-prefund. The bundler drops the op.

If the simulation passes, the bundler includes the op in a bundle. It wraps multiple UserOperations into a single call to handleOps on the EntryPoint, submitted as a normal Ethereum transaction. The EntryPoint becomes the caller.

Inside handleOps, the EntryPoint processes each op sequentially. First: validation. It calls validateUserOp on your wallet again, this time for real. The wallet must return a validation data word. Bits 0-1 define the authorizer: 0 for the wallet itself, 1 for a trusted entity. Bits 2-245 hold a valid-after timestamp. Bits 246-255 hold a valid-until timestamp. Revert here means AA21-did-not-payback or AA23-reverted.

Validation passes. The EntryPoint deducts the prefund from your wallet's deposit. If the deposit runs dry mid-bundle, the EntryPoint reverts the entire bundle. Bundlers hate this. They run their own checks beforehand.

Second: execution. The EntryPoint calls executeUserOp on your wallet with the target and calldata you signed. Your wallet executes the intended action - swap, mint, transfer. The wallet can use its own stored ether. It can also pull ether from the EntryPoint deposit if paymasterData includes a paymaster address.

Execution errors come back as AA32-during-execution-reverted. The EntryPoint catches these. It does not revert the bundle. It marks the op as failed. Other ops in the bundle proceed. The bundler still pays gas for the failed op and recovers nothing from the user. This is why bundlers simulate aggressively.

After all ops in the bundle execute, the EntryPoint settles. It calculates actual gas used per op, refunds unused prefund to the wallet, and pays the bundler: (actualGasUsed + postOpGas) * maxPriorityFeePerGas. The bundler gets its fee. The EntryPoint emits a UserOperationEvent with the op hash, sender, paymaster (if any), and gas values.

Settlement can fail in one edge case: the wallet's postOp function reverts. This happens if the wallet tries to pull funds from a paymaster that lacks balance. Error: AA33-failed-postOp. The EntryPoint still refunds the wallet and pays the bundler. The wallet is left in an intermediate state.

The bundler's transaction confirms. The op is final. Your wallet's state changed. The EntryPoint ledger updated. The user paid gas in tokens the wallet held, not in ETH from an EOA. That is the point.

What can go wrong at each stage:

ERC-4337 is not magic. It replaces the EOA nonce and gas mechanism with a contract-level one. Each step exists because someone had to pay, validate, or revert. The EntryPoint is the honest accountant. The bundler is the risk taker. The user is the one who signed first.

Back to smart wallets