Crypto Gloss

ERC-4337

ERC-4337 is the Ethereum standard that enables account abstraction (AA) — the ability to make smart contract wallets behave like first-class Ethereum transaction senders without changing Ethereum’s core protocol. In standard Ethereum, all transaction initiation must come from an Externally Owned Account (EOA): an account controlled by a single private key (ECDSA signature). This design is simple but limiting: lose your private key = lose everything; no multisig natively; no programmable spend limits; gas always paid in ETH. ERC-4337, finalized by the Ethereum Foundation’s AA team (Yoav Weiss, Dror Tirosh, Vitalik Buterin, et al.) and deployed on Ethereum mainnet in March 2023, solves this by introducing a parallel transaction system: users submit UserOperations (not standard transactions) to a dedicated mempool; Bundlers aggregate UserOperations into a single on-chain transaction submitted to the EntryPoint contract; the EntryPoint calls each user’s smart wallet contract (which defines the validation logic — multisig, passkey, biometrics, whatever the developer chooses); and Paymasters allow third parties to pay gas fees on behalf of users (enabling gasless UX, USDC-denominated gas, sponsored transactions). The result: wallets with social recovery, session keys, transaction batching, gas abstraction, and programmable security — all without a hardfork.

Key Facts

  • EIP: ERC-4337 (also called EIP-4337)
  • Authors: Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, et al.
  • Deployed: Ethereum mainnet: March 1, 2023
  • EntryPoint contract address: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 (v0.6); 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (v0.7)
  • Users (2024): 5M+ smart wallet accounts deployed on-chain via ERC-4337
  • UserOperations sent: 25M+ (smart w/ AA-enabled wallets)
  • Major AA wallets: Safe (v4337 module), Biconomy Smart Account, Alchemy Light Account, ZeroDev Kernel, Coinbase Smart Wallet
  • ERC-7579: complementary standard for modular smart account plugins

EOA vs. Smart Contract Wallet (ERC-4337)

Feature EOA (Traditional Wallet) Smart Wallet (ERC-4337)
Authentication Single private key (ECDSA) Programmable (passkey, multisig, biometrics)
Key loss Permanent loss of funds Social recovery possible
Gas payment Always in ETH ETH or ERC-20 or sponsored
Transaction batching No (one tx at a time) Yes (multiple ops in one)
Spend limits No Yes (programmable)
Session keys No Yes (limited authorization for dapps)
Upgradeable No (static logic) Yes (upgradeable contract)
ERC-1271 (off-chain sig) No Yes

ERC-4337 Architecture

The protocol is built around the following components.

Key Components

1. UserOperation

A new “pseudo-transaction” type (not an Ethereum transaction). Fields include:

  • sender: the smart wallet address
  • callData: what the wallet should execute (which function, what args)
  • signature: proof of authorization (could be ECDSA, passkey, multisig signatures, etc.)
  • paymasterAndData: optional: which Paymaster is sponsoring gas; their signature
  • maxFeePerGas / maxPriorityFeePerGas: like EIP-1559 tx gas parameters

2. Bundler

Node software that:

  1. Accepts UserOperations from users (via a separate UserOp mempool, not Ethereum’s standard tx mempool)
  2. Simulates each UserOperation (validates: signature valid; wallet has enough ETH/Paymaster sponsoring)
  3. Batches multiple valid UserOperations into a single standard Ethereum transaction
  4. Submits the bundled transaction to the EntryPoint contract calling handleOps()
  5. Earns: fee from each UserOperation (the bundler’s compensation for gas + service)

Major bundler providers: Alchemy, Biconomy, StackUp, Pimlico, Gelato

3. EntryPoint Contract (singleton; deployed once; all AA wallets use the same)

  1. Receives bundled handleOps() call from Bundler
  2. For each UserOperation: calls validateUserOp() on the sender’s smart wallet
  3. Wallet: validates: is the signature from an authorized key? Is the operation within spend limits? etc.
  4. EntryPoint: if validation passes: executes the callData from the wallet
  5. EntryPoint: charges gas: from wallet’s ETH deposit OR from Paymaster’s deposit

4. Paymaster

A smart contract that agrees to pay gas fees for specific UserOperations. Use cases:

  • Sponsored gas: dapp wants zero-friction onboarding → pays gas for new users
  • ERC-20 gas: user pays gas in USDC (Paymaster: accepts USDC; pays ETH to EntryPoint)
  • Conditional sponsorship: first N transactions sponsored; or: sponsor if user holds NFT X

5. Smart Wallet Contract (Account)

The user’s actual “wallet” on-chain. Implements:

  • validateUserOp(): verify the signature is authorized for this wallet
  • Execute functions: run the callData

Key Use Cases

The following sections cover this in detail.

Social Recovery

  • Guardians: trusted addresses (friends, hardware wallet, institution)
  • Recovery threshold: 3 of 5 guardians must sign to replace compromised key
  • Time-delay: 48 hours until recovery activates (cancel if not authorized)

Result: key loss ≠ loss of funds (unlike EOA where: one lost key = everything gone)

Session Keys

  • “SpeedrunGame dapp can submit moves on my behalf for 24 hours, max 0.01 ETH per move”
  • User: doesn’t need to sign every in-game action
  • Dapp: submits moves autonomously (within approved parameters)
  • Session key: expires after 24 hours automatically

Use case: blockchain gaming (no: approve-every-move friction), trading bots (limited authorization without full access)

Gas Abstraction (Gasless UX)

  1. New user: lands on dapp; has no ETH (only USDC)
  2. Dapp’s Paymaster: sponsors first 5 transactions
  3. User can immediately start using the dapp without buying and bridging ETH first
  4. Dapp: recaptures cost via: in-app fees, token purchase, etc.

Major use case: onboarding Web2 users who don’t own ETH; CEX withdrawals to smart wallets with immediate dapp access

Transaction Batching

  • Standard flow: 3 separate txs (3 user signatures; 3 gas payments; risk: 2nd fails after 1st succeeds)
  • ERC-4337 batch: 1 UserOperation (1 signature; 1 gas payment; atomic: all succeed or all fail)

ERC-7579: Modular Smart Account Standard

ERC-7579 (complementary to ERC-4337): defines a standard interface for modules (plugins) that extend smart wallet functionality:

  • Validator modules: add new authentication methods (passkey, biometrics, multisig)
  • Executor modules: add new execution logic (scheduled transactions, DCA)
  • Hook modules: add guardrails (spend limits, whitelist addresses)

Goal: write a validator module once → works on all ERC-7579-compatible wallets (ZeroDev Kernel, Biconomy Nexus, Safe, etc.) without redevelopment.

Adoption Landscape

ERC-4337 on non-Ethereum chains:

  • Polygon: pioneered early AA adoption (extensive 2023 activity)
  • Optimism, Arbitrum, Base: high smart wallet usage (gaming, consumer crypto)
  • Ethereum mainnet: higher due to base layer value; growing

Major dapps using ERC-4337:

  • Coinbase: Coinbase Smart Wallet (default for all new Coinbase app users)
  • Lens Protocol: social attestations via AA wallets
  • Mirror: gasless publishing for writers
  • Biconomy: SDK for dapps to integrate AA into their flows without building infra

ERC-4337 vs. Native AA (EIP-7701):

ERC-4337: works without protocol changes (uses UserOperations + EntryPoint contract).

EIP-7701 (future): native AA at protocol level (EOAs: can set validation code natively; no EntryPoint contract needed; simpler; more gas-efficient); on Ethereum roadmap; likely post-Pectra.

Related Terms

Sources

  1. “ERC-4337: Account Abstraction Using Alt Mempool” — Vitalik Buterin, Yoav Weiss, Dror Tirosh et al. / Ethereum EIP (2021-2023). The original ERC-4337 specification — defining the UserOperation type, Bundle architecture, EntryPoint contract interface, Paymaster validation flow, and the core separation between validation logic (wallet: who is authorized to sign) and execution logic (EntryPoint: what to execute) that makes ERC-4337 implementation-agnostic.); EntryPoint: for each UserOp: (1) call: account.validateUserOp(userOp, userOpHash, missingAccountFunds): must return: SIG_VALIDATION_FAILED (0) or SIG_VALIDATION_SUCCESS (1) or time-range validity; (2) if Paymaster: call: paymaster.validatePaymasterUserOp(); (3) if validation passes: call: account.execute(callData); gas: charged: from account’s ETH deposit in EntryPoint OR from Paymaster’s deposit; Bundler incentives: Bundler earns: (maxFeePerGas – baseFee) × gasUsed: per UserOperation; same as priority fees for standard txs; DoS protections: critical issue: how to prevent: spam UserOperations (cost: free to submit; expensive: for Bundler to simulate); ERC-4337: requires: validation logic: ban: environmental opcode access (BLOCKHASH, TIMESTAMP, etc.) in validateUserOp: ensures: simulation = execution (Bundler: can simulate without running risk that: real execution behaves differently); reputation system: Bundlers: track: per-sender and per-paymaster simulation success rates; ban: accounts that: fail simulations frequently; conclusion: ERC-4337 is an elegant solution to AA without protocol change; the UserOperation + Bundler + EntryPoint architecture: cleanly separates roles; the validation opcode restrictions: necessary but: add complexity to wallet developers; the gas economics: equivalent to standard txs (same EIP-1559 mechanics); ERC-4337: successfully deployed on Ethereum mainnet March 2023: proving: protocol-change-free AA is viable; the EIP is a landmark: enables: programmable authentication, social recovery, gas abstraction, session keys — fundamentally changing the wallet UX ceiling for Ethereum users.]
  1. “ERC-4337 Deployment Data: One Year of Account Abstraction on Ethereum and L2s” — Dune Analytics / Bundlebear Research (2024). Comprehensive on-chain data analysis of ERC-4337 adoption — measuring total smart wallet accounts deployed, UserOperations processed, gas volumes, Paymaster sponsorship rates, top wallet implementations (Safe, Biconomy, Alchemy, ZeroDev, Coinbase), chain breakdown (Ethereum vs. Polygon vs. Optimism vs. Base vs. Arbitrum), and growth trends.
  1. “Smart Wallet Security: Recovery Mechanisms, Session Key Risk, and Upgrade Vulnerabilities in ERC-4337 Wallets” — Cyfrin / ConsenSys Diligence Security Research (2024). Security analysis of ERC-4337 smart wallet implementations — examining common vulnerabilities (improper signature validation, upgrade key risks, guardian collusion in social recovery, session key scope creep), how audit findings compare to EOA security (different risk profile: less: single-key risk; more: smart contract risk), and best practices for secure AA wallet deployment.
  1. “Coinbase Smart Wallet: Passkeys, Cross-Chain, and the Mainstream AA Push” — Coinbase Engineering Blog (2024). Technical deep dive into Coinbase Smart Wallet — how Coinbase implemented ERC-4337 for all new wallet users, the passkey authentication model (using WebAuthn P-256 instead of ECDSA for signatures), cross-chain account abstraction (same wallet address on all EVM chains), and the UX impact of AA for mainstream users (no seed phrase, Face ID login, sponsored first transactions).
  1. “From EOA to Smart Wallet: The Road to Native Account Abstraction (EIP-7701/3074)” — Ethereum Foundation / ACD Research (2024). Analysis of the path from ERC-4337 (current: out-of-protocol AA) to future native AA on Ethereum — examining EIP-3074 (allows EOAs to delegate signing authority to invoker contracts: simpler AA for existing wallets; approved for Pectra upgrade), EIP-7701 (native AA: EOAs can set validation code: more powerful but: complex), and how these native proposals relate to/potentially replace ERC-4337.