Account Abstraction — ERC-4337 and Native AA

The overview framed this part as the frontier — the places where Ethereum is still deciding what it wants to be. This page tackles the oldest of those open questions, and it starts from something we already proved earlier in the book. Back in Two Kinds of Account we learned the single rule that splits every entry in the state map into two camps: an account is a contract if and only if it has code, and only a codeless account — an externally-owned account, or EOA — can originate a transaction. That rule is elegant. It is also, on reflection, a wart: the one kind of account users actually hold is the one kind that cannot be programmed.

Account abstraction is the long project of removing that wart — of letting a normal user’s account be a program, so it can define its own rules for who may spend it, how, and who pays. This page explains why the split hurts, how ERC-4337 delivers account abstraction without changing the protocol, and how proposed native abstraction (notably EIP-7702) aims to fold the idea into the base layer. Throughout, keep the book’s throughline in view: untrusting strangers agree on the state of a shared computer, and every new layer we add is a new place that agreement — and its cost — can leak.

The problem: your account is not programmable

An EOA is hardwired in four ways, and each is a limitation you cannot code around, because there is no code in an EOA to change:

• One signature scheme, forever. An EOA is controlled by exactly one ECDSA secp256k1 key. Lose that key and the account is gone; there is no “reset,” no backup signer, no way to say “require two of my three keys.” The account’s authorisation rule is frozen into the protocol.
• It must hold ETH to move. Every transaction pays gas in ether, from the sending account. A brand-new user whose wallet holds only a stablecoin literally cannot transact — they must first acquire ETH from somewhere else to pay for the privilege of spending their own tokens. The gas token and the account are welded together.
• No batching. “Approve this token, then swap it” is two separate signed transactions, each with its own nonce, each independently reversible. An EOA cannot say “do these two things atomically, or neither.” Every multi-step action is a sequence of all-or-nothing steps that are individually all-or-nothing but not jointly so.
• No custom rules. You cannot tell an EOA “never send more than 1 ETH per day,” or “let this game key sign for the next hour but nothing else,” or “if I don’t move for a year, let my recovery contacts take over.” There is nowhere to put the rule.

The root cause is exactly the rule from Two Kinds of Account: validity, gas payment, and signature checking for an EOA are done by the protocol, using logic baked into every client. A contract account, by contrast, could express any of these rules in its code — but a contract cannot originate a transaction. So the account that can be programmed can’t start anything, and the account that can start things can’t be programmed. Account abstraction is the word for closing that gap: making the account itself the thing that decides what “valid” means.

   Today                                 The goal
   ─────                                 ────────
   EOA  ── can start a tx ──►  but       Smart account ── can start a tx ──►  AND
        ── one ECDSA key                              ── any signature rule
        ── must pay gas in ETH                        ── someone else can pay gas
        ── no batching, no rules                      ── batches, limits, recovery

   Contract ── programmable ──►  but
            ── CANNOT start a tx

ERC-4337: account abstraction without a fork

The obvious way to fix this is to change the protocol so that any account can carry validation code. That is a consensus change — every client must upgrade, every node must agree, and getting such a change through Ethereum’s process (see The EIP Process) takes years. ERC-4337, finalised and deployed to mainnet in March 2023, took a different route: it delivers account abstraction entirely in the application layer, using only tools the EVM already has. No hard fork, no new opcode required. It does this by building a second, parallel transaction system that lives above the protocol.

The core move is to stop thinking of the user’s action as a transaction and start thinking of it as a UserOperation — a struct describing “here is what I want to do, and here is how to validate that I’m allowed to.” The pieces:

• UserOperation — a pseudo-transaction. It names the smart-account sender, the calldata to execute, gas parameters, a signature (in whatever scheme the account understands), and optional fields for paying gas in other ways. Critically, its “signature” is opaque to the protocol; only the account’s own code knows how to check it.
• A separate mempool. UserOperations do not go into the normal transaction mempool. They are gossiped in a dedicated alt-mempool among nodes that opt into ERC-4337.
• Bundlers. A bundler is an actor (often itself running an EOA) that collects UserOperations from the alt-mempool, wraps a batch of them into one real Ethereum transaction, and submits it — paying the base-layer gas up front and getting reimbursed from the operations it includes. The bundler is the bridge between the abstract world and the concrete one: it is the EOA that finally “originates the transaction” on everyone’s behalf.
• The EntryPoint. A single, audited singleton contract deployed at a well-known address. The bundler’s transaction calls EntryPoint.handleOps(...). For each UserOperation, the EntryPoint first calls the account’s validateUserOp (a validation step that must not touch outside state, so bundlers can safely simulate it) and, only if that passes, calls the account’s execution logic. The EntryPoint is the trusted referee that guarantees “validate first, execute second, and pay the bundler exactly what was used.”
• Paymasters. An optional contract that agrees to sponsor gas for a UserOperation. A Paymaster can let a user pay in a token (it takes USDC, it fronts the ETH), or pay nothing at all (a dApp sponsors its users’ onboarding). This is what finally unwelds the gas token from the account.

   user's wallet          alt-mempool           bundler (an EOA)        base layer
   ─────────────          ───────────           ────────────────        ──────────
   build a          gossip   ┌────────────┐   pick a batch,      one real tx:
   UserOperation ─────────►  │ UserOp UserOp│ ─── wrap into ────►  EntryPoint.handleOps
   (sign in ANY             │ UserOp ...   │   one tx, pay gas         │
    scheme)                 └────────────┘                            ▼
                                              for each op:  validateUserOp → execute
                                                                       │
                                              (Paymaster may reimburse / sponsor gas)

The elegance is that the account is just a contract — a “smart account” — and its validateUserOp method is where all the freedom lives. Want multisig? Check several signatures there. Want a passkey? Verify a WebAuthn/secp256r1 signature there. Want a daily limit? Read and update a storage counter there. The protocol never had to learn any of these rules; the account teaches them to the EntryPoint at validation time.

Under the hood — why validation must be sandboxed

There is a subtle reason ERC-4337 needs a whole rulebook around what validateUserOp may do. A bundler pays real ETH to submit handleOps. If, after paying, one operation’s validation fails on-chain, the bundler eats the cost. So bundlers simulate each UserOperation off-chain before including it, and only bundle ones that pass. But a simulation is only trustworthy if its result can’t change between simulation and inclusion.

That is why ERC-4337 forbids validation code from reading state that another operation could mutate in the same bundle — no reading arbitrary global storage, no TIMESTAMP games, tightly scoped storage access. The rule is a denial-of-service defence: without it, an attacker could flood the alt-mempool with operations that simulate as valid but revert on-chain, making bundlers waste gas and grind to a halt. The sandbox is the price of letting untrusting bundlers safely front money for strangers’ operations — the throughline again, at the infrastructure layer.

By the numbers — what a Paymaster-sponsored op costs

Sponsorship is not free; someone still pays base-layer gas, plus overhead for the extra validation and reimbursement machinery. A rough shape of the accounting for a token-paying UserOperation:

   base-layer gas the bundler spends on this op ≈
       verification gas  (running validateUserOp, Paymaster checks)
     + call gas          (the actual account execution)
     + a fixed per-op overhead inside handleOps

   the user is charged (in USDC, say) ≈
       (gas used) × (effective gas price) × (Paymaster's exchange rate + markup)

So a 4337 UserOperation is always somewhat more expensive than the equivalent bare EOA transaction — you pay for the smart-account validation call and the EntryPoint’s bookkeeping on top of the work you wanted done. The win is not cheaper gas; it is who pays and in what token, and the programmability around it. (Exact gas figures move with each hard fork and with account/Paymaster design, so treat the shape above as the model, not a quote — as of 2024.)

What it unlocks

Once the account is a program, a pile of features that were impossible for an EOA become ordinary contract logic:

• Social recovery. Instead of one key whose loss is fatal, the account’s validation logic can name guardians (friends, devices, an institution) who can rotate the signing key if enough of them agree. Losing your phone stops being an extinction event.
• Session keys. The account can authorise a scoped, temporary key — “this game may submit moves for the next two hours, spending at most 0.05 ETH, calling only this contract.” A game or app stops asking you to sign every single action.
• Batched transactions. A single UserOperation can carry a list of calls that execute atomically. “Approve then swap” becomes one all-or-nothing unit instead of two separate, independently-failing steps — killing a whole class of “approved but the swap failed” states.
• Gas paid in tokens (or by someone else). Via a Paymaster, a user with only USDC can transact, or a dApp can sponsor a first-time user’s gas so onboarding needs no ETH at all.
• Alternative signature schemes. The account can verify signatures ECDSA-secp256k1 can’t: BLS aggregates, or secp256r1 passkeys so a phone’s secure enclave or a hardware key becomes the wallet — no seed phrase for a normal user to lose.

Each of these is written once, in the account contract, and needs no cooperation from the protocol. That is the whole point of doing abstraction in the application layer.

Native AA: folding it into the protocol

ERC-4337 works today, but it pays for “no consensus change” by standing up an entire parallel system off to the side — its own mempool, its own bundlers, its own singleton contract. Native (or enshrined) account abstraction asks: what if the base protocol understood smart accounts directly, so we didn’t need the scaffolding?

The most concrete live step in that direction is EIP-7702, included in the Pectra upgrade in May 2025. Its idea is small and surgical: let an EOA temporarily point at contract code for the duration of a transaction. An EOA signs a special authorisation naming a contract; while that authorisation is in effect, calls to the EOA’s address run that contract’s logic, and then the EOA reverts to being a plain EOA. In effect, your existing EOA can borrow a smart account’s superpowers — batching, sponsored gas, session-scoped keys — without migrating your funds to a new address. It is deliberately a bridge: it makes the vast base of existing EOAs users already hold able to act like smart accounts, and it dovetails with ERC-4337 rather than replacing it.

Longer-term “endgame” proposals go further — designs (discussed under labels like EIP-7701 and broader enshrined-AA sketches) that would make validation a first-class protocol concept, so the base layer itself processes account-defined validity without a separate EntryPoint or a bundler market. Be clear about what is live and what is not:

Layer	Mechanism	Status (as of mid-2025)
Application	ERC-4337 (UserOps, bundlers, EntryPoint, Paymasters)	Live on mainnet since 2023
Base-layer bridge	EIP-7702 (EOAs temporarily act as smart accounts)	Live via Pectra, 2025
Base-layer endgame	Fully enshrined AA (e.g. EIP-7701-style)	Proposed / in research

The direction of travel is settled — accounts should be programmable — but the endgame shape is not, and anyone telling you native AA is “done” is overstating it.

The trade-offs

Nothing in this book is free, and account abstraction is a especially clear case of moving complexity rather than deleting it.

• A new off-protocol infrastructure layer. ERC-4337 adds bundlers, Paymasters, and an alt-mempool — a whole ecosystem that must exist, stay funded, and stay honest. That is new surface for censorship (a bundler can simply decline your operation) and new trust assumptions (a Paymaster you rely on can go offline, stranding sponsored users). The base layer’s neutrality doesn’t automatically extend to this layer.
• More code between you and a transfer. Every validation is now arbitrary contract logic. That is power, and it is also more places for bugs — a broken validateUserOp or a mis-scoped session key is a smart-contract vulnerability, with all the permanence we saw in the DAO. “Programmable” and “auditable” are in tension.
• Higher per-operation cost. As the By the numbers box showed, running the account’s validation and the EntryPoint’s bookkeeping costs gas the bare EOA never paid. You buy flexibility with overhead.
• Fragmentation risk. With ERC-4337, EIP-7702, and future enshrined designs coexisting, wallets and dApps must support several models at once during the transition — a real cost in complexity, even if each individual model is sound.

It actually happened — the first Parity multisig freeze, 6 November 2017

Programmable accounts are not a purely-future idea; the ecosystem has run “your wallet is a contract” for years, and it has bitten hard. On 6 November 2017, a user experimenting with the Parity multisig wallet library contract triggered a bug: the shared library that hundreds of multisig wallets delegated their logic to had an unprotected initialisation function. The user became its owner and then invoked selfdestruct, deleting the library. Because every wallet built on it depended on that code to move funds, roughly 513,000 ETH across those wallets became permanently frozen — not stolen, just unreachable, because the code they relied on no longer existed.

The lesson lands directly on account abstraction: the instant your account is a program (or delegates to one, exactly the shape EIP-7702 popularises), the safety of your funds is the safety of that code. A smart account gives you social recovery and session keys; it also gives you a new, permanent way to brick yourself. Abstraction moves the risk from “don’t lose your key” to “don’t trust broken validation code” — and the second risk is not obviously smaller. See Access Control and the Parity Multisig for the full autopsy.

The architect’s lens

• Why does it exist? Because the EOA — the account nearly every user actually holds — is the one account Ethereum can’t program: one fixed key, gas only in ETH, no batching, no rules. Account abstraction exists to make the user’s own account a smart contract, so the account itself decides what “valid” means.
• What problem does it solve? It unwelds three things the protocol had fused: who may authorise a spend (any signature scheme, multisig, passkeys, recovery), who pays for it (Paymasters, sponsorship, tokens), and how many actions it takes (atomic batching). Each becomes ordinary contract logic instead of a protocol constant.
• What are the trade-offs? ERC-4337 buys “no hard fork” by erecting a parallel system — bundlers, Paymasters, an alt-mempool — with its own censorship and trust surface, higher per-op gas, and more code (hence more bugs) between you and a transfer.
• When should I avoid it? For a simple, self-custodied transfer where you already hold ETH and want the smallest attack surface, a plain EOA is cheaper and has less code to trust. Reach for a smart account when its features — recovery, session keys, sponsorship — actually earn their added complexity.
• What breaks if I remove it? Take account abstraction away and you are back to the wart: users can never recover a lost key, must always pre-fund ETH to move any asset, and sign every step of every multi-step action separately. The chain still works — it just stays hostile to ordinary humans, which is the barrier AA exists to lower.

Check your understanding

1. State the “design wart” account abstraction fixes in terms of the rule from Two Kinds of Account. Which account can start a transaction, and which can be programmed — and why is that a problem?
2. ERC-4337 delivers account abstraction “without a consensus change.” Name its four main components (UserOperation, alt-mempool, bundler, EntryPoint — and the optional fifth) and say what job each does.
3. A user holds only USDC and no ETH, yet completes a swap via a 4337 wallet. Which component made that possible, and where did the base-layer gas actually come from?
4. Contrast ERC-4337 with EIP-7702. Which is an application-layer system and which is a base-layer change, and what does EIP-7702 specifically let an existing EOA do? Which parts of native AA are live versus proposed?
5. Name two distinct trust or censorship risks that ERC-4337’s off-protocol layer introduces that a bare EOA transaction does not have.

Show answers

1. The rule is: an account is a contract iff it has code, and only a codeless EOA can originate a transaction. So the account that can start things (the EOA) is exactly the one that cannot be programmed, while the account that can be programmed (a contract) cannot originate a transaction. The wart is that ordinary users hold EOAs, which are frozen to one ECDSA key, must pay gas in ETH, and can’t batch or set spending rules.
2. UserOperation — a pseudo-transaction describing the desired action plus an account-defined signature. Alt-mempool — a separate gossip network for UserOperations. Bundler — an EOA that batches UserOperations into one real transaction and submits it, fronting base-layer gas. EntryPoint — a singleton contract that, per op, calls the account’s validateUserOp first and its execution second, and reimburses the bundler. The optional fifth is the Paymaster, a contract that sponsors or subsidises gas (e.g. lets the user pay in a token).
3. A Paymaster. The user’s smart account paired with a Paymaster that accepts USDC (or sponsors outright); the Paymaster fronts the ETH. The base-layer gas was actually paid by the bundler when it submitted EntryPoint.handleOps, and the bundler was reimbursed — ultimately by the Paymaster, which collected the user’s USDC.
4. ERC-4337 is an application-layer system — it needs no fork and runs on top of the protocol via bundlers and the EntryPoint. EIP-7702 is a base-layer change (shipped in Pectra, 2025) that lets an existing EOA temporarily point at contract code for a transaction, so it can act like a smart account without moving funds to a new address. Live: ERC-4337 (since 2023) and EIP-7702 (2025). Proposed/in research: fully enshrined AA (e.g. EIP-7701-style designs).
5. Any two of: a bundler can censor by simply declining to include your UserOperation; a Paymaster you depend on can go offline, stranding users who relied on sponsored gas; the alt-mempool and its actors are extra infrastructure that must stay funded and honest, none of which a bare EOA transaction (which goes straight to the base-layer mempool) needs.