internet-native payments for agents and humans.

Payer mode 1 · machine

An agent pays an API for data.

No human in the loop. A program GETs an agent-facing route, receives a 402 with machine-readable terms, signs an exact authorization, and retries — settlement lands on-chain in the same round trip. The 402 is optional: when the agent already knows the terms from discovery, it pays on the first request and skips the challenge entirely. This is x402 as transaction-native machine-to-machine commerce.

# first request, terms unknown — the server answers with a 402 challenge
$ curl -i https://x402.cloudless.sh/v1/lambda-runtimes
  HTTP/2 402
  payment-required: 

# the agent signs an exact authorization, retries with PAYMENT-SIGNATURE
$ curl -i -H "PAYMENT-SIGNATURE: …" https://x402.cloudless.sh/v1/lambda-runtimes
  HTTP/2 200
  payment-response: 
  ["nodejs26.x","python3.15","java25", …]

# terms already known from discovery? skip the 402 — pay on the first request

// npm i @x402/fetch @x402/evm viem
import { wrapFetchWithPayment, x402Client } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

// set BUYER_PRIVATE_KEY in the environment — never commit a key
const account = privateKeyToAccount(process.env.BUYER_PRIVATE_KEY);

const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(account));
const pay = wrapFetchWithPayment(fetch, client);

// $0.001 USDC paid automatically — gasless EIP-3009, no 402 dance
const res = await pay("https://x402.cloudless.sh/v1/lambda-runtimes");
const runtimes = await res.json();

Payer mode 2 · human

A person pays a wallet for content.

The same protocol, with a person at the keyboard. Open the page, click pay, and a wallet in the browser signs a gasless EIP-3009 authorization — a signature, not a broadcast transaction, so no ETH for gas. The content is released once settlement succeeds. No account, no checkout, no API key. There are two ways to bring that wallet, and both are live here.

// in the browser — the same @x402/* SDK, the wallet is the signer
1. open https://x402.cloudless.sh/x402-market-report
2. click “Pay & download” → wallet pops up (MetaMask / EIP-1193)
3. sign a gasless EIP-3009 authorization — not a broadcast tx, no ETH
4. HTTP/2 200 · application/pdf → the report downloads
// a person just paid $0.001 for content, no account, no checkout

The observers dataset is also agent-payable as JSON — the passkey page is the human counterpart to paying it programmatically. Either path produces the same signed authorization the facilitator settles.

The third party in the middle

Neither payer touches the chain.

Both flows produce the same thing: a signed authorization, not a broadcast transaction. Settlement still costs gas on-chain — the payer just isn't the one who pays it. The facilitator is the external party that turns the signature into a settled payment: on the paid retry it verifies the authorization against the advertised terms, then submits it on-chain and fronts the gas — which is why the payer needs no ETH and no node. The server prepares the resource before settling and releases the response only once settlement succeeds.

Using a facilitator is a deployment choice, not a protocol requirement: this reference server settles through a public x402 facilitator (PayAI, on Base). The signer (agent or wallet) and the recipient never hold each other's keys, and verify is a read-only preflight — it does not reserve funds — so a well-formed 402 is not yet a payment.

The routes

One server, one payment flow.

The paid routes behind this reference server — an agent-facing JSON API, a human-facing PDF report, and an observers dataset payable either by an agent or by passkey in the browser. All paid the same x402 way. The price and terms below are advertised; the live `402` challenge is always authoritative.

Discovery

Machine-readable, for agents.

The same catalog, published as metadata so an agent can find the routes and their payment terms without reading this page — and, knowing the terms up front, pay on its first request instead of waiting for a 402. The runtime `402` challenge is always authoritative over the static documents.

There is a second discovery channel we do not serve ourselves. The facilitator that settles these payments also catalogs them: a route tends to become discoverable through its catalog by being paid — a settled transaction carries the route's advertised terms — rather than by being registered. Discovery there is a consequence of real settlement, not a listing we assert. Indexers such as x402scan read that surface; we treat an accepted listing as separate evidence from settlement, and do not claim one here until it is confirmed.

The payment gate itself is an open Terraform module. How this server is built — the edge module