Author: YQ, in-depth researcher of crypto infrastructure; Translator: xz@Jinse Finance

In 1994, Marc Andreessen made a critical mistake, which he later admitted: Netscape failed to embed payment functionality into its browser. Due to regulatory risks and the conservative stance of financial institutions, Netscape's partnerships with Visa and Microsoft with Mastercard ultimately fell through. This resulted in the default business model of the internet being dominated by advertising surveillance systems for three decades—a trillion-dollar industry built on comprehensive behavioral tracking rather than direct value exchange.

AI agents are now disrupting this balance. Autonomous systems don't watch ads, can't be mentally profiled, and lack 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 revitalize the long-dormant "402 Payment Required" status code in the HTTP standard, reshaping the value exchange paradigm for the AI era by combining blockchain settlement with cryptographic authorization.

The timing seems ripe. The blockchain infrastructure is well-developed: Layer 2 networks achieve tiered transaction costs and sub-second finality, and stablecoins have a circulation exceeding $42 billion across more than 20 chains. Google's A2A protocol further outlines a smart agent ecosystem based on "service payment and fee collection." However, a thorough review of the v1 specification, v2 revision proposals, and early ecosystem progress reveals fundamental limitations in its architecture, making large-scale application difficult without significant adjustments.

This paper conducts a systematic critique based on the principles of distributed systems, the economics of payment protocols, and practical deployment cases, and then proposes an architecture transformation scheme to support Internet-level deployment.

1. Understanding the x402 architecture

This protocol utilizes the EIP-3009 transferWithAuthorization() mechanism to enable gas-free stablecoin transfers. The client constructs a cryptographically signed authorization credential, allowing a third party (i.e., a relayer) to execute the transfer on its behalf.

Key observations: This design enables encrypted payment verification without requiring merchants to handle private keys or directly manage blockchain infrastructure. Settlements occur on networks such as Base (Ethereum L2), with finality of approximately 200 milliseconds and gas costs below $0.0001. While the protocol appears simple and elegant, this apparent simplicity masks several profound architectural issues that only become apparent upon closer examination.

2. Several hidden architectural issues

Question 1: The relay economic model has flaws.

The relay provider performs three functions: EIP-3009 signature verification, blockchain transaction broadcasting, and API infrastructure provision. However, the protocol layer does not provide any economic compensation mechanism. Let's calculate the costs precisely:

Coinbase's CDP relay currently offers free service 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 (excluding server, RPC node, monitoring system, compliance expenses, and engineering maintenance costs). The relay lacks a cost recovery mechanism at the protocol level.

Key finding: Compared to all successful payment protocols in internet history, Stripe charges $2.9% + $0.30 per transaction, PayPal takes approximately 3% of the merchant fee, and credit card networks earn 2-3% through merchant discount rates. These protocols capture value because they create value and establish sustainable business models that scale with transaction volume. In contrast, the x402 relay provides real value but receives no return on that value.

Question 2: Two-phase settlement mechanism leads to delays and atomicity failures.

The current architecture requires two separate blockchain interactions: a verification phase (checking signature validity and nonce status) and a settlement phase (executing the actual transaction). This design introduces both performance overhead and correctness issues.

A latency of 500-1100 milliseconds for a single request is acceptable, but in real-world applications, it can have an exponential cumulative effect:

• The autonomous research agent retrieved data from 100 x402 protected APIs: payment overhead accumulated over 50-110 seconds;
• The trading bot updates positions through 50 real-time data sources: cumulative latency of 25-55 seconds;
• The AI assistant invokes 20 tools during the conversation: the interaction delay increases by 10-22 seconds.

Violating a core principle of distributed systems: This is not a hypothetical concern, but an inevitable consequence of breaking down atomic operations (payments) into two-phase commit protocols. Since the 1970s, distributed systems research has clearly demonstrated that two-phase commit protocols are inherently vulnerable when atomic solutions exist. Two-phase commit (2PC) in the database domain has amply demonstrated its susceptibility to coordinator failure. x402 must avoid repeating this mistake.

Question 3: The exclusivity of EIP-3009 fragments the token ecosystem.

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

This means that x402 v1 has compatibility issues with 40% of its primary target tokens. The compatibility situation is even more severe with other stablecoins: Tether (USDT), the largest stablecoin with a circulating supply exceeding $140 billion, has never supported the EIP-3009 standard and has no plans to do so. The DAI stablecoin uses the EIP-2612 licensed standard; although functionally similar, differences in the interface lead to protocol-level incompatibility.

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

The protocol specification claims that x402 supports "Base, Solana, and any EVM network via self-hosted relays," seemingly offering chain-agnostic flexibility. However, a closer look at the implementation details reveals that its multi-chain support capability is far less than claimed.

Each relayer supports a different subset of networks, with variations in configuration requirements, token lists, and operational maturity. The protocol lacks a discovery mechanism for clients to query "which chains this merchant supports," forcing the service provider to specify a single network in a 402 response, compelling clients to either have funds on a specific chain or abandon the transaction.

Question 5: The relay layer is actually an unnecessary intermediate layer.

We need to examine the fundamental premise of this architecture: why must there be a relay in the design? The traditional explanation is debatable.

This alternative design has several advantages:

• Atomicity: Verification and settlement are completed within a single on-chain transaction;
• Reduced latency: One less network round trip (200-500 milliseconds vs 500-1100 milliseconds);
• Reliability: No reliance on the online status or API availability of the relay;
• Economic sustainability: Protocol fees (1% platform fee) are deducted directly on-chain.
• 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-independent redesign." After reviewing the v2 changelog, roadmap, and specification documents, I believe that although v2 achieves incremental improvements, it fails to solve the aforementioned fundamental architectural problems.

v2 major updates:

Transport layer abstraction: Decomposes protocols into type (data structure), logic (schema), and presentation layer (HTTP, MCP, A2A);

Solution Scalability: Standardize the "Precise Billing" scheme and support the addition of new models (by usage, commercial license, etc.);

Service discovery mechanism: A new Bazaar API has been added to retrieve resources that support x402.

The main legacy issues that were not addressed in v2:

The relay architecture is retained (client → relay/verification → relay/settlement → merchant);

Maintain the zero-cost economic model (the relay party still receives no revenue).

The two-phase settlement model will be retained.

Maintain the exclusivity of EIP-3009 (token support postponed to Q2 2026);

Continues explicit network matching (without a cross-chain abstraction layer);

The involvement of the relay party is still mandatory.

4. Requirements for achieving internet-scale adoption

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

Protocol fee-driven economic sustainability: 1% settlement fee is deducted on-chain to generate continuous revenue;

Atomic settlement is achieved through smart contracts: a single on-chain transaction eliminates race conditions;

Token flexibility: Simultaneously supports EIP-3009, EIP-2612 licenses and standard ERC-20;

Chain abstraction: Intent-based routing is implemented through Circle CCTP and the Across protocol;

Minimize trust dependency: a direct settlement mechanism that does not require mandatory intervention from relay parties.

5. Conclusion

x402 v1 represents a significant breakthrough in solving a problem that has plagued the industry for three decades. Thanks to the maturity of blockchain infrastructure, micropayments are now economically feasible. The rise of the agent economy has created an urgent need for machine-native payment protocols. Coinbase's endorsement and integration with Google's A2A provide institutional-grade credibility to the protocol. Its underlying technical path (HTTP 402 status code + blockchain settlement + cryptographic authorization) is solidly designed.

However, good intentions and corporate endorsements do not guarantee the success of a protocol. The relayer model fosters an unsustainable economic system—critical infrastructure must permanently bear operational losses. The delays and atomicity failures introduced by the two-phase settlement architecture could have been avoided through atomic solutions. EIP-3009's exclusivity fragmented the token ecosystem, excluding not only 40% of USDC's circulating supply but also virtually shutting out all competing stablecoins. Multi-chain support remains superficial, instead directly exposing the fragmentation problem of blockchain to end users. In scenarios where direct settlement via smart contracts offers superior features, the relayer effectively plays an unnecessary intermediary role.

While the v2 proposal improves upon traditional methods in terms of transport abstraction, service discovery mechanisms, and scalability, it remains unaddressed core issues such as the relay economic model, two-phase settlement, token restrictions, and cross-chain fragmentation. The roadmap postpones critical fixes to the second quarter of 2026. An autonomous internet requires an autonomous payment system—x402 v1 demonstrated technical feasibility, and while v2 achieves incremental optimizations, it still has a long way to go before truly meeting the demands.