Account abstraction

Account abstraction is the shift from wallets controlled by a single private key to wallets that are programmable smart contracts, so a "wallet" can define its own rules for signing, paying gas, recovering access, and batching actions. It reached Ethereum through ERC-4337 in 2023 without any protocol change, and got a second, complementary upgrade in 2025 through EIP-7702, which lets ordinary private-key wallets borrow smart contract powers on demand. Today it is the standard UX layer under most consumer crypto apps, and it is also the layer that will let AI agents hold and spend crypto on their own in the coming web4 era.

What Account Abstraction Actually Means

Ethereum has always had two kinds of accounts: externally owned accounts controlled by a private key, and contract accounts controlled by code. Despite great advances in the smart contract wallet ecosystem, EOAs have held back broad adoption of UX improvements across applications, so this direction focuses on adding short-term functionality improvements to EOAs. Account abstraction means making the "account" itself abstract, so it can be a smart contract with custom logic instead of a rigid key-based account.

Account abstraction is the shift from hardcoded Ethereum accounts controlled by a single private key to programmable smart contract accounts that can define their own rules for validation, gas, and recovery. In practice, it means your wallet can feel like a modern app: log in with a passkey, let a dapp sponsor your gas, batch three approvals into one tap, and add a recovery guardian that is not your seed phrase.

How It Actually Works

ERC-4337 introduced this without touching Ethereum's consensus layer. 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 EntryPoint is the trust anchor of the whole system: the EntryPoint is immutable and audited, and smart accounts must trust it because it controls the order of validate-execute-settle. Optional paymaster contracts can cover gas so users never need ETH in their wallet, and the current production version is v0.7, deployed at the same address on Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and most other major EVM chains.

Two years later, Ethereum's Pectra hard fork added a second path. EIP-7702 lets an externally owned account temporarily delegate execution to a smart contract by attaching code to its address for the duration of a transaction, bringing smart-account features, batched transactions, gas sponsorship, session keys, and transaction-level signing rules to the same private keys that already secure most of Ethereum's user accounts. Mechanically, this works by attaching a list of authorization tuples to the transaction, and for each tuple a delegation indicator is written to the authorizing account's code, so all code executing operations load and execute the code pointed to by the delegation. It replaced an earlier design: EIP-3074 had been on the roadmap for two years and was ultimately rejected because it gave one specific contract too much trust, while EIP-7702 distributes that trust by letting users sign delegations to any contract they choose.

The two standards are not rivals. ERC-4337 and EIP-7702 are complementary, and EIP-7702 transactions are fully compatible with ERC-4337 infrastructure and can delegate access to ERC-4337 smart accounts. There is a third phase still on paper: EIP-7701 represents the intended long-term destination, a model where validation logic, nonce handling, and gas sponsorship are protocol primitives rather than application-layer workarounds, with the current roadmap running ERC-4337 and EIP-7702 as production solutions and EIP-7701 as the eventual convergence point. It remains theoretical for now, as its Stagnant status means the benefits are not yet realizable in production.

What People Get Wrong

The biggest misconception is that account abstraction means "new wallet, new address, start over." EIP-7702 was built specifically to avoid that: existing EOAs keep their address, balance, and history while gaining smart wallet behavior. The second misconception is treating ERC-4337 and EIP-7702 as competing standards to choose between, when in practice production stacks combine both, with EIP-7702 for legacy EOAs, ERC-4337 for fresh smart accounts, and ERC-6900/7579 for modular extensions layered on top.

People also underestimate the operational cost of "gasless" experiences. Sponsoring gas is not free, it is a real line item: as of April 2026, dApps and infra teams have collectively sponsored roughly $180M in cumulative gas across ERC-4337 deployments, with major sponsors including Coinbase, Farcaster, and Polymarket. And a meaningful chunk of the infrastructure is more centralized than the marketing implies: in Q1 2026, the top three bundlers processed roughly 78% of UserOperations on EVM chains by count, with the long tail going to permissionless deployments and self-hosted bundlers.

How to Use It Today

For a new user, the simplest entry point is a passkey-based smart wallet. Coinbase's is a good example: Coinbase Smart Wallet launched June 5, 2024 as a passkey-based ERC-4337 wallet that works across Base, Ethereum, Arbitrum, Optimism, Polygon, Zora, and additional EVM chains, has no seed phrase, and handles recovery through passkeys synced via iCloud Keychain, Google Password Manager, or hardware authenticators.

If you already have an existing MetaMask or Rabby-style wallet, you don't need to migrate anything. EIP-7702 adds a new transaction type where an existing EOA can temporarily point to a smart contract implementation, so ERC-4337 is for new smart accounts and EIP-7702 is for upgrading the existing installed base of EOAs. Practically, that means:

• Check whether your wallet supports 7702 delegation (MetaMask, Rabby, and Trust added support through 2025-2026).
• Sign a delegation to a vetted implementation contract rather than an unknown one, since poorly designed delegate contracts can expose accounts to replay attacks, gas griefing, or unauthorized transfers, which is why critical fields like nonce, gas, value, and target must be included in the signed data.
• Set up a recovery guardian if the wallet offers social recovery, rather than relying solely on a seed