Skip to main content
Wallet-native settlement lets a wallet act as the primary credential against the gateway and pay per request through x402. This is the path that agents and on-chain principals use when they do not have, or do not want, a traditional API-key-and-credit-card relationship. This page describes authentication via SIWE and SIWS, per-request payment via x402, and the supported chains and assets.

​
Authentication: SIWE and SIWS

A wallet authenticates to the gateway through Sign-In with Ethereum (SIWE) or Sign-In with Solana (SIWS). The wallet signs a structured message proving it controls a specific address; the gateway verifies the signature and issues a session credential that subsequent requests carry. SIWE binding authenticates the wallet but does not, by itself, grant Z-internal debit privileges. Debit eligibility requires a first qualifying on-chain x402 payment from the wallet. The linking moves the wallet through three states (Unlinked, Pending, Durable), and only the Durable state can debit pre-funded balances. This is intentional: it prevents a freshly signed-in wallet from drawing on credits that were granted to a different principal.

​
Per-request payment: x402

x402 is a protocol for in-band payment over HTTP. A request that requires payment receives a 402 Payment Required response carrying the payment requirements. The client constructs a payment proof against the requirements (for x402 this is a signed on-chain authorization) and retries the request with the proof in a header. The gateway verifies the proof on-chain, debits the proof’s value, and serves the response. The flow is per-request: there is no pre-funded balance to manage at the wallet level (though pre-funding is supported as an optimization). The practical effect: an agent operating on its own wallet can issue an inference request, receive a 402, construct a USDC payment authorization against the requirement, and retry. The total cost is settled at the moment of the request. A note on concurrency: concurrent requests from the same wallet are each challenged at the full rate until prior settlement writes complete. The gateway does not optimistically aggregate concurrent in-flight payments; each request must clear settlement independently.

​
Supported chains and assets

X402 is supported on:
  • Base. USDC. 2-block soft finality with reorg handling.
  • Solana. USDC. Finalized commitment.
USDC is the supported settlement asset. Native ETH and SOL settlement are tracked on the roadmap. X402 on the Z ledger is also on the roadmap.

​
Per-request cap

A per-request cap protects against accidental large payments. The cap is a gateway-policy invariant ($0.50 by default); raising the cap requires explicit configuration in the wallet’s spend policy through the dashboard.

​
Settlement timing

Settlement happens per request. On Base, the gateway uses 2-block soft finality with reorg-credit reversal in the event of a reorg within the reversal window. On Solana, the gateway waits for finalized commitment before allowing the request to proceed. The latency cost of finality is small compared to the inference latency itself. The credit pool reflects the settlement: a successful x402 payment adds credits; the inference request debits them. Zero Completion Insurance applies: if the inference fails, the credits remain in the pool, available for the next request or for withdrawal back to the wallet.

​
Refunds and reorgs

Reorgs on Base within the reversal window are handled by reversing the credit and surfacing a notice to the wallet; the wallet can retry. Reorgs outside the reversal window do not roll back inference that has already been served; the credit pool reflects what was settled at the point of the reorg. Overpayments (payments that exceed the cost of the request) are credited to the wallet’s balance in the pool, not refunded to the originating chain. This is the standard x402 behavior and applies uniformly.

​
Anomaly detection

Per-key and account-level request patterns are monitored for anomalies. Token consumption patterns inconsistent with declared parameters trigger token-pilfering detection; abnormal request rates trigger anomaly isolation. These controls run independently of the node-retry budget. A request being held for anomaly review does not consume retry capacity.