Has Ethereum account abstraction failed?

Author: Haotian

Last time I talked about how the x402 protocol extends the Lightning Network. Recently, during a dinner with a group of programmer friends, I was challenged again: Isn't x402 just the old Account Abstraction (AA) all over again?

The implication is that Ethereum has spent years focusing on account abstraction (Account Abstraction), investing heavily in ERC-4337, Paymaster, and various grants and wallet service providers. But as everyone can see, it's widely criticized for making a lot of noise with little actual impact.

Although I don't believe AA has completely failed, where exactly lies the problem?

1. Paymaster shifts users' gas costs onto project teams. Sounds great in theory, but project teams have weak incentives to burn money paying on behalf of users. With unclear ROI, this inevitably leads to a business model dead end—how can a system survive without self-sustaining revenue, relying solely on external funding?

2. AA account abstraction is limited within the EVM ecosystem—ERC4337, Paymaster, EntryPoint contracts are all Ethereum-specific. To achieve cross-EVM usage involving chains like Solana or BTC, additional middleware services must be layered on. But here's the problem: each middleware adds another fee cut, making ROI even harder to justify!

There are many other complex technical issues I won't go into, but let me say something understandable: AA is essentially a product created "for technology's sake," a work stemming from Ethereum's historically research-driven approach.

In contrast, what does the x402 protocol do differently? Some criticize bringing back HTTP 402 status code—a 30-year-old relic—as merely engraving flowers on gold again.

But don't forget: HTTP 402 status code is part of the internet's foundational protocols, a common language shared by Web2 and Web3.

AA requires smart contracts, on-chain states, and EVM execution; x402 only needs an HTTP request header—any system supporting HTTP can use it, including Web2 APIs, Web3 RPCs, and even traditional payment gateways—all remain compatible.

This isn't a technical optimization through stacking layers, but a "dimensional reduction strike" that simplifies complexity at the protocol level. Instead of struggling with compatibility, adaptation, and trust mechanisms at the application layer, why not first unify standards at the highest protocol layer?

Critically, x402 is naturally a strong standard for cross-chain interoperability. As long as an Agent can send HTTP requests, handle 402 responses, and complete EIP-3009 authorization (or equivalent standards on other chains), whether you're on Base, Monad, Solana, Avalanche, or BSC becomes irrelevant at the protocol level. Differences appear only at the settlement/payment point, making cross-chain significantly cheaper.

A Facilitator can serve multiple chains simultaneously; user payment history data can be uniformly indexed; developers integrate once and instantly "unlock" the entire ecosystem.

My overall impression: AA is an elegant engineering feat born from researcher mindset, while the x402 protocol is practicalism driven by market demand.

Now the question arises: Will ERC-8004 follow the same path as AA?

Theoretically speaking, ERC-8004 looks very much like AA 2.0—it’s still EVM-specific, requiring deployment of three registry layers (Identity/Reputation/Validation), and early-stage incentives still heavily rely on external subsidies or staking. These are pitfalls AA previously encountered. For other chains to be compatible, they'd still need to add an extra layer of trust cost.

But the difference is, under the x402 framework, ERC-8004 is merely a tool—not a governing standard. Other chains need to comply with the x402 protocol, not ERC-8004.

This positioning difference is crucial. What was AA's fundamental problem? It aimed to become the "sole standard for Ethereum's payment experience," demanding the entire ecosystem revolve around it: wallets had to adapt, apps had to integrate, users had to change habits. Such top-down imposition naturally fails without killer applications and clear ROI.

ERC-8004 is different. It doesn't need to be the main character—because x402 has already solved the core issue: payments. ERC-8004 simply provides an "optional" trust layer atop this already functional payment network.

Moreover, ERC-8004 hitches a ride on x402 and doesn't need to build an ecosystem from scratch. x402 already has a clear commercial loop (Provider lead generation, Facilitator fees), a complete tech stack (HTTP protocol + EIP-3009), and a vibrant project ecosystem. ERC-8004 only needs plug-and-play integration.