In 1994, Marc Andreessen made a major mistake, which he later admitted: Netscape failed to embed payment functionality into the browser. Due to regulatory risks and the conservative attitudes of financial institutions, Netscape's collaborations with Visa, and Microsoft's with Mastercard, ultimately fell through. This led to the internet's default business model being dominated by the advertising surveillance system for thirty years—a trillion-dollar industry built on comprehensive behavioural tracking rather than direct value exchange. Today, AI agents are disrupting this balance. Autonomous systems do not watch advertisements, cannot be psychologically profiled, and have no monetisable 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 long-dormant "402 Payment Required" status code in the HTTP standard, combining blockchain settlement with cryptographic authorisation to reshape the paradigm of value exchange for the AI era. The timing seems ripe. Blockchain infrastructure has matured: Layer2 networks enable tiered transaction costs and sub-second finality, stablecoins circulate across over 20 chains with a volume exceeding $42 billion. Google's A2A protocol even more explicitly outlines an agent ecosystem for "paying for and charging for services." However, upon in-depth review of the v1 specification, v2 revision proposals, and early ecosystem progress, fundamental limitations in its architecture have been discovered, which, without significant adjustments, may hinder large-scale adoption. This article systematically critiques based on distributed system principles, payment protocol economics, and actual deployment cases, then proposes an architectural overhaul to support internet-scale deployment. 1. Understanding the x402 Architecture This protocol utilises the EIP-3009 transferWithAuthorization() mechanism to achieve gas-free stablecoin transfers. The client constructs an encrypted signed authorisation credential, allowing a third party (i.e., the relay) to execute the transfer on its behalf.Key observation: This design enables encrypted payment verification without requiring merchants to handle private keys or directly manage blockchain infrastructure. Settlement occurs on networks such as Base (Ethereum L2), with finality around 200 milliseconds and gas costs below $0.0001. The protocol appears elegantly simple, yet this surface simplicity conceals several profound architectural issues that only become apparent upon closer scrutiny. 2. Several Hidden Architectural Issues Issue One: The Relay's Economic Model Has Flaws The relay undertakes 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 precisely calculate the costs: Coinbase's CDP relay currently offers free service fees for USDC transactions on the Base chain. Each transaction costs the relay approximately $0.0006 in gas fees. When processing 1 million transactions per month, gas costs alone reach $600 (excluding server, RPC node, monitoring system, compliance overheads, and engineering maintenance expenses). The relay lacks a cost recovery avenue at the protocol level.Key finding: Compared to all successful payment protocols in internet history, Stripe charges 2.9% + $0.30 per transaction, PayPal extracts approximately 3% merchant fees, and credit card networks capture 2-3% through merchant discount rates. These protocols capture value because they create value, establishing sustainable business models that scale with transaction volume. In contrast, x402 relays provide real value but cannot obtain any value in return. Issue Two: Two-Phase Settlement Mechanism Causes Delay and Atomicity Failure The current architecture requires two independent blockchain interactions: a verification phase (checking signature validity and nonce state) and a settlement phase (executing the actual transfer). This design simultaneously introduces performance penalties and correctness issues.A single request latency of 500-1100 milliseconds is still acceptable, but real-world application scenarios generate exponential compounding effects: An autonomous research agent fetching data from 100 x402-protected APIs: payment overhead accumulates to 50-110 seconds; A trading bot updating positions through 50 real-time data sources: latency accumulates to 25-55 seconds; An AI assistant calling 20 tools in a conversation: interaction delay increases by 10-22 seconds. Violation of core distributed system principles: This is not a hypothetical concern but an inevitable outcome of splitting an atomic operation (payment) into a two-phase protocol. Since the 1970s, distributed systems research has clearly established that two-phase protocols have inherent fragility when atomic alternatives exist. The two-phase commit (2PC) in databases has fully demonstrated its susceptibility to coordinator failures. x402 must avoid repeating these mistakes. Issue Three: EIP-3009 Exclusivity Fragments the Token Ecosystem The protocol mandates the use of the EIP-3009 transferWithAuthorization() method for payment settlement. In principle, this allows any EIP-3009-compliant token to be compatible with x402. However, the reality is that the number of tokens meeting this standard is far fewer than economically relevant stablecoins.This means the x402 v1 version has compatibility issues with 40% of the varieties of its primary target tokens. The compatibility situation for other stablecoins is even more severe: Tether (USDT), as the largest stablecoin with a circulation exceeding $140 billion, has never supported the EIP-3009 standard and has no plans to do so. The DAI stablecoin adopts the EIP-2612 permit standard; although functionally similar, interface differences cause protocol-level incompatibility. Issue Four: Multi-Chain Support Is Misleading The protocol specification claims x402 supports "Base, Solana, and any EVM network via self-hosted relays," seemingly offering chain-agnostic flexibility. However, delving into implementation details reveals that its multi-chain support capability falls far short of what is superficially claimed.Each relay 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 does this merchant support," forcing service providers to specify a single network in the 402 response, compelling clients to either have funds on a specific chain or abandon the transaction. Issue Five: The Relay Is an Unnecessary Middle Layer We need to examine the fundamental premise of this architecture: why must a relay be included in the design? The traditional justifications are questionable.This alternative design offers multiple advantages: Atomicity: Verification and settlement are completed in a single on-chain transaction; Reduced latency: One less network round-trip (200-500 milliseconds vs 500-1100 milliseconds); Reliability: No reliance on the relay's online status or API availability; 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 Unresolved Issues The x402 team has released a v2 specification branch, attempting to address some v1 limitations through a "transport-layer-agnostic redesign." After reviewing the v2 changelog, roadmap, and specification documents, the author believes: although v2 achieves incremental improvements, it fails to resolve the aforementioned fundamental architectural issues. Major v2 updates: Transport layer abstraction: Splits the protocol into types (data structures), logic (schemes), and presentation layers (HTTP, MCP, A2A); Scheme extensibility: Specifies an "exact billing" scheme, supporting new patterns (usage-based, commercial licensing, etc.); Service discovery mechanism: Adds a Bazaar API for retrieving x402-supported resources. Major unresolved issues in v2: Retains the relay architecture (client → relay/verification → relay/settlement → merchant); Maintains a zero-fee economic model (relays still have no revenue); Preserves the two-phase settlement pattern; Insists on EIP-3009 exclusivity (token support postponed to Q2 2026); Continues explicit network matching (no cross-chain abstraction layer); Still mandates relay involvement.4. Conditions Required for Internet-Scale Adoption Based on thirty years of research into distributed systems and payment protocols, the author summarises the following architectural principles: Economic sustainability driven by protocol fees: Deduct 1% settlement fee on-chain to generate continuous revenue; Atomic settlement via smart contracts: Single on-chain transaction eliminates race conditions; Token flexibility: Simultaneously support EIP-3009, EIP-2612 permit, and standard ERC-20; Chain abstraction: Intent-based routing via Circle CCTP, Across protocol; Minimal trust dependence: Direct settlement mechanism without mandatory relay involvement.5. Conclusion x402 v1 has made substantial progress in addressing this thirty-year-old industry dilemma. Thanks to the maturity of blockchain infrastructure, micropayments have become economically feasible. The rise of the agent economy has created an urgent demand for machine-native payment protocols. Coinbase's endorsement and integration with Google A2A provide institutional-level credibility for the protocol. Its foundational technical approach (HTTP 402 status code + blockchain settlement + cryptographic authorisation) has solid design rationale. However, good intentions and corporate backing do not guarantee protocol success. The relay model fosters an unsustainable economic system—critical infrastructure must permanently bear operational losses. The two-phase settlement architecture introduces latency and atomicity failures that could be avoided with atomic alternatives. EIP-3009 exclusivity fragments the token ecosystem, not only excluding 40% of USDC circulation but also almost all competitive stablecoins. Multi-chain support is merely superficial, instead directly exposing blockchain fragmentation issues to end-users. In scenarios where smart contract direct settlement offers superior characteristics, the relay acts as an unnecessary middle layer. Although the v2 proposal makes improvements in transport abstraction, service discovery mechanisms, and scheme extensibility, it does not address core issues such as the relay's economic model, two-phase settlement, token restrictions, and cross-chain fragmentation. The roadmap postpones critical fixes to Q2 2026. An autonomous internet requires autonomous payment systems—x402 v1 demonstrates technical feasibility, and v2, while achieving incremental optimisation, still has a long way to go to truly meet needs.