A standard Ethereum account starts a transaction when one private key signs it. That account also needs ether to pay the network fee. A lost private key has no reset step in the base protocol.
A wallet whose rules live in a contract still needed some other key to submit each transaction. ERC-4337 adds a second path and leaves the normal transaction type in place. The user sends a UserOperation into a separate mempool. A bundler packs those objects into one call to EntryPoint.handleOps.
That path is account abstraction. The account code accepts or rejects the signature, and the block still contains an ordinary transaction from the bundler.
What problem does account abstraction solve?
One private key can move every asset in an externally owned account. The protocol has no step that replaces that key after it is lost. Ethereum itself decides whether the signature is valid.
The account abstraction page on ethereum.org states the practical result. A lost key stays lost. A USDC balance cannot pay the fee, because the fee is denominated in ether. An approval and a later swap are two separate transactions.
ERC-4337 makes a smart contract account the sender. The account’s validateUserOp function checks the signature. The ERC-4337 motivation text says that check can use another signature scheme, a multisig setup, or custom recovery.
A multisig wallet already asks for several keys. Under ERC-4337, the account that holds the assets runs that check. A 2-of-3 account can ignore a UserOperation until two of three keys sign the userOpHash.
Custom recovery means the deployed code can accept a replacement signer named in advance.
EIP-7702 changes the key-controlled account itself. Transaction type 0x04 writes a delegation indicator into the account code. The indicator is the bytes 0xef0100 plus a contract address. The Pectra upgrade activated this on Ethereum mainnet at epoch 364032, on May 7, 2025, at 10:05 UTC.
The EIP’s motivation includes sub-keys with narrower rights. One example is a key that may spend an ERC-20 token and may not spend ether.
The account code can require a second condition before the assets move.
What actually happens when a UserOperation is submitted?
The user submits a UserOperation to a separate mempool, and a bundler later places it inside a normal transaction. The struct carries the sender, a nonce, callData, gas limits, fee caps, and a signature. The account defines what that signature means.
A bundler simulates the operation before keeping it, and ERC-4337 tells the bundler to reject an operation whose validation fails. The bundler then sends one transaction that calls EntryPoint.handleOps with the packed operations and a beneficiary address.
handleOps runs a verification loop and then an execution loop. Verification calls validateUserOp on the sender, and ERC-4337 requires the account to accept that call from a trusted EntryPoint.
The userOpHash covers the operation without the signature. It also covers the EntryPoint address and the chain id. If validateUserOp fails, handleOps skips at least that operation. It can also revert the whole bundle.
The execution loop runs the account’s callData, and the beneficiary receives the gas fees from the bundle.
A first-time account can name a factory, and EntryPoint asks that factory to deploy the sender before validation. For an EIP-7702 account, the factory field is the flag 0x7702.
Ethereum.org states that the EntryPoint contract was deployed to Ethereum mainnet on March 1, 2023.
The UserOperation settles after a bundler includes it and the account’s check passes.
Where the money, risk, and data move
Assets stay in the smart contract account, and gas comes from a deposit held at EntryPoint. That deposit is ether, or the native coin on a layer 2, posted by the account or by a paymaster.
With no paymaster, validateUserOp pays EntryPoint at least missingAccountFunds. The sender can deposit extra and later call withdrawTo to take the unused part back.
A paymaster changes who funds the deposit. EntryPoint calls validateUserOp with missingAccountFunds set to 0, then checks that the paymaster deposit can cover the operation. It next calls validatePaymasterUserOp. If that function returns a non-empty context, EntryPoint calls postOp after execution.
A developer can subsidize the fee from that deposit. A user can pay the paymaster in an ERC-20 token while the deposit pays the chain in ether.
A wallet that holds USDC and no ether can name a paymaster on the UserOperation. The paymaster contract collects the USDC under its own rules, and its EntryPoint deposit pays the beneficiary.
The UserOperation carries the signature, the callData, and any paymaster address. The gas deposit sits at EntryPoint until the beneficiary is paid. The USDC moves when the account’s callData or the paymaster’s postOp transfers it.
Validation risk sits in the account code, which can accept a signature the owner did not intend. A paymaster can reject the operation, and a short deposit fails EntryPoint’s balance check.
ERC-4337 points a bundler that is separate from the block builder toward mev-boost or another proposer-builder path. That bundler chooses which UserOperations to include. A signature in the mempool has not moved the USDC yet.
What it costs and where it leaks
Every UserOperation sets callGasLimit for the action and verificationGasLimit for the account check. preVerificationGas covers bundler overhead, and a paymaster adds paymasterVerificationGasLimit plus paymasterPostOpGasLimit. Each operation pays its own verification gas inside the shared handleOps transaction.
ERC-7562 limits how many operations a bundler keeps. The constant SAME_SENDER_MEMPOOL_COUNT is 4. A bundler that follows the rule holds at most four pending UserOperations from one sender.
An EIP-7702 authorization has a separate gas schedule. Each authorization adds 25,000 gas, the constant PER_EMPTY_ACCOUNT_COST. If the authority account already has code, a nonzero nonce, or a balance, the protocol refunds 12,500 gas. The refund is PER_EMPTY_ACCOUNT_COST minus PER_AUTH_BASE_COST.
A paymaster that takes USDC still spends ether from its deposit. The paymaster contract sets any markup above the network fee. The sender can submit with an empty ether balance when that deposit covers the fee. The chain still collects the fee in the native coin.
What can break or delay the process
A UserOperation can expire, fail its check, or wait if no bundler includes it. validAfter and validUntil are 6-byte values packed into the validateUserOp result. A bundler drops a UserOperation that expires too soon to reach the next block.
On a signature mismatch, ERC-4337 specifies a return value of 1, named SIG_VALIDATION_FAILED, without a revert. Any other validation error must revert, and a revert drops at least that operation from execution.
ERC-4337 requires every paymaster to accept validatePaymasterUserOp and postOp only from EntryPoint. A deposit that cannot cover the operation fails before inclusion.
ERC-7562 runs a second validation before the bundle is submitted, because account state can change after the first simulation. A UserOperation that passed once can fail that second check, and the bundler then removes it.
EIP-7702 writes the delegation indicator before the rest of the transaction executes. The indicator remains if later execution reverts. A failed transaction can leave the account pointing at the delegated contract.
The ethereum.org account page says users still sign with private keys. It also says backup keys can be added to a wallet. A lost seed phrase without those backup keys leaves the assets inaccessible.
A bug in the account smart contract can approve a call the owner did not want. A key-only non-custodial wallet cannot replace a lost seed phrase, because protocol rules name no backup signer.
The UserOperation waits until a bundler includes it and the second check still passes.
