‍x402: The Internet-Native Payment Standard ‍

What is x402?

In the early days of the web, the creators of HTTP designated code 402 for 'payment required' - envisioning a future where servers could charge per request. That future never materialized. This is because online payments didn't exist yet, and there was no viable way to implement. So, 402 sat unused while the web defaulted to ads and subscriptions.

Cut to today, and we have stablecoins, sub-second settlement, no chargebacks, and blockchains that actually scale - the exact properties HTTP 402 needed to succeed. x402 wires these properties into the internet's request-response loop, acting as an open standard that lets any service charge for API or content access over HTTP without traditional accounts, sessions, or credentials. 

How Does x402 Work?

The protocol is simple, consisting of three basic entities: a human/agent client, a server with the desired resource, and a facilitator (infra for payments). Here's an example flow:

You request something from a server, such as an API call or a piece of content. If the resource requires payment, the server responds with HTTP 402 and includes payment instructions, specifying which token is required, the amount, the network, and the destination address.

The client has a wallet. If you're a human, that wallet is policy-driven and managed on the server-side to avoid manually signing everything. If you're an AI agent, you can be provisioned with a wallet that has limits and rules. Either way, the client reads the 402 response and generates a signature authorizing the payment. Overview: 

‍

Critically, instead of forcing the client to manage gas and private keys, this signature uses `transferWithAuthorization` (EIP-3009). This is a permit-style transaction where the client signs off on the transfer, but anyone can actually submit it to the blockchain. The facilitator does that job.

The client sends the signed payment back to the server. The server doesn't trust it yet, so it forwards the signature to the facilitator's `/verify` endpoint, which simulates the transaction and confirms it's legit. Once verified, the facilitator's `/settle` endpoint actually executes the transfer. Money moves. The server sees the settlement, then responds with the requested resource.

The whole loop takes less than a second. From the client's perspective, it's just HTTP. From the agent's perspective, it's just another API call. And that’s entirely the point, x402 makes payments as composable as any other web request.

Official docs: https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works

X402: Benefits & Features 

Universal design - x402 operates through standard HTTP mechanics, meaning it can integrate with any existing web infrastructure without requiring specific SDKs or tooling. Add a line of middleware, configure your endpoint, and you're good to go. 

Micropayments - The protocol itself has no fees. The facilitator's costs are only gas costs and those are incredibly low. This changes the entire equation - suddenly, tiny charges make economic sense, and previously impossible pricing granularity works.

Fast settlement - Payment authorization completes within a single request-response (sub-seconds), while settlement happens asynchronously. The server trusts the facilitator for onchain execution, making payments functionally instant for agents.

Web-native - x402 leverages standard HTTP, allowing it to integrate cleanly into existing web infrastructure. It's compatible with every major programming language, framework, and hosting platform that supports basic HTTP requests. 

Why Does x402 Matter?

Starting with the most obvious: traditional payment systems were never meant for AI agents. They can't fill out forms, wait for invoices, etc. ChatGPT can already buy things via Stripe, but that's one (closed) solution, and it doesn’t make sense for every transaction type. If every service needs custom integrations, agentic commerce becomes fragmented/siloed before it even gets off the ground. 

This is primarily what x402 solves. Instead of a tailored solution for every platform or API provider, an agent can connect to x402 and pay for anything that accepts it. In this way, we evolve past the pay-walled world that exists because micropayments don't really work. 

Historically, you couldn’t pay by the cent for one-off API calls or GPU minutes, everything was bundled at $x/month. With x402, pricing tracks actual usage. There are already live examples of this, eg, pay-per-crawl APIs, where agents pay nano-payments to scrape content - the first glimpses of an entirely new economic dimension.

Agent-Agent Payments 

Zooming in further, x402's real unlock is arguably about autonomy. Consider: an agent querying a data API, hiring another agent to process the output, then paying a compute node to run simulations. Today, this all requires a human for setup/admin. With x402, the agent can just pay each service directly, in real-time.

The transactions are also conditional - pay only if a valid response is received - and composable, agent one's output feeds agent two's input, running at thousands of fractional payments per minute/hour. As described, 'high velocity, high volume, low value, conditional, composable, and cosmopolitan' transactions. Traditional payment rails can't handle this pattern. Blockchains can, and the potential is hard to overstate.

But where this gets really interesting is when you start pairing x402 with other crypto primitives. 

X402 x ERC 8004 x ROFL 

x402 is a step function for payments, but it doesn't magically solve trust. When an agent pays for API access or inference, it's exposing data to the operator. Not to mention all the other agent trust issues, eg, which model is actually executing? Who controls the keys? Who can upgrade the agent, and under what conditions? 

Agents today operate like strangers - they can interact, but lack a shared understanding of each other's capabilities or trustworthiness. They also usually require a high degree of trust in the developer. 

This is where ERC-8004 and ROFL come in. ERC-8004 provides a neutral coordination/discovery layer - onchain registries for identity, reputation, and validation, letting agents find each other and select trust mechanisms to match their needs. 

ROFL plugs into 8004 - adding data privacy, decentralized key management, and verifiable, tamper-proof execution. ROFL-deployed agents generate keys inside TEE, publish the public keys onchain. Validators then validate that the agent responses are signed with said keys, creating a chain of trust. 

The setup features:

• Code verification: Service registers its build artifacts (model weights, inference code, payment logic) onchain, allowing anyone to cryptographically prove the exact code running in the TEE.
• Key isolation: Private keys are generated in the TEE at boot time and never leave encrypted memory, preventing operators from controlling the wallet or  manipulating transactions.
• End-to-end confidentiality: TLS terminates within the TEE, so queries, responses, and payments occur within the attested enclave, where operators can't access them.

Sample Implementations:

The Oasis team has built an example document summarization service that runs Ollama inference inside a ROFL container. Users pay cents per summary via x402, with the entire service verifiable, from model weights to payment logic. 

We've also built another demo using multiple LLM models with cross-validation for oracle consensus. The service illustrates how ROFL can provide trust guarantees for multi-model AI workflows paid through x402 - (now registered via 8004).

Learn more here.