draft v0.1 ยท reference implementation

x429 docs

x429 is an HTTP-native coordination layer for overloaded resources. It turns 429 Too Many Requests into a signed reservation, and gives agents a deterministic way to wait, redeem, or pay for priority.

Where to begin

Choose your path

Updated July 7, 2026

What is implemented today

Working

Signed tickets

Ed25519 ticket creation, encoding, verification, resource scope checks, client-key binding, and nonce replay protection live in packages/core.

Working

Middleware and client

Workers/Hono-style middleware issues tickets. The fetch wrapper handles x429 responses using deadline and budget policy.

Working

Simulator

The 100-agent simulator compares naive retry against x429-aware admission and mock paid priority.

Planned

Real x402 settlement

The payment adapter exists as a placeholder. V1 proves scheduling first, then swaps mock receipts for real x402 verification.

System map

OriginThe API or scarce resource that wants to protect capacity without throwing away demand.
x429 middlewareChecks capacity, issues signed tickets, verifies redemption, and handles priority proof.
Agent clientRecognizes X429-Version: 1, verifies the offer, then waits or pays.
Nonce storePrevents replay and double admission. Durable Object recommended on Workers.
Payment adapterMock today. Real x402 adapter should bind payment to ticket id, class, resource, and amount.
Discovery/.well-known/x429.json publishes keys, docs URL, version, and supported payment modes.

Ecosystem fit

x429 should feel narrow, not vague. It is the admission primitive for overloaded resources. Other systems can plug into it without becoming part of the core protocol.

LayerRolex429 stance
HTTP 429Existing overload signal.x429 stays compatible: legacy clients still see Retry-After.
x402Payment rail for machine-native payments.x429 can use x402 to settle paid priority, but scheduling and tickets remain separate.
MCPTool and context servers for agents.MCP endpoints are strong pilot candidates because agent retry behavior is visible.
llms.txtMachine-readable site instructions.The site publishes concise agent instructions at /llms.txt.
GSLP / policy layersHigher-level service promises, routing, or guarantees.Can reference x429 as the concrete wait/redeem/pay mechanism underneath.

Trust checklist

  • Developers can run the simulator and reproduce the retry-reduction claim.
  • Agents can discover the protocol through headers, JSON, well-known metadata, and llms.txt.
  • Tickets are signed, scoped, time-bound, bound to a client key, and single-use.
  • Payments are explicitly marked mock until a real x402 adapter verifies settlement.
  • The docs separate implemented behavior from planned behavior so readers do not have to guess.

Read next