HTTP 402

The 402 status code has been "reserved for future use" in the HTTP specification since 1991. The x402 protocol activates it: a server returns 402 Payment Required when the client asks for a paid resource without paying, the client signs a payment payload, and the server delivers the resource on retry.

Three headers, three documents

The wire format adds three HTTP headers on top of normal requests and responses. Each carries a base64url-encoded JSON document.

• PAYMENT-REQUIRED — set by the merchant on the 402 response. Lists the schemes and prices the merchant accepts.
• PAYMENT-SIGNATURE — set by the client on the retried request. Carries the signed payment payload.
• PAYMENT-RESPONSE — set by the merchant on the eventual 200 response. Carries the on-chain settlement receipt.

The base64url encoding lets the documents survive hop-by-hop infrastructure (proxies, ingress controllers, browser fetch APIs) without escape issues.

A complete round-trip

POST /api/llm HTTP/1.1
Host: x402.nerochain.io
Content-Type: application/json

{ "prompt": "Hello" }

HTTP/1.1 402 Payment Required
Payment-Required: eyJ4NDAyVmVyc2lvbiI6Mi...    (base64url JSON)
Content-Type: application/json

{ "x402Version": 2, "accepts": [...] }

The decoded accepts list:

[
  {
    "scheme": "aa-native",
    "network": "eip155:1689",
    "amount": "1000",
    "asset": "0x...",
    "payTo": "0x...",
    "maxTimeoutSeconds": 60
  }
]

The client then signs a payload that satisfies one of the entries and re-issues the request:

POST /api/llm HTTP/1.1
Host: x402.nerochain.io
Payment-Signature: eyJ4NDAyVmVyc2lvbiI6Mi...    (base64url JSON)
Content-Type: application/json

{ "prompt": "Hello" }

On success:

HTTP/1.1 200 OK
Payment-Response: eyJzdWNjZXNzIjp0cnVlLi...    (base64url JSON)
Content-Type: application/json

{ "completion": "Hi! How can I help?" }

The decoded Payment-Response contains transactionHash, payer, amount, asset, and the canonical settlement metadata.

Why 402 and not a custom status

Reusing 402 is the whole point. Existing HTTP intermediaries (CDNs, gateways, observability tooling) treat 402 as a normal client error today; they do not strip the Payment-* headers, they pass the body through, and they log requests at the right severity. Inventing a new status code or a non-HTTP layer would break this.

Schemes

The scheme field on each accepts entry names the settlement scheme. NERO 402's facilitator advertises two:

• exact — EIP-3009 transferWithAuthorization from an EOA. Compatible with unmodified upstream @x402/fetch clients.
• aa-native — paymaster-sponsored UserOp from an ERC-4337 SCW. Defined in the aa-native scheme page and the whitepaper.

Schemes share the outer envelope (x402Version, accepted, payload, extensions); only the inner payload differs. New schemes are additive.