What is account abstraction and why seed phrases are becoming optional

Introduction

The standard advice for anyone entering crypto has not changed in a decade: write down 12 words, store them offline, and never lose them. This instruction is correct under the old model. Externally owned accounts (EOAs) derive a single private key from that mnemonic, and whoever holds the key controls the funds. There is no recovery, no spending limit, no way to require a second signature. Lose the phrase, lose everything.

Account abstraction changes this premise. Instead of coupling wallet security to a single secret, AA turns the wallet itself into a smart contract, one that can enforce arbitrary rules about who may sign, how gas is paid, and what happens when a key is compromised. The upgrade does not require users to understand smart contracts. From the outside, a passkey wallet looks like logging into an app with a fingerprint. Underneath, the architecture is fundamentally different.

This guide explains how AA works at the protocol level, what ERC-4337 introduced, and why the shift matters for self-custody going forward.

How Ethereum wallets worked before account abstraction

Every Ethereum address before AA was an externally owned account. An EOA is controlled by a private key derived from a mnemonic seed phrase. The account has no on-chain logic. It can send transactions and sign messages, but it cannot enforce rules about those actions. For a broader overview of wallet types and their mechanics, see what are crypto wallets.

This design has three structural limitations:

No recovery mechanism. If the private key is lost and no backup exists, the account is permanently inaccessible. Chainalysis estimates that roughly 20% of all Bitcoin is held in wallets whose keys are presumed lost. Ethereum faces the same problem.

No spending controls. An EOA cannot limit transaction size, restrict destination addresses, or require multiple signatures. A single compromised key means total loss. Organizations that need shared control over funds must use external multisig contracts instead of native account features. For how those multisig setups work and where they have failed, see how crypto’s biggest treasuries get secured and robbed.

Gas must be paid by the sender. Every transaction requires the signing account to hold ETH for gas. A new user receiving tokens on Ethereum cannot move them without first acquiring ETH from somewhere else. This creates an onboarding dead end that has persisted since Ethereum’s launch in 2015.

What ERC-4337 introduced

ERC-4337, authored by Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, and Shahaf Nacson, went live on Ethereum mainnet in March 2023. It delivers account abstraction without requiring a hard fork, which was a critical design constraint. Previous AA proposals (EIP-2938, EIP-3074) required protocol-level changes that validators and client teams were reluctant to adopt. ERC-4337 sidesteps this by operating entirely at the smart contract layer.

The standard introduces four components:

UserOperations. Instead of sending a regular transaction, users submit a UserOperation (UserOp), a data structure that describes the intended action. UserOps enter a separate mempool, not the standard transaction mempool. Each UserOp contains the sender’s smart account address, the calldata for the intended action, gas limits, and an optional paymaster address.

Bundlers. Specialized nodes collect UserOps from the alternative mempool, bundle them into a single on-chain transaction, and submit that transaction to the network. The bundler pays gas upfront and is reimbursed by the smart account or a paymaster. Bundling creates gas savings: the fixed overhead of an Ethereum transaction is paid once per bundle rather than once per user action.

EntryPoint contract. A singleton contract deployed at a canonical address on every ERC-4337 chain. All bundled UserOps pass through this contract, which calls each smart account’s validation function, executes the operation, and handles gas accounting. The EntryPoint contract has been audited by OpenZeppelin and is immutable once deployed, providing a stable trust anchor for the entire system.

Paymasters. Optional contracts that sponsor gas on behalf of users. A paymaster can pay fees in exchange for ERC-20 tokens, absorb costs as a dapp subsidy, or implement any other payment logic. The paymaster’s validatePaymasterUserOp function is called during validation, and the paymaster can reject operations that do not meet its criteria.

The result: a wallet is no longer a key pair. It is a smart contract with a programmable validateUserOp function that decides whether a given operation is authorized.

The UserOperation lifecycle in detail

Understanding how a UserOp moves through the system clarifies what makes AA different from regular transactions.

1. Construction. The wallet application constructs a UserOp containing the target contract call, gas parameters, and a nonce. If a paymaster is involved, the paymaster address and its approval data are included.
2. Signing. The user signs the UserOp. The signature format is defined by the smart account, not by the protocol. This is the key flexibility: the smart account can accept ECDSA signatures, passkey signatures, multisig thresholds, or any other scheme.
3. Submission. The signed UserOp is submitted to a bundler via a JSON-RPC endpoint (eth_sendUserOperation). The bundler validates the UserOp off-chain to ensure it will not revert.
4. Bundling. The bundler groups multiple UserOps into a single transaction that calls the EntryPoint contract’s handleOps function.
5. Execution. The EntryPoint calls each smart account’s validation function. If validation passes, the EntryPoint executes the operation. If a paymaster is present, the EntryPoint charges the paymaster instead of the smart account for gas.
6. Confirmation. The bundled transaction is included in a block. Each UserOp within it is treated as an independent action that either succeeds or fails without affecting other UserOps in the bundle.

This lifecycle means the user never interacts with the Ethereum mempool directly. The bundler handles gas estimation, nonce management, and transaction submission. From the user’s perspective, the experience is closer to submitting a form on a website than to broadcasting a raw blockchain transaction.

Passkey wallets and the end of seed phrases

The most visible consequence of AA is that wallets can now authenticate users with passkeys instead of seed phrases.

A passkey is a cryptographic credential stored in a device’s secure enclave (the Secure Enclave on Apple devices, Titan M on Google Pixels, or TPM on Windows machines). The user authenticates with a fingerprint, face scan, or device PIN. The private key never leaves the hardware.

Coinbase Smart Wallet, launched in June 2024, uses this approach. Account creation takes under 10 seconds. The user authenticates with a biometric, and the wallet deploys a smart contract account that recognizes that passkey as a valid signer. There is no seed phrase to write down, no browser extension to install. Coinbase reported deploying over 10 million smart accounts through this flow by early 2026.

Safe (formerly Gnosis Safe) has integrated passkey signing into its smart account framework. Users can add a passkey as one of multiple signers on a multi-signature account, combining the convenience of biometric login with the security of threshold signatures.

The tradeoff is platform dependency. A passkey created on an iPhone is synced through iCloud Keychain. If a user loses all Apple devices and cannot access iCloud, the passkey is gone. This is why social recovery exists as a complementary layer. Passkey wallets are strongest when combined with at least one backup signer that uses a different authentication method.

Social recovery: replacing backup with guardians

Social recovery, proposed by Vitalik Buterin in a 2021 blog post, replaces the single backup (seed phrase) with a group of guardians.

The mechanism works as follows:

1. The wallet owner designates a set of guardians. Guardians can be friends, family members, institutional custodians, or even other smart contracts.
2. The owner sets a threshold. For example, 3 of 5 guardians must approve a recovery request.
3. If the owner loses access, they initiate a recovery process from a new device. Guardians independently confirm the request.
4. Once the threshold is met, the smart account replaces the lost signing key with a new one.

The guardians do not need to coordinate simultaneously. Most implementations include a time delay (typically 24 to 48 hours) during which the original owner can cancel a fraudulent recovery attempt.

This model eliminates the single point of failure. Losing a device does not mean losing funds, as long as enough guardians are reachable. It also eliminates the physical security burden of storing a seed phrase in a fireproof safe or safety deposit box.

Guardian selection matters significantly. Guardians should be distributed across different geographies, communication channels, and relationship types. If all guardians are in the same group chat and that chat is compromised, the recovery mechanism becomes an attack vector. Some implementations allow adding institutional guardians (such as a hardware wallet provider or a custodial service) alongside personal contacts, creating defense in depth.

Gas sponsorship and how paymasters work

Before AA, a new user who received USDC on Ethereum could not send it anywhere without first acquiring ETH to pay gas. This chicken-and-egg problem has been one of the largest onboarding barriers in crypto.

Paymasters solve this. A paymaster is a smart contract that agrees to cover gas costs for a UserOperation, subject to its own rules.

Three common paymaster models have emerged:

Dapp-sponsored gas. The application pays all gas for its users. The dapp deposits ETH into the paymaster contract and authorizes UserOps from its users. From the user’s perspective, transactions are free. Dapps treat gas as a customer acquisition cost, similar to free shipping in e-commerce. This model is particularly effective on Layer 2 networks where gas costs are fractions of a cent per transaction.

ERC-20 gas payment. The paymaster accepts an ERC-20 token (USDC, DAI) instead of ETH. The user pays for gas, but in a token they already hold. The paymaster swaps the token for ETH to reimburse the bundler. This removes the need for users to hold two separate tokens (the asset they want to use plus ETH for gas).

Subscription or session-based. The paymaster authorizes a batch of operations within a time window or spending limit. A gaming dapp might sponsor 100 transactions per day per user, for example. Session keys extend this concept further: the user signs a single transaction that grants a temporary key the right to perform specific actions (such as moves in a game) without requiring approval for each one.

Pimlico, Alchemy, and Stackup operate paymaster infrastructure that dapps can integrate with a few API calls. Alchemy alone has facilitated over one million smart account deployments through its paymaster and bundler services. The economics are straightforward: on Layer 2 networks where gas costs pennies, sponsoring user transactions is trivially cheap.

EIP-7702 and the road to native account abstraction

ERC-4337 works without protocol changes, but it is not the end state. Ethereum’s roadmap includes EIP-7702 (authored by Vitalik Buterin and Sam Wilson), which was included in the Pectra upgrade.

EIP-7702 introduces a new transaction type that allows an EOA to temporarily point to smart contract code for the duration of a single transaction. The EOA does not permanently become a smart contract. Instead, it can behave like one when needed, gaining access to batched calls, sponsored gas, and custom validation logic, and then revert to standard EOA behavior.

This matters for two reasons. First, it lets existing EOA holders (anyone with a MetaMask wallet today) access AA features without migrating to a new account. Migration has been a major friction point: users do not want to move all their assets, permissions, and on-chain history to a new address. Second, it reduces gas costs because the permanent smart account deployment overhead is avoided for users who only need AA features occasionally.

The long-term vision, discussed across multiple Ethereum Foundation roadmap posts, is that every account on Ethereum becomes a smart account by default. StarkNet and zkSync already implement this: on those networks, every account is a smart contract from creation. EIP-7702 is the bridge that moves Ethereum’s existing user base toward this model without breaking backward compatibility.

Where account abstraction is deployed today

AA adoption is concentrated on Layer 2 networks where gas costs make experimentation cheap.

Base has the highest density of smart accounts, driven by Coinbase Smart Wallet. By mid-2026, Base had processed over 30 million UserOperations. The network’s sub-cent gas costs make paymaster sponsorship economically trivial.

Polygon integrated AA early and offers native account abstraction at the protocol level in its zkEVM rollup. Polygon’s focus on gaming and social applications aligns well with the session-key model, where users need many low-value transactions without repeated approval prompts.

Arbitrum and Optimism support ERC-4337 through the standard EntryPoint contract. Major dapps on both chains have begun migrating onboarding flows to smart accounts, particularly DeFi protocols that want to offer gasless first trades. For context on how Ethereum updates enabled wallets to operate as smart contracts, the timeline begins with the ERC-4337 EntryPoint deployment.

Ethereum mainnet supports ERC-4337 but higher gas costs mean paymaster sponsorship is more expensive. Most mainnet AA usage comes from high-value multi-sig wallets (Safe) rather than consumer dapps. Safe manages over $100 billion in assets across its smart account deployments.

StarkNet and zkSync implement native account abstraction at the protocol level, meaning every account is a smart contract by default. This is the direction Ethereum’s long-term roadmap points toward.

What this does not cover

This guide focuses on the mechanism of account abstraction and its immediate consequences for wallet design. It does not cover:

• Detailed comparison of specific smart account implementations (Safe, Kernel, Biconomy, ZeroDev)
• The MEV implications of the UserOperation mempool (for MEV mechanics, see what is MEV)
• Formal security audits of individual paymaster contracts
• Cross-chain account abstraction and how smart accounts interact with bridging

Practical checks for evaluating an AA wallet

Before trusting funds to a smart account wallet, consider these questions:

Is the smart contract audited? Check whether the wallet’s smart account implementation has undergone third-party security audits. Safe’s contracts are among the most audited in DeFi. Newer implementations may not have the same track record.

What happens if the provider shuts down? A passkey wallet tied to a single vendor creates a new form of dependency. Look for wallets that allow adding multiple signers, including a traditional private key as a backup.

Where is the passkey stored? Understand whether the passkey is device-bound or synced through a cloud provider. iCloud Keychain and Google Password Manager sync passkeys, which is convenient but expands the attack surface to include cloud account security.

Does the wallet support social recovery? If the only authentication method is a passkey and the passkey is lost, funds may be unrecoverable. Social recovery adds a safety net. Check how many guardians the wallet supports and whether the recovery process has been tested.

What chains does the smart account work on? A smart account on Ethereum mainnet has a different address than the same account on Arbitrum unless the wallet uses CREATE2 deterministic deployment. Verify cross-chain compatibility before depositing funds on multiple networks.

What is the upgrade path? Some smart account implementations are upgradeable (the contract logic can be changed by the owner). This is powerful but introduces risk: a compromised upgrade key could rewrite the wallet’s validation logic. Check whether upgrades require a time delay or multi-party approval.