Paying with x402

Wallets, USDC on HyperEVM, gas sponsorship, and why you are charged actuals rather than the authorized max.

HTTP has carried a 402 Payment Required status code since 1997, reserved and never used. x402 is the protocol that finally uses it: a server answers an unpaid request with a 402 that names a price and a payment method, the client signs a payment and retries, and the same request now carries its own money. No account, no card on file, no subscription. On Omnious the payment is the login.

The wire is two requests. Your first POST returns a 402 whose body quotes a signed worst case for your request at the auction winner's cleared rates. Your wallet signs a USDC authorization for that amount and retries with the x402 v2 PAYMENT-SIGNATURE header. The router verifies the signature and balance in about 100 ms and starts streaming your reply.

Wallets: three ways to sign

• Privy embedded wallet. Log in to the web app with email or a social account and an embedded wallet is created for you. You never handle a key.
• External wallet. Any EVM wallet, or in the SDK any { address, signTypedData } signer: a viem account, a KMS shim, a Privy server wallet. Only typed-data signing is ever needed; no transaction is sent from your side and no gas is spent.
• Zero-config burner. The web app generates a throwaway wallet in your browser on first visit, so you can pay before you have decided to trust anything.

USDC only, gas sponsored

Payments settle in USDC on HyperEVM (eip155:999 in production, eip155:998 on testnet). The authorization you sign is gas-sponsored (EIP-3009 exact or Permit2 upto), which means the router's treasury pays the chain fee, not you. The practical consequence: you hold exactly one asset, USDC, and never need to acquire a gas token to use the market.

Authorized max, charged actuals

The 402 quotes an upper bound: your request run all the way to max_tokensat the winner's cleared prices, plus a buffer for the input-token estimate. You authorize up to that max, but the metering proxy counts what actually streamed and you are charged the metered actuals. The difference refunds automatically at epoch close, no claim to file. The full arithmetic, with real numbers, is on What you actually pay.

Optimistic start, bounded exposure

Chain settlement takes longer than you should wait for a first token. So the router starts inference the moment your signature and balance verify, while settlement lands concurrently on HyperEVM. If a payment ultimately fails, that is the router's bad debt, and the exposure is bounded: capped per wallet and capped router-wide, with defaulting wallets demoted to settle-before-serve. Chain latency never touches your time-to-first-token, and the risk of fronting the work is capped by construction.