Account abstraction

# 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.

Updated July 2026: corrected the EntryPoint version reference to reflect the v0.8 upgrade that shipped alongside Pectra.

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 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 EntryPoint is the trust anchor of the whole system: the EntryPoint is immutable and audited. 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. The reference EntryPoint v0.6 deployed to Ethereum mainnet on 1 March 2023, after audits by OpenZeppelin and Certora, and v0.7 shipped in 2024 with improved paymaster and aggregator interfaces. v0.8 deployed in May 2025 alongside Ethereum's Pectra hard fork, which activated EIP-7702, a protocol-level primitive that lets externally-owned accounts delegate execution to contract code in a single transaction, and EIP-7702 is co-authored by Vitalik Buterin, the lead author of ERC-4337. Both v0.7 and v0.8 remain deployed at their canonical addresses on Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and most other major EVM chains, with v0.8 adding native EIP-7702 support so bundlers can process 7702 authorizations directly as UserOperations.

Two years later, Ethereum's Pectra hard fork added a second path. EIP-7702 was finalized as part of the Pectra hard fork, which activated on Ethereum mainnet at slot 11649024 on May 7, 2025. It lets an externally owned account temporarily delegate execution to a smart contract by attaching code to its address, 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 the EOA's account state stores a 23-byte delegation indicator (the prefix 0xef0100 followed by the 20-byte implementation address) and the EVM treats calls to the EOA as if they were calls to that implementation. It replaced an earlier design: ERC-7702 had a long road. The EIP was first published in May 2024 by Vitalik Buterin and co-authors as a replacement for the older ERC-3074 proposal, which had a similar goal but a different mechanism (an AUTH opcode).

The two standards are not rivals. EIP-7702 is designed to complement ERC-4337, not replace it. While ERC-4337 provides pure smart contract accounts, EIP-7702 makes those account abstraction features accessible to existing EOAs without requiring new wallet creation or migration. There is a third phase still on paper: EIP-7701 is a proposed Ethereum core protocol upgrade that adds native account abstraction at the protocol layer using the EVM Object Format (EOF). Authored by Vitalik Buterin, Yoav Weiss, Alex Forshtat, Dror Tirosh, and Shahaf Nacson and first posted to Ethereum Magicians in May 2024, it introduces a dedicated transaction type (AA_TX_TYPE) and a fixed entry-point address at 0x7701 that the protocol itself enforces. It remains theoretical for now: EIP-7701 is Stagnant as of April 2026, and its validator section cannot ship without EOF, making EIP-7701 contingent on a prerequisite that has not cleared the Ethereum governance process. Any developer building AA infrastructure for production use should plan around ERC-4337 and EIP-7702, not EIP-7701.

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: EIP-7702 allows existing EOAs to gain smart contract functionality without creating a new account or transferring assets. 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. Major sponsors include Coinbase (Base ecosystem), Farcaster (Frame transactions), and Polymarket (sponsored trade execution). And a meaningful chunk of the infrastructure is more centralized than the marketing implies: 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.

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 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.

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. Adoption since Pectra has clustered in the wallet stack that already shipped ERC-4337 features. MetaMask shipped its Smart Account feature in 2025 with ERC-7702 as the primary upgrade path for existing MetaMask users, letting a user upgrade their existing EOA to a smart account that supports batching and gas sponsorship without changing the address. Rabby published its ERC-7702 implementation roadmap shortly after Pectra and shipped support for delegated EOA mode in late 2025, and Trust Wallet added support for signing and displaying ERC-7702 authorizations after Pectra.
• 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