ERC-4337 Account Abstraction: How Smart Wallets Are Changing Crypto UX

Ethereum wallets have historically required users to manage private keys, hold ETH for gas, and sign every transaction individually. Account abstraction via ERC-4337 replaces this model with smart contract wallets that support gas sponsorship, social recovery, session keys, and transaction batching. The result is a wallet experience closer to traditional fintech apps: no seed phrases, no gas tokens, and programmable security rules.

Since its deployment in March 2023, the ERC-4337 ecosystem has grown to over 40 million smart accounts and more than 100 million UserOperations processed by end of 2024. This article covers the architecture, what it enables, who is building on it, and where it falls short.

Why Ethereum Needed Account Abstraction

Ethereum has two account types: externally-owned accounts (EOAs) controlled by a single private key, and contract accounts that run code. EOAs have fundamental limitations. They support only one signature scheme (secp256k1), require ETH to pay gas fees for every transaction, and cannot batch operations or enforce spending rules. Losing the private key means permanent loss of funds: there is no recovery mechanism at the protocol level.

Proposals to add account abstraction directly to the Ethereum protocol date back to 2016, but consensus-level changes are slow and risky. ERC-4337, authored by Vitalik Buterin, Yoav Weiss, Dror Tirosh, and four others in September 2021, took a different approach: it implements account abstraction entirely at the application layer, requiring no changes to the Ethereum protocol itself.

How ERC-4337 Works

ERC-4337 introduces a parallel transaction pipeline that sits alongside Ethereum's standard mempool. Instead of signing raw transactions, users create UserOperations: data structures describing their intent. These flow through a dedicated infrastructure of bundlers, an EntryPoint contract, and optional paymasters before reaching the blockchain.

UserOperations

A UserOperation is a pseudo-transaction containing the user's intent. It includes the sender's smart account address, calldata for the operation, gas parameters, an optional paymaster address, and a signature. The signature format is not fixed by the protocol: each smart account implementation defines its own validation logic, which is what enables passkey signing, multisig, and other schemes.

Bundlers

Bundlers are off-chain actors that monitor an alternative mempool for UserOperations, validate them, and batch multiple UserOps into a single on-chain transaction submitted to the EntryPoint contract. This role is analogous to block builders but operates at the application layer. Any node operator can run a bundler, though in practice a handful of infrastructure providers handle most volume.

The EntryPoint Contract

The EntryPoint is a singleton smart contract deployed at a canonical address across all EVM-compatible chains. Its handleOps function processes UserOperations in two phases. The verification loop validates signatures through each smart account's validateUserOp function, creates new accounts via factories if needed, and confirms paymaster willingness to sponsor gas. The execution loop then runs the actual calldata and handles gas accounting.

Version 0.7 of the EntryPoint (deployed in mid-2024) introduced packed UserOperation fields that save roughly 7,000 gas per operation on calldata, separated paymaster gas limits for better security, and a 10% penalty on unused gas to discourage inflated gas limits. The current canonical addresses are 0x5FF1...2789 for v0.6 and 0x0000...a032 for v0.7.

Paymasters

Paymasters are smart contracts that sponsor gas fees on behalf of users, enabling gasless transactions. During the verification phase, the EntryPoint calls validatePaymasterUserOp on the paymaster to confirm it will cover costs. After execution, an optional postOp callback lets the paymaster finalize accounting. Paymasters can require users to pay in ERC-20 tokens (like USDC) instead of ETH, or sponsors can cover fees entirely for onboarding or promotional purposes.

How it fits together: A user signs a UserOperation with their smart wallet. A bundler picks it up from the alt-mempool, batches it with other UserOps, and submits the bundle to the EntryPoint contract. The EntryPoint validates each operation, checks with paymasters for gas sponsorship, and executes the calldata. The user never interacts with the blockchain directly.

What Account Abstraction Enables

Smart contract wallets unlock capabilities that are impossible with EOAs. These are not theoretical: production wallets already ship these features to millions of users.

Gas Sponsorship and Fee Abstraction

New users no longer need to acquire ETH before they can interact with a dapp. Paymasters allow applications to sponsor gas fees or let users pay in stablecoins. This removes one of the steepest onboarding barriers in crypto: the requirement to hold a native gas token before doing anything useful.

Social Recovery

Smart wallets can designate trusted guardians (friends, family, or institutions) who can collectively approve key rotation if the primary key is lost. This replaces the single-point-of-failure seed phrase model with a programmable recovery mechanism. Under ERC-7579, social recovery is implemented as a plug-and-play module that any compatible smart account can install.

Session Keys

Session keys are temporary signing keys scoped to a specific dapp with spending limits and time windows. A gaming application, for example, can request a session key that allows in-game transactions up to 0.01 ETH for the next hour: the user approves once and plays without further signing prompts. When the session expires, the key becomes useless.

Transaction Batching

EOAs execute one operation per transaction. Transaction batching in smart wallets combines multiple operations (approve a token, execute a swap, stake the result) into a single UserOperation. This reduces the number of confirmations, lowers total gas costs, and eliminates the multi-step approval flow that frustrates DeFi users.

Programmable Security Rules

Smart accounts can enforce spending limits (per-transaction or per-period), restrict interactions to whitelisted contracts, require multi-factor authentication for high-value transfers, and implement time-delayed withdrawals. These rules execute on-chain and cannot be bypassed by compromising a single key.

The Modular Account Standard: ERC-7579

Early smart account implementations were monolithic: each provider built recovery, session keys, and security rules into their own contract. ERC-7579, a collaborative effort between Rhinestone, Biconomy, ZeroDev, and OKX, standardizes a modular architecture with four module types.

Accounts expose installModule and uninstallModule functions, letting users add or remove capabilities without deploying new contracts. This creates a shared ecosystem where a social recovery module built by one team works across any ERC-7579 compatible account.

Standard fragmentation: Alchemy's Account Kit uses ERC-6900 instead of ERC-7579, creating module incompatibility between ecosystems. Developers choosing an account abstraction stack should consider which module standard their target wallets support.

Who Is Building Account Abstraction Infrastructure

The ecosystem has consolidated around several production stacks, each combining smart account contracts, bundler infrastructure, and paymaster services. Most support 25 or more EVM chains.

ZeroDev Kernel

ZeroDev's Kernel is the reference implementation of the ERC-7579 modular account and the most widely deployed by unique addresses. Its architecture separates validation into a "sudo" validator for administrative operations and optional regular validators for day-to-day use. Session keys are treated as a native primitive rather than a bolt-on module, making Kernel popular with gaming and AI agent use cases.

Biconomy Nexus

Biconomy has shipped smart account products since 2021, predating ERC-4337's finalization. Their Nexus account is designed for high performance and EIP-7702 compatibility. The Modular Execution Environment (MEE) enables batched cross-chain transactions: a user can approve and swap on Arbitrum while staking on Base in a single action. Biconomy's Session Key Manager is one of the most battle-tested implementations in production.

Pimlico

Pimlico positions itself as the vendor-neutral infrastructure layer. Its Alto bundler (TypeScript, open-source) supports over 40 EVM chains, the widest coverage in the market. The permissionless.js SDK wraps any ERC-7579 modular account, and dual paymasters support both offchain sponsorship and ERC-20 fee payment. Pimlico has relayed over 200 million transactions across its supported chains.

Coinbase Smart Wallet

Launched in June 2024, Coinbase Smart Wallet uses passkey authentication (WebAuthn) to eliminate seed phrases entirely. Users authenticate with biometrics on their device. Built on ERC-4337 and deployed on Base, it became one of the leading drivers of smart account adoption on that chain.

Adoption and Growth

ERC-4337 adoption accelerated through 2024 and into 2025, driven primarily by Layer 2 networks where lower gas costs make smart account overhead less significant.

• Over 40 million smart accounts deployed across Ethereum and L2s by end of 2024, with nearly 20 million deployed in 2024 alone (roughly 7x year-over-year growth)
• More than 100 million UserOperations processed by end of 2024, a 10x increase from 2023
• Polygon leads with over 7 million smart accounts, followed by Base and Optimism
• Base saw particular growth after the Coinbase Smart Wallet launch made passkey-based wallets the default experience

The adoption pattern is notable: smart accounts are growing fastest on L2s where gas costs are measured in fractions of a cent. On Ethereum mainnet, the ~42,000 gas overhead per UserOperation remains a meaningful cost. This aligns with the broader trend of L2s absorbing user-facing activity while L1 serves as the settlement layer.

Limitations and Tradeoffs

ERC-4337 is not without costs. The application-layer approach that avoided consensus changes introduces its own overhead and complexity.

Gas Overhead

Every UserOperation carries approximately 42,000 gas of fixed overhead for the handleOps wrapper and validation. A simple ETH transfer costs roughly 80,000 gas via a smart account versus 21,000 for an EOA: nearly 4x more. For complex operations like swaps (~400,000 gas), the proportional overhead shrinks to 22-24%, but it never disappears. On L2s with sub-cent fees this is negligible; on Ethereum mainnet during congestion, it adds meaningful cost.

Bundler Centralization

Although anyone can run a bundler, most UserOperations flow through a small number of infrastructure providers (Pimlico, Alchemy, Biconomy, StackUp). This creates an intermediary layer that does not exist for standard EOA transactions. If a dominant bundler censors or delays certain UserOperations, users may experience degraded service, though they can always fall back to a different bundler or submit directly.

Address Migration

ERC-4337 requires deploying a new smart contract wallet with a new address. Users cannot upgrade their existing EOA without abandoning their transaction history, ENS names, and on-chain reputation. This migration problem was one of the primary motivations behind EIP-7702.

Infrastructure Complexity

Developers integrating ERC-4337 must choose a smart account implementation, a bundler provider, a paymaster strategy, and a module standard (ERC-7579 vs ERC-6900). The stack is more complex than sending a standard Ethereum transaction. SDKs from providers like ZeroDev and Alchemy abstract most of this, but the underlying complexity does not disappear.

EIP-7702 and the Push Toward Native Account Abstraction

The Pectra upgrade, activated on Ethereum mainnet on May 7, 2025, introduced EIP-7702: a new transaction type that allows existing EOAs to temporarily delegate execution to a smart contract. Unlike ERC-4337, which requires deploying a new account, EIP-7702 lets users keep their original address while gaining smart wallet capabilities.

A Type 4 transaction includes an authorization_list field containing chain IDs and delegate contract addresses. The protocol writes a delegation marker into the EOA's code field, and execution runs in the EOA's storage and balance context. Delegation can be per-transaction or persistent.

The two standards are complementary rather than competing. ERC-4337 defines the smart wallet infrastructure (bundlers, paymasters, modular accounts), while EIP-7702 allows every existing Ethereum address to participate in that infrastructure without migration. Most ecosystem teams now treat them as a layered stack. Further proposals like RIP-7560 aim to absorb the alt mempool into Ethereum's main mempool, making UserOperations first-class citizens at the protocol level and eliminating EntryPoint overhead entirely.

Lessons for Bitcoin Wallet UX

ERC-4337's impact extends beyond Ethereum. The problems it solves: key management, onboarding friction, and inflexible security models: are universal across blockchains. Bitcoin L2s face the same UX challenges, though they approach solutions differently.

On Ethereum, account abstraction required building an entirely new infrastructure layer: bundlers, paymasters, modular account contracts, and a separate mempool. This was necessary because EVM account types are baked into the protocol. Bitcoin L2s like Spark can learn from these patterns while avoiding some of the complexity. Spark's statechain-based architecture already provides self-custodial transfers without on-chain transactions, and its operator model enables features like offline receiving without the smart contract overhead of EVM-based approaches.

The core insight from Ethereum's account abstraction journey is that wallet UX, not protocol efficiency, is what determines mainstream adoption. Whether through smart contract wallets on Ethereum or embedded wallets on Bitcoin L2s, the direction is the same: abstract away keys, gas, and complexity until the user experience resembles the traditional fintech apps people already know.

Getting Started

Developers exploring account abstraction can start with the ERC-4337 documentation for architectural details, then evaluate the provider comparison above based on chain coverage, module standard preference, and pricing model. For Bitcoin-native wallet development, the Spark SDK offers an alternative approach to improving wallet UX without the EVM smart contract stack.

For deeper dives on related topics, see our research on self-custodial wallet UX barriers, embedded wallet design patterns, and passkey-based wallet authentication.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.