Skip to main content

What Is ERC-4337? Account Abstraction Explained

ERC-4337 brings account abstraction to Ethereum without protocol changes. Smart wallets, paymasters, bundlers, and UserOperations — how the full stack works.

Written by Eco

What Is ERC-4337?

ERC-4337 is an Ethereum standard that delivers account abstraction without requiring a hard fork or any change to the core protocol. Published in 2021 by Vitalik Buterin and co-authors, it introduces a parallel transaction system built on a singleton EntryPoint contract. All compliant smart wallets route operations through this contract rather than through Ethereum's native transaction pool. Two audited EntryPoint versions are live: v0.6 (widely deployed) and v0.7 (released 2024, adds improved paymaster and aggregator interfaces). Read the full EIP on eips.ethereum.org.

At its core, ERC-4337 replaces the concept of "a user sends a transaction" with "a user signs an intent." That intent, called a UserOperation, travels through an alternative mempool, gets picked up by a bundler, validated onchain, and executed via the EntryPoint. The wallet itself is a smart contract, which means its logic (key management, spending rules, signature schemes) is programmable rather than hard-coded into the protocol.

For a broader look at how Ethereum improvement standards work, see What Is an Ethereum ERC Standard?

The Problem ERC-4337 Solves

Externally owned accounts (EOAs), the wallet type every Ethereum user has by default, have four structural weaknesses: no key recovery, no gas abstraction, no batching, and no programmable access control. ERC-4337 was designed to remove all four without waiting for a protocol-level fork. The standard makes smart contract wallets a first-class replacement for EOAs across every EVM-compatible chain. erc4337.io tracks live adoption metrics.

No key recovery. If an EOA private key is lost, the funds are gone permanently. There is no fallback mechanism at the protocol level. ERC-4337 smart wallets can implement social recovery, multisig fallback, or guardian-based recovery entirely in contract logic. See What Is Social Recovery for Crypto Wallets? for how these schemes work in practice.

No gas abstraction. EOA users must hold ETH in the signing account to pay gas, even when transacting in stablecoins. This creates a painful onboarding experience: a new user who receives USDC cannot do anything until they also acquire ETH. ERC-4337 paymasters break this coupling, allowing ETH to be sourced from a sponsor or swapped from any ERC-20 at execution time.

No batching. A typical DeFi interaction (approve + swap + deposit) costs three separate transactions and three separate gas payments. EOAs cannot atomically batch operations. An ERC-4337 smart wallet executes all three in one UserOperation, reducing cost and eliminating partial-execution risk.

No programmable access control. EOAs have one key and one permission level. ERC-4337 wallets support session keys, sub-keys with spending limits, time-locked operations, and role-based access, all enforced by the wallet contract.

How ERC-4337 Works

ERC-4337 introduces a parallel execution pipeline: a pseudo-transaction object called a UserOperation flows through an alternative mempool, is assembled by a bundler into a real Ethereum transaction, and is validated and dispatched by the EntryPoint contract. No consensus changes are needed because the entire mechanism lives in smart contracts. The EIP specification covers every field in detail.

UserOperation struct. A UserOperation (often abbreviated "UserOp") is a data structure that describes what the user wants to do. Key fields include: sender (the smart wallet address), nonce, initCode (deploys the wallet if it does not exist yet), callData (the actual execution payload), callGasLimit, verificationGasLimit, preVerificationGas, maxFeePerGas, maxPriorityFeePerGas, paymasterAndData, and signature. ERC-4337 v0.7 restructures some of these into a cleaner PackedUserOperation to reduce calldata size.

Alternative mempool. UserOps do not enter Ethereum's native transaction pool. Instead, bundler nodes maintain a separate peer-to-peer mempool specifically for UserOps. This pool applies its own validation rules before accepting a UserOp, including simulating the wallet's validateUserOp function to confirm the signature is valid and that fees are covered.

Bundler. A bundler is an offchain actor (similar to a block builder) that collects UserOps from the alt mempool, packs multiple UserOps into a single Ethereum transaction, and submits that transaction to the EntryPoint. The bundler pays the ETH gas for the L1 transaction and recoups it through the gas fees encoded in each UserOp. Bundler services are offered by Pimlico, Alchemy, Stackup, and others.

EntryPoint contract. The EntryPoint is a singleton contract deployed at a canonical address (the same address on every EVM chain). It loops through each UserOp in the bundle, calls validateUserOp on the sender wallet, calls the paymaster if present, executes the callData, and settles gas accounting. The EntryPoint's separation of validation and execution is what makes paymasters and session keys composable with any wallet implementation.

Wallet factory. If a UserOp's initCode is non-empty, the EntryPoint deploys the wallet before executing it. This means a user can have a deterministic smart wallet address (computed via CREATE2) before ever deploying it, and deploy plus execute in a single operation. Gas costs for deployment are rolled into that first UserOp rather than requiring a separate setup transaction.

How Does ERC-4337 Enable Gas Sponsorship?

Gas sponsorship works through a component called a paymaster: a smart contract that the EntryPoint calls during UserOp validation to confirm that someone other than the user will cover the ETH gas cost. Two paymaster types handle the vast majority of production use cases. Alchemy's paymaster guide walks through integration patterns for both. This sponsored execution model unlocks the frictionless onboarding flows found across stablecoin automation platforms that abstract all gas away from the end user.

Sponsored paymaster (Verifying paymaster). The application or protocol agrees to pay gas on behalf of the user. The paymaster contract verifies an offchain signature from the sponsoring entity, then covers the ETH cost. The user pays nothing. This is used for onboarding flows, subsidized NFT mints, loyalty programs, and any product where removing friction is worth the gas subsidy. The sponsor sets its own authorization rules, including per-user daily caps, whitelisting specific contracts, or allowing only specific callData patterns.

Token paymaster (ERC-20 paymaster). The user pays gas in an ERC-20 token, typically a stablecoin like USDC. The paymaster quotes a token amount equivalent to the ETH gas cost (using an onchain oracle or offchain price feed), receives that token from the user's wallet during execution, and then covers the ETH gas itself. From the user's perspective, they hold USDC, they pay in USDC, and they never touch ETH. This pattern removes the "need ETH just to move USDC" friction that blocks mainstream adoption.

Paymaster staking and reputation. To prevent abuse, the EntryPoint requires paymasters to stake ETH and enforces a reputation system. Paymasters that repeatedly sponsor UserOps that fail validation lose reputation and eventually get throttled by bundlers. This creates an economic incentive for paymasters to validate carefully before agreeing to sponsor any UserOp.

Session Keys and Permissions via ERC-4337

Session keys are time-limited, scope-limited signing keys that ERC-4337 smart wallets can authorize without exposing the main wallet key. A dApp requests a session key, the user approves it once, and subsequent actions within the session's defined scope execute without repeated signature prompts. EIP-7715 formalizes the permission request interface. See the full breakdown at What Is ERC-7715? Smart Wallet Permissions Explained.

ERC-7715 (Permission Requests). This standard defines how a dApp requests a set of permissions from a wallet and how the wallet responds. Permissions are typed and scoped: a DeFi protocol might request permission to call a specific contract, with a maximum token spend of 500 USDC, expiring in 24 hours. The wallet signs a permission grant, the dApp stores it, and can execute within that scope without prompting the user again. ERC-7715 sits on top of ERC-4337's execution model and is supported by Coinbase Smart Wallet and ZeroDev Kernel.

ERC-7710 (Smart Contract Permissions). This companion standard focuses on how smart contracts delegate permissions to other contracts or offchain actors. Where ERC-7715 handles the user-to-dApp permission request flow, ERC-7710 handles contract-to-contract permission delegation. Together they form a composable permission layer that enables use cases like subscription payments, automated yield strategies, and cross-protocol automation without exposing root signing keys.

Practical impact. A user playing an onchain game sets a session key scoped to that game's contract with a 0.05 ETH spending cap and a 4-hour expiry. Every in-game transaction executes silently with no pop-ups. When the session expires or the cap is hit, the game requests renewal. The main wallet key never leaves the secure enclave. This same pattern applies to cross-chain intent protocols that need delegated execution rights to fill user orders.

Keystore wallets extend this model by separating key storage from execution logic across chains. See What Are Keystore Wallets? for how that architecture interacts with ERC-4337.

ERC-4337 vs EIP-7702

EIP-7702, included in the Pectra hard fork (May 2025), takes a different architectural approach: it lets an EOA temporarily point its code slot at a smart contract implementation for the duration of one transaction. ERC-4337 is an application-layer standard with no protocol changes; EIP-7702 is an in-protocol change that requires a network upgrade. They are complementary, not mutually exclusive. EIP-7702 specification on eips.ethereum.org.

How EIP-7702 works. A user signs an authorization that says "for this transaction, treat my EOA as if it has the bytecode at address X." The EOA gains smart wallet capabilities (batching, paymasters, session keys) for that transaction. The EOA's private key still controls everything. There is no contract deployment, no factory, no separate UserOp mempool. Wallet providers can point the code slot at an ERC-4337-compatible implementation, which means EIP-7702 accounts can optionally enter the 4337 stack.

Where ERC-4337 wins. ERC-4337 offers richer programmability. The wallet is a real contract with persistent state, custom validation logic (passkeys, multisig, hardware keys), and a factory-driven deployment model. It works today on any EVM chain without waiting for protocol upgrades. It is also the foundation for ERC-7715 session keys and ERC-7710 delegation. For wallets that need advanced features such as social recovery, granular permissions, or keystore separation, ERC-4337 is the right architecture.

Where EIP-7702 wins. EIP-7702 is significantly simpler to integrate. No alt mempool, no bundler dependency, no EntryPoint contract. Existing EOA users get smart wallet features in one signature. It is ideal for products that want to offer batching and gas sponsorship to existing users without asking them to migrate to a new smart wallet address. The tradeoff is that the EOA key remains the root of trust, so a compromised key is still fatal.

In production. Most infrastructure providers now support both. A Coinbase Smart Wallet user gets ERC-4337. A MetaMask user on a Pectra-compatible network gets EIP-7702 features without changing wallets. The two standards will coexist: ERC-4337 for new-wallet deployments requiring full programmability, EIP-7702 for backward-compatible EOA upgrades.

Who Has Deployed ERC-4337 Smart Wallets?

ERC-4337 adoption accelerated sharply through 2024 and into 2025. Tens of millions of smart wallet accounts have been deployed across Ethereum mainnet and L2s including Arbitrum, Base, Optimism, and Polygon. Infrastructure from bundler providers and wallet SDKs has made ERC-4337 integration a matter of days rather than months for most development teams. Alchemy's account abstraction year-in-review covers aggregate deployment data.

Safe (formerly Gnosis Safe). The largest smart contract wallet by total value locked. Safe's ERC-4337 module wraps its existing multisig architecture to support UserOps while preserving Safe's guardian and threshold model. Used primarily by DAOs, treasuries, and institutional custody. Safe{Core} Protocol provides modular extensions including session key managers and recovery modules.

Coinbase Smart Wallet. Launched in 2024 as the default wallet in Coinbase's consumer products. Built on a passkey-native ERC-4337 implementation so users authenticate with biometrics rather than seed phrases. Ships with sponsored transactions for Coinbase-ecosystem dApps. Coinbase's Base L2 waives EntryPoint fees for smart wallet UserOps, making gas costs near-zero for users.

Biconomy. One of the earliest ERC-4337 infrastructure providers. Offers a Modular Smart Account that implements ERC-6900 (the modular account plugin standard) on top of ERC-4337. Biconomy's paymaster and bundler services power a large share of gasless transactions on Polygon and BNB Chain, with integrations across several hundred dApps.

ZeroDev (Kernel wallet). An open-source ERC-4337 kernel designed for maximum composability. Kernel is modular: validators (ECDSA, multisig, passkey, session key) and executors are separate plugins. ZeroDev's infrastructure is widely used by wallet-as-a-service integrations. Kernel v3 implements ERC-7579 (minimal modular account interface) for cross-stack compatibility.

Pimlico. Primarily an infrastructure provider (bundler and paymaster-as-a-service) rather than an end-user wallet. Pimlico's permissionless.js SDK is the most widely referenced open-source ERC-4337 integration library. Their paymaster supports ERC-20 gas payments across 30+ tokens on 20+ chains, and their bundler handles a significant fraction of all UserOps processed globally.

Alchemy LightAccount. A minimal, gas-optimized ERC-4337 smart account published by Alchemy and widely forked. LightAccount strips out features not needed by most consumer applications and focuses on low deployment cost and low UserOp overhead. It is the reference implementation most developers start from before adding modules, and has been audited independently by multiple firms.

EOA vs ERC-4337 vs EIP-7702 vs Gnosis Safe Multisig

The four wallet architectures available on EVM chains today each make different tradeoffs across key recovery, gas flexibility, batching, permissions, and protocol dependencies. ERC-4337 leads on programmability; EOAs remain the simplest entry point; EIP-7702 offers a practical upgrade path for existing EOA users; Safe multisig is the standard for institutional and DAO custody. erc4337.io provides up-to-date deployment counts across wallet types.

Dimension

EOA

ERC-4337 Smart Wallet

EIP-7702 Upgraded EOA

Gnosis Safe Multisig

Key recovery

None. Lost key means lost funds permanently.

Social recovery, guardian schemes, passkey fallback all available in contract logic.

None by default. Implementation contract can add recovery, but EOA key retains root control.

Threshold recovery via co-signers. Losing one key does not mean losing funds if quorum remains.

Gas payment

ETH only, paid by the signing address.

ETH, ERC-20, or fully sponsored via paymaster. User can pay in USDC and never hold ETH.

ETH or ERC-20 via paymaster when using a 4337-compatible implementation. Chain-dependent.

ETH only natively. Safe relayer can abstract gas for users but requires offchain infrastructure.

Transaction batching

Not possible. Each operation is a separate transaction.

Native via callData array in UserOp. Approve + swap + deposit in one atomic operation.

Native via the delegation contract's logic. Same atomicity as 4337 for batched calls.

Native via Safe's execTransaction with MultiSend module.

Session keys / permissions

None. One key, one permission level.

Full support via ERC-7715, ERC-7710, and plugin validators. Scoped, time-limited sub-keys.

Partial. Depends on the implementation contract. ERC-7715 support varies by provider.

Via Safe modules (e.g., Safe{Core} session key module). Requires module installation.

Protocol change required

N/A. This is the base account type.

No. Pure application layer, works on any EVM chain today.

Yes. Requires the Pectra hard fork (EIP-7702), live on Ethereum mainnet May 2025.

No. Safe predates ERC-4337 and operates independently of protocol changes.

Frequently Asked Questions

Is ERC-4337 live on Ethereum mainnet today?

Yes. The EntryPoint v0.6 contract was deployed to Ethereum mainnet in March 2023 after audits by OpenZeppelin and Certora. EntryPoint v0.7 followed in 2024. Both are deployed at canonical addresses on Base, Arbitrum, Optimism, Polygon, and most other EVM-compatible networks. Any wallet or dApp can interact with them without special permission.

Does switching to ERC-4337 require a new wallet address?

Yes if starting fresh. An ERC-4337 smart wallet is a contract at a new address, distinct from any existing EOA. However, counterfactual deployment (via CREATE2) means your new address is computed deterministically before deployment, so you can receive funds there and deploy on first use in one transaction. EIP-7702 is the path for upgrading an existing EOA address in place without migrating.

What is the difference between a bundler and a relayer?

A relayer (pre-ERC-4337) submits meta-transactions on behalf of users but requires custom integration per contract and has no standard validation model. A bundler is a standardized ERC-4337 component that packs multiple UserOps into one transaction, simulates them against the EntryPoint's rules, and handles gas accounting. Bundlers operate a shared alt mempool with interoperable standards; relayers do not.

Can ERC-4337 smart wallets receive ENS names and NFTs?

Yes. An ERC-4337 smart wallet is a smart contract at an Ethereum address and can receive ETH, ERC-20 tokens, ERC-721 NFTs, ERC-1155 tokens, and ENS names exactly like any other address. The wallet contract can also enforce transfer restrictions or spending rules on any asset it holds, which EOAs cannot do.

How does ERC-4337 interact with Layer 2 networks?

ERC-4337 works on any EVM-compatible chain. The EntryPoint contract is deployed at the same canonical address on L2s including Base, Arbitrum, Optimism, Polygon, and zkSync. Gas costs for UserOps on L2s are significantly lower than mainnet. Some L2s (Base in particular) offer additional fee subsidies for smart wallet UserOps routed through their native paymaster infrastructure.


Related reading

Byline: Eco Research. Last updated: April 30, 2026.

Did this answer your question?