What Is Account Abstraction? How Smart Accounts Actually Work

Most people who use crypto have, at some point, done something that felt absurd: copied a 42-character address, checked it three times, paid a fee in a token they did not want to hold, and signed a transaction they could not fully read. The experience is a direct consequence of how Ethereum accounts were designed in 2015, and a decade of work has gone into fixing it. That work is called account abstraction.

It is also one of the most over-marketed ideas in the industry. So this guide sticks to what is actually running on-chain, what it costs, and where it can still hurt you.

The problem with a wallet that can only do one thing

Ethereum has two kinds of accounts. A contract account is code: it can hold rules, react to messages, and refuse to do things. An externally owned account, or EOA, is a private key and nothing else. Every wallet you have ever created with a seed phrase — MetaMask, Ledger, Trust Wallet, a hardware wallet — is an EOA.

An EOA can do exactly one thing: sign a transaction that is valid if the signature matches. It cannot enforce a spending limit, require two approvals, wait an hour before a large transfer, or pay a fee in USDC. Anything resembling that behaviour has to be built by a separate smart contract layered on top, and the EOA still holds the keys to override it.

Account abstraction reverses that. Instead of the protocol deciding what an account may do, the account itself supplies its own validation logic as code. A "smart account" is a contract that defines what counts as a valid instruction from its owner — a signature, a passkey, three of five approvals, a session key that expires at midnight.

What "no protocol change" means in practice

The interesting part of ERC-4337, the standard that made this real, is where it sits. Proposed in September 2021 and finalised in March 2023, it asked for no change to Ethereum's consensus rules. Instead it added a parallel pipeline above the chain.

Users no longer sign raw transactions. They sign a UserOperation: a richer object that describes intent, gas limits, and optionally a sponsor. These objects go into a separate mempool. Off-chain actors called bundlers pick them up, simulate them, and submit a batch in one ordinary on-chain transaction to a single audit-heavy contract called the EntryPoint, which runs validation and execution.

That design is why account abstraction shipped on a live network without a hard fork, and why it works identically on rollups and sidechains. It is also why the system has extra moving parts, each of which can take a fee or fail.

The four pieces you actually interact with

Break any smart-account transaction down and you find the same components.

The **smart account** is your wallet contract. It decides whether a UserOperation is authorised, and it is deployed deterministically by a factory, so your address can be calculated before the contract exists. That is what lets you receive funds at an address that has not been created yet.

The **bundler** is the relayer. It watches the alternative mempool, checks that each operation will pass, packs the valid ones together, and pays the real gas. It earns the priority fees and refunds inside the operations, plus whatever margin it charges. In practice this is a small market: Alchemy, Pimlico, Biconomy, ZeroDev, Coinbase Developer Platform, Stackup, Candide and Etherspot are the names you will run into, and two of them carry most of the traffic.

The **EntryPoint** is the singleton contract everything funnels through. It exists in versions — v0.6 from March 2023, v0.7 from mid-2024, and v0.8 and v0.9 since — and each version has a fixed address across chains. Version 0.7 packed several UserOperation fields together to save roughly 7,000 gas per operation, separated paymaster gas limits, and added a 10% penalty on unused gas to stop wallets from over-reserving.

The **paymaster** is the optional sponsor. If a UserOperation names one, the EntryPoint asks that contract whether it will cover the fee and calls it again after execution to settle. Paymasters are why a game can let new players transact without buying ETH, and why a wallet can charge its fee in USDC instead.

What a smart account can do that a normal wallet cannot

The features are unglamorous individually and transformative together.

**Batching.** Approve-and-swap becomes one signature and one confirmation instead of two.

**Sponsored gas.** Someone else pays, within rules the paymaster enforces. This is not a subsidy trick; sponsored operations have been the overwhelming majority of ERC-4337 volume for two years, usually between roughly 88% and 99% of monthly activity.

**Alternative signatures.** A passkey backed by your phone's secure hardware can authorise a transaction. So can a key held in a different device, or several keys requiring a quorum.

**Recovery and guardrails.** A social recovery setup, a daily outflow cap, or a rule that blocks transfers to addresses you have never sent to. These are ordinary contract logic, which is the whole point.

**Session keys.** You approve a game or trading app for a limited scope and duration instead of handing over signing rights to your whole balance.

Worth being precise about one thing: a smart account does not have to be a multisig, and delegating to a multisig contract does not make you one. Control still depends on which keys can authorise the account.

The numbers, and what they do not prove

The tracking dashboards most articles quote are maintained by BundleBear. Through late 2026 they show roughly 1.2 to 1.3 billion cumulative UserOperations and somewhere between 63 and 66 million accounts that have executed at least one. Paymasters have covered a meaningful but modest slice of total fees — tens of millions of dollars cumulatively, not billions.

Those are infrastructure numbers, not user numbers. An address that executed one UserOperation is not a retained customer, and one person can own many accounts. A September 2026 sampling of mainnet blocks is a useful reality check: EntryPoint calls were about 1.4% of transactions, and EIP-7702 set-code transactions around 0.8% to 1.2%. Volume is also lopsided, with World Chain accounting for roughly two thirds of observed UserOperations and Base about a fifth. Account abstraction is real and load-bearing; it is not yet how most people use crypto.

EIP-7702, the upgrade that changed the shape of this

The biggest practical shift since ERC-4337 is EIP-7702, activated with Ethereum's Pectra upgrade on 7 May 2025. It introduced a new transaction type that carries a signed authorisation, letting an existing EOA point its address at contract code and temporarily adopt that code's behaviour.

The appeal is obvious: no new address, no migration, no seed phrase to re-enter. Your existing wallet can gain batching, sponsorship, passkey signing and spending rules in place. MetaMask and Ambire shipped support, and the design is deliberately reversible — the owner can always sign a fresh authorisation, including one that points at the zero address to clear the delegation. Authorisations are also bound to a chain ID and to the account's nonce, so a replay on another network fails.

Two warnings are worth taking seriously. First, the private key still rules. Delegating to a Safe-style multisig contract does not turn a single-key account into a multisig; the key can simply re-delegate elsewhere. Second, delegation is a phishing surface. Within weeks of activation, security firms were reporting that the large majority of delegations they observed pointed at contracts used in drainer-style scams — users signing authorisations they did not understand, handed to them by sites they should not have trusted. Cumulative set-code transactions reached roughly 94 million with about 50 million live delegations by late 2026, so the pattern is not rare.

Where smart accounts can still bite you

Beyond phishing, three risks deserve attention.

Bundlers and paymasters are a concentration point. If a handful of providers relay nearly all traffic, they can in principle delay or drop operations, which is a censoring lever that does not exist at the base layer. Ethereum's answer is that bundlers are permissionless and anyone can run one, but that is a theoretical escape hatch, not a guarantee of neutrality today.

Sponsorship economics can change without notice. Most "free" transactions are paid by a company with a budget, and when the budget ends the fee does. A sponsored operation is a subsidy, not a protocol feature.

And the account is code, so its bugs are your bugs. A poorly written validator, a badly audited module, or a proxy upgraded by someone else can lose funds in ways a plain key cannot. That risk is why audited, widely used account implementations matter more than feature lists.

What to check before trusting a smart wallet

Ask four questions. Which account implementation runs under the hood, and who audited it? Who operates the bundler and paymaster, and what happens if they stop? Can you revoke a delegation or session key yourself, without help from the provider? And does recovery depend on a single company, or on keys you and your chosen guardians control?

If the wallet cannot answer those plainly, its gasless, one-tap experience is being bought with risks you have not seen. If it can, you are looking at genuine progress. Pair that with the basics — a hardware wallet for large holdings, keys kept offline, approvals reviewed — and smart accounts become what they were meant to be: fewer absurd steps, without handing anyone your money.

Where this is heading

The next step is to move abstraction into the protocol itself. RIP-7560 proposes native account abstraction for rollups, and ERC-7562 already defines the validation rules bundlers must enforce so that one bad operation cannot poison a whole bundle. Both point the same direction: the special-purpose pipeline of ERC-4337 becomes the default behaviour of the chain, and the distinction between a wallet and a smart account disappears.

That is a multi-year project. In the meantime, the practical test is unchanged. Whether the account is a contract by birth or an EOA that borrowed code, what matters is who can authorise a transfer, what they can authorise, and how quickly you can take that power back.