The account abstraction stack is the set of contracts and offchain services that let a smart contract act as a user's wallet under ERC-4337. It has six layers: the account contract itself, a factory that deploys new accounts, the EntryPoint singleton that processes user operations, a bundler service that submits them to the mempool, a paymaster contract that can sponsor or repay gas, and one or more validator modules that authorize each operation. Standard references live at erc4337.io and the EIP repository on ethereum.org.
​

An ERC-4337 wallet is not a single contract. It is a coordinated set of components that together turn a smart contract into something that behaves like an externally owned account (EOA) for the user while supporting features that EOAs cannot: arbitrary signature schemes, gas sponsorship, batched calls, session keys, and social recovery. The standard was finalized in March 2023, and the second EntryPoint version, v0.7, went live mid-2024 with a redesigned UserOperation format and a separate Stake Manager for paymasters.
​

Reading the stack top-down: a user signs a UserOperation, a bundler picks it up from a dedicated mempool, the bundler submits a batch to the EntryPoint contract on the target chain, the EntryPoint loops through each operation and asks the account contract to validate it, the paymaster (if attached) is consulted for gas sponsorship, validators inside the account check the signature against whatever scheme the account uses, and finally the EntryPoint executes the call. Every piece is replaceable. The same account contract can run behind different bundlers; the same bundler can serve accounts from Safe, Kernel, LightAccount, and Etherspot interchangeably.
​

The modular shape is what makes the stack interesting. A team building a consumer wallet picks an account implementation (Coinbase Smart Wallet uses a custom one; many infra vendors ship LightAccount or Kernel), routes operations through a bundler provider (Pimlico, Alchemy, Biconomy, Stackup, Candide), attaches a paymaster for gas policy, and installs validator modules per ERC-7579 or ERC-6900 for features like WebAuthn signatures and session keys.
​

The account contract is the user's wallet. It holds funds, exposes a validateUserOp function for the EntryPoint to call during validation, and an execute function for the actual transaction payload. Different vendors ship different implementations, each with trade-offs across audit history, modularity, gas cost, and recovery features.
​

Safe (formerly Gnosis Safe) is the longest-running smart account, with audits dating back to 2018 and over tens of billions in TVL per DeFiLlama across deployments. The Safe contracts support ERC-4337 through the Safe{Core} 4337 module, which lets a Safe act as a UserOperation account while keeping its native multisig and module system. Safe is the default choice for treasuries, DAOs, and any team that needs multi-signer governance.
​

Kernel is built by ZeroDev and was the first account to ship native ERC-7579 modular support. Kernel separates validation and execution into pluggable modules, so a single account can hold an ECDSA validator for one signer, a WebAuthn validator for a passkey, and a session-key module for a dapp, each governing different permissions. Kernel is documented at docs.zerodev.app.
​

LightAccount is Alchemy's minimal ERC-4337 implementation. It is a single-owner account with optimized gas cost, intended for high-volume consumer apps that do not need module installation. Source is at the alchemyplatform/light-account GitHub repository.
​

SimpleAccount is the reference implementation that ships in the eth-infinitism repo alongside the EntryPoint contracts. It is a starting point for teams writing their own account, not a production wallet. It supports a single ECDSA signer and is the simplest possible 4337 account. Found at eth-infinitism/account-abstraction.
​

Etherspot Modular Account ships ERC-7579 support plus Etherspot's permissions module and a built-in session-key system. It is documented at etherspot.fyi and targets teams that want the modular shape without writing module code themselves.
​

Soul Wallet is an open-source account focused on social recovery, with guardians and timelock-based recovery flows. It uses WebAuthn passkeys as the default signer and is documented at docs.soulwallet.io.
​

A factory contract deploys new account instances. The pattern matters because ERC-4337 supports counterfactual deployment: a user's account address is computed deterministically from the factory address, the implementation address, and a salt, so funds can be sent to the address before the contract actually exists onchain. The account is deployed the first time the user submits a UserOperation. The initCode field on the UserOperation carries the factory call, which the EntryPoint executes during validation.
​

Every account implementation has its own factory. SafeProxyFactory deploys Safe accounts. KernelFactory deploys Kernel accounts. LightAccountFactory deploys LightAccount instances. The factory typically takes the owner's public key (or in the WebAuthn case, the passkey credential ID and public key) plus a salt, and returns the new account's address. The same factory address combined with the same owner and salt always yields the same account address, which is what makes counterfactual addressing work.
​

The downside of counterfactual accounts is that funds sent to an undeployed address cannot be moved until the first UserOperation deploys the contract. In practice, infra providers handle this by attaching the factory call to the first transaction. For users who never interact with the chain, the address stays counterfactual indefinitely and the funds sit at an address whose code is the bytecode the factory would produce.
​

The EntryPoint is the singleton contract that every ERC-4337 bundle routes through. It validates each UserOperation, calls the account's validateUserOp, checks the paymaster, executes the call, and refunds unused gas. Two versions are live in 2026: v0.6, deployed at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 in March 2023, and v0.7, deployed mid-2024 at 0x0000000071727De22E5E9d8BAf0edAc6f37da032.
​

The v0.7 redesign collapsed several UserOperation fields into packed bytes to reduce calldata cost. callGasLimit and verificationGasLimit were packed into a single accountGasLimits field, maxFeePerGas and maxPriorityFeePerGas into gasFees, and the paymaster fields into a single paymasterAndData with a defined sub-format. The change cut roughly 7,000 gas off a typical UserOperation and aligned the layout for the upcoming Pectra-era native AA work.
​

Paymaster handling also changed. v0.7 introduced a separate Stake Manager interface and required paymasters to implement postOp with an explicit mode parameter (succeeded, reverted, or post-op reverted), which fixed a class of edge cases where a paymaster could be charged for a transaction that reverted after its check passed. Migration notes live in the eth-infinitism release notes. New deployments in 2026 should target v0.7; v0.6 is still supported by most bundlers for backward compatibility, but features like ERC-7579 hook composition assume v0.7 semantics.
​

A bundler is an offchain service that runs an alt-mempool for UserOperations, validates them against the EntryPoint's rules, and submits batches as regular Ethereum transactions. Bundlers are the equivalent of EOA mempool relayers, with the extra responsibility of running the validation simulation locally before accepting a UserOp into the mempool. The bundler standard interface, defined in ERC-4337's mempool section, exposes JSON-RPC methods like eth_sendUserOperation and eth_estimateUserOperationGas.
​

Production bundlers in 2026 include Pimlico, Alchemy, Biconomy, Stackup, and Candide. Each runs the same protocol but with different chain coverage, gas estimation accuracy, and reliability profiles. Pimlico and Alchemy have the widest chain coverage; Stackup runs an open-source bundler (skandha and silius implementations exist in the public repos); Candide focuses on self-hostable infrastructure.
​

The bundler economic model is that the bundler pays the L1 gas, then collects it back from the EntryPoint as part of the batch settlement. The EntryPoint reimburses the bundler from either the account's deposit or the paymaster's deposit, plus a markup the bundler sets via the maxFeePerGas field on each UserOp. If the bundler's simulation passes but the onchain transaction reverts (a "reputation" violation), the bundler eats the gas. This is why bundlers enforce a restricted opcode list during simulation, defined in the ERC-4337 mempool rules.
​

A paymaster is a contract that can pay for a UserOperation's gas instead of the account itself. The user signs a UserOp that references a paymaster address; the EntryPoint asks the paymaster to validate sponsorship; if approved, the paymaster's pre-funded deposit covers the gas, and the bundler is reimbursed from that deposit instead of from the user's balance. This is the mechanism behind gasless transactions for end users.
​

Two paymaster patterns dominate. Verifying paymasters require an offchain signature from the sponsor's server, which the paymaster contract checks before approving sponsorship. This is the dominant pattern for app-sponsored gas because the sponsor's backend can apply arbitrary policy (per-user limits, whitelisted contracts, time-bounded campaigns) before signing. Token paymasters accept payment in an ERC-20 like USDC and convert internally to ETH for gas, which lets users hold zero ETH on a chain and still transact. The token-paymaster pattern is documented in the Pimlico permissionless docs.
​

Paymaster economics matter because the sponsor is on the hook for every transaction they approve. A paymaster deposit needs to be sized for the expected transaction volume, monitored for depletion, and protected against griefing where a malicious user submits transactions that pass validation but consume the maximum gas. v0.7's revised postOp flow closes most of the griefing vectors that existed in v0.6. For a deep dive on sponsorship economics, see what is a paymaster and gas sponsorship 2026.
​

Validators decide whether a UserOperation is authorized. In a basic ERC-4337 account, validation is hard-coded: the account checks an ECDSA signature against a fixed owner address and approves or reverts. Modular accounts replace that hard-coded check with installable validator modules, so a single account can validate against multiple signature schemes and permission scopes at once. The two competing module standards are ERC-7579 (minimal modular accounts, broad vendor support) and ERC-6900 (Alchemy-led, more opinionated about lifecycle hooks).
​

ECDSA validators are the default: a single secp256k1 signer, the same scheme an EOA uses. Every account ships an ECDSA validator. WebAuthn validators verify passkey signatures using the secp256r1 curve, which Ethereum cannot verify natively, so the validator either uses the RIP-7212 precompile on supported chains (Polygon PoS and zkSync since 2024; OP Stack chains like Optimism and Base post-Pectra in 2025) or a Solidity P-256 verifier. Coinbase Smart Wallet is the highest-profile WebAuthn-only account, launched in June 2024 with no seed phrase and passkey-based auth.
​

Multisig validators require N-of-M signatures across a guardian set. Safe's native module pattern is the canonical example; ZeroDev ships an ERC-7579 multisig validator that any Kernel account can install. Session-key validators, defined under ERC-7715, scope a temporary signer to specific contracts and methods for a bounded time, which is what makes dapp sessions usable without a signature popup per click. Kernel, Etherspot, and Safe all ship session-key modules.
​

The ERC-7579 vs ERC-6900 split mirrors broader 4337 vendor politics. ERC-7579 is simpler, has a smaller interface surface, and is supported by Kernel, Safe, Etherspot, and Nexus. ERC-6900 adds more lifecycle hooks (pre-execution, post-execution, runtime validation) and is championed by Alchemy through its Modular Account v2. Teams writing a single module that should run on many accounts pick ERC-7579 for compatibility breadth; teams writing a complex permission system pick ERC-6900 for the lifecycle hooks.
​

Walking through a single transaction makes the stack concrete. A user opens a consumer wallet built on Kernel, signs a transfer with their passkey, and watches it confirm without holding ETH. The eight steps:
​

1. The wallet SDK constructs a UserOperation: sender (the account address, possibly counterfactual), nonce, callData (the transfer payload), accountGasLimits, gasFees, paymasterAndData (pointing to the app's sponsoring paymaster), and a signature field initially empty.
​

2. The wallet computes the UserOperation hash per the EntryPoint v0.7 spec and asks the user's passkey to sign it. The passkey returns a WebAuthn signature, which the SDK encodes into the signature field along with the WebAuthn client data and authenticator data the validator will need.
​

3. The SDK posts the UserOp to a bundler RPC endpoint via eth_sendUserOperation. The bundler simulates the UserOp against a forked state to confirm validation passes, the paymaster approves, and the call executes successfully. If simulation passes, the bundler accepts the UserOp into its alt-mempool.
​

4. The bundler batches accepted UserOps (typically every 1-2 seconds) and submits a single Ethereum transaction calling EntryPoint.handleOps() with the batch. The transaction's from is the bundler's EOA.
​

5. EntryPoint loops through each UserOp. For each, it calls the account's validateUserOp, which invokes the WebAuthn validator module to verify the passkey signature. The validator returns a validation result containing the time range during which the signature is valid.
​

6. EntryPoint calls the paymaster's validatePaymasterUserOp. The verifying paymaster checks the offchain sponsor signature against its known signer key and returns approval with a post-op context.
​

7. EntryPoint executes the account's callData. For a transfer, the account calls USDC.transfer(recipient, amount). The transfer succeeds, and execution returns to the EntryPoint.
​

8. EntryPoint calls the paymaster's postOp with the actual gas used. The paymaster's deposit is debited; the bundler's EOA is reimbursed from the EntryPoint, including the bundler's markup. The UserOp is now final.
​

From the user's perspective, this is one signature and one screen. From the chain's perspective, it is a single transaction from a bundler EOA that touches six contracts. For a deeper bundler walkthrough including mempool rules, see what is a bundler.
​

The 2026 vendor landscape for ERC-4337 infrastructure has consolidated around five providers, each covering different layers of the stack. The matrix below shows which layers each ships:
​

Alchemy and Pimlico are the most widely used bundlers by request volume. ZeroDev's Kernel is the most widely deployed ERC-7579 account by unique addresses. Biconomy's Nexus is the newer ERC-7579 entry and is positioned for high-volume consumer apps. Safe via Candide is the choice for treasuries that want native 4337 support on top of the Safe multisig. For a detailed infra comparison, see best ERC-4337 infrastructure 2026.
​

The right stack depends on three questions: who is the user, what is the signature scheme, and what is the gas policy. A consumer app onboarding non-crypto users with passkey auth and full gas sponsorship picks differently than a DeFi protocol adding session keys to its existing UI.
​

Consumer onboarding (passkey + sponsored gas): Coinbase Smart Wallet for the simplest path (no infra at all, Coinbase runs the bundler and paymaster), or Kernel plus Pimlico bundler plus a verifying paymaster for self-hosted control. Both target WebAuthn signatures and zero-ETH UX. The trade-off is that Coinbase Smart Wallet is a Coinbase-controlled implementation; Kernel is open-source and self-deployable.
​

DeFi session keys (existing wallet + scoped permissions): ERC-7715 session-key modules installed on a Kernel, Etherspot, or Safe account, with permissions scoped to the dapp's contracts. The user keeps their existing signer (EOA or passkey) for high-stakes ops and grants the dapp a session key for the click-through actions.
​

Team treasury (multisig + 4337): Safe via the Safe{Core} 4337 module, paired with Candide or Pimlico for bundler service. The multisig requirement is satisfied by Safe's native threshold logic; the 4337 layer adds gas sponsorship and session-key support on top.
​

High-volume single-signer wallet (gas-optimized): LightAccount on Alchemy, or a custom minimal account. LightAccount strips out module support to minimize gas per UserOp, which matters at scale. The trade-off is no future module installation.
​

BYO account (existing custom wallet): Pimlico or Stackup for the bundler and paymaster layer without prescribing the account implementation. Useful when a team has already shipped a smart account (gaming projects, exchanges) and wants 4337 compatibility without rewriting the wallet.
​

ERC-4337 is the offchain path: it works without changes to the Ethereum protocol because the EntryPoint contract handles everything in a regular transaction. ERC-7702, which went live in the Pectra hard fork on May 7, 2025, takes a different path: it lets a regular EOA temporarily delegate to a smart contract for the duration of a transaction, giving the EOA smart-account features (batched calls, gas sponsorship, custom signature checks) without deploying a separate account.
​

The two coexist. ERC-4337 remains the path for accounts that exist independently of any single EOA: WebAuthn-only wallets, multisig treasuries, counterfactual accounts. ERC-7702 is for users who want to keep their existing EOA address and add smart-account features to it. Some accounts (Kernel, Safe, MetaMask Smart Account) already support both modes. For the standards comparison, see ERC-4337 vs ERC-7702 vs native AA.
​

The longer-term direction is native AA at the protocol level, where validation and execution are decoupled in the EVM itself and account contracts are first-class. Proposals like EIP-7701 and the ongoing RIP-7560 work outline what that looks like. Until then, the 4337 stack plus 7702 covers production use cases, and most infra vendors have committed to supporting both indefinitely.
​

Eco Routes operates at the transaction layer below the wallet: any 4337 account, whether a Coinbase Smart Wallet, a Safe, or a Kernel, can use Eco Routes to move stablecoins across the supported chains in a single intent. The wallet signs a UserOperation; the account dispatches the intent to Eco's solver network; the solver settles the cross-chain leg through Hyperlane and CCTP-equivalent rails; and the destination chain receives the funds in the same account address (or a different one, if specified). For builders integrating Eco Routes into an AA wallet, the SDK works with any ERC-4337 account that can call contracts, and the gas for the destination-chain settlement can be sponsored by an app's paymaster.
​

Sources and methodology. ERC-4337 specification from eips.ethereum.org/EIPS/eip-4337 (final March 2023); EntryPoint v0.7 changes from the eth-infinitism release notes; ERC-7579 from eips.ethereum.org/EIPS/eip-7579 and ERC-6900 from eips.ethereum.org/EIPS/eip-6900; ERC-7715 session keys from eips.ethereum.org/EIPS/eip-7715; Safe 4337 integration from docs.safe.global; Kernel from docs.zerodev.app; LightAccount from the alchemyplatform/light-account repo; SimpleAccount from eth-infinitism/account-abstraction; Pectra hard fork (which shipped ERC-7702) on May 7, 2025. Figures refresh quarterly.
​