ERC-4337 is an Ethereum standard that brings account abstraction to the network without requiring any consensus-layer changes. The standard reached final status in March 2023 and defines a higher-level mempool of pseudo-transactions called UserOperation objects, processed by bundlers and routed through a singleton EntryPoint contract that calls into user-controlled smart contract wallets.
​

The proposal originated with Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso, and Tjaden Hess. The canonical specification is EIP-4337 on the Ethereum Improvement Proposals site, with supporting documentation at ethereum.org/roadmap/account-abstraction.
​

Account abstraction is the idea that an Ethereum account should not be limited to a single externally owned key. In the original Ethereum design, every transaction must originate from an externally owned account (EOA) controlled by an ECDSA secp256k1 private key. The protocol hardcodes the signature scheme, the nonce ordering, the gas payment model, and the way a transaction is authorized. None of this is configurable from inside the account.
​

Account abstraction unbundles that fixed transaction model. Instead of "one key signs one transaction," an account becomes a smart contract that defines its own validation logic. The account can require multiple signatures, accept WebAuthn passkeys, enforce spending limits, sponsor its own gas, or rotate keys through social recovery. The account decides what counts as a valid request, and the protocol routes the request through standard infrastructure.
​

The Ethereum roadmap has worked toward this goal through several proposals. EIP-2938 proposed a consensus-layer change in 2020 but stalled because every node would have had to upgrade. ERC-4337 chose the opposite path: it implements account abstraction entirely through smart contracts and a parallel mempool, so no hard fork is required. The first reference implementation deployed to Ethereum mainnet on March 1, 2023, alongside the EIP's final status.
​

ERC-4337 introduces six distinct roles that work together to validate and execute a user request. Each piece is a smart contract or an offchain actor with a defined interface, and the design keeps the consensus layer untouched.
​

A UserOperation is a structured object that describes what the user wants to do. It is not an Ethereum transaction. The structure includes the sender address, a nonce, the calldata to execute, gas limits for verification and execution, fee parameters, an optional paymaster section, and a signature. Wallets construct UserOperations and submit them to a separate alt-mempool rather than the standard Ethereum transaction pool.
​

Because the UserOperation is just data until a bundler picks it up, the signature field can hold anything the account contract knows how to verify. That is the slot where ECDSA, BLS, passkey WebAuthn, multisig, or session-key signatures all live. The account itself decides which schemes count as valid.
​

Every ERC-4337 deployment depends on a singleton EntryPoint contract. Version 0.6.0 deployed at 0x5FF1...DD89 on March 1, 2023, with version 0.7 following in 2024 at the canonical singleton 0x0000000071727De22E5E9d8BAf0edAc6f37da032. ERC-7702 interop is composed at the account-contract level rather than via a new EntryPoint version. The EntryPoint is the only contract bundlers call directly. It receives a batch of UserOperations through its handleOps function, runs validation against each sender account, and then triggers execution.
​

The EntryPoint enforces a strict two-phase pattern: verification first, then execution. During verification, it calls each account's validateUserOp function and, if a paymaster is attached, the paymaster's validatePaymasterUserOp. Only if every validation passes does the EntryPoint loop back and call each account's execution function. This separation is what makes the bundler's economics work, because the verification phase is bounded and predictable.
​

Bundlers are offchain actors that watch the alt-mempool, collect UserOperations, simulate them, and submit valid bundles to the EntryPoint as a single Ethereum transaction. The bundler pays the L1 gas, and the EntryPoint refunds the bundler from the account's prefund (or from a paymaster). Public bundler services include Pimlico, Alchemy Rundler, Stackup, Candide Voltaire, and Etherspot Skandha. For a deeper walkthrough, see the companion article on what a bundler is and how it works.
​

A paymaster is an optional contract that agrees to pay gas on behalf of the user. The paymaster contract implements validatePaymasterUserOp, which the EntryPoint calls during verification. If the paymaster approves, the EntryPoint deducts gas from the paymaster's onchain deposit rather than from the user's account. Paymasters enable USDC-paid gas, app-sponsored gas, and gasless onboarding. The cluster article on paymasters and gas sponsorship covers the patterns.
​

A factory is a contract that deploys new account contracts. The first UserOperation a brand-new account ever sends includes an initCode field. When the EntryPoint sees a non-empty initCode on a sender with no deployed bytecode, it calls the factory address embedded in initCode to deploy the account. This pattern lets wallets advertise a counterfactual address that exists before any transaction has been sent. Funds can arrive at the address, and the account deploys on its first outbound action.
​

The account contract is the user's wallet. It implements two required functions: validateUserOp, which checks the signature and nonce, and an execution function (commonly execute or executeBatch) that performs the actual call. Reference implementations include Safe's 4337 module at safe-modules, the eth-infinitism SimpleAccount at eth-infinitism/account-abstraction, ZeroDev's Kernel, Alchemy's Modular Account, and Biconomy's Nexus.
​

The clearest way to understand ERC-4337 is to follow one request from wallet to settlement. Assume a user holds a Coinbase Smart Wallet at counterfactual address 0xUser and wants to swap 100 USDC for ETH on Uniswap, with the gas sponsored by the dapp.
​

Step one: the wallet UI builds a UserOperation. The sender field is 0xUser. The callData field encodes a call from the account's execute function into the Uniswap router. The nonce is pulled from the EntryPoint's nonce manager. The wallet attaches the dapp's paymaster address in the paymasterAndData field, along with a signed authorization from the paymaster's offchain signer that this user is approved.
​

Step two: the user authenticates with a passkey. The Coinbase Smart Wallet calls navigator.credentials.get via WebAuthn, which prompts Touch ID, Face ID, or a hardware key. The browser returns a signed assertion. The wallet packs that assertion into the UserOperation's signature field.
​

Step three: the wallet submits the UserOperation to a bundler RPC, most commonly through the eth_sendUserOperation method defined in EIP-4337's RPC section. The bundler is typically a service like Pimlico, Alchemy, or Stackup running its own RPC endpoint.
​

Step four: the bundler simulates the UserOperation against the current state. It calls the EntryPoint's simulateValidation entry, which in turn calls the account's validateUserOp and the paymaster's validatePaymasterUserOp. If both return success and the gas estimates fit, the bundler accepts the UserOperation into its bundle.
​

Step five: the bundler sends a real Ethereum transaction. It calls EntryPoint.handleOps with an array of UserOperations and its own EOA as the beneficiary. The transaction lands in a normal block proposed by a validator.
​

Step six: the EntryPoint runs the verification loop. For each UserOperation, it calls validateUserOp on the account, which checks the WebAuthn signature against the stored passkey public key. It calls validatePaymasterUserOp on the dapp's paymaster, which verifies the offchain authorization signature. Both pass.
​

Step seven: the EntryPoint runs the execution loop. It calls the account's execute function, which in turn calls the Uniswap router. The swap settles. USDC leaves 0xUser, ETH arrives at 0xUser.
​

Step eight: the EntryPoint settles gas. The paymaster's prefunded deposit is debited for the gas used, plus a small premium that goes back to the bundler. The bundler's own EOA pays the L1 gas to the validator and receives the refund.
​

From the user's perspective, the entire flow was one biometric prompt. From the protocol's perspective, no consensus rules changed. Everything happened inside contracts and an alt-mempool.
​

Several wallets, rollups, and infrastructure providers have shipped production ERC-4337 deployments since the EntryPoint went live in March 2023. The picture in May 2026 is broader than any single chain.
​

Coinbase Smart Wallet launched on June 5, 2024 as a passkey-based ERC-4337 wallet that works across Base, Ethereum, Arbitrum, Optimism, Polygon, Zora, and additional EVM chains. The wallet has no seed phrase. Recovery is handled through passkeys synced via Apple iCloud Keychain, Google Password Manager, or hardware authenticators. The contract source is published at github.com/coinbase/smart-wallet.
​

Safe (formerly Gnosis Safe) shipped its 4337 module in 2023 and now offers ERC-4337 alongside its native multisig flow. Safe's documentation at docs.safe.global describes the module and the audit history of the SafeProxyFactory and Safe singleton contracts.
​

MetaMask added Smart Account support to its main extension in 2025 via the Delegation Toolkit, with the ERC-4337 stack covered in MetaMask's developer docs. Trust Wallet, Rainbow, Ambire, and Soul Wallet ship ERC-4337 accounts as their default flow on at least one chain.
​

Infrastructure providers concentrate around a short list: Alchemy, Pimlico, Biconomy, ZeroDev, Stackup, Candide, Etherspot, and thirdweb. Each offers bundler RPCs, paymaster contracts, and SDKs for wallet developers. The cluster article on ERC-4337 infrastructure providers compares them.
​

The EntryPoint contract itself has shipped at the same canonical address on Ethereum mainnet, every major L2, and most EVM sidechains. Public deployment records for v0.6.0, v0.7.0, and v0.7 are available at eth-infinitism's deployment log.
​

ERC-7702 is a separate proposal that gives existing EOAs the ability to temporarily behave like smart contract accounts. It was included in Ethereum's Pectra hard fork, which activated on May 7, 2025. The full specification lives at EIP-7702.
​

The mechanism is different from ERC-4337. ERC-7702 introduces a new transaction type (0x04) that includes a list of authorization tuples. Each tuple signs a delegation that points the signing EOA at a smart contract implementation. While the transaction executes, the EOA runs the delegated contract's code. After execution, the delegation persists onchain until the EOA signs another authorization.
​

The two standards solve overlapping problems but through different routes. ERC-4337 builds a new account type and a new mempool. ERC-7702 upgrades the account type Ethereum already has. In practice, both will coexist because they serve different starting conditions.
​

ERC-4337 fits net-new users. A fresh wallet with no prior onchain history can deploy directly to a counterfactual smart contract account, skip the EOA stage entirely, and use passkeys from day one. Coinbase Smart Wallet is the canonical example.
​

ERC-7702 fits existing users. A wallet with five years of history, established token approvals, and a recognized address can opt into smart account features without migrating to a new address. The deeper walkthrough sits in the ERC-7702 deep dive, and the comparison article on ERC-4337 vs ERC-7702 vs native AA sets the two side by side with native L2 account abstraction.
​

One concrete way they interoperate: a 7702-delegated EOA can sign UserOperations that go through the standard 4337 EntryPoint. Account contracts implement this composition directly, so a single account can pull from both ecosystems' tooling.
​

Some chains never went through the EOA-first model. Starknet and zkSync Era ship with account abstraction built into the protocol itself, which is called native AA. Every account on these chains is a smart contract from inception, and there is no EOA equivalent.
​

Starknet, built by StarkWare and live since November 2021 on Ethereum L2, has no EOAs at all. Every Starknet account is a Cairo contract that defines its own __validate__ and __execute__ functions. Argent's Starknet wallet uses this model to support social recovery, daily limits, and session keys without any ERC-4337 plumbing. The Starknet account interface lives at docs.starknet.io.
​

zkSync Era, launched March 2023 by Matter Labs, supports both EOAs (for compatibility) and native smart accounts through its account abstraction interface. zkSync smart accounts implement IAccount with a validateTransaction and executeTransaction pattern documented at docs.zksync.io.
​

Native AA avoids the overhead of an alt-mempool and a separate EntryPoint, because the protocol itself routes account-validation calls. The trade-off is portability: a Starknet account contract cannot run on Ethereum mainnet without re-implementation. ERC-4337 accounts, by contrast, deploy to any EVM chain that has the canonical EntryPoint.
​

Several misreadings of ERC-4337 show up repeatedly in developer discussions and writeups. Each one is worth correcting because each leads to wrong architectural decisions.
​

Misconception 1: ERC-4337 required a hard fork. It did not. The entire standard runs on smart contracts and an alt-mempool. The Ethereum consensus layer was unchanged. This is precisely why the standard could ship in March 2023 without coordination with validators or core developers.
​

Misconception 2: ERC-4337 replaces EOAs. It does not. EOAs continue to exist and continue to be the dominant account type on Ethereum mainnet. ERC-4337 introduces a parallel system. A user can hold an EOA, an ERC-4337 account, and a 7702-delegated EOA simultaneously.
​

Misconception 3: UserOperations are transactions. They are not. A UserOperation is a data structure that lives in an alt-mempool. It becomes part of an Ethereum transaction only when a bundler wraps it inside a call to EntryPoint.handleOps. Block explorers that index ERC-4337 traffic show the bundler's transaction as the parent and the UserOperations as internal entries.
​

Misconception 4: Paymasters mean gas is free. Gas is paid; the paymaster is paying it. The paymaster either passes the cost back to the user in a different token (USDC, USDT) or absorbs the cost as a customer acquisition expense. The economics of app-sponsored gas deserve their own article.
​

Misconception 5: Bundlers can censor users. Any user can run their own bundler. The bundler is permissionless infrastructure, and the alt-mempool spec includes peer-to-peer gossip so that no single bundler controls a UserOperation's path to inclusion. A bundler can choose not to include a particular UserOp, but another bundler can pick it up. In practice, services like Pimlico and Alchemy run public bundlers because the economics support it.
​

Misconception 6: ERC-4337 only works on Ethereum mainnet. The EntryPoint contract has been deployed to every major EVM chain. The deployment log at eth-infinitism's repo covers Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Avalanche, Scroll, Linea, and additional networks.
​

ERC-4337 changes the practical experience of paying with stablecoins onchain. Before 4337, a USDC user needed to hold ETH on every chain where they wanted to transact, because gas could only be paid in the native gas token. Onboarding required acquiring two assets, not one. Paymasters break that constraint.
​

With a paymaster, a user can hold only USDC on Base or Polygon, send a payment, and have the paymaster deduct the equivalent USDC for gas in the same transaction. The user never touches ETH or MATIC. Eco's payment infrastructure routes stablecoin transactions across chains, and ERC-4337 paymasters compose cleanly with that routing: an app sponsors gas with a paymaster, Eco routes the underlying stablecoin from wherever the user holds it, and the recipient sees a single settlement. For teams building stablecoin checkout, the combination removes the two friction points that historically blocked mainstream use.
​

This article draws from the ERC-4337 specification, the eth-infinitism reference implementation, and public deployment records as of May 2026. Adoption claims reference launch dates from the cited vendors' own documentation, not third-party trackers. No active-account or volume figures are quoted, because reliable cross-chain ERC-4337 counts vary by source and methodology.
​

Primary sources: