x429

HTTP admission control

429 says later.x429 says when.

Signed, single-use admission windows for overloaded APIs. Clients verify the offer, wait or submit one sealed maximum, then redeem once.

Run the reference Read the wire spec

Durable v2 implementation. SQLite Durable Objects enforce finite lanes. Priority can settle through x402 v2 exact USDC; mock remains local-only. Funded-chain proof and independent audit are still launch gates.

Stop turning overload into more load.

Blind retries multiply traffic when capacity is already scarce. x429 gives the client one verifiable time to return.

admission.trace
t+0.0s
Blind retry 1 request

Waiting for a response.

x429 1 request

Requesting one signed return window.

A signed way back in.

An x429 offer is still an ordinary 429. V2 binds each window to a client proof, reserves it durably, and never lets priority or payment bypass capacity.

V2 PROTOCOL TRACE NON-LIVE 
HTTP/2 429 Too Many Requests
retry-after: 47
x429-version: 2
cache-control: no-store

{
  "ticket": "signed future slot · single use",
  "auction": {
    "bid": "one sealed maximum",
    "fundedAtSubmission": false
  },
  "clientPolicy": ["WAIT", "BID ONCE", "EXIT"],
  "settlement": "x402 exact after win",
  "redeem": "X429-Ticket | X429-Award"
}
Static protocol trace. This page sends no protected request and mints no ticket, award, permit, or payment.

The client owns the decision.

One signed offer. Three deterministic outcomes. The client waits, takes an available upgrade, or stops without another blind request.

client.policy(ticket) deadline 60s · signed window +47s
Client action WAIT hold(ticket)

13 seconds remain. Hold the signed ticket.

  • Wait when the signed window opens before the deadline.
  • Upgrade when waiting misses the deadline but an available priority route fits the budget.
  • Exit when neither route fits, without sending another blind retry.

Run the reference.

The protocol, Worker, client, and exact-settlement tests are reproducible implementation evidence. They are not a funded-chain record or independent audit.

100simulated clients
≥80%attempt-reduction target
1×successful nonce spend
0tampered tickets accepted
git clone git@github.com:x429-protocol/x429.git && cd x429 && npm ci && npm run check

Private repository access is required. Runtime-dependent development simulation, not a production benchmark.

Deploy one admission boundary.

V2 runs as a separate Worker in front of a fixed origin. Explicit route mappings share admission state through named finite capacity pools; EIP-3009 payment replay state is global. The upstream verifies a short-lived signed origin assertion.

npm ci
install -d -m 700 .x429/staging-secrets
npm run keys:generate -- x429-staging-2026-07 \
  --secret-output .x429/staging-secrets/issuer.json
npm run keys:generate -- x429-origin-staging-2026-07 --origin \
  --secret-output .x429/staging-secrets/origin.json
npm run check

# copy/review the staging config and import both key files,
# RPC URLs, and distinct operator tokens into one mode-0600 JSON
npm run worker:preflight:staging
npm run worker:bootstrap:staging -- \
  --secrets-file .x429/staging-secrets/bootstrap.json

The v2 Worker, exact payer, origin assertion verifier, and reconciliation command are implemented in this private repository. Key generation writes only to new owner-only POSIX files; import them directly without printing private fields. The first Worker release validates and uploads its complete secret set in one strict, issuance-disabled deployment. On native Windows, use reviewed secret-manager-native tooling or WSL on a private Linux filesystem—not a shared Windows mount—otherwise do not run those writers. Packages remain unpublished and deployment is source-controlled. No funded public-network result or audit is claimed.

Make overload schedulable.

Start with the reference Open the console