ERC-4337

ERC-4337 is the standard that brings smart accounts to Ethereum *without* a consensus change: user operations flow through a dedicated mempool, bundlers pa

ERC-4337

ERC-4337 is the Ethereum standard that brings smart accounts to Ethereum without any consensus change: user operations flow through a dedicated mempool, bundlers package them, and a global EntryPoint contract validates and executes them. Launching in mainnet deployment in March 2023, it turned "wallets become programmable software" from a research idea into a production specification — and spawned the entire smart-wallet ecosystem. How it works ERC-4337 reuses Ethereum's security model while changing who can initiate a transaction: User operations: instead of an EOA signature over a raw transaction, the user signs a structured user operation — intent, nonce, gas, validation-hook targets — that most wallets publish to a dedicated mempool. Bundlers: permissionless bundlers (anyone, no staking) package compatible operations into one handleOps call on the EntryPoint. EntryPoint validation: the contract verifies each operation's signature/validation logic, enforces paymaster deposits and gas limits, then executes the calls — with strict deposit accounting so nobody owes the network for someone else's operation. Programmable accounts: because the wallet is a contract, it can hold session keys, social recovery, spending limits, and multi-step authorization logic, upgradeable over time. Everything settles as ordinary Ethereum transactions — no hard fork, no new consensus rule, no L1 changes. Uniswap-certifiable neutrality is the design's selling point: the standard is an application-layer contract system. Why it matters for decentralization ERC-4337 upgrades wallet UX without touching consensus — the safest possible path to mass-usable self-custody, and a direct empowerment of the "verify, don't trust" principle: the account logic is contract code anyone can audit, not a proprietary backend. It also moves the decentralization surface to new actors: bundlers, paymasters, and account implementations. The standard is neutral; the operator set is the audit target. Under the four-pillar model, a smart-wallet ecosystem's software pillar looks at implementation diversity (how many entry points/account contracts), and the infrastructure pillar at bundler/paymaster concentration — the same lens our Ethereum and layer-2 audits apply to validators and sequencers. Example: what changed for a real user Before 4337, buying on a dApp meant approving a token, then signing a transaction, and praying the signature UX worked. After, a single smart-wallet flow on Base or Arbitrum can: detect the intent ("buy this NFT"), present one authorization, sponsor gas via a paymaster, and execute with a session key — all in one user operation. Major products using the flow include safe-smart-account integrations, Coinbase's onchain smart wallet, and a growing family of wallet SDKs that route through compliant bundlers. Risks & limitations Overhead: user operations cost more gas than simple EOA transactions — the price of programmability, material at low-value transaction volumes. Young infrastructure: bundler and paymaster best practices are still being hardened; audits evolve along with them. Dependence surfaces: every sponsored flow depends on its paymaster's uptime and policy, and every wallet depends on bundler availability. Recovery quality: social recovery is only as strong as its guardian design — a weak recovery path can be the weakest link in an otherwise excellent account. ERC-4337 went live on Ethereum mainnet on 1 March 2023, and the technical machinery matters to auditors because it defines where the trust surface actually sits. The design is deliberately application-layer: no protocol upgrade was required. EntryPoint v0.6 / v0.7: the current specification, with v0.6 on mainnet and v0.7 under adoption. v0.6 tightened gas-accounting rules; v0.7 adds validation-gas restrictions that prevent certain denial-of-service vectors on bundler simulation. Account implementations: Safe (modular, plugin-friendly), Alchemy Light Account, Avocado, Soul, and Kernel are the leading contract accounts. Their shared property: validation logic is owner-controlled, so recovery, session keys, and multi-sig can be layered on the same base. Native AA on L2s: RIP-7560 and related proposals move account abstraction from application-layer contracts to protocol-level execution on rollups — the L2s where the overhead of the current EntryPoint flow matters most at scale. EOA migration: EIP-7702 (included in Pectra, shipped 2025) lets EOAs temporarily delegate to a smart-account implementation, bridging the "EOA vs smart account" gap without wallet migration. This is the real unlock for mass adoption of programmable accounts. Under the software pillar of the W3D model, implementation diversity (how many independent account contracts, how many entry points) is the quality signal. The erc4337.io dashboard tracks adoption metrics; chain audits track whether those implementations hold up under the operator-set reality. The life of one user operation Tracing a single operation shows how the standard ties together: Construct: the wallet builds a user operation (intent, capped gas, paymaster reference, aggregator reference if used) and signs it. Publish: the wallet sends it to the user-op mempool via any bundler RPC; multiple bundlers typically see it. Bundle: a bundler selects compatible ops, simulates each, and wraps the set in one handleOps transaction to the EntryPoint. Validate: the EntryPoint calls each account's validateUserOp (signature, nonce, policy), then each paymaster's validatePaymasterUserOp, and charges deposits in a strict order that prevents freeloading. Execute: the EntryPoint runs each call via the account's execute, then calls postOp to reconcile paymaster refunds — bundle ends, refunds settle, funds never cross bundles. Auditors like the standard because the accounting is explicit: deposits, refunds, and validation are all on the EntryPoint contract, queryable for every bundle ever submitted. That transparency — the same spirit the W3D methodology applies to chain metrics — is what makes ERC-4337 boringly, beautifully auditable. The compatibility story also keeps the standard future-proof: because validators never re-ordered consensus, unsig rules stay ecosystem-owned, so every L2 — from Base to Arbitrum — can adopt the same smart-account ecosystem with zero layer-specific code, a property that markedly simplifies cross-chain wallet UX. Frequently asked questions Do I need to migrate my wallet to benefit? No. EOAs keep working forever. Smart accounts are opt-in upgrades, and migration tooling from EOA to smart account is already available in several wallets. Is ERC-4337 "real" account abstraction? It is the standardized, consensus-free version — application-layer account abstraction. Full protocol-level abstraction (RIP-7560-style) may arrive on layer 2s years from now, without invalidating 4337 wallets. What breaks if bundlers centralize? Censorship and fee extraction at the inclusion layer: funds stay safe, access degrades. It is the same risk shape as mining-pool centralization, with new actors. Sources & methodology ERC-4337 spec — formal EntryPoint and user-operation interfaces. erc4337.io — live stats on accounts, bundlers, and paymasters. W3D methodology + academy dataset. Related terms Account abstraction · Bundler · Paymaster · Session keys · Wallet Chain audits: Base · Arbitrum · tool: Address checker

ERC-4337 is the Ethereum standard that brings smart accounts to Ethereum without any consensus change: user operations flow through a dedicated mempool, bundlers package them, and a global EntryPoint contract validates and executes them. Launching in mainnet deployment in March 2023, it turned “wallets become programmable software” from a research idea into a production specification — and spawned the entire smart-wallet ecosystem.

How it works

ERC-4337 reuses Ethereum’s security model while changing who can initiate a transaction:

  • User operations: instead of an EOA signature over a raw transaction, the user signs a structured user operation — intent, nonce, gas, validation-hook targets — that most wallets publish to a dedicated mempool.
  • Bundlers: permissionless bundlers (anyone, no staking) package compatible operations into one handleOps call on the EntryPoint.
  • EntryPoint validation: the contract verifies each operation’s signature/validation logic, enforces paymaster deposits and gas limits, then executes the calls — with strict deposit accounting so nobody owes the network for someone else’s operation.
  • Programmable accounts: because the wallet is a contract, it can hold session keys, social recovery, spending limits, and multi-step authorization logic, upgradeable over time.

Everything settles as ordinary Ethereum transactions — no hard fork, no new consensus rule, no L1 changes. Uniswap-certifiable neutrality is the design’s selling point: the standard is an application-layer contract system.

Why it matters for decentralization

ERC-4337 upgrades wallet UX without touching consensus — the safest possible path to mass-usable self-custody, and a direct empowerment of the “verify, don’t trust” principle: the account logic is contract code anyone can audit, not a proprietary backend. It also moves the decentralization surface to new actors: bundlers, paymasters, and account implementations. The standard is neutral; the operator set is the audit target. Under the four-pillar model, a smart-wallet ecosystem’s software pillar looks at implementation diversity (how many entry points/account contracts), and the infrastructure pillar at bundler/paymaster concentration — the same lens our Ethereum and layer-2 audits apply to validators and sequencers.

Example: what changed for a real user

Before 4337, buying on a dApp meant approving a token, then signing a transaction, and praying the signature UX worked. After, a single smart-wallet flow on Base or Arbitrum can: detect the intent (“buy this NFT”), present one authorization, sponsor gas via a paymaster, and execute with a session key — all in one user operation. Major products using the flow include safe-smart-account integrations, Coinbase’s onchain smart wallet, and a growing family of wallet SDKs that route through compliant bundlers.

Risks & limitations

  • Overhead: user operations cost more gas than simple EOA transactions — the price of programmability, material at low-value transaction volumes.
  • Young infrastructure: bundler and paymaster best practices are still being hardened; audits evolve along with them.
  • Dependence surfaces: every sponsored flow depends on its paymaster’s uptime and policy, and every wallet depends on bundler availability.
  • Recovery quality: social recovery is only as strong as its guardian design — a weak recovery path can be the weakest link in an otherwise excellent account.

ERC-4337 went live on Ethereum mainnet on 1 March 2023, and the technical machinery matters to auditors because it defines where the trust surface actually sits. The design is deliberately application-layer: no protocol upgrade was required.

  • EntryPoint v0.6 / v0.7: the current specification, with v0.6 on mainnet and v0.7 under adoption. v0.6 tightened gas-accounting rules; v0.7 adds validation-gas restrictions that prevent certain denial-of-service vectors on bundler simulation.
  • Account implementations: Safe (modular, plugin-friendly), Alchemy Light Account, Avocado, Soul, and Kernel are the leading contract accounts. Their shared property: validation logic is owner-controlled, so recovery, session keys, and multi-sig can be layered on the same base.
  • Native AA on L2s: RIP-7560 and related proposals move account abstraction from application-layer contracts to protocol-level execution on rollups — the L2s where the overhead of the current EntryPoint flow matters most at scale.
  • EOA migration: EIP-7702 (included in Pectra, shipped 2025) lets EOAs temporarily delegate to a smart-account implementation, bridging the “EOA vs smart account” gap without wallet migration. This is the real unlock for mass adoption of programmable accounts.

Under the software pillar of the W3D model, implementation diversity (how many independent account contracts, how many entry points) is the quality signal. The erc4337.io dashboard tracks adoption metrics; chain audits track whether those implementations hold up under the operator-set reality.

The life of one user operation

Tracing a single operation shows how the standard ties together:

  1. Construct: the wallet builds a user operation (intent, capped gas, paymaster reference, aggregator reference if used) and signs it.
  2. Publish: the wallet sends it to the user-op mempool via any bundler RPC; multiple bundlers typically see it.
  3. Bundle: a bundler selects compatible ops, simulates each, and wraps the set in one handleOps transaction to the EntryPoint.
  4. Validate: the EntryPoint calls each account’s validateUserOp (signature, nonce, policy), then each paymaster’s validatePaymasterUserOp, and charges deposits in a strict order that prevents freeloading.
  5. Execute: the EntryPoint runs each call via the account’s execute, then calls postOp to reconcile paymaster refunds — bundle ends, refunds settle, funds never cross bundles.

Auditors like the standard because the accounting is explicit: deposits, refunds, and validation are all on the EntryPoint contract, queryable for every bundle ever submitted. That transparency — the same spirit the W3D methodology applies to chain metrics — is what makes ERC-4337 boringly, beautifully auditable.

The compatibility story also keeps the standard future-proof: because validators never re-ordered consensus, unsig rules stay ecosystem-owned, so every L2 — from Base to Arbitrum — can adopt the same smart-account ecosystem with zero layer-specific code, a property that markedly simplifies cross-chain wallet UX.

Frequently asked questions

Do I need to migrate my wallet to benefit?

No. EOAs keep working forever. Smart accounts are opt-in upgrades, and migration tooling from EOA to smart account is already available in several wallets.

Is ERC-4337 “real” account abstraction?

It is the standardized, consensus-free version — application-layer account abstraction. Full protocol-level abstraction (RIP-7560-style) may arrive on layer 2s years from now, without invalidating 4337 wallets.

What breaks if bundlers centralize?

Censorship and fee extraction at the inclusion layer: funds stay safe, access degrades. It is the same risk shape as mining-pool centralization, with new actors.

Sources & methodology

Account abstraction · Bundler · Paymaster · Session keys · Wallet

Chain audits: Base · Arbitrum · tool: Address checker

Browse all glossary terms · Start a free course