Account abstraction means your crypto account is controlled by code you choose instead of by one fixed private key. That code decides what counts as a valid signature, who pays the gas and what the account is allowed to do, so a wallet can offer passkey logins, spending limits, batched transactions, gas paid by someone else and key recovery. On Ethereum it arrives through two routes: ERC-4337 smart accounts (live since the EntryPoint contract launched on 1 March 2023) and EIP-7702, which lets an ordinary address borrow smart-account code and went live with the Pectra upgrade on 7 May 2025. Chains such as Starknet, ZKsync and Abstract build it into the protocol. The trade-off is new attack surface: EIP-7702 delegation phishing has already drained users, and multisig smart accounts were at the centre of the $1.5 billion Bybit theft in February 2025.
Most explainers of account abstraction were written in 2022 and 2023, before the idea shipped at scale. They describe EIP-4337 as “coming soon”, treat externally owned accounts and smart contracts as two separate worlds, and leave out EIP-7702 entirely. This guide covers what account abstraction is, how ERC-4337 and EIP-7702 actually work today, which EntryPoint versions exist, how native account abstraction on other chains differs, how smart wallets compare with multisig and MPC wallets, current adoption figures and the security incidents you should know about. All statuses and figures were checked on 14 October 2026.
What is account abstraction?
Account abstraction is a design in which a blockchain account’s rules (how it proves who is signing, how it pays fees and what it may do) are set by programmable code instead of being hard-wired to a single private key. A wallet built this way is usually called a smart account or smart contract wallet.
The “abstraction” is the protocol stepping back. Instead of the chain checking one kind of signature from one key, it asks the account’s own code: “is this transaction valid?” The account can answer with a passkey check, two of three signatures, a daily limit, or anything else a developer writes.
Google’s AI Overview for this search describes account abstraction as turning “rigid user accounts into programmable smart contract wallets”. That is right as far as it goes, but it stops before the part that matters in 2026: on Ethereum you can now get there either by deploying a new smart account or by upgrading the address you already have.
What are blockchain accounts? EOAs vs contract accounts
A blockchain account is the identity that holds assets and sends transactions. Ethereum has two types:
- Externally owned accounts (EOAs). In ethereum.org’s words, “EOAs are simply public-private key pairs.” Whoever holds the private key can do anything, and without it you “can do nothing”. A standard MetaMask or Trust Wallet address is an EOA.
- Contract accounts. Accounts controlled by code. Before account abstraction they could not start a transaction on their own: an EOA had to call them first.
That split is the root problem. If your account is an EOA, a lost seed phrase means lost funds, every action needs ETH for gas, and you cannot add rules such as a spending limit. Account abstraction removes the “only a key can start a transaction” assumption.
What account abstraction lets a wallet do
- Different ways to sign. Passkeys from your phone or laptop, several signers, or a hardware module instead of a seed phrase.
- Recovery. ethereum.org notes that “backup keys can be added to a wallet, enabling key replacement if the primary key is compromised”, and that you can share account security “across trusted devices or individuals”. That second idea is usually called social recovery.
- Gas sponsorship and gas in other tokens. A paymaster contract can pay the fee for you, or accept a token such as a stablecoin instead of ETH.
- Batching. Approve and swap, or several transfers, in one confirmation.
- Limits and session keys. Daily caps, allow-lists, or a temporary key a game or app can use for set actions only.
None of these is automatic. Each is something a wallet developer can build, and each adds code that can have bugs.
How ERC-4337 works: UserOperations, bundlers, EntryPoint, paymasters
ERC-4337 is the route that needed no change to Ethereum’s consensus rules. The ERC-4337 specification (status Final, checked 14 October 2026) says it “completely avoids the need for consensus-layer protocol changes” by adding a higher-layer transaction object and a shared contract. The moving parts:
- UserOperation. Your wallet does not send a normal transaction. It builds a UserOperation, a pseudo-transaction describing what your smart account should do, and signs it in whatever format the account accepts. It goes to a separate UserOperation mempool, not the normal transaction pool.
- Bundler. A node that collects UserOperations, simulates them to check they will pay, and packs many of them into one real transaction calling
handleOps. The bundler pays the ETH gas up front and is reimbursed. - EntryPoint. A single shared contract, “a singleton contract to execute bundles of UserOperations”. It asks each account to validate its UserOperation, collects payment, then executes.
- Account and factory. Your smart account is a contract. If it does not exist yet, a factory contract deploys it in the same flow, so you can receive funds at the address before it is deployed.
- Paymaster. Optional: “a helper contract that agrees to pay for the transaction, instead of the sender itself”. This is how apps sponsor gas or let you pay in tokens.
- Aggregator. Optional: lets many UserOperations share one combined signature check to save gas.
Developers should note that the current specification lists EIP-7702 as a requirement and has a section for bundling 7702 authorizations into UserOperations, so the two routes are now designed to work together rather than compete.
EntryPoint versions
Wallets, bundlers and paymasters have to agree on which EntryPoint they use, and signatures are tied to the EntryPoint address so they cannot be replayed across versions. These are the versions published in the eth-infinitism reference repository (checked 14 October 2026):
| Version | EntryPoint address | Main changes |
|---|---|---|
| v0.6 | 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 | EntryPoint manages nonces; new UserOperation hash |
| v0.7 | 0x0000000071727De22E5E9d8BAf0edAc6f37da032 | PackedUserOperation struct; simulation moved off-chain; penalty on unused execution gas; paymaster postOp called once |
| v0.8 | 0x4337084d9e255ff0702461cf8895ce9e3b5ff108 | Native EIP-7702 authorization support; EIP-712 UserOperation signatures; Simple7702Account |
| v0.9 (latest) | 0x433709009B8330FDa32311DF1C2AFA402eD8D009 | ABI-compatible with v0.7 and v0.8; separate paymasterSignature; block-number validity ranges |
Source: eth-infinitism/account-abstraction GitHub releases (checked 14 October 2026). The repository warns you to verify EntryPoint addresses and code hashes against the official audit report before switching. OpenZeppelin dates the mainnet deployment of the first audited EntryPoint to 1 March 2023.
What is EIP-7702? Smart features for your existing address
EIP-7702 lets an ordinary address (an EOA) point to a smart contract and run that contract’s code as its own, while keeping the same address and private key. It is a core protocol change, so it needed a network upgrade: the Ethereum Foundation’s Pectra mainnet announcement set activation for 7 May 2025 at 10:05:11 UTC (epoch 364032), with EIP-7702 listed as “Set EOA account code”.
How it works, from the EIP-7702 specification (status Final, checked 14 October 2026):
- A new transaction type,
0x04, carries a list of signed authorizations. Each one is[chain_id, address, nonce, y_parity, r, s]: “my account may run the code at this address”. - Your account’s code is set to a delegation designator,
0xef0100followed by the contract address. Calls to your account then run that contract’s code in your account’s context. - A
chain_idof 0 makes the authorization valid on every chain, which is convenient and also a risk. - You can undo it by delegating to the zero address, which resets the account to a plain EOA.
The key point for you: your original private key still controls the account. EIP-7702 adds features such as batching and sponsored gas, but it does not by itself give you seed-phrase-free recovery, because whoever has the old key can still sign anything.
ERC-4337 vs EIP-7702 vs native account abstraction
| ERC-4337 smart account | EIP-7702 delegated EOA | Native AA (Starknet, ZKsync, Abstract) | |
|---|---|---|---|
| Address | New contract address | Your existing address | Every account is a contract account |
| Protocol change needed | No (contracts plus off-chain bundlers) | Yes (Pectra, 7 May 2025) | Built in at launch |
| Who submits transactions | Bundlers via the EntryPoint | You, a relayer, or a bundler | The chain’s normal sequencer |
| Original key still all-powerful? | No, the account code decides | Yes | No, the account code decides |
| Main trade-off | Extra infrastructure; moving to it means moving assets | Delegation phishing; the old key remains a single point of failure | Works on that chain only; tooling differs from Ethereum |
Sources: ERC-4337 and EIP-7702 specifications, Starknet, ZKsync and Abstract documentation (checked 14 October 2026).
What is native account abstraction?
Native account abstraction means the chain itself treats every account as programmable. Starknet’s documentation says “smart contract accounts with arbitrary verification logic are used instead of EOAs”: an account is any contract with a __validate__ function (checks the transaction) and an __execute__ function (runs it). ZKsync’s documentation says its accounts “can initiate transactions, like an EOA” while running custom logic, and that paymasters can let users pay fees in ERC-20 tokens. Abstract’s documentation says all of its accounts are smart contract accounts implementing a standard IAccount interface, and that MetaMask-style EOAs still work because they are treated as a DefaultAccount.
There is no separate bundler or alternative mempool: the chain’s sequencer handles these transactions like any other. For how sequencers order transactions on layer 2s, see what a sequencer is.
Modular smart accounts: ERC-7579 and ERC-6900
Once accounts are code, developers want to add features as plug-ins rather than rewrite the wallet. Two standards (both Draft status as of 14 October 2026) define how:
- ERC-7579, “Minimal Modular Smart Accounts” (created December 2023), defines four module types: validators (decide whether a transaction is valid), executors (act on the account’s behalf), fallback handlers and hooks (checks before and after execution).
- ERC-6900, “Modular Smart Contract Accounts” (created April 2023), splits an account into validation functions, execution functions and hooks in external contracts, and is built to be ERC-4337 compliant.
For you as a user, modules are why one smart account can gain a passkey signer or a spending limit later. They are also a risk: a malicious or buggy module installed on your account can act with the account’s full power.
Passkeys and seed-phrase-free wallets
Passkeys sign with the P-256 (secp256r1) curve, while Ethereum keys use secp256k1. Verifying P-256 inside a contract used to be expensive. EIP-7951 adds a P256VERIFY precompile at address 0x100 for signatures from “Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices”, at a cost of 6,900 gas. It was included in the Fusaka upgrade, which the Ethereum Foundation scheduled for mainnet on 3 December 2025, and supersedes RIP-7212, the earlier rollup version of the same precompile.
A passkey wallet still has a recovery question: if the passkey lives in your phone’s cloud account, that account becomes part of your security. Check which recovery methods a wallet actually offers before moving funds.
Smart wallets vs multisig vs MPC wallets
These three are often confused, and the queries “what is a multisig wallet” and “what is an MPC wallet” sit right next to this one.
| Smart (AA) wallet | Multisig wallet | MPC wallet | |
|---|---|---|---|
| What it is | An account whose rules are set by code | A smart contract account that needs M of N signers to approve | One key split into shares held by separate parties |
| Where rules are enforced | On-chain | On-chain | Off-chain, during signing |
| What the chain sees | A contract account | A contract account | A normal single signature |
| Chain support | Chains with AA or EIP-7702/4337 | Chains that support the contract | Any chain using ECDSA or EdDSA |
| Changing signers | Update the account code or modules | An on-chain transaction approved by the current signers | Handled off-chain by the signing parties |
Sources: Fireblocks’ MPC explainer for MPC and multisig mechanics; ERC-4337 specification (checked 14 October 2026).
A multisig is effectively an early smart account, and many ERC-4337 wallets support multiple signers. MPC, in Fireblocks’ description, keeps the full key from ever existing in one place and works across chains, but its rules live with the signing parties, not on-chain where you can audit them. Institutions often combine these; see institutional crypto custody and the Wallet & Custody Providers section.
How widely is account abstraction used?
Adoption is large, but read the numbers carefully because sources count different things:
| Metric | Figure | Source |
|---|---|---|
| ERC-4337 UserOperations, all tracked chains, cumulative | 1,321,276,174 | BundleBear overview |
| Accounts with at least one UserOperation | 69,186,652 | BundleBear overview |
| Gas paid by paymasters, cumulative | $14,946,825 | BundleBear overview |
| EIP-7702 accounts with a live delegation | 65,871,739 | BundleBear EIP-7702 overview |
| EIP-7702 authorizations, cumulative | 267,303,970 | BundleBear EIP-7702 overview |
Source: BundleBear dashboards, figures as displayed on 14 October 2026 across all chains it tracks (Ethereum and several layer 2s and sidechains). BundleBear does not state a data cut-off on the page.
ethereum.org’s account abstraction page (last updated 24 June 2026) still quotes “over 26 million smart accounts and 170 million UserOperations” and says EIP-7702 is “scheduled for May 7, 2025”, so treat it as out of date on numbers. A high EIP-7702 count also does not prove deliberate adoption: as the next section shows, attackers trick users into signing delegations too.
Is account abstraction safe? Risks and real incidents
Account abstraction moves security from one key into code and signing interfaces. That removes some old risks and adds new ones.
| Date | Incident | What it shows |
|---|---|---|
| 21 February 2025 | About $1.5 billion stolen from Bybit, attributed by the FBI to North Korea (“TraderTraitor”). Bybit was moving funds from an Ethereum cold wallet through Safe{Wallet}’s multisig workflow; Safeheron’s analysis notes the signers’ Ledger devices “only displayed contract interaction parameters” | A multisig smart account is only as strong as the interface the signers trust. Blind signing on the hardware device meant the signers’ checks failed |
| 24 May 2025 | A user lost over $146,000 in tokens after signing a malicious batched transaction through an EIP-7702-upgraded account; GoPlus attributes it to the Inferno Drainer group | Batching makes one bad signature drain many assets |
Sources: FBI public service announcement, 26 February 2025; Safeheron, “Anatomy of Bybit’s breach” (26 February 2025); GoPlus Security, EIP-7702 phishing guide (3 June 2025).
The EIP-7702 specification is blunt about the main risk: “There is no safe way to provide this interface” for signing arbitrary delegations, because the delegated code gets full control of your account. It also flags three developer-level issues:
- Initialization front-running. No setup code runs during delegation, so an attacker can race to initialize the account. Setup data should be signed by the EOA’s key.
- Storage collisions. Switching from one delegate to another can corrupt storage; use namespaced layouts such as ERC-7201.
tx.originchecks break. Contracts that userequire(msg.sender == tx.origin)to block contracts can no longer rely on it.
For ERC-4337, OpenZeppelin’s security review highlights paymasters as a key risk area: badly written payment conditions can let users take free operations or leave the paymaster paying.
How to protect yourself
- Only accept an EIP-7702 upgrade inside your wallet app, never from a website prompt. GoPlus recommends treating any web page asking for a delegation signature as likely phishing.
- Check the target contract and the chain. Be wary of authorizations with chain ID 0, which work on every chain.
- Read each call in a batched transaction before you confirm.
- If you suspect a bad delegation, revoke it by delegating to the zero address through your wallet, then move funds from a key you trust.
- Prefer wallets whose account contracts and modules are open source and audited, and remember that an audit covers a specific version on a specific date.
For wallet-specific evidence, see the reviews of whether MetaMask is safe and whether Trust Wallet is safe.
Is a smart wallet free, and how do you withdraw from one?
Gas still has to be paid. A smart wallet can feel free when an app’s paymaster sponsors your transactions, but someone pays: the app, the wallet, or you through a token fee. Sponsorship is a business decision that can change. Deploying a new ERC-4337 account also costs gas, usually bundled into your first transaction.
Withdrawing works like any wallet: you send assets to another address or to an exchange deposit address, and the wallet turns it into a UserOperation or a normal transaction. Two checks matter:
- A smart account is a contract that exists on a specific chain. Before you send funds to the same address on another network, confirm in your wallet that the account exists or can be deployed there.
- If the receiving service or network is unfamiliar, send a small test amount first.
What this means for you
If you are a user, account abstraction is mostly invisible: you see passkey logins, gas-free onboarding and one-tap batches. What you should look for is how recovery works, who can change your account’s code or modules, and whether your wallet shows you exactly what a delegation or batch will do before you sign. If you are a developer, decide early between a new ERC-4337 account and EIP-7702 for existing users, pin a specific EntryPoint version, and treat paymasters and delegate contracts as security-critical code that needs an audit. If you are choosing a wallet or custody provider for a business, compare smart accounts, multisig and MPC on where the rules are enforced and who can override them.
More on wallets and custody is in Wallet & Custody Providers. How this site sources and dates its facts is set out in the methodology.
