ERC-4337

live

ERC-4337 Account Abstraction

by Vitalik Buterin, Yoav Weiss, eth-infinitism· launched 2023-03verified 2026-09-02

At a glance

Layer
custody
Category
primitive
Rails
—
Settlement
—
Reversible
—
Human in loop
—
D2C fit
—
B2B fit
—
Spec
https://eips.ethereum.org/EIPS/eip-4337

An account-abstraction standard that enables programmable smart-contract wallets on Ethereum without consensus-layer changes. It is a supporting custody primitive for agent payments — session keys, spending limits, gas abstraction — not a payment protocol in its own right.

How it works

ERC-4337 brings account abstraction to Ethereum entirely at the application layer, with no changes to the consensus protocol. Instead of an externally-owned account (EOA) signing a native transaction, a user (or agent) expresses intent as a UserOperation pseudo-transaction.

  • Separate mempool. UserOperation objects are broadcast to a dedicated mempool, not the normal transaction pool.
  • Bundlers. A class of actors called bundlers collect UserOperations and package them into a single handleOps call to a singleton EntryPoint contract, which runs a verification loop then an execution loop.
  • Smart accounts. Each account implements validateUserOp, so validation logic is fully programmable — passkeys, multisig, social recovery, session keys, and per-operation spending limits.
  • Paymasters. An optional paymaster (validatePaymasterUserOp) can sponsor gas or let a user pay gas in an ERC-20, and initCode deploys the account on first use.

For this registry, ERC-4337 matters as custody infrastructure: it is how an agent can hold funds and sign payments under tightly-scoped, revocable authority (for example paying an x402 endpoint from a session-keyed smart account) rather than a rail that itself moves value.

Tradeoffs

  • It is account infrastructure, not a payment protocol: value transfer still happens over a separate rail built on top of it.
  • Added complexity and gas overhead versus a plain EOA, and reliance on off-chain bundler and paymaster infrastructure.
  • Accounts must trust a specific singleton EntryPoint contract; trusting the wrong EntryPoint is a risk.
  • The EIP is formally still Standards-Track "Draft" and has shipped in versioned revisions (v0.6, v0.7) whose interfaces differ, so implementations must pin a version.

Security & limitations

  • Custody safety depends on the correctness of each account's validateUserOp logic; a bug there is a direct loss-of-funds risk.
  • Bundler/paymaster griefing and denial vectors are constrained by staking and validation rules (ERC-7562), which implementations must honor.
  • Session keys and delegated spending limits must be scoped and revocable, or a compromised agent can drain within its allowance.

See sources below. Documented for commentary and identification only.

Fits together with

  • x402 — x402 Payment Protocol

Deployments using ERC-4337

No deployments recorded yet.

Sources

  1. [1]ERC-4337: Account Abstraction Using Alt Mempool (specification)— Ethereum Improvement Proposals
  2. [2]eth-infinitism/account-abstraction (reference implementation)— eth-infinitism (GitHub)
  3. [3]ERC-4337 Documentation— erc4337.io