Wire formats

Signed quotes, x402 payment payloads, receipts, and the ModelChallenge typed data, annotated field by field.

Owner

Developer Experience

Version

api-2026.07

Verified

2026-07-13

Four payloads carry the market's economics. Each one is signed, so each one is evidence: a quote that cannot be repudiated, a payment that cannot be forged, a receipt that cannot be rewritten, and a challenge that cannot be filed anonymously. Field lists below match the shipped schemas.

The signed standing quote

{
  "quote_id":        "q-3f9a1c72",
  "provider_id":     "minimax",
  "model_class":     "minimax-m3",
  "price_in":        210000,      // USDC base units per 1M input tokens ($0.21/M)
  "price_out":       680000,      // per 1M output tokens ($0.68/M)
  "max_context":     131072,      // tokens
  "valid_until":     1752241031,  // unix seconds; TTL capped at 30s

  "capacity_rps":     8,           // signed realtime concurrency ceiling

  // optional session (two-part tariff) fields:
  "price_in_cached": 42000,       // per 1M CACHED input tokens
  "session_ttl_s":   600,         // cache + rate-hold commitment, seconds

  // optional non-launch capabilities (feature-gated on the router):
  "context_protocol": "passport-v1",
  "context_cache_ttl_s": 600,
  "delta_handoff": true,
  "speculative": true,
  "speculative_cancel_ms": 5000,

  "sig": "0x..."                  // EIP-191 by the provider's registered key
}

A quote is a firm commitment, not an indication: valid until its TTL (capped at 30 seconds), up to the stated capacity. The signature covers a pipe-joined string of every economic field in a fixed order; changing that order is a breaking protocol change. The two session fields append to the payload only when present, so a cache-blind quoter's signature is byte-identical to the V1 protocol. A quote carrying them is also a commitment to hold the cache and those rates for session_ttl_s. Context fields use a tagged context-v1 suffix, so they cannot be confused with the positional session extension. speculative:trueis the provider's signed consent to a bounded, zero-customer-byte hedge. These capability fields may be quoted while their router features are dark; they are inert unless enabled in a private validation environment.speculative_cancel_msbounds the attempt until its first usable output event, not the winning generation's total duration.capacity_rps is the signed realtime concurrency ceiling attached to this quote.

Deadline-constrained routing

POST /v1/chat/completions
{
  "model": "auto",
  "messages": [{"role":"user","content":"Run the release checks"}],
  "routing": {
    "task": "coding",
    "min_quality": 0.8,
    "latency_slo": {
      "metric": "first_token",
      "deadline_ms": 1500,
      "confidence": 0.95
    }
  }
}

// model:auto chooses the cheapest feasible class.
// deadline-price/1 then clears the cheapest feasible provider.

A latency SLO is an eligibility constraint, not a guessed exchange rate. The router filters on its decayed empirical TTFT quantile, then minimizes cost inside the feasible class and provider fields. Version one promises first-token latency only; it does not present a throughput mean as a full-completion probability.

The x402 handshake

HTTP/1.1 402 Payment Required
{
  "accepts": [{
    "scheme":            "exact",        // or "upto" (Permit2, settles actuals)
    "network":           "eip155:999",   // HyperEVM mainnet
    "maxAmountRequired": "550",          // worst case, USDC base units (string)
    "payTo":             "0x<treasury>",
    "asset":             "0x<usdc contract on this rail>",
    "maxTimeoutSeconds": 300
  }]
}

// SDK-only protocol shape: Base64(JSON.stringify(this envelope)) becomes
// the PAYMENT-SIGNATURE header after the wallet signs it.
{ "x402Version": 2, "scheme": "exact",
  "network": "eip155:999", "payload": {
  "authorization": {
    "from":        "0x<payer>",
    "to":          "0x<treasury>",
    "value":       "550",          // exact: the signed amount settles
    "validAfter":  "1752240971",   // unix seconds
    "validBefore": "1752241331",
    "nonce":       "0x<random 32 bytes>"
  },
  "signature": "0x..."             // EIP-712 TransferWithAuthorization (EIP-3009)
}}

The accepts array is what makes the router chain-agnostic: each enabled settlement adapter contributes one entry and the client picks the rail it can pay on. Two schemes ride HyperEVM. exact is EIP-3009 transferWithAuthorization: the customer signs the exact worst case, the router submits and pays the gas, and any overage refunds at epoch close. upto rides Permit2: the customer signs a maximum and the router settles the metered actual at stream end, so charged equals settled by construction. In both cases the customer only ever signs typed data and never holds the gas token.

Which scheme settles where

Both schemes verify on every rail, but each paid surface settles one lifecycle and rejects the other before any money state moves. Signing the wrong scheme costs nothing: the rejection is another 402 with accepts included, so a client just re-signs.

• Per-turn completions (chat, Anthropic messages, responses): either scheme. upto is the pay-for-use path; the metered actual settles at stream end.
• Session budgets and top-up tranches: exact only. A budget is already an authorize-max, draw-actuals mechanism, so funding one with upto would nest two deferred settlements.
• Embeddings and image generation: exact only, priced up front.

Signing windows

Validity is checked against the router's clock at verify, with 5 seconds of skew allowance. For exact, validAfter must have passed and validBefore must leave at least 120 seconds of broadcast runway and lie within 7 days. For upto, the Permit2 deadline must survive the whole stream plus the on-chain settle: at least 30 minutes ahead, at most 2 hours. The SDK signs 60 minutes.

402 response codes

Beyond error text, a 402 body may carry a machine-readable code, and sometimes a hint with the recommended next step:

The adjacent 409 session_used (a session bound to another concurrent request) is handled the same way by the SDK: rotate and retry.

The prepaid credit request

POST /v1/chat/completions
content-type: application/json
x-credit-key: vk_...                 // spend-capable, server-side key
idempotency-key: agent-req-123

{ "model": "auto", "messages": [{"role":"user","content":"hello"}] }

// reserve worst case → stream → capture actuals → release remainder

A spend-capable credit key authorizes a draw from a wallet's unified API balance. The reservation, metering, capture, and release happen in the request lifecycle; no per-request wallet signature or 402 retry is needed. Ordinary API keys are attribution-only and cannot spend prepaid credits.

The Context Passport request

POST /v1/chat/completions
x-credit-key: vk_...
x-context-token: ct_...       // omitted only when creating
{
  "model": "best",
  "messages": [{"role":"user","content":"Continue the implementation"}],
  "context": {
    "passport_id": "ctx_...", // or {"save":true} on turn one
    "mode": "delta",
    "expected_version": 4,
    "handoff": {
      "facts": ["The app is static HTML"],
      "decisions": ["Use embedded data with graceful empty states"],
      "open_questions": ["Which live feed should production use?"],
      "tool_state": {"files":["index.html"]}
    }
  },
  "routing": {"speculative":{"candidates":2,"hedge_after_ms":250}}
}

The raw context token is stored by the client and sent only to the router. The router persists its hash, strips the contextextension before provider dispatch, and returns the token only on creation. Every successful turn becomes an append-only delta with its parent version, provider, model class, input, and normalized assistant output. Inspect or delete the passport with GET/DELETE /v1/context/passports/:idplus the same token. The response's x-context-version is the reserved version for that successful turn; echo it as expected_version to reject stale writers. A second concurrent write receives 409 context_busy before it is paid or served.

The usage receipt

GET /v1/receipts/:request_id
{
  "request_id":       "3d1c...",
  "wallet":           "0x<payer>",
  "provider_id":      "minimax",
  "model_class":      "minimax-m3",
  "in_tokens":        1043,        // metered by the router's proxy, not claimed
  "out_tokens":       512,
  "cached_tokens":    0,           // session turns: prefix billed at cached rate
  "price_in":         230000,      // CLEARED prices (second-score), base units/1M
  "price_out":        710000,
  "price_in_cached":  null,
  "charged":          603,         // metered actuals, USDC base units
  "authorized":       750,         // the signed max; overage refunds
  "payment_ref":      "0x<tx>",    // settlement reference
  "refund_ref":       null,
  "ttft_ms":          412,         // router-measured time to first token
  "status":           "ok",
  "settlement":       "landed",
  "epoch_id":         472119,      // this epoch's hash anchors on-chain
  "session_id":       null,
  "quotes_competing": 4,
  "created_at":       1752241034123
}

This row is the atom of settlement: billing, payouts, refunds, analytics, and points all derive from it. Note what is absent: no prompt, no reply. Ordinary requests keep receipts, not transcripts; transcript storage occurs only when the caller explicitly creates or continues a Context Passport. Each hour's records hash into an epoch anchor on-chain, so the row you fetch today is provably the row that settled.

The ModelChallenge typed data

{
  "domain": { "name": "Omnious Model Integrity", "version": "1" },
  "primaryType": "ModelChallenge",
  "types": {
    "ModelChallenge": [
      { "name": "purpose",      "type": "string"  },
      { "name": "wallet",       "type": "address" },
      { "name": "receiptId",    "type": "string"  },
      { "name": "evidenceHash", "type": "bytes32" }
    ]
  },
  "message": {
    "purpose":      "Open an Omnious model integrity challenge",
    "wallet":       "0x<approved challenger>",
    "receiptId":    "<the challenged request id>",
    "evidenceHash": "0x<sha256 over { receipt_id, summary, details }>"
  }
}

Filing a challenge means signing this over the receipt you dispute. The evidenceHash binds the signature to the exact evidence submitted, and the human-readable purpose line is what a wallet displays before you sign. Price the stake first with GET /v1/model-integrity/challenges/quote; the flow is described in Becoming a challenger.