A signed way back in
x429 adds an admission offer, a signed ticket, and a redemption header to an ordinary HTTP 429 response.
The problem x429 solves
A normal 429 says "not now" but gives no binding commitment. Agents either retry too fast, retry too late, or spend compute guessing. x429 returns a signed admission offer instead.
Advisory retry
Retry-After is a hint. It does not reserve capacity and does not prevent a second collision when clients return.
Signed ticket
An x429 ticket is a cryptographic commitment scoped to a resource, client binding, and time window.
Vocabulary
| Term | Meaning |
|---|---|
| Origin | The API or service protecting a scarce endpoint. |
| Resource | In the current v2 profile, the configured public origin plus pathname; the HTTP method selects a separate coordinator. Arbitrary logical keys are not implemented. |
| Ticket | A signed object that describes who can redeem, when, and for what. |
| Slot | The future admission window described by notBeforeMs and notAfterMs. |
| Binding | A thumbprint of the client's Ed25519 proof key plus the exact authenticated request context. A copied public key cannot redeem by itself. |
| Nonce | A single-use replay guard for proof, credential, payment authorization, or upstream assertion. |
| Paid lane | A finite earlier admission class. Research/mock mode supports a sealed-maximum uniform-clearing auction; deployed exact mode exposes one fixed-price slot to one vetted client. |
| Discovery | The v2 Worker's /.well-known/x429.json document. It publishes capabilities, but clients still require independent trust pins. |
Compatibility rule
Every x429 response must still be a valid HTTP 429. Legacy clients continue to receive the standard status and Retry-After; capable clients can verify the added offer.
HTTP/1.1 429 Too Many Requests
Retry-After: 10
X429-Version: 2The marketing site is not a discovery or admission authority. V2 discovery must come from the separately deployed admission origin and still be checked against out-of-band trust pins.
What x429 does not do
- It does not identify humans.
- It does not detect bots.
- It does not custody a wallet or choose an agent's budget. Exact settlement uses a separately constrained x402 payer.
- It does not make unfunded bids trustworthy; submitted maxima are not locked funds.
- It does not derive capacity from arbitrary URLs. Operators explicitly map exact paths or terminal
/*prefixes to named finite pools; paths in one pool share a coordinator, query values remain request-bound, and unmatched paths fail closed. - It does not make infinite capacity. It makes scarcity explicit and schedulable.