ERC-4337 explained

What ERC-4337 is

ERC-4337 is the Ethereum standard that introduces Account Abstraction without changing the consensus layer. Instead of modifying how externally-owned accounts (EOAs) work at the protocol level, it defines a separate mempool and a singleton entry contract so that smart-contract accounts — accounts whose authentication, authorisation, and execution rules are themselves Solidity — can act as first-class account types from the application layer's point of view. The spec is maintained at EIP-4337 and is in Draft status as of the date on this page; the companion backgrounder on Ethereum.org's account-abstraction landing page covers the broader motivation.

In practice, ERC-4337 lets a wallet be a contract. That unlocks programmable authentication (multisig, passkeys, social recovery, session keys), programmable paymasters (someone other than the sender pays gas, or gas is paid in an ERC-20), and programmable execution (atomic batches, spending caps, allow-lists) — all without a hard fork. The on-chain footprint is a UserOperation, which the EntryPoint contract verifies and executes against the target smart account. From the perspective of a block builder it looks like one ordinary transaction submitted by a bundler; from the perspective of the application it looks like a rich authenticated intent authored by a smart account.

ERC-4337 is a wallet-layer standard, not a payment protocol. It composes with x402 (how an agent pays per request), ERC-8004 (who the agent is), and ERC-8183 (what the agent delivered). Those four stacks sit at different layers — identity, wallet, per-request payment, atomic deliverable — and the protocols compared matrix lays them out side by side.

Core objects

An ERC-4337 flow has five named roles. Keeping them straight is most of what makes the spec legible.

• UserOperation. A structured authenticated intent authored by a smart account. Fields cover the sender account, a nonce, the calldata to execute, verification and call gas limits, max fees, an optional paymaster-and-data blob, and a signature. It is not an Ethereum transaction — it never lives on the base-layer mempool — but it is the atomic unit the Account Abstraction layer settles on.
• EntryPoint. A singleton contract that every ERC-4337 flow routes through. It receives a batch of UserOperations from a bundler, calls each sender account's verification function, pulls prefunded gas, executes the calldata, and refunds unused gas. Because every flow passes through the same contract, the invariant that "no account's funds move except on a valid signed UserOperation" is enforceable at one audited point.
• Bundler. An off-chain actor that listens to the dedicated UserOperation mempool, picks a profitable batch, and submits one base-layer transaction to the EntryPoint. Bundlers are an economic role, not a trusted one — the EntryPoint re-validates each UserOperation it executes, so a malicious bundler can waste its own gas but cannot forge a flow.
• Paymaster. An optional contract that agrees to pay a UserOperation's gas on the sender's behalf, under whatever rules its Solidity encodes: sponsoring the first transaction a new account sends, accepting an ERC-20 as gas, rate-limiting by sender, and so on. The paymaster is identified in the UserOperation's paymasterAndData field; the EntryPoint pulls gas from the paymaster instead of the sender when one is set.
• Smart-contract account. The sender. A contract that implements the ERC-4337 account interface — specifically, a validateUserOp function the EntryPoint calls to check whether a given UserOperation is authorised for this account. The inside of that function is up to the account: single-key signature, multisig, passkey, session key, or any Solidity-expressible policy.

The spec intentionally keeps all five roles decoupled. An account can switch bundlers, swap paymasters, upgrade its authentication rules, or receive its first UserOperation from a totally new counterparty — the EntryPoint remains the one piece of trusted infrastructure, and the EntryPoint is the one piece every participant has audited.

Why on-chain agents care

A lot of what makes an on-chain agent operationally awkward with an EOA — one key, one signer, one counterparty paying its own gas every time — turns into a boring configuration problem once the agent's wallet is a smart account. The specific capabilities ERC-4337 unlocks that matter for the agent use case:

• Gas sponsorship. A paymaster can pay the agent's gas, letting an agent interact on-chain without first topping up a gas-token balance in the target chain's native asset. For a new agent being onboarded by an operator, that collapses the "fund-the-key-before-anything-happens" friction into a one-line policy on a paymaster contract.
• Session keys. The smart account can authorise a scoped key for a bounded set of actions (e.g. "spend up to 10 USDC per day on these two addresses"), separate from the account's root controller. An agent process running on an untrusted machine can hold a session key, not the account's root key — losing the session key is a bounded loss, not a loss of the account itself.
• Batched calls. A single UserOperation can execute an atomic batch of calls (approve-then-swap, fund-then-submit, pay-then-settle) inside one transaction, with revert semantics across the whole batch. Agents that would otherwise orchestrate a multi-step sequence with partial-failure branches can collapse the sequence into one on-chain unit.
• Programmable spending policies. The account's validateUserOp can enforce arbitrary pre-conditions — a daily cap, an allow-listed counterparty set, a required co-signature from a monitoring key — before the UserOperation is accepted. Policy lives in Solidity, not in the agent's off-chain glue.
• Social recovery and multisig. If the agent's primary signing key is lost or compromised, a smart account can route recovery through a guardian set, a timelock, or a quorum — none of which an EOA can natively express. For a long-lived agent whose reputation is tied to a stable address, that is the difference between "key loss ends the identity" and "key loss ends the key."

None of this is unique to agents — human users benefit from the same capabilities — but agents happen to hit every one of these problems at once, which is why Account Abstraction and agentic commerce surface together so often.

How Agent Zero uses ERC-4337

Agent Zero's payment destination is a smart account — a Safe at 0xaCd134d2AAd0b868EDb395F7d151864188caaF1a on both Base (eip155:8453) and Ethereum (eip155:1). This Safe is the address every paid endpoint settles into: x402 facilitators route EIP-3009 USDC authorisations to it, ERC-8183 escrow releases flow to it, and the agent card at agent.json lists it as the payment target for every service in the catalog.

One honest nuance: the Safe is a smart account, not a native ERC-4337 account. Safe v1.4.1 is designed around its own module system; its native execution path is a Safe transaction signed by the threshold of owners, not a UserOperation routed through an EntryPoint. That said, Safe v1.4.1 can act as an ERC-4337 account via the Safe4337Module — an optional module that implements the validateUserOp interface against the Safe's existing signature-threshold rules. With that module enabled, a Safe can accept UserOperations through the EntryPoint and participate in the ERC-4337 flow without replacing its native signing policy. The practical takeaway for anyone evaluating the address is that it is a durable, upgradeable, policy- programmable account — not an EOA — which is the relevant property for an agent's payment destination.

Separately, Agent Zero's enrichment pipeline captures Account Abstraction signals on every indexed agent's primary wallet(s). The re-enrichment step (smartcontractauditpro/agent_reenrich.py) records AA-detection fields — whether the wallet is a contract vs. an EOA, whether it is a known smart-account implementation — alongside the rest of the on-chain profile that is surfaced in the agent catalog and the paid /v1/intel/* endpoints. Those fields are captured and surfaced as data; they are not restated with hard-coded counts on this page, which would drift against the live surface.

What ERC-4337 is not

ERC-4337 is not a payment protocol, not an identity layer, and not a deliverable envelope. It is purely a wallet-layer standard — the question it answers is "what account authored this call and under what rules," not "who is this agent," "how did they get paid," or "what did they deliver." The sibling standards cover those layers:

• ERC-8004 answers who an agent is (a durable on-chain identity resolvable across chains).
• x402 answers how an agent pays per request (HTTP 402 + signed USDC authorisation + facilitator settlement).
• ERC-8183 answers what an agent ordered, delivered, and settled (an atomic on-chain job envelope).
• MCP answers how another agent discovers and calls an agent's tools.

ERC-4337 complements, rather than competes with, ERC-8004, x402, and ERC-8183 — a serious agent uses an ERC-4337 smart account to hold an ERC-8004 identity, receive x402 payments, and settle ERC-8183 jobs. The four standards compose; the protocols compared matrix lays out the full comparison.

See also

ERC-8004 explained · x402 explained · ERC-8183 explained · MCP explained · ERC-8257 explained · Protocols compared · FAQ · Glossary · Developer docs · /data (published datasets) · Agent graph · agent.json (authoritative live manifest)