Wuraw
Open App

Whitepaper · v1.2

Routing inference without an account

A single OpenAI-compatible endpoint across a redundant provider set, with settlement moved out of the billing relationship and into the request itself.

Revised 1 August 20267 sections · 15 referencesIncludes a limitations section

Abstract

Model inference is sold through accounts. An account is the attachment point for geographic restriction, identity verification, prepaid float and a per-vendor rate card, and it is the reason a two-provider redundancy strategy costs twice the operational surface rather than the same one. We describe a router that presents one OpenAI-compatible endpoint over 400+ models across 3 upstream tiers, and that replaces the account with a per-request payment carried inside the HTTP exchange using the x402 standard and an EIP-3009 transfer authorization settled in USDG on Robinhood Chain. The design removes custodial float, makes per-agent spend limits enforceable at the signer rather than at the counterparty, and produces an audit trail as a side effect of settlement. We state the security assumptions explicitly and devote §6 to what this architecture does not fix, including the fact that the router remains a trusted intermediary for routing even where payment is trustless.

1

The problem

Three failures recur in production LLM integrations, and they share a root cause.

1.1 · Availability

Model providers operate at roughly 99 to 99.5 percent availability, six to fourteen times worse than the cloud infrastructure they run on [1]. A single-provider integration inherits that number directly: at 99.53 percent, expected downtime is about 41 hours a year. Two independent providers with automatic failover reach better than 99.99 percent combined — about 12 minutes a year [1]. The three orders of magnitude are not an optimization. They are the difference between an availability target you can commit to and one you cannot.

Redundancy is therefore not optional, and yet it is rarely implemented, because the cost is not the failover logic. It is the second account, the second key, the second rate-limit tier, the second rate card and the second set of quirks in the request dialect.

1.2 · Access

Major providers enforce geographic restrictions at the API level using IP geolocation, payment-country mismatch signals and abuse heuristics, and offering access from an unsupported territory is grounds for suspension [14]. Verification steps — phone, identity, payment instrument — gate use cases but do not convert an unsupported region into a permitted one. Resold access through a cloud marketplace is frequently more restrictive than the origin provider, not less. None of this is an inference constraint. It is an account constraint.

1.3 · Capital and control

Incumbent routers monetize a markup on prepaid credits [11]. The resulting float is the customer’s capital held by the intermediary, non-transferable to any other vendor, and exposed to custodial failure. It is also the wrong primitive for autonomous software: an agent cannot open an account, so it inherits a shared key against a shared pool, and a non-terminating loop is bounded only by the balance. Spend controls exist as vendor-side policy, which means they fire after the request is sent and are enforced by the party being paid.

2

Architecture

The router is four components behind one endpoint. Nothing about the request shape is novel — that is deliberate, because the migration cost of a router that requires a new dialect exceeds what it saves.

  client / agent
        │  POST /v1/chat/completions        (no key, no account)
        ▼
  ┌───────────────┐
  │   INGRESS     │  validate · normalize to the common dialect
  └──────┬────────┘
         ▼
  ┌───────────────┐   catalog: model × provider matrix
  │   RESOLVER    │   alias → concrete model (pinned or live)
  └──────┬────────┘
         ▼
  ┌───────────────┐   policy: cost | latency | quality
  │    ROUTER     │   health: observed error rate + TTFT band
  └──────┬────────┘
         │  402 Payment Required  ──────────►  wallet signs EIP-3009
         │  ◄────────────────────────────────  signed authorization
         ▼
  ┌───────────────┐   facilitator verifies off-chain (1 round trip)
  │  SETTLEMENT   │   facilitator submits transfer, returns tx hash
  └──────┬────────┘
         ▼
  ┌───────────────┐   Dolphin · Surplus · AntSeed
  │   UPSTREAMS   │   fallback walks the ordered candidate list
  └──────┬────────┘
         ▼
     SSE stream  +  { routing, settlement }
Fig. 1 — request path, metered tier

2.1 · Resolver

The catalog is a model-by-provider matrix: for each model, every upstream that can serve it, with context window, price, observed latency band and current health. The resolver maps the requested identifier — a vendor SKU or an alias in the wuraw/ namespace — to a concrete model and a candidate list. Aliases may be pinned to a date, freezing resolution so that outputs remain reproducible at the cost of following the catalog forward.

2.2 · Router

Selection is a policy applied to the candidate list, filtered by health. Health is measured, not declared: a rolling error rate and TTFT distribution per provider and region, de-weighting a degraded upstream within seconds and probing it back gradually. Only idempotent failures walk the fallback list; a client-side 4xx is returned unchanged rather than replayed at the payer’s expense.

2.3 · Tiers

Dolphin serves open-weight models free and rate-limited, and never touches the settlement path — which makes it the degraded-mode surface when settlement is unavailable. Surplus and AntSeed serve the metered catalog over independent capacity, so failover between them is failover between distinct operational failure domains rather than between two regions of one provider.

2.4 · What the router does not hold

No balances, no keys belonging to the payer, and no conversation history. Prompt and completion bodies transit the router and are not retained beyond the request, and nothing about their content is written onchain. The router’s durable state is the catalog, the health table and the settlement references — none of which describe what anyone asked a model.

3

Settlement

Payment is carried inside the request cycle rather than beside it. A metered route answers an unpaid request with 402 and a machine-readable quote: scheme, network, asset, exact amount, payee and a validity window [2]. The client signs an EIP-3009 transferWithAuthorization message committing to that exact amount [4] and repeats the request with the signed payload in the payment header.

We do not name that header anywhere in our documentation. The community specification and current vendor documentation disagree on it, and the divergence appears to be a version boundary rather than an error [2]. Clients should read the header name from the challenge and code against the authorization payload, which is stable across both.

3.1 · Facilitator

A facilitator verifies the signature off-chain and submits the transfer, paying gas itself and returning a transaction hash [2]. The payer therefore never holds gas, never manages a nonce and never broadcasts anything. We treat facilitators as a redundant set rather than a fixed integration and record which one handled each transfer, because facilitator liveness sits directly in the critical path (§6.2).

3.2 · Asset and chain

USDG, the Global Dollar, is issued by Paxos and redeemable one for one against US dollars, with the issuing entity supervised as a Major Payments Institution in Singapore and separately regulated in the EU [7]. It is the first natively issued stablecoin on Robinhood Chain and that chain’s primary settlement asset [6][8].

Robinhood Chain is an Arbitrum Orbit rollup operating as an Ethereum L2 that settles directly to Ethereum, with blob data availability [5], chain ID 4663, a base fee near 0.05 gwei, and configurable block times with preconfirmations giving roughly 100 ms on the payment path [6]. Gas is paid in ETH and there is no native chain token, so a payer funds one asset and monitors one balance.

3.3 · Post-settlement failure

If an upstream fails after settlement has landed, the transfer cannot be reversed. The router issues a credit note against the payer address, redeemable on a subsequent request. This is a real asymmetry and we state it rather than describing it as a refund.

4

Economics

Inference-as-a-service is a $23.4 billion market in 2026, forecast at $197.5 billion by 2035; the broader AI inference market, which includes on-premise hardware and edge silicon, reaches $117.8 billion in 2026 [15]. The routing layer within it has no credible standalone sizing, and we decline to invent one. The observable proxy is that a single incumbent gateway at roughly a 5 percent take rate and about $50 million annualized revenue implies on the order of $1 billion of inference spend passing through one router [10][11].

4.1 · Where the fee sits

A metered request is quoted as upstream cost plus a routing fee, and the quote is the price — there is no separate invoice, no minimum and no monthly floor. Because the fee is expressed per request rather than as a markup on a balance, a caller can compare it against a direct integration on a per-call basis instead of against an amortized credit purchase.

4.2 · Float is not revenue here

The incumbent model earns on the spread and on the float: capital rests with the intermediary between top-up and consumption [11]. Per-request settlement forgoes that entirely. This is a smaller business per unit of volume and a materially simpler one — no deposit liability, no reconciliation of unspent balances, no jurisdictional question about what a stored balance is.

4.3 · Cost of settlement

Each metered call carries a facilitator fee and gas on a low-fee L2 [2][6]. At per-request prices measured in cents this is a small but non-zero share of the transaction, and it sets a practical floor below which per-request settlement stops being sensible. For very high-frequency, low-value calls, batching an authorization across a window is the correct engineering answer, and we say so rather than claiming per-request settlement dominates everywhere.

5

Security model

The properties below are what the design actually guarantees. Anything not listed here should be assumed not to hold.

5.1 · What the payer proves

A signature over an authorization commits to a specific sender, recipient, amount, validity window and nonce [4]. The router learns an address and an amount. It does not learn, and cannot require, an identity, a jurisdiction or an instrument. A replayed authorization fails on the nonce; an expired one fails on the window.

5.2 · Spend bounds are payer-side

A per-agent cap is enforced before signing. An over-budget request is never signed and therefore never sent, so the bound does not depend on the router cooperating. This is strictly stronger than vendor-side policy, which fires after transmission and is enforced by the party receiving the money.

5.3 · Trust boundaries

Three parties can affect a request: the router (routing correctness and prompt confidentiality in transit), the facilitator (verification and submission liveness), and the upstream provider (the completion itself and whatever its own retention policy is). Payment integrity depends on none of them — it depends on the signature and the chain. Everything else does.

5.4 · Key handling

Signers are held by the caller and never transmitted. We recommend one signer per agent, funded with the period’s budget, rotated per period both to bound loss and to limit the linkability described in §6.4.

6

Limitations

This section exists because a paper without one is marketing. Every item below is a property of the design, not a roadmap item that will quietly close.

6.1 · The router is a trusted intermediary

Payment is trustless. Routing is not. The router chooses which provider serves a request, and a caller cannot independently verify from the response that the choice honoured the stated policy — that the cheapest healthy provider really was cheapest, or that the quality policy really preferred a first-party endpoint. We publish the decision on every response and the health data behind it, which makes dishonesty detectable in aggregate over time. It does not make it impossible. A caller who needs a cryptographic guarantee of routing behaviour does not get one here, and should say so in their own threat model.

6.2 · Facilitator liveness is a hard dependency

Verification sits in the critical path of a metered request. If the facilitator set is unavailable, metered calls fail — not silently, but they fail. A redundant set reduces the probability and does not remove the dependency, and the free tier remains the only path that is unaffected by definition. The same applies one layer down: the settlement chain’s sequencer is centralized and operated by a single party, which is normal for a young rollup and is still a liveness assumption [6].

6.3 · Upstream terms of service still apply

Routing does not launder a provider’s terms. Where an upstream restricts use by territory, by use case, or by content policy, those restrictions attach to traffic the router sends to that upstream, and the router complies with them. What changes is that the restriction is scoped to one candidate provider rather than to the caller’s ability to use the catalog at all — a request that one upstream will not serve may route to another that will, and if none will, it fails. We are describing a different distribution of the constraint, not its absence, and any claim that a router removes provider policy would be false.

6.4 · Settlement is public and permanent

Amount, timestamp, payer address, payee and resource identifier are onchain forever. Prompts and completions are not, and no content is written to the chain. But the spend pattern of an address — cadence, magnitude, silence — is readable by anyone, and repeated use of one signer makes a workload profile linkable across its whole history. Rotation mitigates this. Nothing removes it, and no record can be deleted on request, by us or by anyone.

6.5 · Wallet adoption and regulatory variance

Every payer needs a wallet and a funded stablecoin balance. For an agent this is nearly free; for a human developer accustomed to a card it is real friction, and it is the single most cited criticism of the payment standard. Regulatory treatment of per-request stablecoin settlement also varies by jurisdiction and is still moving. We take the view that a supervised issuer [7] is the strongest available answer, and acknowledge that it is not a complete one.

6.6 · Routing does not make migration free

Aliases decouple a model retirement deadline from a deploy. They do not re-tune your prompts, re-baseline your evaluation suite, or restore a prompt cache whose prefix keys just changed [12]. The claim is narrow and we intend to keep it narrow.

7

References

Sources are dated because this subject moves. Where two sources disagree — model pricing, adoption counts, network rankings — the disagreement is noted at the point of use rather than resolved silently in our favour.

  1. [01]Tian Pan. “LLM API Resilience in Production.” tianpan.co, 11 March 2026. — provider uptime bands and the two-provider failover arithmetic.
  2. [02]Coinbase Developer Platform. “x402: Welcome.” docs.cdp.coinbase.com — protocol overview, facilitator role, supported assets and networks.
  3. [03]Linux Foundation. “Linux Foundation is launching the x402 Foundation.” 2 April 2026, and PRNewswire, “Operational launch of the x402 Foundation,” 14 July 2026.
  4. [04]EIP-3009: Transfer With Authorization. Ethereum Improvement Proposals — the gasless signed-transfer primitive the payment path depends on.
  5. [05]EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals — the blob data-availability mechanism used by the settlement rollup.
  6. [06]Arbitrum. “Robinhood Chain mainnet.” blog.arbitrum.io, July 2026 — Orbit stack, L2 positioning, preconfirmation latency, launch-and-migrate model.
  7. [07]Paxos. “Paxos introduces Global Dollar (USDG)” and “USDG and the Global Dollar Network.” paxos.com — issuance, redemption and the reserve-return model.
  8. [08]Real-world-asset data tracker, Networks leaderboard, reported via CryptoTimes, 27 July 2026 — distribution-ratio and holder metrics. Note: a ranking on distribution, not on absolute tokenized value.
  9. [09]tftc.io. “x402 Foundation operational launch and AI agent payments,” April 2026 — cumulative settled transaction count and volume figures.
  10. [10]Businesswire, 26 May 2026, and TechCrunch, 26 May 2026 — incumbent gateway scale: model count, weekly token volume, funding and valuation.
  11. [11]Sacra. “OpenRouter.” sacra.com — take-rate and prepaid-credit business model of the incumbent router.
  12. [12]customgpt.ai. “How to avoid LLM vendor lock-in,” 2026 — migration cost inventory and the model-retirement failure mode.
  13. [13]groovyweb.co. “LLM integration: rate limiting, caching, fallbacks,” 2026 — undocumented provider-side rate-limit changes and retry-storm behaviour.
  14. [14]OpenAI Help Center, “ChatGPT and API services in unsupported countries and territories,” and the supported-countries reference — the geographic-gate baseline.
  15. [15]Precedence Research, “AI inference-as-a-service market,” and Fortune Business Insights, “AI inference market,” 13 July 2026 — market sizing used in §4.

Next.

Wuraw whitepaper · version 1.2 · revised 1 August 2026 · chain id 4663