ERC-4337 went live on Ethereum mainnet in March 2023. Three years in, the pattern is clear. Builder adoption is broad. User retention is not. The shape of the data on any public Dune dashboard tracking smart-account activity is the same: a wide funnel at deployment and almost nothing at the bottom.
That is not the shape of a UX breakthrough. It is the shape of a system that onboards people and stops getting used.
I am not here to attack the engineering. ERC-4337 shipped account abstraction under one hard constraint: no consensus changes. It proved the idea. Circle's gasless USDC, session keys, paymasters on L2: all real wins. The problem is that the constraint that let it ship is now its ceiling.
On January 29, 2026, Vitalik Buterin, lightclient, Felix Lange, and other EF researchers published EIP-8141 (Frame Transactions). It defines a new type-0x06 transaction that lets the protocol validate against the account's own code instead of ECDSA, and it is being considered for inclusion in the Hegota fork targeted for late 2026. Native account abstraction at the protocol level is no longer a forum argument. It is on the roadmap.
The Numbers Do Not Match the Narrative
Builder adoption has been strong. Most major wallet teams, embedded-wallet providers, and paymaster stacks ship ERC-4337 support out of the box. User retention has not matched. That gap between who integrates it and who actually uses it month over month is the whole story.
The distribution curve on any public smart-account dashboard looks the same: a large population of accounts that deployed once, a small middle of accounts that ran a handful of UserOperations, and almost nothing at the tail. Onboarding works. Keeping users does not.
The geography is as telling as the retention. The overwhelming majority of UserOperation volume lives on L2, not on Ethereum mainnet, with Base carrying the largest share by a wide margin. ERC-4337 has not been stress-tested at L1 gas prices. It works on L2 because L2 gas is cheap.
The bundler market has consolidated in parallel. The original pitch was a decentralized alt-mempool of competing bundlers. In practice, a small number of providers (Alchemy, Pimlico, Stackup, and Candide among them) carry most of the flow, on thin margins, absorbing DoS risk, with no protocol-level revenue. That is not the decentralization story ERC-4337 was supposed to tell.
Five Gaps No Patch Can Close
ERC-4337 was built as an ERC, not a protocol change. That choice ruled out five things a protocol-layer design would get for free.
- 01Gas overhead. The EntryPoint contract re-implements signature verification, nonce handling, and gas accounting in Solidity. Roughly 42,000 gas per UserOp versus 21,000 for a plain transfer. The 20k delta is permanent.
- 02Censorship resistance. UserOps live outside the protocol's inclusion-list machinery. FOCIL cannot see them.
- 03EOA / smart-account split. Two developer ecosystems. A ZeroDev account cannot be used by a Biconomy app. ERC-6900 and ERC-7579 exist to patch this, but they stack on top of ERC-4337.
- 04Parallel validation. Builders cannot parallelize UserOp validation against shared state. The bottleneck stays at the builder.
- 05Quantum migration. Every EOA is secp256k1-signed. The protocol only knows ECDSA. There is no path to force-upgrade the network to a post-quantum scheme.
# ERC-4337 UserOperation gas anatomy
EOA_TRANSFER_BASE = 21,000 # protocol-native, one transaction
ENTRYPOINT_OVERHEAD = 20,000+ # signature + nonce + gas logic, in Solidity
USEROP_TOTAL_BASE = 42,000+ # before the actual call payload runsTwenty thousand extra gas is the number most often waved away. It is fatal for tips, micro-subscriptions, and in-game actions: the flows any consumer UX has to carry. The reason UserOps cluster on Base is not that Base has better infrastructure. It is that L1 gas makes the economics stop working for low-value high-frequency actions.
The Alt-Mempool Is a Permanent Audit Surface
ERC-7562 is the validation scope rules every bundler must enforce. It exists because simulating arbitrary Solidity in the mempool-admission path is DoS-able. Forbidden opcodes. Banned storage patterns. Reputation thresholds. All necessary. None elegant.
The EntryPoint contract has been patched repeatedly as new griefing vectors surface. One representative class: an attacker plants a temporary must-revert condition against a victim's UserOp, forcing the UserOp to consume gas without completing. Victim pays. Attacker does not. Each discovery produces another EntryPoint revision.
Look at the shape of the fix. Another EntryPoint version. Another audit. Another reputation heuristic. v0.6, v0.7, and v0.8 shipped in under two years, the last one adding native EIP-7702 support. Every release lands as a new reference bundler implementation and new validation rules. When validation runs in user-written Solidity off-protocol, the security surface is permanent. You can close vectors. You cannot close the surface.
EIP-7702 Is the Strongest Argument for Native AA (Not Against It)
EIP-7702 shipped with Pectra on May 7, 2025. The type-0x04 set-code transaction lets an EOA temporarily adopt contract code by delegating to an address. It is the best user-facing upgrade that still respects the EOA. Circle shipped gasless USDC via 7702 paymasters. Safe, Ambire, and Gelato shipped 7702-compatible wallets. The same wallet code now serves an EOA and a pure smart account.
It is also the clearest warning signal in the entire account-abstraction history.
If the minimal, carefully scoped version of delegation produces a $12M phishing category in its first year, the application-layer approach has reached its limits.
$12M drained from 15,000 wallets via malicious delegation signatures, documented in an arXiv study and a Nethermind analysis. Over 90% of observed on-chain 7702 delegations link to sweeper contracts. Attackers watch for signed authorizations, delegate first, run their own init. The authorization tuples are not visible in the transaction fields users typically inspect. The signature looks routine. The consequence is not.
Phishing is not the only damage. Governance and LP contracts have relied on the tx.origin == msg.sender check as an EOA detector since 2015. That API contract is silently broken for any delegated EOA. Storage-slot collisions let slot 0 be a bool under one delegation and a uint256 under the next, with no runtime guard. There is no initcode in 7702, so any wallet not designed for 7702 from day one can be front-run at the authorization moment.
None of these are implementation bugs. They are what happens when you bolt smart-account semantics onto an address format defined by ECDSA recovery. The lesson from 7702 is not that delegation was a bad idea. It is that delegation as a surface patch carries compounding costs. The next step cannot be another surface patch.
What Native AA Actually Is
Native AA means the protocol treats every account as programmable, validates transactions against the code the account points to, and admits them to the canonical mempool under protocol-enforced rules. No alt-mempool. No off-chain bundler. No EntryPoint contract.

EIP-8141 builds on the earlier EIP-7701 native-AA design. It defines a type-0x06 transaction made of frames. The spec describes three frame modes: DEFAULT (which executes as an entry point), VERIFY (which runs the account's validation code in a bounded context), and SENDER (which executes on behalf of the sender). Nodes simulate the frames before admitting the transaction to the mempool. The validation code can be ECDSA, multisig, passkeys, social recovery, or post-quantum signature schemes like Lamport, SPHINCS+, or ML-DSA. All of it first-class. All of it inside the same inclusion-list rules as ordinary transactions.
The pairing with FOCIL (Fork-Choice Inclusion Lists) is what makes this consequential. Under FOCIL, each slot has seventeen actors: one proposer and sixteen includers, all chosen at random. Any of them can force inclusion of a transaction within one or two slots. With EIP-8141, the transactions that qualify for that guarantee include smart-wallet operations, gas-sponsored operations, and privacy-protocol calls, sent through the public mempool directly to a FOCIL includer. No wrapper transaction. No off-chain broadcaster. No dependence on the last-look proposer role that ePBS auctions off. Today's FOCILs are 8 kB each, small by design, with a stated extension path to eventually carry the majority of block traffic if needed.
EIP-8141 is not alone. EIP-8130 (Chris Hunter, Coinbase, October 2025) takes a different approach: rather than let each account ship arbitrary Solidity in its validation path, it has transactions declare an explicit verifier contract and register owners through an on-chain Account Configuration. Nodes can filter on the verifier without full EVM simulation. Paradigm's Tempo proposal goes further in that direction, defining a narrow transaction-level primitive (type 0x76) with batching, passkeys, and occasional sponsorship, and deliberately refusing to support arbitrary validation logic. All three proposals agree native AA has to happen at L1. The argument is about scope on day one, not direction.
The existence proof is already on-chain. ZKsync Era treats every account, including EOAs, as a smart-contract account and runs a unified mempool with no bundler infrastructure. StarkNet's sequencer processes AA directly. Both have been live in production for years. The bundler detour on Ethereum L1 was never required by the idea of account abstraction. It was required by the constraint that 4337 ship without consensus changes.
What Breaks Open
The endgame the roadmap has described since 2015 is finally tractable: programmable accounts by default, ECDSA de-enshrined, EOAs as a legacy shim.
- 01A 21,000 gas floor with no Solidity re-implementation of validation or nonce handling.
- 02One transaction format. One mempool. One inclusion-rule set.
- 03Protocol-level censorship resistance. Frame transactions participate in FOCIL inclusion lists on equal footing.
- 04Parallel validation. Builders can statically analyze validation frames against shared state.
- 05First-class paymasters. Fee sponsorship is a native transaction shape, not a simulated call path.
- 06A concrete post-quantum migration. Overlay rules treat every EOA as a standardized wallet contract; the network rotates to PQ signatures through ordinary wallet upgrades. No flag day.
- 07True account portability. An account is the code at its address.
None of these are hypothetical. Each one is live on a production native-AA chain or specified in a written proposal under review.
Who Should Care, and Why
If you build wallets, current 4337 and 7702 work is not wasted. It is bridge code. The account-interface patterns in ERC-6900 and ERC-7579 carry forward. The EntryPoint abstraction does not. Any roadmap that treats EntryPoint v1.0 as a stable target is planning for the wrong endgame.
If you build applications, watch the gas floor. A 20,000 gas premium per UserOp is the line between feasible on L1 and only feasible on L2. When that premium disappears, tips, micro-subscriptions, in-game actions, and paymaster-sponsored onboarding become viable at mainnet cost, not just at Base cost.
If you run a client, EIP-8141 is a real implementation budget. Scope compression is the live debate on the All Core Devs calls. The direction is settled.
The Structural Argument
ERC-4337 shipped under a real constraint. The constraint is the problem. As long as validation runs in user-written Solidity inside an EntryPoint contract, the system carries a 20k gas tax, a DoS surface that requires continuous patching, and a concentrated bundler market in place of the decentralized alt-mempool that was promised.
A retention curve that falls off a cliff. 20k of unavoidable overhead per operation. Three EntryPoint revisions in under two years. $12M drained from 15,000-plus wallets via 7702 phishing in its first year, with over 90% of observed 7702 delegations pointing to sweeper contracts. These are not bugs to be patched. They are the shape of the architecture.
EIP-8141, or a scoped variant like EIP-8130 or Tempo, in Hegota is the moment Ethereum either commits to the endgame it has been describing since 2015 or spends another cycle patching the workaround.
The conversation has already moved. The fork has to catch up.
References
- ↗EIP-8141: Frame Transaction (Buterin, lightclient, Lange et al., Jan 2026)
- ↗EIP-8130: Account Abstraction by Account Configuration (Hunter, Coinbase, Oct 2025)
- ↗Vitalik Buterin on X: FOCIL and EIP-8141
- ↗Vitalik Buterin: The Road to Account Abstraction (HackMD)
- ↗ERC-4337: Account Abstraction Using Alt Mempool
- ↗ERC-7562: Account Abstraction Validation Scope Rules
- ↗EIP-7701: Native Account Abstraction
- ↗EIP-7702: Set Code for EOAs (Pectra, May 7 2025)
- ↗RIP-7560: Native Account Abstraction (rollups)
- ↗Ethereum Foundation: Pectra Mainnet Announcement
- ↗arXiv 2512.12174: EIP-7702 Phishing Attack
- ↗eth-infinitism/account-abstraction releases (EntryPoint v0.6 to v0.8)
- ↗ZKsync Era: Native AA vs EIP-4337
- ↗Starknet: Account Abstraction