Payment is the killer app for the AI agent era, but it only becomes real when it is embedded into concrete business flows instead of staying as a speculative story. Over the past decade, most of the economic activity in crypto has been trading, while everyday payments and machine‑to‑machine transactions remained marginal. Autonomous agents change this equation: they need to be able to discover services, decide when a payment is worthwhile, and execute many small transactions automatically, often across different protocols and chains.

The emerging payment stack around agents is built from several complementary pieces. At the Web2 layer, Stripe’s Agentic Commerce Protocol (ACP) connects AI agents to existing merchants over Stripe’s card and bank rails. At the agent communication layer, Google’s A2A/AP2 defines how agents talk to each other and how payment credentials travel between them. On the crypto side, x402 finally gives real meaning to the long‑reserved HTTP status code 402 Payment Required, letting servers express pay‑per‑use access in a standard way. Beneath that, Ethereum standards such as ERC‑3009 and ERC‑8004 provide gas‑abstracted token transfers and an on‑chain identity and reputation layer for agents. Together, these elements form an end‑to‑end payment and trust stack for autonomous AI.

This article follows the outline implied by this table. It starts from Stripe ACP, moves through A2A/AP2, and then focuses on x402 and its supporting Ethereum standards, before ending with ecosystem developments, limitations and long‑term bets around players like Coinbase and Cloudflare.

Stripe ACP

What's ACP

Stripe’s Agentic Commerce Protocol (ACP) is an open standard co‑developed by OpenAI and Stripe in 2025. Its goal is to let AI agents such as ChatGPT complete e‑commerce transactions on behalf of users directly inside a conversation, without sending them through traditional checkout pages. Rather than inventing a new currency or chain, ACP wraps Stripe’s existing card and bank rails in an agent‑friendly interface with clear limits, signatures and consent flows.

What's the Architecture

At a high level, four roles appear in an ACP flow. The user provides an intent such as “Book me a hotel in Tokyo under $200.” The AI agent searches, compares options and negotiates with merchants. The merchant backend is a normal Stripe‑integrated system that already knows how to charge cards or bank accounts. Between them sits the ACP infrastructure operated by Stripe and OpenAI, which turns user approval into a short‑lived payment token that the agent can pass to the merchant. The agent never touches raw card data; it only sees these scoped tokens.

What's the Process

The process typically begins when the user expresses a purchase intent in an AI conversation. The agent calls ACP to open a payment session, and the user sees a lightweight embedded confirmation UI, usually inside the same chat. Once the user confirms, ACP issues a one‑time token that is bound to a specific user, merchant and amount. The agent sends this token to the merchant backend via an API call. The merchant uses its existing Stripe integration to capture funds with that token and then returns the result, such as a receipt or booking details. The agent summarizes the outcome for the user, who experiences the whole sequence as a single, natural dialogue.

What's the use cases

Stripe ACP’s main use case is conversational shopping and service purchase. Users can ask an AI to find products, filter and compare them, and buy the final choice without ever visiting a website. For routine needs, such as weekly grocery orders or periodic replacement of consumables, users can delegate clear rules to an agent that operates within defined spending and merchant limits. Over time this pattern can extend to digital subscriptions, travel and software purchases. ACP therefore provides the first large‑scale bridge between general‑purpose AI agents and Web2 merchants.

Google A2A & AP2

What's A2A

A2A (Agent‑to‑Agent) is a communication protocol introduced by Google in April 2025 to standardize how AI agents talk to each other across different platforms. It is built on familiar web primitives such as HTTP, Server‑Sent Events and JSON‑RPC style messaging, so that agents can exchange structured requests and responses over the open internet. AP2 (Agent Payments Protocol) is an extension that brings payment‑related information, such as verifiable credentials and spending permissions, into this agent‑to‑agent channel. In this architecture, MCP is mainly for connecting an agent to tools and models, while A2A is for connecting agents to one another.

What's the architecture

A2A follows a client‑server model over HTTP. Each agent exposes an Agent Card, which is a machine‑readable description of the tasks it can perform, the input and output formats it expects, and any authentication requirements. Other agents can fetch this card to discover capabilities dynamically instead of relying on hard‑coded integrations. Once a connection is established, agents exchange Messages that can contain different Parts such as plain text, JSON data or small binary files. A2A supports multi‑turn dialogues, so agents can ask clarifying questions, send intermediate results and coordinate over several steps before completing a task.

What's the relationship between A2A with payment protocol and x402?

A2A is already seeing real adoption as a generic way for agents to cooperate, and it is not crypto‑specific. Crypto projects with multi‑agent systems, such as DAO automation or on‑chain games, can use A2A off‑chain to negotiate and coordinate before committing final results to the blockchain. The proposed Ethereum standard ERC‑8004 explicitly references A2A endpoints in its agent metadata format, showing that the ecosystem expects these web‑native and on‑chain layers to interoperate closely.

AP2 (Agent Payment Protocol) extends A2A with payment semantics and verifiable digital credentials, in collaboration with card networks like Mastercard, PayPal and Amex, and crypto partners such as Coinbase, the Ethereum Foundation, Mysten Labs, Questflow, MetaMask and Eigen Labs. Through AP2, an agent can present credentials that say it is allowed to spend up to a certain amount for a given user or task. But AP2 more focuses on "Manifests" and "Intents." It is more deeply integrated into the Android/Chrome ecosystem and relies on Google Pay rails (fiat-centric). Protocols like x402 then provide a concrete way for servers to request and verify actual payments over HTTP, based on those credentials.

What's the mechanism

The mechanism that ties this together is verifiable credentials. A wallet, bank or identity provider can issue a credential saying an agent has passed KYC, or that it has a spending limit on behalf of a user, or that it is allowed to access certain categories of service. These credentials are signed in a way that any third party can verify without contacting the issuer. When an agent participates in an A2A/AP2 exchange or an x402 payment, it can attach the relevant credentials so that counterparties and facilitators can check that it is acting within its mandate.

x402

What's the x402

While HTTP status codes such as 200 OK for success, 404 Not Found for missing resources and 500 Internal Server Error for failures became part of everyday web language, 402 Payment Required remained a reserved placeholder. This gap reflected a deeper design choice: the web did not include a native value transfer layer. Payments were always bolted on through separate systems like card networks, subscriptions or proprietary billing APIs.

HTTP 402 is defined as the status code for a resource that requires payment, but in practice it was almost never used in a standardized way. x402 is a proposal to change that by giving 402 Payment Required a precise meaning. It defines how a server can respond with a 402 and a machine‑readable description of what payment is needed, and how a client can answer with a signed crypto payment payload to gain access. x402 is deliberately narrow: it is a neutral protocol layer for payments that can sit underneath many different commerce or agent communication protocols, rather than a product or currency on its own.

The Architecture

In x402, it is helpful to separate the main actors and their responsibilities.

• Client
  • Uses wallet addresses to send and sign payments, and is identified by those addresses in the protocol.
  • Can be a human‑operated application, an autonomous agent, or a backend service acting on behalf of a user or system.
• Server
  • Owns the protected resource (for example, an API endpoint or a data file).
  • Decides the pricing rules and what kind of payment payload it will accept.
• Facilitator
  • Runs off‑chain (often by an exchange or wallet provider) and receives the client’s signed payment authorization.
  • Verifies payments: checks that the client’s payment payload matches the server’s declared requirements (asset, amount, validity window and so on).
  • Settles payments: submits validated payments to the blockchain and monitors confirmation.
  • Provides responses: sends verification and settlement results back to the server so that the server can decide whether to grant access.

The standard intentionally separates client, server and facilitator so that different vendors can implement each role. A server may use Coinbase’s facilitator or run its own, and a user’s agent can choose among competing facilitators based on speed, supported networks and fees.

The Workflow

V1

1. An AI agent or client sends an HTTP request to a resource.
2. The server responds with HTTP 402, including payment details (e.g., amount, recipient address).
3. The client autonomously executes the payment using stablecoins, often via a wallet or agent toolkit.
   • gathers a payment payload – often a signed token transfer or permit (e.g. an ERC-20 permit signature) authorizing the exact amount to the merchant
4. Upon verification, the server grants access.

V2

This simple V1 model works well when each request is worth at least several cents and gas is cheap, but it becomes fragile for sub‑cent or very high‑frequency usage. If network congestion pushes gas costs higher than the value per request, the economics break down. The x402 roadmap therefore points toward a V2 that focuses on deferred settlement and more flexible payment schemes. Instead of paying exactly once per request, clients can open a tab, authorize spending up to a maximum for a period, or agree to streaming rates that accumulate over time and are settled in batches.

The "Deferred" scheme is the critical innovation enabling Pay-per-Crawl. It decouples the commitment from the settlement.

• Workflow: The Client signs an off-chain authorization. The Facilitator aggregates these authorizations and settles them in a batch at a later time.
• Pros: Instant finality (from the client's perspective), near-zero marginal gas cost, infinite throughput.
• Cons: Introduces trust in the Facilitator; requires complex state management.
• Use Case: High-frequency, low-value interactions (e.g., crawling, API calls).
  We would demonstrate it the Cloudflare section later.

Facilitator is the key part

Why Facilitator is the key

The facilitator is the defining architectural innovation of x402 because it bridges the synchronous world of HTTP and the asynchronous world of blockchains. A pure on‑chain design would force servers to wait for blocks and confirmations before responding, which does not fit real‑time APIs. With a facilitator in the middle, servers can rely on fast off‑chain verification of payment payloads and make their own choices about when to deliver content and when to wait for stronger finality. In production, the facilitator must also handle queuing, batching and error handling, otherwise the economic and reliability benefits of x402 cannot be realized.

Complementary

ERC-3009

What's the ERC-3009

In a standard ERC-20 payment flow, a user usually has to perform two on-chain transactions. First, they call approve(spender, amount) to authorize a smart contract to move funds on their behalf. Then they call transferFrom(sender, recipient, amount) to actually execute the transfer. This pattern is gas-heavy, clumsy for user experience, and it encourages very large or even unlimited approvals, which become a security risk if the approved contract is ever exploited.

abstract contract EIP3009 is IERC20Transfer, EIP712Domain {
    // keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
    bytes32 public constant TRANSFER_WITH_AUTHORIZATION_TYPEHASH = 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267;

    // keccak256("ReceiveWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
    bytes32 public constant RECEIVE_WITH_AUTHORIZATION_TYPEHASH = 0xd099cc98ef71107a616c4f0f941f04c322d8e254fe26b3c6668db87aae413de8;

    mapping(address => mapping(bytes32 => bool)) internal _authorizationStates;

    event AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce);

    string internal constant _INVALID_SIGNATURE_ERROR = "EIP3009: invalid signature";

    function authorizationState(address authorizer, bytes32 nonce)
        external
        view
        returns (bool)
    {
        return _authorizationStates[authorizer][nonce];
    }

    function transferWithAuthorization(
        address from,
        address to,
        uint256 value,
        uint256 validAfter,
        uint256 validBefore,
        bytes32 nonce,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external {
        require(now > validAfter, "EIP3009: authorization is not yet valid");
        require(now < validBefore, "EIP3009: authorization is expired");
        require(
            !_authorizationStates[from][nonce],
            "EIP3009: authorization is used"
        );

        bytes memory data = abi.encode(
            TRANSFER_WITH_AUTHORIZATION_TYPEHASH,
            from,
            to,
            value,
            validAfter,
            validBefore,
            nonce
        );
        require(
            EIP712.recover(DOMAIN_SEPARATOR, v, r, s, data) == from,
            "EIP3009: invalid signature"
        );

        _authorizationStates[from][nonce] = true;
        emit AuthorizationUsed(from, nonce);

        _transfer(from, to, value);
    }
}

EIP-3009 introduces a new function, transferWithAuthorization, that reshapes this pattern. Instead of sending approvals and transfers directly on-chain, the token holder signs a structured message off-chain that specifies who can transfer how much, within which time window, and under which random nonce. A third party, often called a relayer or facilitator, wraps this signed message into a single on-chain transaction, pays the gas and lets the contract verify the signature and execute the transfer. In practice, the user signs a message saying “I authorize the transfer of X tokens to Y,” sends it to the relayer, and the contract validates and carries out the instruction.

This design solves two problems at once. First, it loosens the user’s dependency on holding native gas. The relayer can sponsor gas and recover its cost through fees paid in the ERC-20 token or off-chain. Second, it avoids the approval anti-pattern: each authorization can be narrow, time-limited and tied to a specific nonce, rather than a broad, open-ended allowance. The contract maintains an authorizationState[authorizer][nonce] mapping to track used nonces, ensuring that each signed authorization can only be consumed once.

The random nonce mechanism also enables true parallel processing. A user can generate many unique nonces and sign distinct payment authorizations for each of them. These can be submitted to the network by different facilitators, in any order and even within the same block, and the contract will process them correctly as long as each nonce is fresh and the time window is still valid. This is exactly what high-frequency, machine-driven payment systems need when many small transfers are being settled concurrently.

What's complementary for x402

For x402, ERC-3009 acts as an ideal lower-level messaging layer for value. It transforms the rigid, sequential, gas-heavy Ethereum transaction model into a flexible, parallel, gas-abstracted stream of signed payment instructions. x402 then wraps that stream in the familiar semantics of HTTP, where servers can ask for payment through 402 Payment Required responses and clients can respond with ERC-3009-style payment payloads in headers. Any web server can effectively become a crypto-native merchant without designing its own on-chain approval and transfer logic.

A remaining security concern for agents is how to avoid holding large balances directly in the keys they control. The likely answer is delegated spending, potentially standardized via ERC-7710. In this model, a user’s main vault (a cold wallet) signs a “session key” delegation that says, for example, “I authorize key X to sign ERC-3009 transfers on my behalf, up to 50 USDC, valid for 24 hours.” The AI agent only holds key X. It can roam the web paying for resources via x402, but if it is hacked, the attacker can only steal at most the remaining daily budget. x402 facilitators can verify these delegations on-chain, using Ethereum’s composability to keep delegated spending transparent and enforceable.

ERC-8004

What's the ERC-8004

ERC-8004, proposed in August 2025, is an Ethereum standard that defines a trust and discovery layer for autonomous AI agents. It is designed to transform Ethereum into a coordination layer where agents are first-class on-chain entities with identities, reputations and validation records, rather than just anonymous addresses calling contracts. The standard builds on Google’s A2A protocol by adding on-chain structures that mirror the agent descriptions and communication channels defined off-chain.

At its core, ERC-8004 introduces several registries. An Identity Registry mints agents as ERC-721 tokens with unique IDs (for example, eip155:chainId:registry:agentId) and links them to off-chain JSON metadata. That metadata can include A2A endpoints, MCP servers, wallet addresses and the trust models an agent relies on, whether they are reputation-based, crypto-economic or hardware-backed. A Reputation Registry lets clients submit scored feedback after tasks, typically on a 0–100 scale, authorized by the agent’s signature; it supports revocation, responses and off-chain attachments such as detailed reports or payment proofs. A Validation Registry records the results of independent validations, such as zk-based re-execution or stake-secured audits, so that future clients can see whether an agent’s claims have been checked by third parties.

Payment proofs from x402 are one of the signals that can enrich these registries. A client might reference a series of successful x402 payments and completed tasks in its feedback, or an auditor might confirm that the payments and outputs of a workflow match what an agent claims. The ERC-8004 proposal explicitly notes that payments are orthogonal to trust, but that proofs of payment can still improve the quality of feedback signals.

What's the progress, when approved

ERC-8004 is still in the review phase, but it has strong backing. It was co-authored by engineers from MetaMask, Coinbase, Google and the Ethereum Foundation, which suggests that wallet providers, exchanges, cloud teams and protocol researchers agree on the need for a shared agent identity and reputation layer. Even if the specification evolves before finalization, the core ideas are likely to shape how on-chain agent ecosystems are built.

What's complementary for x402

For x402, ERC-8004 fills the gap between payment and long-term trust. x402 can say that a payment happened and what resource it unlocked, but it does not say whether the agent delivered high-quality work after being paid or whether any disputes were resolved fairly. ERC-8004 provides a way to store and query that kind of information over time. This makes it possible to imagine autonomous AI economies in which agents manage funds, pay each other via x402 and still face reputational consequences for their actions.

With on-chain identities and scores, it becomes natural to build marketplaces where agents are discoverable by capability, price and reputation. Users and other agents can hire those with strong histories of correct behavior and financial discipline, and avoid those with poor ratings or unresolved disputes. In this sense, ERC-8004 and x402 are complementary: one handles who paid whom, and the other describes who can be trusted.

The Advantages and Potential Use Cases

Compared with traditional payment systems, x402 has a clear edge in speed and simplicity for machine-driven use cases. A typical interaction is just an HTTP round-trip plus a verification call: the server returns 402 with payment requirements, the client replies with a verified payment payload, and content can be delivered as soon as that payload is checked, often without waiting for final block confirmation. This fits neatly into existing web architectures and can be optimized or cached by facilitators.

Costs can also be competitive. On low-fee L2 networks, x402 can achieve Lightning-like economics by batching authorizations and settlements, while still using regular HTTP instead of specialized channels. And because all logic is expressed in cryptographic payloads rather than user interfaces, x402 is inherently compatible with machine payments: agents can reason about budgets, make dynamic decisions about whether a call is worth the cost and keep internal accounting without human intervention.

From a crypto perspective, x402 is also a meaningful step forward. It is chain-agnostic at the protocol level, even though most early implementations rely on ERC-20 stablecoins such as USDC on EVM chains and L2s where fees are low. With the right facilitators, the same HTTP pattern can be adapted to other networks such as Solana or specialized app-chains. The crucial requirement is that there exists a secure way to verify and settle signed transfer authorizations on the underlying network, whether through ERC-3009 or an equivalent mechanism.

There are several natural use cases that follow from these properties. For API monetization, a research platform can expose individual articles or data points behind x402 instead of selling only bundled subscriptions, allowing AI-driven tools to pay only for the specific content they need. A video streaming service can charge per second or per segment watched rather than relying exclusively on monthly plans, while a trading AI can pay a few cents per real-time quote instead of signing an expensive long-term contract. More broadly, consumers can obtain on-demand access to articles or videos without maintaining dozens of separate subscriptions, because agents can orchestrate and pay for each access silently in the background.

In the DePIN world, x402 can support pay-per-use access to storage, bandwidth or sensor data, aligning revenue more tightly with actual usage. For AI model providers, the protocol can underpin pay-per-inference or pay-per-token models, where agents select models dynamically based on cost and quality signals. Agents that manage long-running workflows can also use x402 to pay for short bursts of cloud compute and storage, all while respecting user-defined budgets enforced through ERC-3009-style authorizations and session keys.

Limitations and Future improvement possible

Even with these advantages, x402 faces several limitations and open questions. One is facilitator centralization risk. Many quickstart guides use the Coinbase-hosted facilitator as the default, which is convenient for developers but means that their ability to accept revenue can become tightly coupled to a single company’s API uptime and policies. If that facilitator goes offline, the “402 loop” cannot complete, and the API becomes inaccessible to paying clients even though the underlying chain is still running.

Another concern is the long-term economics of micro-payments. When gas fees on an L2 are around $0.0001, a $0.01 payment has roughly 1% overhead and the model works well. If congestion pushes gas to $0.05, the economics for sub-cent payments collapse. Facilitators themselves also bear infrastructure and gas costs and will eventually need to charge explicit fees. If a facilitator charges a $0.01 flat fee per payment, then pay-per-request for very low-value APIs quickly becomes unviable. This is why the x402 roadmap is already exploring deferred settlement and batched payments, where many small events are accumulated and settled once per day or per session instead of one by one.

Chargeback and Refund

x402 itself does not provide a chargeback mechanism or guarantees about service delivery. The server verifies your payment, usually via a facilitator, and then decides when to settle on-chain and when to deliver content or execute an action. Refunds, escrow and arbitration are explicitly out of scope for the base protocol; any protection for buyers or agents has to be layered on top through application-level contracts, service terms or independent dispute resolution.

ERC-3009 offers some building blocks that can be used to design safer flows. The validAfter field enables “post-dated checks,” where a user authorizes a payment that cannot be claimed until a future time. This is useful for subscription models or escrow-like setups where funds are committed but not immediately transferable. The validBefore field sets a hard expiry, so any authorization that is not used by the deadline simply becomes unusable. In addition, many implementations provide an optional cancelAuthorization function, which allows a user to cancel a signed but unexecuted authorization for a specific nonce. The contract marks that nonce as used without moving any tokens, and any later attempt to use it will fail.

Token Supported is limited

Most legacy ERC-20 tokens (including Tether/USDT, Shiba Inu and many DeFi governance tokens) do not support EIP-3009 or EIP-2612 (Permit). This limits their usability in gas-abstracted, relayer-driven models and means facilitators are likely to prefer a smaller set of well-behaved, standard-compliant tokens for x402 payments. In practice, stablecoins that adopt ERC-3009 or similar mechanisms are best positioned to become the primary currencies of agent-driven payments.

The Exact Amount to Variable Amount

x402 today is mostly focused on defining an exact amount or exact pricing per resource. This is straightforward when the cost is fixed, but less so when the resource is usage-based, such as an LLM API where the final cost depends on how many tokens are processed. In those cases, the server cannot always know the precise price before the call. To keep the protocol clean, x402 separates the transport mechanism from the notion of “payment schemes”: schemes describe how payments are formed, validated and settled on specific networks, while remaining independent from HTTP itself.

{
  "x402Version": 1,
  "error": "X-PAYMENT header is required",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base-sepolia",
      "maxAmountRequired": "10000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "resource": "https://api.example.com/premium-data",
      "description": "Access to premium market data",
      "mimeType": "application/json",
      "outputSchema": null,
      "maxTimeoutSeconds": 60,
      "extra": {
        "name": "USDC",
        "version": "2"
      }
    }
  ]
}

This design makes it easy to extend the protocol with new schemes over time. The roadmap already includes ideas such as upto (authorize spending up to a maximum), stream (support stream-based or usage-based payments) and permit2-style mechanisms. Each new scheme can be added without changing how clients and servers use 402 responses or X-PAYMENT headers; they only need to agree on how to interpret the scheme field and related parameters.

Coinbase's Ambition

Coinbase is one of the main drivers behind the x402 ecosystem, both on the tooling side and as a facilitator operator.

• CDP resources and toolkits
  • Provides wallet clients with helper packages, including a CDP server wallet and standalone EVM and SVM libraries that make it easier for developers to sign and verify x402 payment payloads.
  • Operates a hosted x402 facilitator that currently offers fee‑free USDC payments on Base by subsidizing gas costs. This lets sellers receive the full payment amount and gives developers a Web2‑like experience.
  • For now, supports USDC as the main payment asset but focuses on high throughput and fast settlement on the Base network.
• x402 Bazaar
  • Runs an explorer that lists all x402‑compatible services registered with the CDP facilitator, exposed through a simple /list endpoint.
  • Today, Bazaar is dominated by Questflow and other providers offering “Swarm” agents for marketing, research and general tasks, along with data, infrastructure, DeFi and social services.
  • This mix shows that AI agents and data‑intensive workloads are the earliest real users of x402.

Beyond the facilitator itself, Coinbase is also extending x402 into other environments.

• MiniKit
  • Powers miniapps that run inside Farcaster clients and can accept instant USDC payments.
  • Lets users pay inside the social app without opening separate wallet UIs or dealing with complex payment flows.
• Payment MCP
  • Combines an MCP server with a wallet app so that AI agents can autonomously pay for x402 services using USDC.
  • Handles wallet management through an embedded wallet with email/OTP onboarding, balance checks, address retrieval and a wallet UI that includes a Bazaar‑style explorer.
  • Gives agents a simple way to discover x402 services, make automatic payments and access paid APIs on behalf of users.

Circle's Strategy

Circle (the issuer of USDC) has proposed a specific architecture called Circle Gateway to enhance the deferred scheme.

• Problem: EIP-3009 is single-chain. An agent on Base cannot easily pay a merchant on Ethereum Mainnet without complex bridging.

• Solution: Circle Gateway acts as a cross-chain abstraction layer. Agents deposit funds into a Gateway smart contract. The Facilitator manages the balances off-chain. When a payment occurs, the Facilitator simply updates the internal ledger (Buyer -$,Seller+$).

• Batching: Periodically, the Gateway "net settles" onto the blockchain. This allows for millions of transactions per second (TPS) throughput, limited only by the Facilitator’s server capacity, not the blockchain’s block space.11

What's the Bet and Why Cloudflare is here?

The emergence of Large Language Models (LLMs) and Generative AI has fundamentally shattered this contract. AI agents, such as those powering ChatGPT, Claude, or Perplexity, consume content not to index it, but to ingest it—extracting the informational value to train models that often answer user queries directly. This "zero-click" paradigm effectively disintermediates the publisher. The publisher bears the cost of content creation and infrastructure, while the AI company captures the economic value.

Strategically, x402 is a bet that the SaaS and data economy will move away from heavy subscriptions toward a more merit-based, pay-per-use world. Today, an agent that needs one specific data point from a news API may have to buy a $50 per month subscription. In an x402 future, that agent can pay $0.01 (or less) for a single call. If the combination of gas and facilitator fees can be kept below the value of the data, this creates a hyper-competitive market where services compete on the quality and price of each individual request rather than long-term lock-in. x402 removes much of the friction around accounts, prepaid credits and invoicing that currently protects incumbents.

Cloudflare’s interest in x402 and “pay per crawl” fits neatly into this picture. As an edge network in front of a large share of web traffic, it is in a unique position to enforce 402-based gates on behalf of content owners. Rather than trying to block bots with CAPTCHAs or IP bans, Cloudflare proposes to change the economics of crawling so that large-scale scraping becomes unprofitable unless the scraper is willing to pay.

Most generic crawlers exist because the marginal cost of scraping is close to zero: if a bot wants 1,000,000 pages, the primary expenses are bandwidth and compute, and these systems are built to expect 200 OK or simple redirects. When confronted with 402 Payment Required, they usually treat it as an error and stop, unless they have been deliberately engineered to handle wallets, signing and facilitator flows. If each request costs even $0.001, grabbing 1,000,000 pages suddenly costs $1,000, which many low-value SEO farms and content mills cannot justify. In this way, x402 shifts the battlefield from technical defenses to pricing.

Deferred payment schemes and pay-per-crawl policies also give domain owners precise control over their monetization strategy. A publisher can set a flat per-request price across the site and then decide, for each crawler, whether to allow free access, charge at that price or block entirely. This provides a cleaner negotiation space between content owners and AI crawlers: access is no longer assumed for free, but it is always available if both sides agree on the price.

Myany publishers, content creators and website owners currently feel like they have a binary
choice — either leave the front door wide open for AI to consume everything they create, or
create their own walled garden.

Ecosystem Building

The x402 ecosystem is still young but expanding. The official x402.org site tracks projects that have integrated the standard, ranging from experimental demos to early production systems. This public catalog makes it easier for developers and agents to discover existing x402 services and see which verticals are adopting the protocol fastest.

Networks

Because x402 itself is chain-agnostic, any chain can be configured and added to the shared config as long as it exposes a compatible RPC endpoint and settlement environment.

Base was the default network for early x402 testing. Coinbase began subsidizing facilitator infrastructure on Base very early, which made it the easiest place to experiment. Historically, Base has processed ~62.7M x402-related transactions compared to Solana’s ~5.5M (about an 11× difference), and has settled around $25.11M in volume versus Solana’s $1.80M.

However, while Base dominates the historical record, Solana is currently processing the vast majority of new traffic. In the past 24 hours, Solana accounted for roughly 94.0% of activity, with Base at around 6.0%. This suggests that new facilitators and tooling in the Solana ecosystem are shifting where fresh x402 volume is being generated.

Facilitators

In the x402 architecture, Facilitators are the gatekeepers. The x402Scan project provides a package that offers a unified, drop-in configuration for all known x402 facilitators, so developers can more easily switch or connect to multiple providers.

The reason Solana can now have much more recent volume but fewer historical transactions than Base is that the leading facilitators in the current wave come from the Solana ecosystem, especially PAYAI and Dexter. Coinbase’s own facilitator has also added Solana support, further contributing to the shift.

Most facilitators initially offered free service to bootstrap adoption. Coinbase’s x402 Facilitator aggressively subsidized infrastructure at the start, but will introduce a minimal fee from Jan 1, 2026: a free tier for the first 1,000 settled payments per month, and $0.001 per settled payment after that.

PAYAI positions itself as a multi-chain facilitator with an aggressive focus on Solana and BNB Chain. It markets itself as a neutral layer for DePIN (Decentralized Physical Infrastructure) and autonomous agent networks. Today its free tier offers up to 100,000 settlements per month, with a rate limit of 4 requests per second, and the team has announced upcoming paid tiers at $1,500 and $2,800 per month with higher limits.

PAYAI is also building tooling around x402, such as Echo for testing mainnet x402 payments and Freelance AI for coordinating work between agents. Because of this infra-first focus, its seller count is still secondary to Coinbase’s, but its influence among developers is growing.

Dexter is a more recent “hype” project that operates both its own agent and a corresponding facilitator, so most of its volume currently comes from its own agent’s activity rather than third-party services.

Heurist, backed by Amber, runs a facilitator mainly used by x54.ai, acting as a security-focused layer for x402 payments with more emphasis on monitoring and risk controls than sheer volume.

On BNB Chain, the ecosystem is somewhat isolated from Base and Solana. Its main facilitator is built by AEON, and statistics and explorer tooling are maintained separately from x402Scan’s primary dashboards.

Servers

Currently, most servers provide Data & Intelligence services. Platforms like Token Metrics were among the first major data providers to gate their analytics APIs with x402, letting agents pay per call for crypto market data instead of committing to full subscriptions. Neynar exposes Farcaster social graph data; AI agents can pay to read and write casts or analyze social trends without managing long-lived API keys. Pinata offers decentralized storage via IPFS, where agents autonomously pay to upload and retrieve files, enabling “headless” data persistence for workflows.

A second group of servers is emerging around Compute & Inference. Projects like AiMo Network and Heurist offer “pay-per-inference” models so that, instead of renting GPUs by the month, agents pay only for the compute milliseconds actually used to run an LLM query. On the web side, search and scraping services such as Firecrawl are adopting x402 to let agents pay on demand for up-to-date crawling and search results, without pre-purchasing large data bundles.

Reference

1. A2A Protocol
2. ERC-3009: Transfer With Authorization
3. GitHub - coinbase/x402: A payments protocol for the internet. Built on HTTP.
4. Introducing pay per crawl: Enabling content owners to charge AI crawlers for access
5. Launching the x402 Foundation with Coinbase, and support for x402 transactions
6. Welcome to x402 - Coinbase Developer Documentation
7. Welcome to x402 | x402
8. x402/specs/x402-specification.md at main · coinbase/x402 · GitHub
9. x402-whitepaper.pdf
10. x402: Coinbase and the Beginning of the AI Agent Era | CoinGecko