ERC-4337 : Final, Not Finished

Part 1 of 3 in ERC-4337: A Retrospective written by Taek Lee.

ERC-4337 is Final. I spent years building around it, and production validated something narrower than the consumer-wallet thesis I started with: a shared rail for sponsored and embedded account flows.

Final means the normative standard has converged enough to be judged against production rather than defended as a promise. That record shows little evidence of mass migration from established EOAs into standalone smart-account addresses. (EIP-4337)This builder’s retrospective assumes familiarity with EOAs, UserOperations, bundlers, paymasters, session keys, and smart accounts.

What Usage Revealed

No public dataset cleanly measures how many people consider a smart account their primary wallet. Onchain data can count UserOperations and account addresses, but it cannot tell us whether two addresses belong to one person, whether an account was used once or retained, or whether its owner consciously chose a smart-account architecture.The mid-2026 snapshot gives us four signals:

• Scale, not migration. BundleBear reports approximately 1.22 billion UserOperations and 62.9 million account addresses that have executed at least one UserOperation. Those are meaningful infrastructure numbers, but they are not 62.9 million distinct people, retained users, or migrated main wallets. (BundleBear)
• Sponsorship dominated. Across EntryPoint v0.6 through v0.8 on 26 mainnets, sponsored UserOperations represented roughly 90–99% of observed monthly volume over the preceding year and had not fallen below about 88% in two years. The historical dashboard did not yet include v0.9, so this is a view of the included lanes rather than every ERC-4337 operation.
• The delivery mechanism changed. Two years earlier, almost all sponsored volume in our snapshot passed through paymaster contracts. By mid-2026, the paymaster share had fallen from roughly 97% toward one-third, while UserOperations carrying zero gas-price fields had grown from almost nothing to more than half of sponsored volume. In those flows, the operator paid for the enclosing bundle transaction.
• Volume was concentrated. World Chain represented roughly two-thirds of observed UserOperations and Base approximately another fifth. Aggregate volume was therefore shaped heavily by a small number of large deployments rather than thousands of equally weighted product choices.

These figures have a selection effect. Applications often adopt ERC-4337 precisely because they want to sponsor gas, so the sponsored share is not a survey proving that every wallet user values free transactions above every other feature. In its largest observable consumer deployments, ERC-4337 specialized primarily into a sponsorship rail.In practice, users felt the disappearance of gas most directly. The complexity moved into the infrastructure and commercial relationships behind that experience.UltraRelay: When Billing Absorbed the PaymasterUltraRelay was another extreme case of complexity relocating rather than disappearing. It removed the paymaster and sponsorship-specific round trips from the critical path, then submitted an ordinary bundle transaction from a funded operator account.ZeroDev’s offchain billing relationship absorbed the missing complexity: eligibility, limits, collections, abuse handling, payment guarantees, and credit risk.

What Survived the Original Thesis

For me, this is personal. At ZeroDev, I led the design and development of Kernel from v1 through v4 and worked on the paymasters, bundling infrastructure, and SDKs around it. That work rested on a product forecast that smart accounts would become the default inside consumer wallets. That did not happen on our timeline.That forecast produced several distinct outcomes:

• The shared execution rail worked. Wallets, apps, account implementations, bundlers, sponsors, SDKs, explorers, and auditors could accumulate knowledge around one flow instead of rebuilding a private relayer system for every wallet.
• Gas abstraction worked. Apps could remove the need to acquire ETH before the first useful action and settle transaction costs through a different economic relationship.
• Standalone main-wallet migration did not materialize at mass-market scale. Public data cannot identify a user’s primary wallet, but it provides no evidence of broad migration from established EOA addresses to new standalone smart-account addresses. Smart accounts grew most cleanly when account creation disappeared behind an application flow.
• The permissionless infrastructure result was mixed. The standard preserved an open interface and permissionless design, while production traffic concentrated around a relatively small number of operators and deployments.

The capabilities also matured on different timelines:

• Immediate product wins: gas sponsorship and embedded onboarding removed visible friction without asking users to understand a new account model.
• Narrow but durable wins: batching and session keys worked when an application could name an obvious sequence or repeated signing had become the product bottleneck.
• A deeper architectural win: replaceable validation created a path for passkeys, recovery, signer rotation, team control, and future cryptographic schemes.
• Capabilities still searching for packaging: fine-grained permissions, broad modularity, and other flexible mechanisms mattered only when a product could make their value legible.

The mistake was treating those capabilities as one market, one user need, and one adoption timeline.Programmability became a product only when it addressed a pain someone already felt.That is why EIP-7702 matters. It begins attaching smart-account behavior to existing EOA addresses without asking users to relocate first. (EIP-7702)

Why a Shared Layer Still Mattered

Programmable wallets existed long before ERC-4337. So did multisigs, meta-transactions, custom relayers, sponsored flows, and permission systems. The problem was that every implementation carried its own wallet contract, transaction envelope, relayer network, gas model, signing flow, deployment assumptions, and failure modes.Apps would not integrate a different transaction stack for every wallet, infrastructure providers could not economically support every private envelope, and explorers or auditors could not accumulate shared knowledge if every design created a new interpretation surface.ERC-2771 had already exposed the coordination problem. Meta-transactions could preserve a user-facing sender, but recipient contracts had to recognize trusted forwarders and recover the actor through _msgSender()-style logic instead of ordinary msg.sender. The technology worked; the integration boundary remained expensive.ERC-4337 standardized a smaller set of shared responsibilities:

• Submission: a common UserOperation format rather than a private request object for every account system.
• Validation and execution: a common EntryPoint coordinating account checks and execution.
• Inclusion: bundlers translating UserOperations into ordinary Ethereum transactions.
• Alternative payment: optional paymasters or operator-managed sponsorship paths.
• Account-defined authorization: contract accounts deciding what counted as a valid signature or policy.

Account execution interfaces, permission semantics, module composition, recovery UX, and the way wallets explain authority remained outside the standard. One shared infrastructure boundary was enough to turn isolated experimentation into cumulative evidence.The second benefit was timing. Native account abstraction would have required protocol design, client implementations, fork scheduling, and ecosystem adoption before anyone knew which product assumptions were right. ERC-4337 inverted that sequence: builders could ship first, production could reveal what survived, and protocol design could learn from those results.The cost was a heavy stack: an alternate mempool model, a singleton EntryPoint, bundlers, simulation rules, staking and reputation assumptions, paymaster choreography, and multiple gas domains.For the sponsorship-heavy use case that dominated, the full stack can look overbuilt. As a protocol sandbox, much of that weight was intentional.That complexity bought the right to be wrong in public without putting the base layer at risk. The practical alternatives were continued fragmentation or waiting years for protocol-level account abstraction while the product questions remained unanswered.

What Convergence Looked Like

The EntryPoint’s version history shows production lessons being written back into the shared layer:

• v0.6 — Identity and ordering. EntryPoint-owned nonce management and a stable userOpHash made operations reliably unique and indexable.
• v0.7 — Cost accounting. Packed onchain representation, explicit paymaster gas domains, and unused-gas penalties made resource reservation a shared concern.
• v0.8 — Security and compatibility. Native EIP-7702 and EIP-712 support arrived alongside fixes derived from production failures and security findings.
• v0.9 — Concurrency and edge friction. Post-signing paymaster data, block-based validity, and better concurrency for undeployed accounts improved composition without another structural redesign. (account-abstraction releases)

The version history is dominated by indexing, gas reservation, deployment races, error attribution, concurrency, and awkward interactions between independently operated components. Those production concerns are stronger evidence of a working standard than another headline feature.Each version moved another class of coordination failure out of private implementations and into the shared layer.Final status means the normative layer is stable enough that the ecosystem no longer has to design around the assumption of another structural revision. Accounts, wallets, bundlers, and products will continue to evolve above it.

The Installed-Base Problem

Users did not necessarily choose the EOA’s limited authorization model over programmable validation. They stayed where their assets, approvals, history, counterparties, and application assumptions already lived.EIP-7702 matters because it shows that smart-account behavior can reach existing addresses without requiring users to relocate first. A complete transition would need to go further: preserve continuity, replace the root authorization, and allow the old credential to be removed permanently.Before getting there, Part 2 turns inward to Kernel. Four versions forced us to distinguish the capabilities that became products from those that remained serious, useful, and early. Part 3 then returns to the installed base and asks what an in-place path to native account abstraction should preserve.