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.
Don't trust the pitch. Curl it.
This site runs its own protocol. GET /429 answers with a real 429 Too Many Requests carrying a freshly signed ticket, and /.well-known/x429.json publishes the discovery document agents read first. Three moves, one round trip:
Any HTTP client. No SDK, no account, no API key. The server happens to be saturated.
A signed, time-boxed slot commitment — plus a priced upgrade if waiting costs more than paying.
One header on the retry. The server verifies with three stateless checks, sub-millisecond.
$ curl -i https://x429.dev/429
HTTP/2 429
retry-after: 47
x429-version: 1
link: </.well-known/x429.json>; rel="service-desc"
{ "x429": 1,
"ticket": { "id": "tkt_…", "class": "free",
"notBefore": "…T14:03:47Z",
"notAfter": "…T14:04:17Z",
"sig": "ed25519:…" },
"upgrades": [ { "class": "immediate",
"price": { "amount": "0.004",
"asset": "USDC", "rail": "mock" } } ],
"redeem": { "header": "X429-Ticket" } }
$ curl -s https://x429.dev/.well-known/x429.json
{ "x429": 1,
"issuer": "https://x429.dev",
"docs": "https://x429.dev/docs/",
"keys": [ { "kid": "x429-protocol-demo",
"alg": "Ed25519" } ],
"paymentModes": ["mock"],
"headers": { "ticket": "X429-Ticket",
"clientKey": "X429-Client-Key" } }
└ a client that has never heard of x429 sees an honest Retry-After and retries like it always has — turning this on breaks nobody
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" }
}
Install in ten minutes.
One middleware on the scarce route, one well-known route, one Ed25519 key pair in env. Capacity policy stays yours — x429 only decides what the wall says when the answer is no.
import { x429, x429WellKnown } from "@x429/hono";
import { mockPaymentVerifier } from "@x429/payment-mock";
app.use("/v1/*", x429({
issuer: "https://api.example.com",
privateKey: env.X429_PRIVATE_KEY, // Ed25519
capacity: { limit: 5, intervalMs: 1000 }, // your policy
ticket: { freeDelayMs: 10_000, redeemWindowMs: 30_000 },
upgrades: [{ class: "immediate", delayMs: 500,
price: { amount: "0.004", asset: "USDC", rail: "mock" },
payment: mockPaymentVerifier({ /* … */ }) }]
}));
app.get("/.well-known/x429.json", x429WellKnown({ /* keys, docs */ }));
v0.1, stated plainly.
This is a draft protocol with a working reference implementation — not a finished product. What runs today runs for real; what doesn't is listed, not implied.
Working today
- Signed tickets — Ed25519, resource-scoped, time-bound, client-bound, single-use
- Hono / Workers middleware issuing and verifying tickets
- Agent client: an x429-aware fetch with deadline + budget policy
- 100-agent simulator comparing naive retry vs ticketed admission
- Paid priority end-to-end — with mock receipts, no real money moves
Planned
- Real x402 settlement adapter — the interface is specified, the rail is not wired
- Transparency log for auditable issuance ordering
- More framework integrations beyond Hono / Workers
Four doors in.
Wrap one scarce endpoint with the middleware and your 429s start selling instead of shedding.
install the middleware → Agent buildersSwap fetch for the x429-aware client: it verifies the offer, waits, redeems, and pays only within budget.
use the client → Payment / x402 buildersPriority settles over x402; the adapter interface is specified and mocked, waiting for a real rail.
read the payment spec → Design partnersPilot on one genuinely overloaded endpoint and measure retry reduction and completion rate.
read the pilot guide →Where the queue forms first.
x429 pays off wherever demand is machine-driven and bursty — callers with deadlines and budgets, hitting resources that are genuinely scarce.
Agents already retry tools in tight loops. Give the loop a contract instead of a guess.
Sell the burst instead of shedding it — the overflow is your most motivated traffic.
Long jobs, hard deadlines, visible queue depth: priority pricing is already implicit. Make it explicit.
Crawlers and pipelines can almost always wait — and say so honestly when they can't.
Deadline-driven callers with budgets are exactly the client x429 was designed for.
Drops, mints, releases: the wall's busiest hour. Sell order, not luck, and keep the bots honest.
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.