What is account abstraction (ERC-4337)? · Jumpstart Blockchain
What is account abstraction (ERC-4337)?
ERC-4337 makes user accounts smart contracts via UserOperations, bundlers, an EntryPoint and paymasters, enabling batching, gas sponsorship and recovery. EIP-7702 lets existing EOAs delegate to such code.
Account abstraction means a user's account is a smart contract that decides for itself what counts as a valid transaction, instead of an externally owned account (EOA) whose only rule is "signed by this one private key". ERC-4337 is the standard that makes this work on Ethereum and EVM chains like Base without changing the protocol: it builds a separate transaction flow on top of existing contracts and infrastructure.
Why EOAs are limiting
An EOA is a key pair. That gives you exactly one authorization rule and a handful of hard limits:
Lose the key and the account is gone; leak it and everything is gone.
Every transaction needs the account to hold the native token for gas.
One signature scheme (secp256k1), so no passkeys, multisig or spending limits at the account level.
One call per transaction, so "approve then swap" is two transactions and two prompts.
A smart contract account can implement any of these rules in code: social recovery, multisig, session keys with limits, passkey signatures, batched calls, and gas paid by someone else.
How ERC-4337 works
Instead of sending a transaction, the user signs a UserOperation: a struct describing what the account should do and how much gas it may use. The pieces:
Component
Role
Smart account
The user's contract. Implements validateUserOp to check the signature and nonce, then executes the calls.
UserOperation
The signed intent: sender, nonce, callData, gas limits and fees, optional factory and paymaster data, signature.
Bundler
An off-chain service with its own mempool of UserOperations. It simulates them, packs several into one real transaction, and pays the gas up front.
EntryPoint
A singleton contract, deployed at the same address on each chain per version. It calls validation on each account, executes the operations, and reimburses the bundler.
Paymaster
Optional contract that agrees to pay gas for an operation, for example an app sponsoring its users, or accepting ERC-20 tokens instead of ETH.
Factory
Deploys the account on its first operation, so users get a counterfactual address before anything is on-chain.
The flow: wallet builds and signs a UserOperation, sends it to a bundler with eth_sendUserOperation, the bundler calls EntryPoint.handleOps, and the EntryPoint runs validation for each operation (account, then paymaster) and then execution.
The account's side of this in EntryPoint v0.7 looks like:
validationData of 0 means valid, 1 means signature failure, and other values pack a time window (validAfter/validUntil) plus an optional aggregator address. The account must only accept calls to validateUserOp from the EntryPoint, and must pay missingAccountFunds to it when no paymaster covers gas.
Why validation is restricted
A bundler pays gas for everything it includes. If an operation passes simulation but fails validation on-chain, the bundler eats the cost. To keep that from being a cheap attack, validation code must follow the rules in ERC-7562: no banned opcodes like TIMESTAMP or BLOCKHASH whose values can change between simulation and inclusion, and restricted access to storage outside the account's own. This is why you can't write arbitrary logic in validateUserOp, and why paymasters that access shared state must stake with the EntryPoint.
Using it from an app
You rarely write the account contract yourself. Use an audited implementation and a library that speaks the bundler RPC. With viem:
Two calls, one signature, one on-chain transaction. account.address is known before the account is deployed; fund it (or configure a paymaster) and the first operation deploys it. The bundler URL comes from your infrastructure provider; many offer bundler and paymaster endpoints for Base and other chains. Keep the owner key in a secure signer, not in source code.
Where EIP-7702 fits
ERC-4337 accounts are new contract addresses, so existing EOA users have to move their assets. EIP-7702, activated on Ethereum mainnet in the Pectra upgrade, takes a different route: an EOA signs an authorization that sets its code to a delegation pointing at an existing contract. After that, calls to the EOA run that contract's code, while the address and assets stay the same. It's set with a new transaction type, and it persists until the EOA signs a new delegation (or clears it).
The two are complementary. A 7702-delegated EOA can run a 4337-compatible smart account implementation and use bundlers and paymasters, and newer EntryPoint versions support this directly. L2s adopt such changes on their own schedules, so check your chain's docs; OP Stack chains including Base have added 7702 support.
Key difference: with 7702 the original private key still has full control. It can't be rotated away the way a smart account's signer can, so 7702 improves UX but doesn't remove the single-key risk.
Security notes
Delegating an EOA (7702) or installing a module means trusting that code with the whole account. Treat any site asking you to sign a delegation to an unknown contract as phishing.
tx.origin == msg.sender no longer proves "no code at this address"; don't use it as an EOA check.
Pin which EntryPoint version your account supports, and use audited account and paymaster contracts.
Summary
ERC-4337 makes accounts contracts, via UserOperations, bundlers, a singleton EntryPoint and optional paymasters.
Validation runs under ERC-7562 rules so bundlers can't be griefed.
You get batching, gas sponsorship, custom signatures and recovery without protocol changes.
EIP-7702 lets existing EOAs delegate to smart account code; it complements 4337 but keeps the original key all-powerful.
