x402, explained: how an AI agent pays for a GPU

An AI agent that makes images, tests code, or runs a model needs a GPU the way it needs everything else: right now, and for a short while.

The usual way to buy one was built for people. Make an account, add a card, buy credits, create an API key, and paste it into a config file. x402 replaces those steps with one: the agent pays in the same HTTP exchange that asks for the work.

A status code from 1997

HTTP has had a code for this for almost 30 years. The HTTP/1.1 standard of January 1997 listed 402 Payment Required and said, "This code is reserved for future use." The standard of today still says that it is reserved for future use.

x402 is that future use. Coinbase contributed the protocol to the Linux Foundation, and the x402 Foundation became fully active on July 14, 2026, with 40 member organizations. Its premier members include AWS, American Express, Circle, Cloudflare, Coinbase, Google, Mastercard, Shopify, Stripe, and Visa.

The flow, step by step

An x402 payment takes four steps, all over ordinary HTTP:

1. The agent asks. It sends a normal request for an output.
2. The server names its price. It answers 402 Payment Required with the amount, the token, the address to pay, and the network.
3. The agent signs. It signs an authorization for that amount and sends the same request again with the signature attached.
4. The payment settles. A service called a facilitator verifies the signature, submits the transaction, and pays the gas. The server then returns the output.

A shortened example, in the order the agent sees it:

POST /v1/outputs  model=flux-schnell
402  Payment required: 0.0028 USDG on Robinhood Chain
POST /v1/outputs  + signed USDG authorization
200  Output ready, payment settled

The agent needs no account, no API key, and no gas. It needs a wallet that holds a stablecoin and a key to sign with.

Why one signature is enough

The main method of x402 on EVM chains uses EIP-3009, a standard for token contracts. The signature names the sender, the recipient, the amount, a window of time, and a nonce that the contract accepts only once.

That makes it a narrow permission. It pays one amount to one address, inside one window, one time. If nobody submits it, it expires, and it leaves no open approval behind.

USDG, the dollar stablecoin that Paxos issues on Robinhood Chain, supports EIP-3009. We tested the contract on mainnet in October 2026 with a signed authorization, so the standard flow works there as written.

Why it suits GPUs

GPU work comes in small, exact amounts: one image, one clip, one 3D asset. A payment per request matches that shape, and three things follow:

• The price comes first. The 402 names the price before the agent pays, so an agent can compare services and decide in code.
• An agent can start on its own. With no signup, it can use a new service the moment it finds one, with no person in the loop.
• Spending stays in bounds. The agent signs for one amount at a time, and whoever funds its wallet decides how much it holds.

What about a rental?

An output fits one request. A rental runs for a while, with the meter running per second. For that, an agent holds a balance and spends from it, inside a spend cap.

So the two work together. x402 pays for one output at a time, and a balance keeps a GPU instance running for as long as the work needs it.

Where Texel fits

Texel is building both into the onchain GPU cloud on Robinhood Chain. An agent will get a 402 from the gateway with the price, sign one USDG authorization, and get its output in the same request. With its own balance, it will also rent a GPU instance, run its work, and stop it. You set its spend cap, and one switch stops it.

Sources

• IETF, RFC 2068: Hypertext Transfer Protocol, HTTP/1.1, January 1997.
• IETF, RFC 9110: HTTP Semantics, June 2022.
• Linux Foundation, Linux Foundation Announces Operational Launch of x402 Foundation, July 14, 2026.
• x402, x402.org.
• Ethereum, EIP-3009: Transfer With Authorization.
• USDG on Robinhood Chain, the contract.