x402.

X402PaymentRequired, X402PaymentPayload, X402Facilitator, X402PaymentServer, X402Client implement the full Coinbase spec.

CdpFacilitatorClient covers the Coinbase facilitator verify and settle endpoints. EIP-712 typed data, CAIP-2 chain ids, well-known USDC token addresses.

A challenge pins a scheme in extra.scheme; the verifier dispatches to the matching backend. Each scheme has its own domain-separated preimage so an authorization for one can never be replayed as another.

• exact-eip3009 / permit2 / erc7710 — one-shot fixed amount over the Coinbase facilitator.
• upto — the buyer signs a maximum; the seller serves, then settles the actual amount consumed up to that ceiling.
• batch-settlement — the buyer deposits once into a channel, then signs cumulative off-chain vouchers; the seller settles many vouchers with a single on-chain claim.
• tenzro-hybrid — the default, settled by the local settlement engine with an Ed25519 + ML-DSA-65 hybrid signature.

List what a node has wired with tenzro_listX402Schemes.

An inference or query endpoint rarely knows the price before it runs. With upto the buyer authorizes a ceiling once; the seller meters the real cost while serving and captures only what was used. The authorization preimage is tagged tenzro/x402/upto, distinct from the exact-amount preimage.

For a stream of small charges — per-token billing, per-epoch storage — a channel amortizes on-chain settlement to one transaction. The buyer deposits, then signs a monotonically increasing cumulative voucher per charge. Each voucher commits to the channel id and the running total; the seller redeems the latest one against the deposit at close. Voucher preimages are tagged tenzro/x402/batch-voucher.

A seller advertises a paid resource — its URL, accepted schemes, and price — so buyers find it without prior coordination. tenzro_x402RegisterResource publishes an offer, tenzro_x402DiscoverResources lists what is on offer, and tenzro_x402DeregisterResource withdraws it. Offers are signed; tenzro_x402VerifyOffer checks the signature before a buyer acts on it.

A retried request must not double-charge. tenzro_x402PaymentId derives a deterministic identifier from the offer and authorization so a repeated settlement collapses to the first. tenzro_x402ProtocolInfo reports the schemes, chains, and facilitators a node supports.

When a payment settles in native TNZO, the balance move is a consensus-mediated on-chain transaction, not an entry in a local ledger. The gateway's settlement callback builds a system-key-signed X402Settle typed transaction carrying { payer, payee, amount, payment_id }, admits it to the consensus mempool, and returns the real in-block transaction hash once it lands in a finalized block — the receipt's settlement_tx is that hash.

On dispatch the native VM checks payer ≠ payee, amount > 0, and the payer's on-chain balance before any state change; a persisted per-payment_id replay marker rejects a duplicated callback so balance can never double-move. The debit and credit write through to the same accounts store read by eth_getBalance. Payments in an external-chain asset settle through the facilitator instead and never use this path.

tenzro x402 pay   --resource https://api.example.com/data   --max 0.10