x402 is good, but what issues are being covered up?

Author: YQ, encryption infrastructure Depth researcher; Translator: xz@Golden Finance

In 1994, Marc Andreessen made a significant mistake, which he later admitted: Netscape failed to embed payment functionality into the browser. Due to regulatory risks and the conservative attitude of financial institutions, the collaboration between Netscape and Visa, as well as between Microsoft and MasterCard, ultimately fell through. This led to the internet's default business model being dominated by an advertising surveillance system for thirty years—a trillion-dollar industry built on comprehensive behavioral tracking rather than direct value exchange.

AI agents are now breaking this balance. Autonomous systems do not watch ads, cannot be profiled psychologically, and have no monetizable attention. Content publishers face a binary choice: either allow parasitic scraping that destroys creative motivation or establish direct payment mechanisms. The x402 protocol is the most reliable attempt to activate the “402 Payment Required” status code that has been dormant in the HTTP standard, reshaping the paradigm of value exchange for the AI era through a combination of blockchain settlement and encryption authorization.

The timing seems to be ripe. The blockchain infrastructure has been完善: Layer 2 networks achieve tiered transaction costs and sub-second finality, with stablecoins circulating over 42 billion dollars across more than 20 chains. Google's A2A protocol has more clearly outlined the “service payment and charging” agent ecosystem. However, after深入研读 the v1 specifications, v2 revision proposals, and early ecological progress, it is found that its architecture has fundamental limitations, and without significant adjustments, it is difficult to achieve large-scale application.

This article conducts a systematic critique based on the principles of distributed systems, the economics of payment protocols, and actual deployment cases, and then proposes an architectural transformation plan to support internet-level deployments.

1**, Understand x402 Architecture

The protocol uses the EIP-3009 transferWithAuthorization() mechanism to achieve gas-free stablecoin transfers. The client will construct an encrypted signature authorization credential that allows a third party (i.e., a relayer) to execute the transfer on its behalf.

Key Observation: This design implements encryption payment verification without merchants handling private keys or directly managing blockchain infrastructure. Settlements occur on networks such as Base (Ethereum L2), with finality around 200 milliseconds and Gas costs below $0.0001. The protocol appears simple and elegant; however, this surface simplicity conceals several profound architectural issues that only become apparent upon closer examination.

2**, Several Covered Architectural Issues**

Question 1: The relay party's economic model has defects

The relay party undertakes three functions: EIP-3009 signature verification, blockchain transaction broadcasting, and API infrastructure supply. However, the protocol layer does not provide any economic compensation mechanism. Let us accurately calculate the costs:

The CDP relay of Coinbase currently implements zero service fees for USDC transactions on the Base chain. Each transaction incurs approximately $0.0006 in Gas fees for the relay. When processing 1 million transactions per month, the Gas cost alone reaches $600 (not including server, RPC node, monitoring system, compliance expenses, and engineering maintenance costs). The relay lacks cost recovery avenues at the protocol level.

Key Findings: Compared to all successful payment protocols in the history of the Internet, Stripe charges 2.9% + $0.3 per transaction, PayPal takes about 3% merchant fees, and credit card networks earn 2-3% through merchant discount rates. These protocols can capture value because they create value and establish sustainable business models that scale with transaction volume. However, the x402 relay party provides real value but cannot receive any value in return.

Question 2: The two-stage settlement mechanism leads to delays and atomicity failure

The current architecture requires two independent blockchain interactions: Verification Phase (checking signature validity and nonce status) and Settlement Phase (executing the actual transfer). This design simultaneously raises performance losses and correctness issues.

A latency of 500-1100 milliseconds per request is acceptable, but in real application scenarios, an exponential cumulative effect will occur:

Self-research agency obtains data from 100 APIs protected by x402: payment expenses accumulate 50-110 seconds;

Trading bots update positions through 50 real-time data sources: delay accumulation of 25-55 seconds;

AI****Assistant invokes 20 tools in the conversation: interaction delay increased by 10-22 seconds.

Violation of Core Principles of Distributed Systems: This is not a hypothetical concern, but an inevitable result of splitting atomic operations (payments) into a two-phase protocol. Since the 1970s, distributed systems research has made it clear: when atomic schemes exist, two-phase protocols have inherent vulnerabilities. The two-phase commit (2PC) in the database field has fully demonstrated its susceptibility to coordinator failures. x402 must avoid repeating this mistake.

Question 3:EIP-3009's exclusivity fractures the token ecosystem

The protocol mandates the use of the EIP-3009 transferWithAuthorization() method for payment settlement. In principle, this allows any token that complies with the EIP-3009 standard to be compatible with x402. However, the reality is that the number of tokens that meet this standard is far less than the number of economically relevant stablecoins.

This means that the x402 v1 version has compatibility issues with 40% of the varieties among its main target tokens. The compatibility situation with other stablecoins is even more severe: Tether (USDT), the largest stablecoin with a circulating supply of over $140 billion, has never supported the EIP-3009 standard and has no related plans. The DAI stablecoin adopts the EIP-2612 permission standard, which, although functionally similar, leads to protocol layer incompatibility due to interface differences.

Question 4: Multi-chain support is not as it seems

The protocol specification claims that x402 supports “Base, Solana, and any EVM networks through self-hosted relays”, which seems to provide chain-agnostic flexibility. However, a deeper look into the implementation details reveals that its multi-chain support capability is far lower than what is claimed on the surface.

Each relay party supports different subsets of networks, and there are variations in configuration requirements, token lists, and operational maturity. The protocol lacks a discovery mechanism for clients to query “which chains are supported by this merchant,” and the service provider can only specify a single network in the 402 response, forcing clients to either have funds on a specific chain or abandon the transaction.

Question 5: The relay party is indeed an unnecessary intermediary layer

We need to examine the basic premise of this architecture: why must there be an intermediary in the design? The traditional reasoning is worth discussing.

This alternative design has multiple advantages:

Atomicity: Verification and settlement are completed in a single on-chain transaction;

Reduced latency: Reduce one round trip of the network (200-500 milliseconds vs 500-1100 milliseconds);

Reliability: No need to rely on the online status or API availability of intermediaries;

Economic Sustainability: Direct deduction of protocol fees on-chain (1% platform fee);

Transparency: All settlement logic is auditable on-chain.

3**、v2 Proposal: Improvements and Legacy Issues**

The x402 team has released the v2 specification branch, attempting to address some of the limitations of v1 through a “transport layer agnostic redesign.” After reviewing the v2 changelog, roadmap, and specification documents, the author believes that while v2 has achieved incremental improvements, it has not resolved the aforementioned fundamental architectural issues.

v2****Main updates：

Transport Layer Abstraction: Splitting protocols into types (data structures), logic (schemes), and representation layers (HTTP, MCP, A2A);

Scalability of the solution: Standardize the “precise billing” solution, supporting the addition of new models (such as usage-based, commercial licensing, etc.);

Service discovery mechanism: New Bazaar API added for retrieving resources that support x402.

v2****Unresolved Major Legacy Issues:

Continue to use the relay party architecture (client → relay party/verification → relay party/settlement → merchant);

Maintain zero-fee economic model (relay party still has no revenue);

Retain the two-stage settlement model;

Adhere to EIP-3009 exclusivity (token support postponed to the second quarter of 2026);

Continuing explicit network matching (no cross-chain abstraction layer);

Still require the intermediary to intervene.

4**, Requirements for Achieving Internet-Level Scale Adoption**

Based on thirty years of research on distributed systems and payment protocols, I have summarized the following architectural principles:

Economic Sustainability Driven by Protocol Fees: A 1% settlement fee is deducted on-chain to generate continuous revenue;

Atomic Settlement via Smart Contracts: Single on-chain transaction eliminates race conditions;

Token Flexibility: Synchronously supports EIP-3009, EIP-2612 permissions and standard ERC-20;

Chain Abstraction: Achieving intent-based routing through Circle CCTP and Across protocol;

Minimize Trust Dependency: A direct settlement mechanism that does not require mandatory intervention from intermediaries.

5**, Conclusion**

x402 v1 has made substantial breakthroughs in solving a problem that has plagued the industry for thirty years. Thanks to the maturity of blockchain infrastructure, micro-payments have become economically feasible. The rise of the agent economy has created an urgent demand for machine-native payment protocols. The endorsement from Coinbase and its integration with Google A2A provides institutional-level credibility for this protocol. Its foundational technology path (HTTP 402 status code + blockchain settlement + encryption authorization) has solid design rationality.

However, good intentions and corporate endorsements do not guarantee the success of a protocol. The relay model has given rise to an unsustainable economic system—key infrastructure must permanently bear operational losses. The delays and atomic failures brought about by the two-stage settlement architecture could have been avoided through atomic solutions. The exclusivity of EIP-3009 has fragmented the token ecosystem, excluding not only 40% of USDC's circulation but also almost all competitive stablecoins. Multi-chain support remains superficial, directly exposing the fragmentation issue of blockchain to end users. In scenarios where direct settlement via smart contracts can provide better features, the relay actually plays an unnecessary intermediary role.

Although the v2 proposal has made improvements in transmission abstraction, service discovery mechanisms, and solution scalability, it does not touch on core issues such as the economic model of relay parties, two-stage settlement, token restrictions, and cross-chain fragmentation. The roadmap postpones key fixes to the second quarter of 2026. An autonomous internet needs an autonomous payment system - x402 v1 demonstrates technical feasibility, while v2 has achieved incremental optimization, it is still a long way from truly meeting the needs.