​ERC-4337 is the Ethereum standard that delivers account abstraction without a hard fork. Instead of changing the protocol, ERC-4337 layers a parallel transaction system on top: users sign UserOperations, network actors called bundlers aggregate them, and a singleton EntryPoint contract validates and executes each one through the user's smart contract account. Every modern smart wallet — Coinbase Smart Wallet, Safe, Argent, ZeroDev — ships on top of this system.
​

This guide walks through ERC-4337 explained at the level a developer or technical PM needs: the data flow from signature to inclusion, the role of each component, the security model, and the gas-cost reality versus a vanilla EOA transaction. By the end you will know what a UserOperation field actually contains, how the bundler mempool differs from the public mempool, why the EntryPoint is a singleton contract, and where paymaster sponsorship money actually goes.
​

ERC-4337 is an Ethereum standard finalized in March 2023 that defines a way to do account abstraction without modifying the consensus protocol. Before ERC-4337, every transaction on Ethereum had to originate from an externally owned account (EOA) controlled by a single secp256k1 key. Smart contracts could hold funds and run code, but they could not initiate transactions. ERC-4337 fixes this from the application layer: it defines a separate transaction format (the UserOperation), a separate mempool, and a singleton on-chain contract (the EntryPoint) that walks each UserOp through validation and execution against the user's smart contract account.
​

The full specification is at eips.ethereum.org/EIPS/eip-4337. The reference EntryPoint contract is open-source at eth-infinitism/account-abstraction and audited by OpenZeppelin and ChainSecurity. Multiple bundler implementations (Pimlico's Alto, Stackup's bundler, Voltaire) interoperate with the same EntryPoint, which is what makes the system usefully decentralized.
​

The key word in "out-of-protocol" is permissionless. Anyone can run a bundler. Anyone can deploy a smart account contract. The EntryPoint is the only piece that requires consensus on what counts as canonical, and it is intentionally minimal so it can stay immutable.
​

A UserOperation is a struct that describes a transaction the user wants to execute, plus all the metadata needed to validate it without trusting the bundler.

Two fields are unusual. verificationGasLimit exists because validation is no longer a fixed protocol step — the smart account runs arbitrary code to decide if a UserOperation is authorized, and that code costs gas. paymasterAndData is how a third party agrees to pay for this transaction; it points at a paymaster contract and includes the sponsorship signature or eligibility data the paymaster needs.
​

The signature field is whatever the smart account's validateUserOp function expects. For a standard ECDSA-signed account it's a 65-byte signature. For a passkey wallet it's a P-256 signature plus authenticator data. For a multisig it's a concatenation of N signatures. The protocol does not care; the contract does.
​

A bundler is a node that listens to UserOperations, decides which ones are profitable to include, and submits them to the EntryPoint as part of a regular Ethereum transaction.
​

The bundler runs an off-chain validation pass before accepting a UserOp into its local mempool. ERC-4337 imposes specific rules — the validation function cannot read storage from arbitrary contracts, cannot call CREATE2 to deploy new contracts during validation, and cannot make external calls that read mutable state. These restrictions exist so the bundler can simulate the validation step, decide if the UserOp is valid, and trust that on-chain validation will produce the same result. Without these rules, an adversarial UserOp could pass off-chain simulation and revert on-chain, leaving the bundler to eat the gas.
​

Once validated, the bundler packages multiple UserOperations (often 1-20 per batch) into a single call to EntryPoint.handleOps(). Each UserOp pays the bundler for its included gas, plus a small premium for the bundler's overhead and risk. Bundlers compete on inclusion speed and reliability; in practice a handful of operators handle most volume, with public RPCs (like Pimlico's permissionless bundler) acting as a fallback for any wallet that wants to bypass private operators.
​

Bundler economics matter. BundleBear tracks live bundler revenue across networks; in Q1 2026, the top three bundlers (Pimlico, Stackup, Coinbase) processed roughly 78% of UserOperations on EVM chains by count, with the long tail going to permissionless deployments and self-hosted bundlers.
​

Every ERC-4337 chain has a single canonical EntryPoint. The current production version is v0.7, deployed at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 on Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and most other major EVM chains.
​

The EntryPoint does three things per UserOp.
​

Validate. Calls validateUserOp on the smart account. If a paymaster is involved, also calls validatePaymasterUserOp on the paymaster. Both must succeed without reverting; both must respect the storage-access rules.
​

Execute. Calls into the smart account with the supplied callData. This is where the actual user-facing operation runs — a token transfer, a swap, a contract call, a batch.
​

Settle gas. Calculates actual gas used and deducts payment. If the user's smart account is paying, the EntryPoint takes the fee from the smart account's deposit (an internal balance the wallet must pre-fund). If a paymaster is sponsoring, the paymaster's deposit is debited and the paymaster's postOp hook runs to handle any per-tx accounting (refunds, ERC-20 conversion).
​

The EntryPoint is intentionally minimal. The hard work — validation logic, execution logic, gas accounting policy — lives in the smart account and paymaster contracts. The EntryPoint only orchestrates.
​

A paymaster is an optional contract that agrees to pay for a UserOperation's gas. The user signs paymasterAndData into their UserOp, which authorizes the EntryPoint to deduct the gas fee from the paymaster's pre-deposited ETH instead of from the user's smart account.
​

Three paymaster patterns dominate.
​

Verifying paymaster. The dApp's backend signs an off-chain eligibility token and embeds it in paymasterAndData. The paymaster contract verifies the signature on-chain. This is the pattern for sponsored UX where the dApp wants to gate sponsorship — only authenticated users, only specific actions, only up to a per-user cap. Most consumer apps (Coinbase Smart Wallet's free transactions, Polymarket's gasless trades) use verifying paymasters.
​

ERC-20 paymaster. The user pays gas in a token (USDC, DAI, the dApp's own token). The paymaster collects the ERC-20 from the user's smart account and pays the EntryPoint in ETH on the user's behalf. Pimlico's ERC-20 paymaster is the most widely deployed reference. The user gets stablecoin-native UX and never holds the chain's native token.
​

Deposit paymaster. The user pre-funds the paymaster with stablecoin and draws down over many transactions. Useful for power users or treasury-style flows where one funding event covers a year of activity.
​

Paymaster funding is the big operational lift for any sponsored-UX product. As of April 2026, dApps and infra teams have collectively sponsored roughly $180M in cumulative gas across ERC-4337 deployments. Major sponsors include Coinbase (Base ecosystem), Farcaster (Frame transactions), and Polymarket (sponsored trade execution).
​

The smart account is the contract whose address is the user's wallet. Several reference implementations are in production.
​

Safe (formerly Gnosis Safe). The treasury default. Multi-sig first, with optional 4337 module enabling UserOperation flow. Securing tens of billions of dollars across DAOs and corporates. Audited extensively, with a long deployment history pre-dating ERC-4337.
​

Coinbase Smart Wallet. Passkey-native (P-256 signature) smart account designed for retail. Deployed deterministically via CREATE2 so the same address resolves on every supported chain. Open-source at coinbase/smart-wallet. Coinbase runs the bundler and paymaster infra, but the wallet itself is portable.
​

Kernel (ZeroDev). Modular smart account with a plug-in architecture for validators, executors, hooks, and fallbacks. Supports session keys, multi-validator setups, and cross-chain replay protection. The Kernel reference is at zerodevapp/kernel.
​

Alchemy Light Account. A minimal ECDSA-signed smart account for teams that want a simple, audited starting point. Backs Alchemy's Account Kit and the Embedded Accounts product (sign-in-with-Google flows that wrap an EOA in a smart wallet).
​

Argent X. The original smart wallet — first shipped on StarkNet, then Ethereum. Pioneered guardian-based social recovery, which most other implementations later adopted.
​

For a side-by-side feature comparison see our breakdown in Best Smart Wallet SDKs for Developers.
​

Account abstraction is not free. The validation step alone costs gas because the smart account runs code, not a hard-coded ECDSA check.

The fixed overhead is roughly 60k gas — the cost of validation plus the EntryPoint's accounting. On Ethereum mainnet at 20 gwei that's ~$0.04 per UserOp. On L2s the absolute cost is far lower (sub-cent on most chains in 2026), and the relative overhead is hidden by L2 economics.
​

Batching is where 4337 beats EOAs head-on. Three sequential ERC-20 transfers from an EOA require three separate transactions, paying 21,000 gas of base overhead each. The same three transfers from a smart account can be one UserOp with one validation pass and three execution calls — fewer fixed costs.
​

The security story has four parts.
​

EntryPoint trust. The EntryPoint is immutable and audited. Smart accounts must trust it because it controls the order of validate-execute-settle. The standard mitigation is to deploy at the well-known canonical address and verify bytecode against the published source.
​

Bundler trust. Bundlers cannot steal funds — the EntryPoint validates each UserOp on-chain — but they can censor (refuse to include) and front-run (re-order). Mitigation: any user can submit to a different bundler, and the alt-mempool is permissionless, so censorship requires a near-total operator collusion that is structurally hard to maintain.
​

Smart account trust. The wallet contract holds the funds. Bugs in the wallet are the single largest risk. The community has converged on a small number of audited, battle-tested implementations (Safe, Kernel, Coinbase Smart Wallet, Light Account); deviating without strong reason is not advised.
​

Paymaster trust. A paymaster cannot drain the user's funds (the EntryPoint enforces that), but it can grief by failing to honor a sponsorship after off-chain validation. The verifying-paymaster pattern with backend signature checks closes this gap.
​

For applications moving stablecoins, ERC-4337 unlocks two patterns that EOAs cannot easily replicate.
​

First, gas paid in stablecoin. A USDC-only treasury app can issue UserOperations whose gas is paid via an ERC-20 paymaster, never holding ETH. Combined with cross-chain routing, this means the same operational currency works end-to-end — fund the treasury in USDC, pay gas in USDC, settle on-chain in USDC.
​

Second, atomic cross-chain intent. A smart account can batch a "approve to bridge" + "deposit into Eco Routes" + "post fill order" into a single UserOp. Eco Routes treats this as one intent and selects the optimal rail (CCTP, Hyperlane, LayerZero) to deliver the stablecoin on the destination chain. Without account abstraction, the same flow takes three sequential signatures and three transactions.
​

For the deeper stablecoin-app integration pattern see Account Abstraction for Stablecoin Apps. For the broader umbrella, our guide to account abstraction walks through how 4337 fits alongside EIP-7702 and the rest of the smart-wallet stack.
​

ERC stands for Ethereum Request for Comments — a category of EIPs (Ethereum Improvement Proposals) that define application-layer standards rather than protocol-layer changes. ERC-4337 is application-layer because it ships entirely without consensus changes, in contrast to EIP-7702, which is a protocol-layer upgrade requiring a hard fork.
​

Yes. ERC-4337 has been live on mainnet since March 2023, with the v0.7 EntryPoint deployed across Ethereum, all major L2s, Polygon, BNB Chain, Avalanche, and more. Multiple bundler operators (Pimlico, Stackup, Coinbase) provide RPC endpoints, and consumer wallets like Coinbase Smart Wallet make it usable without writing any 4337-specific code.
​

No. The two are complementary. ERC-4337 is for purpose-built smart wallets where the account is a contract from the start. EIP-7702 is for upgrading existing EOAs to behave like smart wallets without migration. Most production stacks support both — a 7702 delegation can call into the same logic a 4337 smart account would use.
​

Roughly 60,000 gas more than the equivalent EOA transaction, due to the validation step and EntryPoint accounting. On Ethereum mainnet at 20 gwei that's about $0.04 of overhead. On L2s it is sub-cent. Batching multiple operations into one UserOp can offset the overhead and even beat sequential EOA transactions on total cost.
​

Anyone, in principle — the bundler role is permissionless. In practice, most volume routes through a small number of operators (Pimlico, Stackup, Alchemy, Coinbase, Biconomy) that offer hosted RPC endpoints with SLAs. Self-hosted bundlers and public bundlers exist as fallbacks.
​

A multisig is one example of a smart account: validation requires N-of-M signatures. A smart account is the broader category — any contract that can be a sender. Smart accounts can implement any validation logic, including multisig, single-signer ECDSA, passkey, ZK proof, or social recovery quorums. Safe is the dominant multisig smart account; Coinbase Smart Wallet is a single-signer passkey smart account.
​