When Machines Move Money

What do payment rails in an agentic economy look like?

A special thanks to Lucas and Kevin for their feedback and review.

In 1849, tens of thousands of men went searching for gold in California. Some made out to be kings. Most made out poor. But the greatest success fell upon the merchants building picks and shovels: the foundational tools that would remain important so long as there was gold in the ground. Today’s gold rush is AI. Payments are becoming a foundational part of AI agent workflows, and inevitably, the rails facilitating those payments become today’s picks and shovels. In this paper, we dive deep into the x402 protocol; one particular emerging open agent-native payment rail, including what it is, how it works, where adoption stands today, and what open questions face x402 when machines move money.

A Seismic Shift Is Underway

History is defined by seismic shifts. Sudden, profound transformations that change the very foundation of life itself. The physical geography we inhabit today was formed some 175 million years ago when the Earth’s tectonic plates shifted and broke apart. Tectonic plates are still shifting today, albeit much slower, but the biggest seismic shifts in the modern world have materialized through human innovation.

Foundational inventions, be it the Sumerian wheel, the Gutenberg press, the steam engine yield a similar reinforcing flywheel: humans build machines, these machines yield economic surplus, which leads to more money for building more machines (and better ones at that) which further compounds the output. As technology improves, the cost of experimentation falls while the rate of iteration increases. We’ve seen this dynamic accelerate particularly within the last few decades with computers and the applications and services built around them.

Today this transformative dynamic is materializing through software, particularly artificial intelligence.

AI has been around for a long time. The first paper on neural networks was published as far back as 1943. Expert systems in the 80s and statistical machine learning in the 90s quietly embedded AI into production workflows, from credit scoring to ad targeting.

Spam filters, recommendation engines, and fraud detection have been running on machine learning models since the early 2000s. What changed is the interface. Generative AI lets humans interact with these systems through free-form natural language, and that shift in accessibility is what brought AI into mainstream consumer markets.

OpenAI launched ChatGPT as a simple and intuitive way to interact with its underlying GPT models, which reached 1 million users in 5 days and 100 million in 2 months, the fastest consumer internet adoption in history. Shortly after competing generative AI applications (e.g. Gemini, Claude, Grok) started rolling out, and the ensuing competition drove major AI labs to quickly improve models and ship new product features. On a darker note, fears of job displacement have mounted as corporate executives continue to iterate reducing headcount and increasing investments in AI (though it’s worth noting over half of US workers today are working jobs which didn’t exist in 1940).

No one can state with certainty how AI will ultimately reshape society. But as of late 2025, roughly one in six people worldwide have used generative AI, a technology that barely existed three years ago. While early, a seismic shift is well underway.

But there’s only so much to be done by simply talking to AI. Read access, e.g. letting LLMs look things up, condense large bodies of text, write code, analyze data, is evidently useful but only goes so far. But pairing that with write access, in other words letting AI actually do things across external environments, has unlocked an entirely different set of capabilities.

In 2025, OpenAI rolled out Operator and Codex, Anthropic shipped Claude Code, Perplexity launched Comet, Google embedded Gemini-powered agents across Workspace applications, Microsoft pushed Copilot deeper into Office and Windows. Perplexity, Cursor, Sierra, and Cognition each raised hundreds of millions in new funding and reached new all fun highs in revenue. It’s clear that agents will define the next chapter in how humans interact with AI.

But an overlooked reality is that autonomous agents have been driving economic activity online for years. The digital ads marketplace is one massive agentic economy operating beneath the surface of nearly every ad-supported webpage (which includes most large consumer sites and platforms today).

Whenever someone loads a site, the empty ad space is put up for sale in a mini-auction, and agents operating on behalf of advertisers (this could be any merchant selling goods online) determine how much that ad space is worth to them and submit bids. The highest bid wins and the winning ad is rendered in the slot, within hundreds of milliseconds. By the time the site loads, the ad is already displayed. To put this scale into perspective, consider that programmatic digital ad spend amounts to hundreds of billions annually, which accounts for over 90% of display ad budgets today.

Crawlers are another example. These autonomous agents roam the web, follow URLs, fetch webpages, and feed that content into large-scale indexing and training pipelines. Similarly, scrapers extract raw data from webpages and are actively used in a variety of fields today. On a darker note, “bad bots”, programs set up to exploit business logic online, accounted for as much as 37% of internet traffic in 2025. Collectively, over half of all web traffic is already run by autonomous software agents.

Yet evidently, few people know about these agents, and even fewer actually use them. However useful these agents may be at their particular function, e.g. bidding for ad space, their utility is limited by their purpose-built nature. A crawler crawls, a scraper scrapes, a bidder bids, and nothing more.

When these different capabilities are stacked together into one single program, controlled from one single interface, the nature of the application changes entirely. This is where the general-purpose AI agents most people know today come in. Their most foundational change is their ability to perform many different tasks and operate across multiple apps and environments within one interface. These agents were designed to accelerate human output and productivity: they do more things, at a much greater rate, and as their adoption grows, they generate an ever larger share of web traffic.

So what is exactly an agent? In simple terms, a goal-oriented software program which receives a goal, identifies the steps needed to achieve that goal, and takes action within certain environments using tools available at its disposal to achieve that goal.

A user types a prompt, which is then delivered to an agent’s runtime environment. From there, the agent provides a prompt to its model, which makes decisions and functions as the brains of the operation. The agent uses any available tools it may have access to (i.e. web browsers, APIs, databases, calendars etc) to carry out these tasks, and then carries out a cycle of absorbing information from its actions, reasoning about the information, and using this information to determine its next action or decision until the defined stopping point (e.g. the goal specified in the user prompt) has been reached.

Gartner predicts roughly 40% of enterprise applications will have task‑specific AI agents embedded by the end of 2026. McKinsey estimates AI agents account for $3–5 trillion of global consumer commerce by 2030. Goldman Sachs projects that by 2030, agents could erode meaningful TAM for SaaS by becoming a primary interface for knowledge work even as they expand the overall software market.

Of course, these are forecasts and not facts, and some predictions about the immediate impact of agents have already proven to be too ambitious. Nonetheless, it is difficult (and naive) to ignore the size of the bet being made here: if AI agents are to capture even a fraction of their predicted growth, they start to become consumers. And consumers need, first and foremost, a way to pay for the goods and services they wish to purchase.

Machines Need To Move Money

And so the role of money comes up. Money is a coordination tool: a shared medium of exchange and unit of account that enables humans to coordinate with strangers and settle transactions efficiently. It enables human societies to cooperate at scale; to compound individual effort into part of a greater productive whole.

As AI agents take on more economic responsibilities, they too require access to this shared coordination layer. But agents are a structurally different kind of consumer, with different behavioral patterns and optimization criteria. They don’t face the same cognitive or computational constraints as humans. Their very purpose is to multiply human output by magnitudes: more work, in far less time, though often through more frequent and granular consumption of resources along the way. Agents also aren’t susceptible to the emotional appeals that advertising deploys on human consumers. They are, by design, economically rational actors.

In this context, money plays a familiar but functionally extended role. As a medium of exchange it minimizes transaction friction, enabling seamless value transfer between agents. As a unit of account it provides the standardized measure agents need to conduct precise cost-benefit analyses, evaluating whether the compute cost of a task justifies its expected reward. And as a store of value it allows agents to preserve purchasing power and allocate capital efficiently across time and tasks.

To make use of these functions, however, we must distinguish between the asset itself and the infrastructure that moves it. Money is a coordination tool but payments are its mechanism of action. Stripped to its core, a payment is a way to settle an obligation: the process of reconciling a ledger to prove that value has actually changed hands. For an agent, this is the functional execution of a contract. It is the step that converts a decision into a realized outcome, unblocking access to a resource. Without this settlement capability, an agent is effectively stuck in a read-only state. Agents need a designated way to pay for goods and services online.

But Machines Already Move Money?

To state the obvious, this is already possible. AI agents already have access to infrastructure which trillions of dollars already move online every year through. These systems are built around what we can call checkout-specific flows. A (human) user confirms their purchase intent, a payment token is created for that transaction, and the merchant processes the payment through their respective PSP infrastructure.

Take OpenAI and Stripe’s Agentic Commerce Protocol (ACP) for example. ACP is an open‑source API specification that enables AI agents to complete purchases on behalf of users by standardizing how merchants expose their catalogs, how agents represent offers and carts, and how payment details are delegated back to the merchant’s PSP once the user confirms intent. The clearest implementation of ACP today is Instant Checkout in ChatGPT, powered by Stripe’s Shared Payments infrastructure. Through intuitive natural language language prompts, users can take care of shopping needs (e.g. buy running shoes, order takeout, book reservations) from the familiar ChatGPT interface. On the backend, ChatGPT delivers a scoped payment token to the merchant’s PSP, and the merchant charges for the payment.

Beyond ACP, agent payments are growing as the agentic commerce stack begins to form. Claude Code and Codex run workflows using prepaid balances on user accounts. OpenClaw takes this one step further and enables virtual cards with spending limits to be issued to an agent. Google’s UCP and AP2 use payment tokens linked to user credit cards and email addresses.

This system works. It prompts no immediate reinvention. For human-agent checkout flows, this model performs exactly as designed.

Machines Do Move Money, Just Not Autonomously

However, the point that really matters here is that this is not the the final form for agentic payments. This model becomes strained when applied to continuous agentic workflows at scale.

This emerging ecosystem is what has been characterized as a “virtual agent economy”: a set of linked digital markets where AI agents transact with one another to generate economic value independently of human labor. Critically, in such an economy, agents transact and coordinate at scales and speeds beyond direct human oversight. And this is where key economic and technical constraints begin to emerge within today’s commerce stack.

Protocols like ACP use legacy payment mechanisms: credit cards, digital wallets, BNPL services. Consumers and merchants using these protocols still absorb their economics: 2.9% + $0.30 per transaction, multi-day settlement, 120-day chargeback windows. Annoying but manageable for humans.

Agents, however, transact at a far greater scale. Agentic systems routinely decompose complex problems into granular distributed tasks worth fractions of a cent. Applied across thousands of steps, the cost structure collapses; consider that a $0.30 fixed fee on a microtask worth, say $0.02, is already a 1,500% markup.

Ultimately, this stems from a deeper architectural issue. As Felipe Montealegre articulates in Internet Finance, modern financial systems are just collections of private servers. Moving value requires permissioned administrators to reconcile entries across those servers, a process reflected in settlement delays and layered fees. When an AI agent initiates a purchase via a protocol like ACP, a synchronous chain follows: the request routes to Stripe, which routes to issuing banks. Stripe has its fee layer, Visa and Mastercard have theirs, banks have theirs. Each operates independently.

The efficiency of this reconciliation mechanism sets the speed limit for the entire economy. A 2024 BIS report found that a one-percentage-point increase in digital payment adoption corresponds to a 0.10 percentage-point rise in GDP per capita growth over two years. If removing friction for humans produces that, the implications for agents operating orders of magnitude faster are larger still.

There is also a less visible cost: permission itself. Legacy rails were designed around discrete human-to-human purchases with meaningful transaction sizes (e.g. at least a few dollars’ worth). The compliance architecture built on top, KYC, AML checks, chargeback systems, correspondent banking, reflects rational responses to legal liability at that scale. A $0.004 API call carries different risk than a $50,000 wire transfer, but today’s rails treat them with similar overhead.

Nick Szabo identified a related problem in 1999: mental transaction costs, that is, the cognitive burden of deciding whether a small purchase is worth making. Early micropayment businesses failed not because the technology couldn’t handle small payments, but because humans had to consciously approve each one. Attention, at scale, costs more than money.

Agentic systems appear to solve this. Claude Code draws from a pre-funded account and proceeds without interrupting the user. But this is a proxy with a budget, not an autonomous economic actor. The agent’s economic range is fixed at setup by its human operator. It cannot negotiate access to new resources, acquire capabilities outside what was pre-provisioned, or carry any economic identity beyond the session. Szabo’s problem reemerges as a ceiling on what the agent can do.

Another key constraint agents encounter with legacy payment rails is identity. In existing human:agent checkout flows, agents essentially borrow their user’s identity to transact. The entire stack assumes the payer is a person with a legal identity, bank relationship, and personal liability, which agents have none of (at least not yet). When Claude Code makes a payment it does so via its user’s Stripe credentials, the merchant’s fraud model, the card network’s chargeback rules, and the bank’s settlement framework. An agent economy where every transaction is anchored around legal human identity is not much of an agent economy after all.

This also creates unresolved legal questions. How does an agent run an AML check? File a suspicious activity report? Screen for sanctions violations? There may soon be answers to these questions, as this issue is now gaining recognition at the federal level. NIST’s National Cybersecurity Center of Excellence just published a concept paper on AI agent identity and authorization, identifying it as an unsolved infrastructure problem requiring new open-source future standards.

Human-agent checkout flows are genuinely useful. But in their next evolution – an economy of AI agents – cost, autonomy, and identity are three constraints existing systems cannot reconcile. Multi-day settlement and the absence of 24/7 global rails add further friction, though these are secondary to the structural issues above. Solving these constraints starts with understanding how AI agents actually work. Agents are software, they run on the web, therefore perhaps the most natural place to look for a payments layer is within the web itself.

POST /merchant/transfers/payment HTTP/1.1
Host: payments.example.com
Content-Type: application/json
Content-Length: 402

{
  "payment_transfer": {
    "reference": "PAYMENT123456",
    "amount": "1337",
    "currency": "EUR",
    "sender_account_uri": "pan:5299920000000149;exp=2020-08;cvc=123",
    "sender": {
      "first_name": "Amelia",
      "middle_name": "Rosenburg",
      "email": "test123@sender.example.com"
    },
    "recipient": {
      "first_name": "Tyrone",
      "middle_name": "Johnston",
      "email": "test123@example.com",
      "merchant_id": "123"
    },
    "authentication_value": "ucaf:jJJLtQa+Iws8AREAEbjsA1MAAAA",
  }
}

An example of calling a payment API using a POST request to initiate a transaction via HTTP-402.

HTTP 402 was reserved decades ago but never implemented. It anticipated a world where payment could be handled at the protocol level, the same way authentication is handled today. It was simply missing two things needed to make it real: a defined standard, and a form of money that could move at web speed.

We Already Have Web-Native Payment Rails

Just as HTTP moves information freely and permissionlessly across the internet, global value transfer on public blockchain rails is already happening at a meaningful scale. Tens of trillions have already been moved in stablecoins. Circulating stablecoin supply sits at over $308B today.

Mckinsey and Artemis Analytics tracked stablecoin payment volume at $390 billion in 2025, more than double from the year prior, with volume concentrated in B2B and P2P payments, card-linked spending, and B2C payouts. Though most onchain stablecoin activity has historically been trading-driven, chain-specific data shows payment demand emerging as a distinct and growing share.

A stablecoin in its simplest terms is software programmed to maintain the value of a stable unit of exchange, most commonly the US Dollar. A piece of software known as a smart contract is called, and in turn a stablecoin, is either minted or redeemed. Several key properties that make these bits of software uniquely suited for web-native payments, particularly in agentic commerce.

The economic advantage is the most obvious. Stablecoin transactions are orders of magnitude cheaper than legacy payment rails because there is no intermediary taking a cut. A stablecoin transaction is a redistribution of balances on a shared digital ledger. The primary resource consumed is the computing power required to update that balance, paid as a gas fee. Gas fees across most major chains now sit in the sub-cent range. Against the transaction fees associated with credit cards, the cost differential is stark.

A more distinctive advantage is programmability. As Hadfield and Koh point out, agents need “programmable money” to achieve the kind of autonomous cooperation required for complex economic activity at scale. Stablecoins are issued and redeemed via smart contracts in which payment conditions can be encoded directly: conditional releases, payment limits, recurring transfers, etc. Agents can control wallets through cryptographic keys and sign transactions directly, which removes the need for human credentials at the payment layer.

Haseeb Qureshi makes the sharper point: crypto is better suited for agents than it is for humans. An agent can verify transaction details, audit smart contract code, and confirm settlement in seconds. It does not need to trust a counterparty’s legal representation or a jurisdiction’s enforcement mechanism. Code on the other hand is deterministic: given the same inputs, it always produces the same outputs. A smart contract that says “release payment when condition X is met” will release payment every single time condition X is met, enforcement is built into execution.

An agent entering an economic agreement via smart contract knows exactly what will happen under every possible condition before it signs. It can read the code, verify the logic, and confirm the outcome in milliseconds. A stablecoin is just code. A wallet is just code. An agent can hold funds, transact, and enter economic agreements as naturally as it sends an HTTP request.

The Missing Piece

HTTP 402 defines how a server signals that a resource requires payment. Stablecoins provide money that can move at web speed. Together, they start to look less like a checkout flow and more like an HTTP handshake.

Consider a vending machine. It provides one specific item, a soda or a candy bar, but only in exchange for the exact payment amount. The operator does not need to produce anything it sells. It simply provides neutral infrastructure that lets willing buyers access a resource.

This is the model for web-native agentic payments. An agent makes a request, the server responds with a payment requirement, the agent provides payment, and the resource is unlocked. HTTP 402 provides the status code. Stablecoins provide the settlement layer. The missing piece is what ties them together: a web-native vending machine.

x402: A Web-Native Payment Rail

In May 2025, Erik Reppel, head of engineering at the Coinbase Developer Platform, published a whitepaper co-authored with colleagues Kevin Leffew, Dan Kim, and Nemil Dalal that gave HTTP 402 its first real implementation in 29 years: the x402 protocol.

The idea, which this paper takes as its central premise, was simple: the internet has always needed a native way to send and receive payments, and stablecoins now make that possible. Coinbase had been exploring internet payment standards since 2015, but even then the idea was ahead of its time. By May 2025, the conditions had finally aligned. Onchain fees cost fractions of a penny on chains like Solana and Base. Stablecoin supply had grown rapidly and was approaching $300 billion. Agentic commerce had materialized into something concrete enough to build for.

What is x402?

x402 is an open-source payments protocol that standardizes how web clients and servers exchange value using HTTP 402 and stablecoins. It is, in the most literal sense, the missing web-native vending machine: a buyer makes a request, a seller names a price, and payment clears directly through HTTP without a pre-established relationship between the parties.

At its core, x402 separates three things: transport, which is how data moves between parties; payment logic, or the scheme by which value moves; and the settlement network where that value lands onchain. This separation is what makes x402 extensible. HTTP is the primary transport and the 402 status code is the native signal, but the same payment logic can run over MCP or A2A without touching the underlying standard. In practice, x402 plugs into existing web infrastructure as lightweight middleware. Server-side implementation takes a single function call. A client can pay any supported endpoint without a prior relationship with the resource provider.

How Does x402 Work?

In summary, the x402 payment flow works like this:

1. A client requests a paid resource from a server

2. The server returns HTTP-402 with machine-readable payment instructions.

3. The client constructs a signed payment payload and resubmits the request.

4. The payload is verified, and the server fulfills the original request. Note, the payment is first submitted and settled onchain, and the settlement proof passed along via the Facilitator to confirm payment.

5. Once confirmed, the server returns a 200 OK response alongside the requested resource and transaction proof to the client.

There are certain steps involved in which the details vary by specific chain architecture, as we will expand on below. But importantly, each step maps to a specific component split across two layers: an offchain layer where communication occurs, and an onchain layer where payment settles.

The Communication Layer

x402 is transport-native by design. While HTTP is the primary implementation, the protocol complements existing data transportation without mandating additional requests outside a typical client-server flow. Any request-response based system can implement x402 payment flows, which means x402 runs across HTTP for web APIs and REST services, MCP for AI agent tools and resources, and A2A for direct agent-to-agent payments.

The primary offchain components are the client and the server, which apply across all supported transport layers.

The client represents the buyer: the entity requesting access to a paid web resource. This can be a human developer making calls through an HTTP client library, or an AI agent operating as a web client. A client sends the initial request, constructs a valid payment payload, and retries the request with a Payment-Signature header containing the signed payload.

The server represents the seller, or resource provider. Usually an API or content endpoint, but ultimately any digital resource accessible via a supported network. The server responds to client requests with payment requirements, verifies incoming payment payloads, and returns the resource once the transaction confirms.

For agents, no separate integration is required per transport layer. Payments are handled automatically across HTTP APIs, MCP tools, and A2A interactions.

The Onchain Layer

The onchain layer of the x402 protocol is where payment occurs. This consists of a wallet to hold funds and authorize payments, a Facilitator service to verify payloads and submit payments onchain, and the stablecoin or token contract which actually moves between parties.

To execute payments with x402, a client needs a funded cryptographic wallet. A wallet is a public-private key pair. The public key is a pseudonymous identifier that functions as the client’s onchain address, analogous to a routing number. The private key authorizes the client to sign and execute transactions, analogous to a password. When an agent needs to access a paid resource, it constructs a payment payload by signing a transaction authorization with that private key. The signed payload includes the public key so the server can verify the sender and confirm the transaction onchain independently.

To settle payments onchain, a server uses a Facilitator. A Facilitator is a transaction relay and gas abstraction service: it receives a signed payment payload, validates it against the token contract’s authorization parameters, and broadcasts the transfer onchain on the server’s behalf, covering gas costs in the process. When a server receives a signed payment payload, it can either handle onchain settlement directly or POST the payload to the Facilitator’s /settle endpoint. The Facilitator validates the cryptographic signature against the token contract’s authorization parameters, calls transferWithAuthorization the token contract, covers gas from its own balance, and broadcasts the transaction to the network.

Critically, the Facilitator is not a custodian. It executes a transfer that was already cryptographically authorized by the client’s signature. It cannot redirect funds or modify payment terms; it can only execute or reject what the client already signed. Coinbase runs a Facilitator on Base and Solana for USDC payments, but the role is open. Any server can run its own verification logic locally if it prefers not to outsource.

x402: EVM vs Solana

The HTTP handshake in the x402 payment flow is identical across chains. What differs is the onchain settlement mechanism, which is downstream of the architectural differences between EVM-compatible chains and Solana.

On EVM-compatible chains, x402 uses EIP-3009 as its core token transfer primitive. EIP-3009, authored by Coinbase engineers Peter Jihoon Kim, Kevin Britz, and David Knott in 2020, quietly facilitates tens of billions in monthly USDC transfer volume.

The key mechanic is the separation of authorization from execution. EIP-3009 provides a single-use cryptographic signature created offchain, authorizing a specific transfer of a specific amount to a specific address within a defined validity window. That signature becomes the payment payload in x402.

There are two main functions involved here: transferWithAuthorization and receiveWithAuthorization. The client signs a structured EIP-712 message containing the payment details and a random 32-byte nonce. Using random nonces here lets multiple payment authorizations be created in parallel without ordering constraints.

When the server receives the Payment-Signature header, validation is a deterministic checklist: verify the recipient address matches, the payment amount meets the requirement, the token contract is an accepted asset, the validBefore timestamp hasn’t expired, and the EIP-712 signature is cryptographically valid. Because authorization is separated from execution, the server validates the signed payload before submitting anything onchain. An invalid signature, mismatched amount, or expired timestamp gets rejected at zero cost to either party.

If all checks pass, the server or its Facilitator calls transferWithAuthorization on the token contract. The Facilitator covers gas from its own balance, which is why the client only needs to hold the payment asset rather than the chain’s native gas token. Once confirmed, the server returns the requested resource alongside a transaction hash and block number the client can verify independently.

Solana

On Solana, x402 uses a different settlement mechanism that reflects how transactions are structured on the chain. Rather than an offchain EIP-712 signature authorizing a future transfer, the client constructs and partially signs a full SPL token transfer transaction using Ed25519 signing, then encodes it as a base64 payload in the Payment-Signature header. The transaction is partially signed because the client signs the transfer instruction while designating the Facilitator as fee payer, a role that requires the Facilitator’s own signature before the transaction can be broadcast.

Before building the transaction, the client queries the Facilitator’s /supported endpoint to get its fee payer address and confirm support for the requested network. The Facilitator then receives the partially signed transaction, validates it, adds its own signature as fee payer, and broadcasts it to the network. The client pays in USDC without needing to hold SOL for gas.

Both the EVM and Solana flows achieve atomic settlement through different primitives native to each chain. The EVM flow uses an offchain signature authorizing a future transfer the Facilitator executes; the Solana flow uses a partially built transaction the Facilitator completes and broadcasts.

Beyond the mechanics, each chain carries practical advantages. EIP-3009 shifts gas costs from clients to servers, who accept this because payment amounts structurally exceed gas fees. For agents making repeated calls to the same endpoint, servers can batch multiple authorizations into a single transaction, spreading the fixed base gas cost across payments. The authorization-execution split also enables payments in low-connectivity environments: a client can construct and sign an EIP-712 message locally without network access and transmit it when connectivity resumes. Solana’s architecture is optimized for throughput, making it better suited for higher-frequency payment patterns.

That said, x402 is chain-agnostic. The protocol uses CAIP-2 network identifiers so the same handshake handles routing across Base, Solana, Polygon, Scroll, and Avalanche. The server specifies which networks and assets it accepts in the 402 response; the client picks from what its wallet supports. As the Facilitator landscape matures and new chains meet x402’s acceptance criteria, the protocol extends without changes to the underlying standard.

What Does x402 Uniquely Solve?

It’s worth zooming out to revisit what makes x402 valuable.

The ability to transact online is becoming a foundational requirement for AI agents. As software programs that communicate via HTTP and consume web resources continuously, paying for things is central to how they operate. The problem is that the infrastructure underpinning something so fundamental to their function wasn’t built for them. In human-agent checkout flows, agents transact through human infrastructure, borrowing credentials and depending on intermediaries designed for a different kind of consumer. x402 runs on the same web-native rails agents already operate on.

The differences are structural. Cost is the most obvious one; gas fees for stablecoin transactions on the chains x402 currently supports (e.g. Base, Solana) cost fractions of a cent, and represent the only transaction costs within the traditional x402 payment flow. This matches the granular economics with which AI agents operate at (e.g. per-call, per-task etc); which quickly breaks down with a 2.9% + $0.30 fee charged per transaction.

Settlement goes deeper. Because payment conditions are enforced at execution, a transaction cannot finalize unless predefined terms are met. The rails enforce this through code, so the agent doesn’t need to know or trust the counterparty. This is the difference between post-hoc verification and preemptive execution, and it’s what makes delegation to high-stakes workflows safe. An operator defines spending constraints once: daily caps, per-transaction limits, whitelisted addresses. The agent executes within them without requiring approval on each call.

Beyond cost and settlement, there’s identity. Every transaction an agent makes is signed by the same cryptographic wallet address, a consistent and verifiable identifier it owns and controls. Rather than borrowing a human’s credentials for each new service, the wallet travels with the agent, standardizing how it shows up across every interaction.

But in practice, why do these advantages even matter?

Granular pricing structures, e.g. Pay-per-article, pay-per-video, pay-per-stream, were always the intuitive business models for digital content. The early web was built with that vision in mind, but it never materialized because transaction costs made small payments uneconomical and the cognitive overhead of approving each one made them exhausting. x402 absorbs both problems; pricing can actually match how content is actually consumed rather than bundled into subscriptions that most users only partially use.

For AI agents, granularity is a necessity to how they consume resources in discrete, measurable units (inference per prompt, market data per query, compute per job, API calls per task.) It’s difficult to map these naturally onto subscription pricing, which exists largely because per-unit micropayments weren’t viable. At fractions of a cent per transaction, they are.

x402 also reshapes the software market for agents. Historically, accessing a capability meant either paying a subscription or building it yourself. As inference costs fall, building is increasingly viable. x402 introduces a third option: an agent mid-workflow can access a capability instantly, paying only for what it uses, rather than spinning up inference to replicate it. That’s a real-time cost decision agents are uniquely positioned to make, and it implies a software market structured around access rather than ownership.

The most expansive implication is what happens to how products get structured. Goods and services are bundled largely because transaction costs make granular pricing impractical. A news article packages interviews, photos, and context together because selling each piece individually wasn’t worth the overhead. An AI agent, meanwhile, can track what a user has already read, coordinate with a content provider to surface only what’s new or relevant, and pay for exactly that. The same logic extends to any digital product with separable components. As micropayments make individual pieces of content economically viable, agent-to-agent commerce could give rise to a retrieval ecosystem where content creators get compensated per use and users get something closer to a personalized product than a standardized one.

This extends to how AI agents actually move through a workflow. When an agent hits a paywall mid-task, the server returns a 402 with machine-readable payment instructions. The agent constructs a signed payment payload, settles onchain, and continues. The workflow never stops for manual authorization. The only prerequisite is a funded wallet, which the operator provisions once upfront.

This becomes particularly relevant in multi-agent systems or swarms. Modern agentic workloads increasingly decompose across specialized agents that coordinate through handoffs: one agent calls another, which calls a service, which calls another agent. When payments need to flow through that same graph, a central billing relationship can become an operational bottleneck. x402’s stateless design means each hop settles independently, such that the payment layer scales with the workflow rather than sitting above it.

All of this is straightforward to integrate. x402 ships with a full reference implementation: core protocol libraries, server-side middleware for Express.js and Next.js, and client libraries for browser and Node.js environments. Server-side integration is a single function call. An agent can hit a paid endpoint, receive a 402, construct a signed payload, and settle onchain without any custom payment logic written on top.

With that in mind, let’s take a look at the current state of x402 adoption today.

The Current State of x402

x402 launched on May 6, 2025, initially supporting USDC on Base. In the nine months since, the protocol has processed 164m total transactions worth $46.4m in volume, across 447k unique buyers and 89k sellers in total.

That growth was not linear; at its peak on November 17, x402 drove 19% of Base’s 17 million daily transactions, a striking demonstration of how quickly the protocol could saturate a single chain’s activity. Since then, amid a broader pullback in onchain and crypto market activity, transaction volume has declined meaningfully, although there has been a meaningful resurgence in transactions and volume count in March once again.

What the data tells us, and what it doesn’t, is worth examining closer.

X402 is a chain-agnostic framework that’s live on a small but growing number of chains today. Base accounts for the majority of x402 activity to date — 125m transactions and $39m in volume — a feat driven in no small part by its early-mover advantage, as well as being home to Coinbase’s native facilitator infrastructure, and the deepest facilitator ecosystem on the protocol with 27 active facilitators. Solana came online in July 2025 and has processed 38m transactions and just under $7m in volume to date. By early February 2026, Solana was gaining rapid share of transaction count (and volume?), accounting for as much as 97% of daily transaction share on February 2nd. Nonetheless, Base still hosts a much larger share of buyers (423k buyers vs Solana’s 23k) and sellers (68k vs Solana’s 20k), suggesting Base still dominates on the demand side even as Solana captures a growing share of transaction count.

Beyond Base and Solana, x402 is actively expanding support to new chains, now live on Polygon, Avalanche, Sei, Optimism, and Arbitrum. These chains are live but collectively still account for a small fraction of activity relative to Base and Solana. It is too early to tell where the most x402 activity will settle, but the answer is far more likely to depend on a specific application on a specific chain rather than the infrastructure of the chain itself.

The facilitator landscape meanwhile, has grown alongside the protocol. Coinbase remains dominant by transactions (78m) and volume ($27.3m), and it’s worth noting their Facilitator offers a zero-fee structure and has a first-mover position. But the ecosystem has started to diversify; PayAI, Dexter, Daydreams, and Virtuals Protocol are among the more active third-party facilitators, which collectively account for the majority of facilitator transactions and volume in more recent months.

But not all agent activity is as it seems. For instance, despite the recent craze around Moltbook, a viral social network exclusively for AI agents which drew lots of coverage about millions of agents posting and coordinating their own lives, much of this early activity was revealed to be agents pattern-matching through trained social media behaviors, with humans involved in many cases.

The same scrutiny applies to x402. Artemis Analytics distinguishes between real and gamed transactions in its x402 dashboard, gamed transactions being indicative of wash trading. One explanation for the incentive to game transactions with x402 is launching a memecoin, driving transaction volume to climb the x402scan leaderboard, and converting that visibility into token buyers.

Though x402 went live in May 2025, the first major surge in activity only took place a few months later around early Q4 ‘25. Much of this activity was memecoin-related however; throughout much of November and early December, gamed transactions accounted for a larger share of total transactions than real transactions.

However, as total x402 transactions have declined in the past few months, real transactions are starting to account for a larger share of total transaction count. February saw 5 straight days in which real transactions accounted for 100% of total count.

Gamed transactions do help stress-test infrastructure, validate settlement mechanics, and prove throughput at scale. But financial incentives and the downstream activity of those incentives dilute the assessment of the quality of x402’s adoption. Whether they are memecoin-related, airdrop farming-related, or otherwise, the bottom line is that gamed transactions represent behavior optimized for financial incentive rather than organic x402 utility.

But numbers, as useful as they are, only tell so much. For a more holistic overview of x402 adoption to date, it’s worth looking at the x402 ecosystem.

The x402 Ecosystem

The x402 ecosystem is made up of the various participants in the x402 payment flow. Clients represent the buyers making requests for web resources to paid endpoints (e.g. AI agents), Servers are the services and paid endpoints (APIs, data providers, content platforms, and any digital resource exposing a paid route via x402), Facilitators are various third-party services handling payment verification and onchain settlement for Servers, and supporting infrastructure and tooling covers any SDKs, analytics, wallets, and developer tooling that make building on x402 practical.

Much of the x402 ecosystem is still early, but the range of service partner integrations and experiments being built on top of the protocol offers a glimpse into its surrounding excitement and interest across different industries and fields.

x402 Within The Broader Agentic Commerce Stack

It’s important to zoom out and recognize that agentic commerce is a wide-ranging multi-layered stack that intersects across several industries. Discovery, consent, checkout, and agent coordination are each being handled by different protocols involving a number of the biggest players across the tech and finance sectors.

On the commerce side: we touched on ACP earlier, which defines how AI agents handle the shopping flow on behalf of human users from product discovery through checkout. Critically, ACP is designed to be processor-agnostic, meaning merchants can plug in whatever payment provider they already use. Google’s UCP (Universal Commerce Protocol) serves a similar purpose for Google’s ecosystem: it standardizes how agents operating inside Google Search and Gemini discover products, negotiate offers, and complete purchases on a user’s behalf. Where ACP is optimized for conversational interfaces like ChatGPT, UCP is designed to work across Google’s broader range of products. The Agent Payments Protocol (AP2), also from Google, sits one layer down from both of these, handling authorization specifically. Before an agent can spend money, AP2 generates a cryptographically signed mandate confirming that a real user authorized this agent to spend up to X for purpose Y. Every transaction gets a tamper-proof record tied to that mandate, which gives merchants and financial institutions an auditable trail to verify the transaction was legitimate. Google’s A2A, now maintained by the Linux Foundation with over 100 supporting organizations, handles a different problem entirely: how agents from different companies and platforms talk to each other. When an agent built by one vendor needs to hand off a task to an agent built by another, A2A provides the common language for that coordination.

X402 complements this stack in several ways. Google and Coinbase built the A2A x402 extension as a production-ready module within AP2 specifically for agent-based stablecoin payments. The split is clean: AP2 provides the authorization mandate, confirming the agent has permission to spend; x402 executes the actual per-call transfer once that mandate is in place, settling in USDC onchain. Cloudflare added x402 into its Agents SDK and MCP server tooling, so any tool or API exposed via MCP can require a 402 payment before granting access. In practice, an ACP-driven assistant might discover a service via MCP, see that the endpoint returns a 402, get operator budget approval, and settle via x402 on every subsequent call while ACP manages the overall order and recordkeeping.

Legacy payment networks have been getting involved with agentic payments too. Visa launched the Trusted Agent Protocol to help merchants identify and verify AI agents during checkout, particularly to distinguish a legitimate shopping agent from a malicious bot. Trusted Agent Protocol gives verified agents a cryptographic signature they can present to merchants during browsing and checkout, built on Cloudflare’s Web Bot Auth infrastructure and backed by partners including Microsoft, Stripe, Shopify, and Worldpay. Visa is working with Coinbase to ensure Trusted Agent Protocol is interoperable with x402. Mastercard launched Agent Pay the same month with its own merchant verification framework: tokenized agent credentials that let merchants register and authenticate AI agents before any transaction clears. While Mastercard has not announced a direct x402 integration, it is a named AP2 partner, and Cloudflare is working with Mastercard on the same Web Bot Auth infrastructure that underpins x402’s authentication layer.

Stripe is another major player that’s been actively ramping up development efforts around agentic payments. In February 2026, Stripe launched Machine Payments in preview, with x402 via USDC on Base as the first supported method, letting developers bill agents for API calls, MCP requests, or HTTP endpoints through the standard PaymentIntents API: the same infrastructure merchants already use for card payments. Alongside this, Stripe introduced Shared Payment Tokens: scoped, time-limited credentials that let agents initiate payments without exposing underlying account details, which non-Stripe merchants can forward to their own processors.

On March 18 the same PaymentIntents API was reintroduced as the foundation for the Machine Payments Protocol (MPP), a new open standard for agentic payments launched alongside Tempo’s mainnet. MPP encodes the same HTTP 402 signaling mechanism as x402 and targets the same fundamental problem but introduces two architectural differences: a “sessions” primitive that lets clients deposit funds into an onchain escrow once and sign offchain vouchers per-request, and multi-payment rail support, featuring native stablecoin settlement on Tempo with Visa, Lightspark, and Stripe extending MPP to cards, Bitcoin Lightning, and fiat methods as well.

x402 and MPP, unlike x402 and other agentic commerce protocols e.g. ACP/ UCP/A2A, are more adversarial than they are complementary. Tempo raised $500M from Stripe and Paradigm, and launched with merchants wielding lots of distribution power including Visa, Mastercard, Anthropic, OpenAI, and Shopify. Their competitive dynamics are worth diving deeper into a future paper; however it is worth acknowledging here that the two protocols are compatible. Cloudflare’s documentation confirms MPP is backwards-compatible with x402: existing x402 flows map directly onto MPP’s “charge” intent, and Stripe supports both.

What’s important to understand with all these different agentic commerce protocols is their division of labor. ACP and UCP enable AI agents to handle online shopping experiences on their human user’s behalf. AP2 handles authorization and audit. Visa and Mastercard handle merchant-facing trust and agent verification. Stripe is working to abstract developer integration across all of it. x402 sits at the execution layer of the stack: it’s a neutral payment API that any agent, any service, any developer can implement in a few lines of code, with no merchant account, processor agreement, or card network required. When an agent hits a paid endpoint (i.e. a raw API call, an MCP tool, or an HTTP resource gated by Stripe’s Machine Payments) the server returns a payment request in the HTTP response, the agent pays in stablecoins, and the request completes. The money moves, the workflow goes on. Onchain rails simply match the granularity of AI agent economics with greater cost, speed, and programmability than legacy payment infrastructure.

Coinbase

Coinbase authored x402 and remains its primary infrastructure provider. Coinbase published the open specification, shipped the reference SDK, and runs the dominant facilitator service. The CDP facilitator processes payments on Base and Solana and currently handles the majority of x402 volume.

Beyond infrastructure, Coinbase’s distribution plays a critical role in x402’s success. Payments MCP is the most significant piece. It packages x402, an embedded non-custodial wallet, and an onramp into a single MCP server that Claude, Gemini, Codex, and other LLMs can connect to directly. A developer can go from zero to a transacting agent without an API key or manual setup. Complementary to this are Agentic Wallets: wallets purpose-built for agents with programmable spending limits, gasless transactions on Base, and a CLI for agent management. Together, Payments MCP and Agent Wallets products form a vertically integrated stack to help developers get started with building on x402.

Major Integrations

Coinbase also co-founded the x402 Foundation with Cloudflare, which has been actively involved with x402; having integrated the protocol into its Agents SDK and MCP tooling to allow MCP-exposed tools to be 402-gated and paid per-call. The practical implication of this shouldn’t be understated; any server using Cloudflare (roughly 20% of all web traffic globally) can become a paid x402 endpoint without modifying backend code.

Amazon Web Services (AWS) is also an x402 Foundation ecosystem member and has published a reference architecture showing how x402 can be layered onto existing HTTP infrastructure using CloudFront and Lambda@Edge. In that flow, CloudFront acts as a global reverse proxy while Lambda@Edge runs payment verification logic at the network edge: when a request arrives, Lambda@Edge checks for a valid payment signature; if missing, it returns an HTTP 402 challenge. The architecture applies x402 to any origin without touching backend code, whether hosted on AWS, GCP, Azure, or on-premise. One of the more interesting capabilities this integration unlocks is the ability to to charge bots while keeping access for human users free. More broadly, this integration means x402 isn’t a crypto-native tool that requires rebuilding infrastructure around it; rather it easily fits into the cloud stack enterprises already run.

Privy added native x402 support, wrapping the full payment flow without browser extensions, seed phrases, or gas tokens. This includes detecting 402 challenges, signing payment authorization with the embedded wallet via a custom useX402Payment React hook, constructing the X-PAYMENT header, and retrying the request. Users only need USDC in their wallet on Base or Base Sepolia; facilitators absorb gas. Privy is also exploring policy-engine integrations for programmable spend controls at the domain, agent, and workflow level, running off-chain. Developers building with Privy can add x402 payment flows without building a wallet layer from scratch, plugging into the 90 million accounts Privy powers today.

X402 and ERC-8004

An important emerging complement to x402 is ERC-8004, an Ethereum standard co-authored by teams at MetaMask, the Ethereum Foundation, Google, and Coinbase, including x402’s own Erik Reppel. Both standards treat AI agents like first-class citizens in a new emerging virtual economy; where x402 provides payments infrastructure, ERC-8004 is designed to provide reputation and identity infrastructure.

The standard is made up of three lightweight onchain registries: Identity, which gives each agent a portable, globally unique identifier via ERC-721; Reputation, which maintains an onchain audit trail of client-authorized feedback; and Validation, which supports cryptographic or crypto-economic proof that a task was actually executed correctly. Together they function as an open credit score and track record for AI agents.

The integration with x402 creates a recursive loop. An agent discovers a service via the ERC-8004 identity registry, checks its reputation and validation history, makes an API call, receives an HTTP 402 code, pays via x402, and submits payment proof back into the reputation registry as a verifiable feedback signal. This way, each transaction helps strengthen the trust record. Over time this enables more sophisticated economic relationships: agent-native credit systems, outcome-based lending, constrained capital deployment where an agent doesn’t receive free funds but specific, verifiable capability.

X402x

x402x (short for x402-exec) is a programmable settlement framework built on top of x402 that turns payment into a complete execution primitive. Where the base x402 protocol handles payment routing, x402x combines payment verification, business logic execution, and facilitator incentives in a single atomic transaction. Standard x402 settles in 500-1100ms across a two-phase flow; x402x reduces that to 200-500ms via a Gateway contract that executes verification, authorization, token transfer, fee deduction, and nonce marking atomically. It adds four hook execution points — beforePayment, afterPayment, beforeBatchPayment, afterBatchPayment — enabling merchants to inject custom TypeScript logic for credential verification, subscription checks, NFT minting, loyalty point distribution, or complex settlement logic without modifying the core protocol. Batch settlement aggregates up to 100 payments per transaction, reducing per-payment gas costs by approximately 92%. A configurable platform fee mechanism gives facilitators an economically sustainable model. Critically, x402x is not a protocol replacement in any way, rather it is a production extension layer that runs fully compatible with the x402 specification.

T54

T54 is building a trust and risk layer for agentic commerce on top of x402. x402-secure is an open-source SDK and proxy layer that adds pre-transaction risk assessment, verified identity, and liability attribution to x402 payments. The system is powered by Trustline, T54’s own risk engine, which captures an agent’s reasoning traces and attaches them to the payment flow as verifiable evidence. Before a transaction settles, independent validators analyze the agent’s reasoning chain, behavioral patterns, and context to produce a risk score. The practical effect is that both buyers and sellers get auditable proof-of-agent intent, which opens a path toward dispute resolution and clearer liability in a protocol that is otherwise irreversible by design. T54 also shipped Claw Credit, an agent-native credit product built on x402 that allows agents to build a credit profile through usage and repayment to then unlock higher spending limits over time. T54’s agentic infrastructure is supported on Base, Solana, and XRPL.

Experiments and Early Builders

Beyond the major integrations, a scrappier layer of builders is exploring what x402 enables in practice. Conway Research’s Automaton is among the most striking examples: an open-source AI agent that owns a cryptographic wallet, pays for its own compute costs in USDC via x402, earns revenue by building and deploying products, and funds child agents when profitable. The agent runs on Conway’s MCP-compatible terminal infrastructure, integrates with Claude Code, Codex, or OpenClaw, and ceases to function if it cannot earn enough to cover its operational costs. Daydreams built xGate as an agent-native discovery layer for x402-enabled endpoints, alongside Lucid Agents, a commerce SDK that bootstraps agents with native x402, A2A, and ERC-8004 support. Developers have built self-generating task markets where agents post, discover, and pay for work autonomously. Agents can now buy their own web domains with x402. Some builders are experimenting with x402 and OpenClaw. There’s agents already using x402 for financial operations entirely through x402-gated endpoints: portfolio queries, market data pulls, swap execution.

Privacy is another open frontier. Onchain rails make every x402 transaction publicly observable: payment flows, cost structures, and purchase intent permanently recorded on a public ledger. Correlating onchain timestamps with server-side metadata is enough to reconstruct behavioral profiles over time, which becomes a nonstarter for enterprise workflows where any AI agent handles sensitive information. Several teams are working on solutions: x402Z, a collaboration between Zama and Mind Network, uses Fully Homomorphic Encryption combined with the ERC-7984 Confidential Token standard to validate transactions without revealing amounts, balances, or intent; Fhenix402 takes a parallel approach using CoFHE, performing computation on encrypted data without decrypting it; Aztec, Payy Network, and Miden, through their respective distinct architectural approaches, feature private settlement embedded natively at the protocol layer. With multi-chain support a core part of the x402 V2 spec, there is a direct path forward for adoption on privacy-native onchain rails.

New AI releases ship every single day, and what’s exciting about x402 is how boring it is: a simple neutral framework doing exactly what it says. That simplicity is what makes it universally applicable. In a world where agents transact autonomously at scale, the payment primitive underneath all of it may be the most important infrastructure layer no one is talking about.

That said, a reality check is in order.

Looking Ahead

Open Questions And Important Considerations

x402 and agentic commerce more broadly are still early. The protocol works, the ecosystem is growing, and there is undeniable value in micropayments and API-native monetization

But the full picture requires both internal development and external adoption to materialize in parallel. Standards like MCP and agentic payment flows still need to mature, and adoption among merchants and payment processors is an external force that no one controls on a fixed timeline.

X402 is not the first attempt to solve machine-native payments over onchain rails, and that history is worth holding onto when evaluating the open questions below. Balaji Srinivasan’s work at 21.co proved in 2013 that the concept of machine-readable micropayments was sound: Bitcoin payment channels could, in theory, enable devices to pay each other autonomously. The infrastructure wasn’t ready: Bitcoin transaction costs made sub-cent payments economically incoherent. L402, developed by Lightning Labs nearly a decade later, got further. It proved the technical viability of the HTTP 402 status code for payment-metered APIs and built real tooling around it. It failed for infrastructure reasons specific to its stack (e.g. Lightning’s statefulness, Bitcoin’s volatility, the two-sided cold-start problem) not because the underlying idea was wrong.

X402 fixes each of those specifically: USDC replaces volatile pricing, Base’s L2 removes channel management, and the facilitator model collapses the integration barrier to a single line of code. But some of the obstacles that slowed L402 including discoverability, compliance, and merchant behavior change have not been solved by upgrading the underlying infrastructure. The following are a few of the biggest questions concerning the adoption and success of x402.

Will credit cards adapt fast enough to make stablecoins unnecessary?

Whether its incumbents can actually be disrupted remains the defining question for x402’s role within agentic payments more broadly. Card networks have largely survived every predicted disruption for fifty years, from PayPal to Apple Pay to crypto, by adapting just enough, just in time. Credit card infrastructure is already deeply embedded, improving rapidly, and both Visa and Mastercard are actively building agent-specific payment frameworks. Agents already transact over card rails today. Virtual agent cards with programmable spending limits and backward compatibility with existing merchant infrastructure are an emerging middle path, which notably requires no stablecoin or crypto exposure whatsoever. If the major card networks lower fees, add programmable controls, and extend their rails to machine-native flows, the cost advantage of stablecoin settlement narrows.

Of course, card networks have built their entire business model on per-transaction fees and interchange, and there is no obvious incentive to destroy that margin to serve a new virtual economy that has not yet fully materialized. Stablecoins are also structurally more programmable, globally accessible, infinitely divisible, and require no chargebacks. The bigger question is whether the friction of crypto adoption is lower than the friction of waiting for card networks to adapt.

It’s worth noting the x402 V2 explicitly added support for legacy payment rails including ACH, SEPA, and card networks. As per the spec, x402 is an open standard for internet native payments which specifically “aims to support all networks (both crypto & fiat) and forms of value (stablecoins, tokens, fiat)”. Even if card networks adapt fast enough to close the cost gap, x402 is designed to work with whatever settlement layer wins.

The crawling and discoverability problem

This is a structural oversight x402 shares with L402, and it has no clean solution yet. Search engine crawlers do not have wallets. When they hit an HTTP 402 response, they treat it as a blocked page. Google’s own documentation confirms that 4xx status codes cause it to stop indexing affected URLs over time. Content protected by x402 is effectively invisible to the open web. Search engines will not index it and will not surface it in results.

Partial mitigations exist. Serving free previews to unidentified crawlers and using structured data to signal paywalled content are both established practices, borrowed from how publishers handle subscription paywalls today. But they add complexity, reintroduce the two-tier access model x402 was designed to eliminate, and don’t translate cleanly to pure API endpoints with no human-readable content to preview.

The longer-term resolution may not come from fixing x402’s relationship with search engines at all. If agents increasingly discover services through other agents, AI interfaces, and protocol-level registries rather than search crawlers, the relevant discovery layer shifts entirely. The SEO problem matters a lot if x402 adoption depends on organic web discovery; much less so if agents find services through agent registries, MCP directories, and AI-native discovery layers instead.

Regulatory and compliance risk

L402 stalled partly on compliance friction: accepting Lightning payments without a regulated gateway created AML exposure most businesses were unwilling to take on, compounding the existing adoption challenges Lightning already faced. x402 faces a version of the same problem, with a more explicit split.

Coinbase’s hosted facilitator includes KYT screening and OFAC checks on every transaction, inheriting Coinbase’s existing compliance stack. A merchant routing payments through that facilitator sits in a position analogous to using Stripe or PayPal: not a money services business, not directly exposed to AML liability. The tension emerges at the edges. Operators running self-hosted facilitators that take custody of assets or perform fiat conversion will, under conservative FinCEN and state interpretations, likely fall into MSB territory and face full BSA compliance requirements. The protocol is designed to be permissionless. The compliance infrastructure is not. If the facilitator layer becomes permissioned enough to satisfy regulators at scale, it concentrates gatekeeping in a way that undermines the protocol’s neutrality. If it stays permissionless enough to be genuinely open, it will likely hit the same OFAC and sanctions walls that complicated L402 adoption.

This is the same unresolved tension that has slowed stablecoin adoption in enterprise contexts for years. x402 does not resolve it, nor is that a failure of Coinbase’s execution. It is a protocol-level constraint: a permissionless payment standard operating in a world that requires permissioned compliance at meaningful scale. Coinbase’s facilitator is currently the most practical answer to that constraint, providing production-ready KYT and OFAC coverage that lets merchants transact without building compliance infrastructure themselves. The open question is what happens as the facilitator ecosystem diversifies and traffic routes through operators without Coinbase’s compliance stack.

Who is liable when an agent makes a bad payment?

Hadfield and Koh raise another structural problem sits underneath all of agentic commerce: current legal systems assume humans can monitor and control their agents, but that assumption breaks down as autonomy increases. When an agent using x402 overspends, sends funds to the wrong address, or is manipulated into paying a malicious endpoint, the liability chain is genuinely unclear. The protocol is irreversible by design. There is no chargeback. The facilitator verified the transaction. The agent acted within its programmed parameters.

This matters more because the same underlying models are deployed across many firms simultaneously. Hadfield and Koh warn that AI agent errors may be more correlated than human errors for precisely this reason: when agents share architecture, training data, or model weights, their failure modes cluster. The 2010 Flash Crash offers the clearest prior example of what correlated automated behavior produces at speed. Algorithmic trading systems briefly erased nearly $1 trillion in market value in under 36 minutes, not because any single actor failed catastrophically, but because systems trained on similar data responded to the same signal in the same way at the same time. The market recovered that day. Human regulators and exchange circuit breakers intervened at 2:45 PM when the CME halted trading for five seconds, breaking the feedback loop.

x402 has no protocol-level circuit breaker. Operators can enforce spending limits and whitelisted addresses at the application layer, and most current deployments still have humans setting those constraints upfront. But as agent autonomy increases and human oversight recedes by design, the window for intervention narrows. A correlated error that propagates through thousands of agents simultaneously would settle onchain before most oversight mechanisms could respond. The settlement finality that makes x402 useful is the same property that makes a cascade hard to stop

What does the future of x402 governance look like?

Coinbase and Cloudflare announced their intent to co-found the x402 Foundation in September 2025, with a stated mission of neutral, open governance. The structure makes sense as a distribution partnership: Cloudflare is one of the largest internet infrastructure providers globally, and Coinbase provides the stablecoin infrastructure and L2. Cloudflare CEO Matthew Prince acknowledged the dynamic directly, saying “Coinbase deserves immense credit for starting the work on the x402 protocol” while framing the Foundation as the path to independent governance.

But Coinbase is also the dominant facilitator, the author of the spec, the operator of the reference SDK, the issuer of USDC on Base, and a publicly traded company with shareholders. That is a significant concentration of involvement in a protocol designed to be a neutral payments layer for the broader web. The Foundation has stated it will welcome additional members from e-commerce platforms, AI companies, and payment providers through an open application process, but as of this writing no formal governance documentation, bylaws, or membership charter has been published.

Open source software has produced some of the most durable infrastructure in the world. Linux is the canonical example, but the Linux Foundation publishes its bylaws, board structure, and membership tiers publicly. The x402 Foundation has not yet done the same. Governance neutrality requires more than a stated mission. It requires structural commitment: published documentation, a clear roadmap for decentralizing facilitator infrastructure, and a governance model that doesn’t concentrate spec authority with the entity that also controls the dominant facilitator, the primary stablecoin, and the reference chain. None of that has materialized yet, as admittedly the Foundation is still young, but much of the difference between x402’s stated aspiration and its real-world impact lies in how effectively it can be governed and led over time.

The advertising fork in the road

In January 2026, OpenAI announced it would begin testing ads in ChatGPT’s free tier, with the first placements appearing in February. The move is understandable financially given OpenAI’s well-documented rate of burning cash, but it surfaces a deeper question about how the agentic economy gets monetized.

If the dominant AI interfaces become advertising-supported, agents face a structural conflict of interest. An agent that recommends a product because a merchant paid for placement is acting as a distribution channel, not in the interest of the end user. OpenAI says ads will not influence ChatGPT’s answers, but whether that holds at scale, under commercial pressure, over years, is a different question.

X402 and infrastructure like it represent an alternative model: agents complete transactions efficiently enough that the economic model does not require selling user attention. But the advertising flywheel has proven itself across every major internet platform for thirty years and generates hundreds of billions annually. The question is whether open payment rails can generate enough revenue fast enough to compete.

From attention economy to preference economy

This extends into something more structurally interesting. Today’s digital economy runs on advertising because there are more products than consumers have time to evaluate, and ads capture attention to guide transactions. In an agentic world where assistants interact with millions of services on behalf of consumers, attention becomes a less constrained resource. What matters more is the algorithm that matches assistants to services.

If strong central intermediaries once again dominate the matching layer, some form of paid prioritization (analogous to today’s advertising) will certainly influence rankings. The truly scarce and valuable resource in that world is not attention. It is high-quality human feedback on goods and services: the signal that distinguishes good services from bad ones, that trains better agents, and that creates a preference flywheel rather than an attention one. The key question is whether agent-to-agent commerce happens inside closed walled gardens controlled by a few dominant providers, or through an open web of agents that freely connect and transact. The answer will determine whether x402 and protocols like it become foundational infrastructure or a niche payment rail inside someone else’s ecosystem.

But merchant adoption doesn’t grow on trees

162 million transactions is a real number, but the majority of that volume flows through Coinbase’s own ecosystem and a small cluster of developer tools and crypto-native APIs. The harder test is whether mainstream API providers, SaaS companies, and non-crypto businesses add x402 alongside their existing subscription and API key models. Cloudflare’s network position reduces the technical barrier significantly, but the ecosystem needs merchants who have a genuine reason to prefer per-request stablecoin settlement over Stripe. That case gets stronger as agent traffic grows, but it is not proven yet.

And markets don’t form spontaneously

A useful corrective from Strange Loop Canon: markets form under coercion or coordination, and when they do exist, strategic sophistication determines who wins depending on how agents are configured. Alignment problems do not disappear just because agents can negotiate with each other. An AI agent economy running on x402 still requires discovery, trust, and security infrastructure among interacting agents. Whoever controls the dominant discovery layer — the mechanism by which agents find services and counterparties — holds enormous structural power regardless of how neutral the payment rail underneath it is. The payment layer is necessary but not sufficient. The governance of the layers above it matters just as much.

There are also several unresolved infrastructure problems that compound the challenges facing x402. The facilitator model has no sustainable economics built in at scale: Coinbase’s CDP charges $0.001 per transaction after a free tier of 1,000 monthly transactions, but third-party facilitators are largely running at zero fees with no clear revenue path. Two-phase settlement adds 500 to 1,100 milliseconds of latency per payment, which compounds quickly: an agent making 100 API calls in a single workflow carries over a minute of payment overhead before any work gets done. And EIP-3009 exclusivity means USDT — the largest stablecoin by market cap — remains incompatible with x402 entirely. Tether’s newer USDT0 variant addresses this technically, but it requires users to hold a different version of an asset they already own. BitGPT built h402 explicitly to preserve the protocol schema of x402 while ensuring the team isn’t “limited by someone else’s tech stack or product roadmap” — a signal that the developer community has noticed these gaps and is hedging against them.

Zooming out, x402 is early, the infrastructure is maturing, and most of these problems have plausible paths to resolution. What they collectively suggest is that x402’s current traction has mostly come from developer-native use cases where friction is low and tolerance for rough edges is high. The harder test is whether the same architecture holds at the scale of HTTP and the web as we know it today.

Closing Thoughts

The protocols that matter most rarely announce themselves. TCP/IP had no launch event. HTTP wasn’t pitched as the infrastructure layer for a trillion-dollar economy. They became load-bearing slowly, by being the path of least resistance for enough people solving concrete problems that adoption accumulated before anyone decided it was significant.

X402 is designed to be a primitive, not a standalone product. It requires one function call on the server and one signed payload from the client. There is no merchant account, processor agreement, or card network inherently required to transfer value. The implementation surface is deliberately small. Cloudflare, AWS, and Stripe aren’t endorsing x402 so much as absorbing it into infrastructure developers already use. That is what the early stages of a load-bearing protocol looks like, though institutional involvement is not the same as widespread adoption.

What makes x402 especially interesting is that it is the only current option that fits how AI agents actually operate. Legacy payment infrastructure requires agents to borrow human identity, human credentials, and operate on human settlement timelines. X402 runs on the same web-native rails agents already communicate over, prices at the granularity agents actually consume resources, and settles in seconds. That asymmetry is modest today. Whether it compounds is the real question.

Infrastructure like x402 “wins” when timing and adjacent development mature together. Facilitator economics need a sustainable model. Regulatory clarity around stablecoin and crypto market structure more broadly is still unresolved. Merchant adoption outside crypto-native developer tooling is not a given. The advertising model, which has monetized every major internet platform for thirty years, is already reaching into the agentic stack. And there is the stark reality that x402 may not be the HTTP-native micropayments solution that ultimately captures the agentic economy after all. The history of machine-native payment attempts is a reminder that the right idea pitched at the wrong time still fails.

What is clear is that AI agents are becoming economically active participants in a new virtual economy, and the infrastructure built for human consumers was not designed for them. In any new economic movement where which applications will succeed remains genuinely uncertain, the highest ROI historically has been foundational infrastructure investments, rather than the applications built on top of it. x402 is an attempt to occupy that position: a neutral payment API, running on open rails, that any agent or developer can implement without a card network or a bank in the middle.

The internet has always moved information freely. At Shoal, we believe it is inevitable that value travels the same way. But the infrastructure driving these movements matters more than any single applications built on top of them. x402 is an early attempt to get that infrastructure right, and whether it succeeds is still an open question. But x402 has one advantage its predecessors didn’t: timing. The conditions that made prior attempts at machine payment impossible, whether it be settlement costs, stablecoin liquidity, or AI agent adoption, are no longer the constraint. A virtual economy of AI agents is forming. Money will move through it. The remaining question is what the underlying rails look like when machines move money.

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

Sources

Data sourced from DeFi Llama, Artemis Analytics, and x402 Scan.

• “Moore’s Law: Transistors per Microprocessor.” Our World in Data, ourworldindata.org/grapher/transistors-per-microprocessor

• Hadfield, Gillian & Koh, Bryan. “Agentic AI and Law.” arxiv.org/pdf/2509.01063

• “Buy It in ChatGPT.” OpenAI, openai.com/index/buy-it-in-chatgpt/

• “Agentic Commerce Protocol Documentation.” Stripe, agenticcommerce.dev/docs

• “AI Agents to Boost Productivity and Size of Software Market.” Goldman Sachs, goldmansachs.com/insights/articles/ai-agents-to-boost-productivity-and-size-of-software-market

• “x402: A Payment Protocol for the Internet.” Erik Reppel, Dan Kim, Nemil Dalal. arxiv.org/pdf/2509.10147

• “x402 GitHub Repository.” Coinbase, github.com/coinbase/x402

• “How x402 Works.” Coinbase, docs.cdp.coinbase.com/x402/core-concepts/how-it-works

• “X402x.” @yq_acc, x.com/yq_acc/status/1987968102605484152

• “Fhenix402.” Fhenix, fhenix.io/blog/fhenix402

• “Monetize Any HTTP Application with x402 and CloudFront + Lambda@Edge.” AWS, builder.aws.com/content/38fLQk6zKRfLnaUNzcLPsUexUlZ

• “Internet Finance.” Montealegre, Felipe. source

• “EIP-3009: Transfer With Authorization.” Ethereum, eips.ethereum.org/EIPS/eip-3009

• “Why the Ad Industry Isn’t Ready to Let AI Agents Spend Ad Dollars.” Digiday, digiday.com/marketing/intentionally-being-cautious-why-the-ad-industry-isnt-ready-to-let-ai-agents-spend-ad-dollars/