What Is x402, and What Our Header Does Beside It

What it is, and whose it is

x402 is a protocol for paying for an HTTP request. A server answers a request with the payment-required status, states what it wants, and the client pays and retries. The status code has been in the specification since the beginning and went essentially unused for decades; the protocol puts machinery behind it.

It is not ours. We did not write it, we do not steward it, and nothing on this page should read as if we did.

We do not implement it

Measured across the backend and the shared packages: nothing. No code parses a payment-required response, reads a payment-requirements object, constructs a payment payload, or retries a request with one attached.

CONTROL, and it makes the zero stronger than a plain absence: the status code does appear in our code. Our own free-tier limit answers with it when a workspace is over its agent allowance. So the search finds the token, and still finds no protocol implementation. A zero that survives a token that exists is not a broken query.

What we ship instead, stated precisely

A header an agent attaches to a request it is already making. The agent derives a fresh selective-disclosure proof, entirely offline, and puts it in an identity header. The receiving service verifies it and learns whichever claims the agent chose to disclose.

It composes without either side knowing about the other. The protocol's own headers do their job, ours does its job, and neither depends on the other's presence.

And this is the part worth being exact about: what the proof binds

Three things: the request method, the request path, and a timestamp. The proof is bound to a string built from exactly those.

Not the body. Not an amount. Not an asset or a recipient.

So the header is an identity presentation and it is not a payment authorisation. It answers "which agent is calling this endpoint, right now, and what does it choose to disclose". It does not answer "may this payment happen".

A service that saw our header travelling beside a payment and treated it as approving that payment would be making an inference the cryptography does not support, and saying so plainly is more useful than letting the adjacency imply it.

What is already built, because absences alone would misdescribe us

Verifier middleware for four runtimes, so a service checking our header does not have to write the verification itself.

Offline proof derivation, so presenting a credential needs no call to us at any point.

And the credential format is a published standard, with the identifier method registered in the W3C DID Method Registry, so the verifying side is implementable without our code.

That is a real integration surface, and it is an identity surface rather than a payment one.

The anti-replay model, published because it is good

Cross-endpoint replay is prevented by construction. Because the method and path are inside the signed binding, a proof captured on one endpoint does not verify on another.

Same-endpoint replay is time-boxed. The verifier rejects a proof whose timestamp is outside a window that defaults to sixty seconds.

A replay cache is on by default, rejecting an identical proof seen twice inside that window.

And the package documents its own limit rather than implying there is none: a verifier that needs strict one-time semantics is told to issue its own challenge and verify against that. Software that names the boundary of its own guarantee is doing the thing this estate keeps asking other people's software to do.