Library Data and agents2021Design paperCorpus record

Account Abstraction Using Alt Mempool

ERC-4337. Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso and Tjaden Hess.

Smart-contract accounts that propose UserOperations, bundled by a separate mempool, without a change to Ethereum's consensus. Paymasters can sponsor gas. The validation rule lives in the account, which is the point and the risk.

ERC-4337 lets a smart contract be the account. Users submit UserOperations to a separate mempool. Bundlers wrap them into an ordinary Ethereum transaction. No consensus change is required. The account's own code decides what counts as authorisation.

The five-minute read

Above the protocol, not inside it

Validators still see a normal transaction from the bundler to the EntryPoint. They do not need to understand a UserOperation. That is how the proposal shipped without a fork. It is also why a bundler's mempool is a new place for the usual games.

Validation is programmable

The account defines what a valid signature is. It might be a multisig, a passkey, or a session key for an agent. A bug in that function is a bug in the lock, not in Ethereum's transaction format.

Paymasters sponsor gas

A contract can pay the bundler if its own checks pass and it has deposited funds. Sponsorship can be revoked, emptied, or used as a censor. It is not a protocol right.

Simulation has rules

Bundlers simulate validation before including an operation. The specification restricts what validation may read, so a sender cannot make the simulation succeed and the execution fail in a way that wastes the bundler. Those restrictions are the spec. Ignoring them makes the mempool griefable.

One action, walked through

An account contract is deployed, with a validation function and an execution function.
The holder builds a UserOperation describing the call they want.
A bundler simulates validation and, if it likes the fee, includes the operation in a bundle.
The EntryPoint contract runs validation, then execution, and pays the bundler from the account or the paymaster.
If validation fails on chain, the bundler should not have included it. If execution fails after validation, the fee rules in the spec decide who eats the gas.

The argument, unpacked

Account abstraction here is a market structure

The protocol did not grow a new transaction type. A new set of intermediaries, the bundlers and paymasters, appeared. They can offer better wallets and they can reorder, refuse, or sponsor selectively. The MEV question moves up a layer. It does not close.

Recovery is not included

A contract account can implement social recovery or a guardian. The EIP does not require one. An account with a single key and custom validation can be just as final, when the key is lost, as an externally owned account. The flexibility is also the footgun.

What has to be true

The EntryPoint used by the account is the contract the holder meant. A fake entry point can pass a wallet's user interface and fail the user.
Bundlers exist and find the operation. There is no protocol guarantee that the alt mempool is dense.
Validation follows the spec's restrictions if the holder cares about being included by ordinary bundlers.
Paymaster deposits are solvent if gas is supposed to be sponsored. An empty deposit fails the operation.

What happened after the paper

Smart-contract wallets on Ethereum largely converged on this ERC rather than on a consensus change. Passkeys, session keys, and agent allowances are application policies on top of the UserOperation. The EIP is the citation for the alt mempool and the EntryPoint. It is not a citation for any particular wallet's recovery story, and it does not by itself authorise an agent to spend.

What to check before you use the idea

Which EntryPoint does the account trust?
What does validation actually accept?
Who pays gas, and can they refuse?
Is there a recovery path if the key is lost?

Terms

UserOperation: The object a contract account submits, describing the call and the data that should validate it.
Bundler: A node that packs UserOperations into an ordinary transaction and is paid for the gas.

The problem the paper names

Protocol-level account abstraction means changing what a transaction is. ERC-4337 tries to get custom validation, batching, and sponsored gas by adding a contract and a mempool above the protocol.

What the design proposes

A UserOperation carries the sender, the call, and the signature-like data the account expects.
Bundlers simulate validation, then submit a bundle to the EntryPoint contract.
A paymaster can cover gas if it deposits and if its own validation agrees.

How the mechanism is specified

Validation must not depend on state that the bundler cannot safely simulate. The spec's rules exist so a bundle cannot be griefed after simulation.
The EntryPoint is shared infrastructure. A bug there touches every account that uses it.
The account's validation function defines what 'signature' means. It can be a passkey, a multisig, or a mistake.

What this page does not treat as proven

This is not consensus account abstraction. A node does not have to understand UserOperations.
A paymaster can refuse, censor, or be empty. Sponsored gas is not a right.
Custom validation can lock the owner out. Recovery is a policy the account must include. The EIP does not supply one.

Why a venture studio still reads it

An agent wallet or a passkey account on Ethereum is usually this shape. Ask who validates, who bundles, who pays gas, and what happens if the EntryPoint or the paymaster stops.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.