Omniousdocs
ArchitectureLive V1

The request path

402, sign, verify, stream, bill. Inference starts optimistically while settlement runs beside it.

HTTP has had a status code for payments since 1997: 402 Payment Required. The x402 protocol finally uses it, and the whole request path is that status code doing its job. No account, no API key, no subscription: a single HTTP exchange carries the query, the price, and the payment.

Beat by beat

  1. POST. The client sends an OpenAI-compatible chat request to /v1/chat/completions. No payment attached yet.
  2. Auction. The router runs the second-score auction against the in-memory quote book in under 1 ms. No round trip to providers, no added latency: the competition already happened, in the standing quotes.
  3. 402. The response is 402 Payment Requiredwith the worst-case cost at the winner's cleared prices: estimated input tokens plus max_tokens of output, at the rates the auction just cleared. This is an upper bound, not the bill.
  4. Sign and retry. The client signs a USDC authorization for that maximum and retries the same request with the x402 v2 PAYMENT-SIGNATURE header. Wallet libraries and the SDK do this automatically.
  5. Verify, then start optimistically. The router verifies the signature and balance in about 100 ms, then dispatches to the winning provider immediately. On-chain settlement on HyperEVM runs concurrently with inference, so chain latency never touches time-to-first-token. Tokens stream back through the metering proxy while the transaction confirms.
  6. Bill actuals. At stream end the router bills the metered token counts at the cleared rates, never the authorized maximum. Overage refunds automatically (above a $0.01 dust floor, via the hourly cron), and the request gets a signed receipt.
one request, six beats

What optimistic start risks, and how it is bounded

Starting inference before settlement confirms means the router briefly fronts the cost of a request whose payment could still fail. That exposure is deliberately small and capped twice: per wallet (a hard limit on unsettled value any one payer can have in flight) and router-wide (a global cap across all wallets). A wallet whose settlement fails is demoted to settle-before-stream until it proves good again. The worst case is a bounded, priced risk, and in exchange the customer never waits on a chain.

warm pathReturning clients skip the 402 round trip entirely: every response carries a short-lived signed price attestation, so the next request can arrive with payment already attached against known pricing.
As a customerThe 402 number is the most you can pay, not what you will pay. You are charged metered actuals, the difference comes back automatically, and the receipt plus /v1/analytics shows exactly how the price was formed.
As a providerBy the time a request reaches you it is funded: signature and balance verified, cleared price locked. You serve tokens; the router carries the settlement risk inside its bad-debt caps, and your payout nets up at the epoch regardless of chain timing.
where this lives in code