Priority economics

Payments

x429 does not settle money. It defines what is being bought: earlier admission. The payment rail is an adapter.

Current state

Implemented

Mock paid priority

Signed mock receipts prove the scheduling path without involving money.

Planned

x402 adapter

Real priority should settle over x402 once ticket mechanics are stable.

Later

Auctions

Batch auctions are out of v1. Fixed-price upgrade classes are enough for mechanism proof.

Upgrade offer

{
  "class": "immediate",
  "notBeforeMs": 500,
  "price": { "amount": "0.004", "asset": "USDC", "rail": "mock" }
}

An agent should choose an upgrade only when the free slot misses its deadline and the price fits its budget.

Mock receipt

The mock adapter signs a receipt bound to the ticket and upgrade class. This is not money; it is a testing tool.

{
  "receipt": {
    "id": "pay_...",
    "payer": "agent",
    "ticketId": "tkt_...",
    "class": "immediate",
    "amount": "0.004",
    "asset": "USDC",
    "rail": "mock",
    "issuedAt": "2026-07-07T14:03:47Z"
  },
  "sig": "ed25519:..."
}

Real x402 requirements

The x402 adapter must verify that payment and admission are bound tightly enough that neither side can cheat.

  • Bind payment to ticket.id.
  • Bind payment to issuer, resource, and upgrade class.
  • Verify amount, asset, network, and recipient.
  • Do not admit early if settlement or facilitator verification fails.
  • Do not charge if there is no valid admission path.
  • Log payment verification failures separately from ticket verification failures.

x402 bridge design

The adapter should be thin. x429 decides whether priority admission is available; x402 proves that the buyer paid for that exact priority class.

x429 objectx402/payment object must prove
ticket.idThe payment is for this specific admission offer.
issuerThe payment recipient is the API owner or configured facilitator destination.
resourceThe payment cannot be replayed against another endpoint or capacity pool.
classThe buyer paid for the selected priority lane, not just any request.
priceAmount, asset, network, and recipient match the server offer.
nonceThe admission ticket is still spent exactly once, even when payment succeeds.

The important product decision is this: payment buys earlier admission, not unlimited access. A paid proof should never bypass signature checks, resource scope, or replay protection.

Why mock first?

Paid priority has two hard parts: scheduling correctness and payment correctness. Mocking payments lets the project prove the scheduling mechanism first: tickets, windows, priority class behavior, and replay protection. Then the adapter can replace mock proof with x402 proof without redesigning the rest of the protocol.

Read next