# ERC-4337 Account Abstraction

> 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.

## At a glance

| Field | Value |
| --- | --- |
| Name | ERC-4337 |
| Layer | wallet-custody |
| Category | primitive |
| Status | live |
| Created by | Vitalik Buterin, Yoav Weiss, eth-infinitism |
| Launched | 2023-03 |
| Rails | — |
| Settlement | — |
| Reversible | — |
| Human in loop | — |
| D2C fit | — |
| B2B fit | — |
| Spec | https://eips.ethereum.org/EIPS/eip-4337 |
| Last verified | 2026-09-02 |

## 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 `UserOperation`s 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.

## Fits together with

- x402

## Sources

1. [ERC-4337: Account Abstraction Using Alt Mempool (specification)](https://eips.ethereum.org/EIPS/eip-4337) — Ethereum Improvement Proposals
2. [eth-infinitism/account-abstraction (reference implementation)](https://github.com/eth-infinitism/account-abstraction) — eth-infinitism (GitHub)
3. [ERC-4337 Documentation](https://docs.erc4337.io/) — erc4337.io

---
_Source: payful.ai — independent editorial reference. Verified 2026-09-02._