Author: Haotian; Source: X, @tmel0211
Last time I talked about how the x402 protocol continued the Lightning Network. Recently, while having dinner with a group of programmer friends, I was "challenged" again: Isn't x402 just the previous AA account abstraction?
The subtext is that Ethereum has been working on account abstraction for many years, investing so many resources in ERC-4337, Paymaster, and others, including various grants and wallet service providers, but as we've seen, it's been criticized by many as all talk and no action.
While I don't think AA has failed, where exactly is the crux of the problem?
... 1. Paymaster shifts the user's gas consumption to the project team, which sounds appealing, but the project team's motivation to burn money on payment services is weak, and the ROI is unclear. Undoubtedly, this has led to a dead end in the business model. How can a business model survive without self-sustaining profitability and rely solely on external funding? 2. The AA account abstraction is limited to the EVM ecosystem. For example, ERC4337, Paymaster, and EntryPoint contracts are all Ethereum-specific. To achieve cross-EVM ecosystem use including Solana and BTC, additional middleware services are needed. However, this adds another layer of fee sharing, further jeopardizing the business model's ROI. There are many other complex technical issues, which I won't elaborate on, but to put it simply, AA is essentially a product of "technology for technology's sake," a product of past Ethereum research trends. In comparison, what does the x402 protocol do? What are the differences? Some criticize it for bringing out the 30-year-old HTTP 402 status code, like playing with fire. But don't forget, the HTTP 402 status code—this is a fundamental internet protocol, the common language of Web2 and Web3. AA requires smart contracts, on-chain state, and EVM execution; x402 only requires an HTTP request header, and can be used by any system that supports HTTP—Web2 APIs, Web3 RPCs, and even traditional payment gateways are all compatible. This isn't an optimization solution based on stacked technologies, but rather a "dimensional reduction attack" that simplifies the protocol layer. Instead of struggling with various compatibility and trust methods at the application layer, it's better to first unify the standards at the upstream protocol layer. Crucially, x402 is inherently a good cross-chain interoperability standard. As long as the Agent can send HTTP requests, handle 402 responses, and complete EIP-3009 authorization (or equivalent standards of other chains), whether it's Base, Monad, Solana, Avalanche, or BSC, cross-chain interoperability is seamless at the protocol level, only affecting the single point of failure in settlement and payment. Comparatively, cross-chain costs are much lower. Facilitator can serve multiple chains simultaneously, user payment history data can be indexed uniformly, and developers can "connect" the entire ecosystem with a single integration. My overall feeling is that AA is a sophisticated project driven by a researcher's mindset, while the x402 protocol is a pragmatic approach forced by market demand. The question then arises: will ERC-8004 follow the same path as AA? From a purely theoretical perspective, ERC-8004 is very similar to AA 2.0, still exclusive to the EVM, requiring the deployment of a three-layer registry (Identity/Reputation/Validation), and its early incentives heavily rely on external subsidies or staking—all pitfalls that AA encountered. For other chains to be compatible, an additional layer of trust costs will be added. However, the difference lies in the fact that, within the x402 framework, ERC-8004 is merely a tool, not a overarching standard. Other chains need to be compatible with the x402 protocol, not ERC8004 itself. This difference in positioning is crucial. What was AA's problem back then? It wanted to become the "sole standard for Ethereum payment experience," demanding the entire ecosystem revolve around it: wallets had to adapt, applications had to integrate, and users had to change their habits. This top-down, forceful push, without a killer application and a clear ROI, naturally failed to gain traction. ERC-8004, however, is different. It doesn't need to be the main player because x402 has already solved the core problem: payments. ERC-8004 simply provides an "optional" trust layer on this already functional payment network. Moreover, ERC-8004 rides on the coattails of x402, without needing to build its own ecosystem from scratch. x402 already has a clear business model (Provider-driven traffic, Facilitator-based monetization), a complete technology stack (HTTP protocol + EIP-3009), and an active project ecosystem; ERC-8004 only requires "plug and play."