The wall now sells the door.
Every rate limit on the internet answers demand the same way: 429 Too Many Requests — a rejection with no memory, no price, no commitment. x429 turns that rejection into an offer: a signed ticket for a guaranteed future slot, or priced priority paid machine-to-machine over x402.
Same traffic. Different physics.
Both walls below receive identical demand — the same requests per second, the same synchronized bursts. On the left, today's internet: rejected requests scatter, retry at machine speed, and burn money until they give up. On the right, x429: every arrival is ticketed into one ordered queue, and when a request can't afford to wait, it pays the resource owner to go first.
Watch the right side: every few seconds an agent with a deadline pays a small x402 fee, the queue makes room, and it enters first. That money used to be captured by whoever wrote the fastest retry bot. Now it goes to the server.
One round trip buys certainty.
GET /v1/infer HTTP/1.1 Host: api.gpu-cluster.io
HTTP/1.1 429 Too Many Requests
Retry-After: 47
X429-Version: 1
{ "ticket": {
"id": "tkt_9f2c81d4",
"window": { "notBefore": "14:03:47Z", "notAfter": "14:04:17Z" },
"bind": "wallet:0x7a3f…c2",
"sig": "ed25519:MEUCIQ…"
},
"upgrades": [
{ "class": "immediate", "window": "PT2S",
"pay": { "amount": "0.004", "asset": "USDC", "rail": "x402" } }
],
"estimates": { "freeWaitSeconds": 47, "queueDepth": 1284 } }
└ still a perfectly legal 429 — a client that has never heard of x429 sees an honest Retry-After and nothing breaks
deadline 5s < free wait 47s budget 0.01 USDC ≥ price 0.004 → pay "immediate" over x402
└ the developer wrote none of this — they set a deadline and a budget; the retry handler does the rest
GET /v1/infer HTTP/1.1 Host: api.gpu-cluster.io X429-Ticket: tkt_9f2c81d4 X-Payment: x402:0.004 USDC · settled 182ms
HTTP/1.1 200 OK
└ signature check, window check, nonce check — three comparisons, sub-millisecond, no database. No account, no API key, no human.
Your rate limiter is a bouncer. x429 turns it into a maître d'. Same door, same protection — but the overflow gets a reservation instead of a rejection, and the impatient pay you for the front of the line.
Small enough to read. Boring enough to trust.
The whole protocol is a wire format, a header, and a client state machine. It composes with x402 instead of competing with it — 402 sells access, 429 sells timing, same rail. These are the rules it refuses to break:
§1 Binding, not advisory. A ticket is a signed commitment to a slot. Present it in its window, get admitted. Breach is detectable — and logged.
§2 Degradation is sacred. Every x429 response is also a valid legacy 429 with an honest Retry-After. Sellers adopt at zero risk; clients upgrade whenever.
§3 Stateless verification. Ed25519 signatures verify without a database lookup. The only server state is a short-lived nonce set.
§4 x402-native. Upgrade offers are standard x402 payment payloads. Any client that can pay a 402 can already pay for priority.
§5 Auditable ordering. Issuance order is committed to a public log — certificate transparency, but for queues. Fairness you can check, not trust.
§6 Pseudonymous. Tickets bind to keys and wallets, never identities. x429 is not an identity system and refuses to become one.
HTTP/1.1 429 Too Many Requests
Retry-After: 47
X429-Version: 1
Content-Type: application/json
{
"x429": 1,
"resource": "api.example.com/v1/search",
"ticket": { "id": "tkt_9f2c81d4", "keyid": "ex-2026-07",
"window": { "notBefore": "…T14:03:47Z", "notAfter": "…T14:04:17Z" },
"bind": "wallet:0x7a3f…c2", "nonce": "u4vX…",
"sig": "ed25519:MEUCIQ…" },
"upgrades": [ { "class": "immediate", "window": "PT2S",
"pay": { "amount": "0.004", "asset": "USDC", "rail": "x402" } } ],
"estimates": { "freeWaitSeconds": 47, "queueDepth": 1284 },
"policy": { "sloAdmitP99": "PT1S",
"transparencyLog": "…/.well-known/x429-log" }
}
Questions with real answers.
Is x429 a payment system?
No. Payments settle over x402, directly between buyer and seller. x429 defines what's being sold — timing — and adds zero payment surface of its own.
Isn't paid priority just scalping?
It's scalper revenue redirected to the resource owner. Today the priority market already exists — it's run covertly by whoever writes the fastest retry bot, the seller earns nothing, and the queue is provably unfair. x429 keeps a free guaranteed lane, publishes the ordering log, and pays the server.
What about clients that have never heard of it?
They see a standard 429 with an honest Retry-After. Nothing breaks, nobody is worse off. That asymmetry is the whole adoption strategy: sellers risk nothing by turning it on.
Who is behind this?
An open draft — spec and reference implementation on GitHub, Apache-2.0, test vectors included. Read it, break it, file issues.