What is ERC4337?

ERC4337 is Ethereum's account abstraction standard: activated on mainnet 1 March 2023, originally proposed 29 September 2021 by Vitalik Buterin with Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso, and Tjaden Hess. Rather than modify the protocol, it introduces a parallel UserOperation mempool, a singleton EntryPoint contract, bundlers that batch UserOps into transactions, and paymasters that can sponsor gas. Contract accounts get first-class transactor behavior — at the cost of an entirely separate infrastructure layer sitting beside the normal transaction flow. LUKSO's LSP0 + LSP6 + LSP20 + LSP25 stack ships the same account-abstraction outcomes natively, with no parallel layer required.

Origin

Protocol-level account abstraction had been attempted for years before ERC4337 — EIP-86 (2017), EIP-2938 (2020), EIP-3074 (2021) — none shipped, each requiring consensus-layer changes the network wasn't ready to ratify. In parallel, a meta-transaction lineage ran from ERC-1613 (Tabookey, 2018) through ERC-2771 (2020, co-authored by the same Tabookey team). ERC4337 is that meta-transaction lineage absorbing the account-abstraction ambition: the bundler is GSN's relay server, generalized; the EntryPoint is GSN's RelayHub, generalized.

Vitalik's own introduction post was titled, in plain text, "ERC-4337: Account Abstraction Without Ethereum Protocol Changes." That title is the clearest acknowledgment available of the design constraint being worked around — a hard fork wasn't politically available, so the whole architecture was built to sit above the protocol instead of inside it.

The interface

// EntryPoint (singleton)
function handleOps(PackedUserOperation[] calldata ops, address payable beneficiary) external;

// IAccount (each smart account implements)
function validateUserOp(
  PackedUserOperation calldata userOp,
  bytes32 userOpHash,
  uint256 missingAccountFunds
) external returns (uint256 validationData);

// IPaymaster (optional, sponsors gas)
function validatePaymasterUserOp(
  PackedUserOperation calldata userOp,
  bytes32 userOpHash,
  uint256 maxCost
) external returns (bytes memory context, uint256 validationData);

function postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas) external;

Where the layered approach costs

The parallel mempool

UserOperations aren't transactions — they live in a separate alt-mempool, get packed by bundlers, and route through the singleton EntryPoint before ever reaching the account. Every UserOp pays a bundler-submission cost on top of the gas it consumes, and the bundler position carries censorship and reordering risk the broader L1 mempool doesn't share.

A worse trace and explorer surface

Block explorers show handleOps, not the user's actual function call. Debugging happens through an extra indirection: handleOps → EntryPoint → account → target, instead of a direct call.

Per-account validator modules, no shared permission vocabulary

validateUserOp is one function each account implements however it wants — deliberately. The cost is that Safe, Kernel, Biconomy, Alchemy LightAccount, and Soul Wallet each invent their own validator shape. Permission audits are per-account, not per-standard, and migrating between implementations is non-trivial.

Paymaster trust as a separate failure surface

Gas sponsorship needs a paymaster contract with its own ETH deposit, its own validation function, and its own post-execution accounting — a second failure point on every sponsored operation, and wallets end up shipping per-paymaster integrations.

Account abstraction sits above the EVM, not in it

EIP-7702 (Pectra, May 2025) — co-authored by Vitalik himself — is the eventual protocol-level patch. Its own Motivation section cites that existing EOAs can't become ERC4337 smart accounts without losing address history, ENS, reputation, and airdrop eligibility. Four years after framing account abstraction as something to ship without protocol changes, its lead author was co-signing the protocol change that closes the gap the layered design left open.

The LUKSO successor

	ERC4337	LSP account stack
Transaction flow	user → UserOp pool → bundler → EntryPoint → account	user (controller) → account contract, directly
Permission layer	per-account validator module	LSP6 — one standardized vocabulary
Gas sponsorship	separate paymaster contract	LSP25 executeRelayCall, on the Key Manager the account already has
Signature verification	validateUserOp on the account	LSP20 inline verification
Trace / explorer	handleOps + EntryPoint hop	direct call into the account contract

LSP0 ERC725 Account is the call entry point — there's no EntryPoint singleton, no UserOperation envelope, no bundler. msg.sender at every downstream contract is the account itself. Even accounting for Pectra's real progress, the LSP stack still covers ground 7702 + 4337 don't: a Universal Profile has no residual EOA root key that can override a recovered configuration, whereas a 7702-delegated EOA's original key remains authoritative unless the wallet design explicitly handles revocation (a gap EIP-7851 still only proposes to close, as a draft). Permissions, receiving hooks, ownership transitions, and extensions are one shared vocabulary across every LUKSO account, not a per-wallet-vendor module.

Is ERC4337 still the right choice?

When account abstraction needs to layer onto a chain whose native transaction model is EOA-anchored, with pluggable per-account validators and a sponsorship plane decoupled from the account contract itself, ERC4337's decoupling is a genuine strength — validators are swappable and mixable per UserOp. The LSP stack wins when the account contract itself should be the entry point, with no EntryPoint hop and one standardized permission vocabulary.

FAQ

What is a bundler?

An off-chain actor that watches the UserOperation mempool, validates UserOps, packs valid ones into a single handleOps transaction, and submits it on-chain — earning fees per UserOp, with real censorship and reordering risk.

What's the difference between ERC4337 and EIP-7702?

ERC4337 deploys a separate smart-contract account processed through bundlers and an EntryPoint. EIP-7702 lets an existing EOA delegate execution to contract code without redeploying — but the original ECDSA key remains authoritative unless the wallet design handles revocation carefully. See ERC4337 vs EIP-7702.

Is a Universal Profile a smart wallet that uses ERC4337?

No. A Universal Profile is a smart wallet built on LSP0, LSP6, LSP20, and LSP25 that doesn't use the 4337 stack at all — no EntryPoint, no UserOperation, no bundler.

Related reading: ERC4337 vs the LSP account stack · ERC4337 vs EIP-7702 · ERC4337's bundler tax · Gasless onboarding without a paymaster