x402 is very good, but what are the hidden issues?

Author: YQ, Deep Researcher in Cryptocurrency Infrastructure; 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 conservative attitudes of financial institutions, the collaboration between Netscape and Visa, as well as Microsoft and MasterCard, ultimately fell apart. This resulted in the internet’s default commercial model being dominated by advertising surveillance systems for thirty years — a trillion-dollar industry built on comprehensive behavioral tracking rather than direct value exchange.

Today, AI intelligent agents are breaking this balance. Autonomous systems do not watch ads, cannot be psychologically profiled, and have no monetizable attention. Content publishers face a binary choice: either tolerate parasitic scraping that destroys creative motivation or establish direct payment mechanisms. The x402 protocol is the most reliable attempt to activate the long-sealed “402 Payment Required” status code in the HTTP standard, combining blockchain settlement and cryptographic authorization to reshape value exchange paradigms for the AI era.

The timing appears to be ripe. Blockchain infrastructure has matured: Layer 2 networks enable tiered transaction costs and sub-second finality; stablecoins circulate on over 20 chains with a total volume exceeding $42 billion. Google’s A2A protocol more explicitly plans for an “Service Payment and Charging” intelligent agent ecosystem. However, after a thorough review of the v1 specification, v2 revision proposals, and early ecosystem progress, it becomes clear that the architecture has fundamental limitations. Without major adjustments, large-scale application will be difficult.

This article systematically critiques the architecture based on principles of distributed systems, payment protocol economics, and deployment case studies, then proposes a structural overhaul to support internet-scale deployment.

1. Understanding the x402 Architecture

This protocol uses the EIP-3009 transferWithAuthorization mechanism to enable stablecoin transfers without gas fees. The client constructs an encrypted signed authorization credential, allowing a third party (relay) to execute the transfer on its behalf.

Key observation: This design achieves encrypted payment verification without merchants handling private keys or directly managing blockchain infrastructure. Settlement occurs on networks like Base (Ethereum Layer 2), with finality around 200 milliseconds and gas costs below $0.0001. The protocol appears elegant and simple, but this superficial simplicity conceals several profound architectural issues that only become apparent upon deeper examination.

( 2. Several Hidden Architectural Problems

)# Issue 1: Flaws in the Relay Economic Model

The relay performs three functions: EIP-3009 signature verification, blockchain transaction broadcasting, and API infrastructure provisioning. Yet, the protocol layer provides no economic compensation mechanism. Let’s precisely calculate the costs:

Currently, Coinbase’s CDP relay on Base for USDC transactions charges no service fee. Each transaction consumes about $0.0006 in gas for the relay. Processing 1 million transactions per month would incur a gas cost of $600 (excluding server, RPC node, monitoring, compliance, and engineering maintenance costs). The relay has no means of recovering these costs at the protocol level.

![]###https://img-cdn.gateio.im/webp-social/moments-ddee013a366166814f8d26dc28d9fd03.webp###

Key insight: Compared to all successful payment protocols in internet history—Stripe charges 2.9% + $0.30 per transaction, PayPal takes about 3% merchant fee, credit card networks earn 2-3% via merchant discounts—these protocols capture value because they create value and establish sustainable business models that grow with transaction volume. The x402 relay provides real value but cannot obtain any value return.

(# Issue 2: Two-Stage Settlement Causes Latency and Atomicity Failures

The current architecture requires two separate blockchain interactions: verification (checking signature validity and nonce status) and settlement (executing the actual transfer). This design introduces performance degradation and correctness risks.

![])https://img-cdn.gateio.im/webp-social/moments-dd212d72791fedc2fb9fa662f0c07c8c.webp###

A single request with 500-1100 milliseconds delay might be acceptable, but in real-world scenarios, the effects compound exponentially:

• Autonomous research agents fetching data from 100 APIs protected by x402: cumulative payment overhead of 50-110 seconds;
• Trading bots updating positions from 50 real-time data sources: cumulative delay of 25-55 seconds;
• AI assistants invoking 20 tools during conversations: interaction latency increases by 10-22 seconds.

This violates core principles of distributed systems: it’s not hypothetical concern but an inevitable consequence of splitting atomic operations (payment) into a two-phase protocol. Since the 1970s, distributed systems research has shown that two-phase protocols are inherently fragile when a solution requires atomicity. The two-phase commit (2PC) in databases has demonstrated susceptibility to coordinator failures. x402 must avoid repeating these pitfalls.

(# Issue 3: EIP-3009’s Exclusivity Fragmentation of the Token Ecosystem

The protocol mandates using EIP-3009 transferWithAuthorization for payments. In principle, any token compliant with EIP-3009 can be used with x402. However, in practice, the number of tokens supporting this standard is far fewer than the correlation of relevant stablecoins.

![])https://img-cdn.gateio.im/webp-social/moments-6f09c6c24be2c0a2a12436288a493991.webp###

This means that about 40% of the main target tokens for x402 v1 are incompatible. The situation is even more severe for other stablecoins: Tether (USDT), with a circulating supply exceeding $140 billion, has never supported EIP-3009 and has no plans to do so. DAI uses the EIP-2612 permit standard, which is similar but incompatible at the protocol interface level.

(# Issue 4: Multi-Chain Support Is Superficial

The specification claims x402 supports “Base, Solana, and any EVM network via self-hosted relays,” suggesting chain-agnostic flexibility. But a closer look at implementation details reveals support is far less comprehensive.

![])https://img-cdn.gateio.im/webp-social/moments-e4d211b779bd8c99d0961bb1d4244472.webp(

Each relay supports a different subset of networks, with varying configuration requirements, token lists, and operational maturity. The protocol lacks a discovery mechanism for clients to query “which chains does this merchant support?” The service provider can only specify a single network in the 402 response, forcing clients either to hold funds on that chain or abandon the transaction.

)# Issue 5: Relay as an Unnecessary Middle Layer

We need to reconsider the fundamental premise: why must there be a relay? Traditional explanations are questionable.

An alternative design offers multiple advantages:

• Atomicity: verification and settlement are completed in a single on-chain transaction;
• Reduced latency: fewer network round-trips (200-500 ms vs 500-1100 ms);
• Reliability: no dependency on relay’s online status or API availability;
• Economic sustainability: direct on-chain deduction of protocol fees (1% platform fee);
• Transparency: all settlement logic is auditable on-chain.

3. v2 Proposal: Improvements and Remaining Issues

The x402 team has released a v2 specification branch, attempting to address some limitations of v1 through “protocol-layer agnostic redesign.” After reviewing the v2 changelog, roadmap, and specification documents, I believe: although v2 introduces incremental improvements, it fails to resolve the fundamental architectural issues outlined above.

Main updates in v2:

• Transport layer abstraction: splitting the protocol into types (data structures), logic (schemes), and presentation layers (HTTP, MCP, A2A);
• Scheme extensibility: defining “precise billing” schemes supporting new modes (usage-based, commercial licensing);
• Service discovery: adding Bazaar API to retrieve resources supporting x402.

Major unresolved issues in v2:

• Continued reliance on relay architecture (client→relay/verification→relay/settlement→merchant);
• Maintaining a zero-fee economic model (relays still have no revenue);
• Preserving two-phase settlement;
• Insisting on EIP-3009 exclusivity (token support delayed to Q2 2026);
• Continuing explicit network matching (no cross-chain abstraction layer);
• Forcing relay involvement.

4. Achieving Internet-Scale Deployment Conditions

Based on three decades of research into distributed systems and payment protocols, I summarize the following architectural principles:

• Protocol fee-driven economic sustainability: deduct 1% on-chain settlement fee to generate ongoing revenue;
• Atomic settlement via smart contracts: single on-chain transaction eliminates race conditions;
• Token flexibility: support EIP-3009, EIP-2612 permits, and standard ERC-20 tokens;
• Chain abstraction: routing based on intent via Circle’s Cross-Chain Transfer Protocol (CCTP), Across Protocol;
• Minimize trust dependencies: direct settlement mechanisms without mandatory relay involvement.

(https://img-cdn.gateio.im/webp-social/moments-8ebc414b571549d8648102043969650e.webp)

5. Conclusion

x402 v1 has made a substantial breakthrough in solving a problem that has plagued the industry for thirty years. Thanks to the maturity of blockchain infrastructure, micropayments are now economically feasible. The rise of intelligent agents creates an urgent demand for machine-native payment protocols. Coinbase’s endorsement and integration with Google’s A2A protocol lend institutional credibility. Its core technical path (HTTP 402 status code + blockchain settlement + cryptographic authorization) is well-designed.

However, good intentions and corporate backing do not guarantee success. The relay model has fostered an unsustainable economic system—key infrastructure must bear operational losses indefinitely. The two-phase settlement architecture introduces latency and atomicity failures that could be avoided with atomic solutions. EIP-3009’s exclusivity fragments the token ecosystem, excluding 40% of USDC circulation and nearly all competing stablecoins. Multi-chain support remains superficial, exposing blockchain fragmentation issues directly to end users. In scenarios where direct on-chain settlement offers better features, relays are essentially unnecessary middle layers.

Although the v2 proposal improves transport abstraction, service discovery, and scheme extensibility, it does not address core issues such as relay economic models, two-phase settlement, token restrictions, and cross-chain fragmentation. Its roadmap delays key fixes until Q2 2026. An autonomous internet requires autonomous payment systems—x402 v1 demonstrates technical feasibility, and v2 offers incremental improvements, but there is still a long way to go to truly meet the needs.