Whitepaper | Qoura

Summary

AI workloads increasingly purchase their own inputs: tokens, images, lookups and, soon, runtime. Software can custody a stablecoin far more easily than it can obtain a bank card, but stablecoin transfers are permanent public records. Paying for compute that way publishes a running diary of what a project does and who funds it.

Qoura separates the two halves. Paying for a credit happens openly on Robinhood Chain. Spending it happens through an API key that was topped up by a zero-knowledge proof, and that proof establishes only that its holder owns some unspent credit of a stated face value. The seller collects, the caller is served, and no public record joins them.

Why this exists

Three trends meet here.

Autonomous spending. A single agent run can involve hundreds of paid calls worth fractions of a cent. No human signs off on each.
Identity-first billing. Conventional AI APIs bill an account tied to a person or company. An agent uses its operator's, so its whole activity is filed under that operator.
Readable ledgers. Spend patterns reveal strategy: which models, how often, how much. A transparent chain keeps that pattern open to competitors and observers indefinitely.

Paying with stablecoins removes the account and the card. It also makes the third problem sharper. Unlinking payment from use is the piece that closes the gap.

Design goals

Accountless	Paying requires a wallet; spending requires a key. There is no sign-up, email or profile anywhere.
Scriptable	Buying, proving, redeeming and calling are all plain HTTP requests or contract calls.
Unlinkable	Neither the operator nor a chain analyst can match a key to the transfer that financed it.
Non-custodial	The desk contract forwards USDG to the treasury inside the purchase transaction and never sits on a balance.
Integer money	All amounts are counted in USDG base units (6 decimals); discounts round up by at most one unit, never in floating point.
Honest copy	Every limitation below is also stated on the pages where it matters.

The catalogue

Listings are grouped by job: Reason (language models, metered per token), Render (image generation, metered per call), Look up (search-grounded answers today; raw results and page extraction later) and Execute (sandboxes and GPU time, on the roadmap).

One credit pays for any listing. Deliberately so: if credits were item-specific, the item would shrink the set of possible owners. As built, a redeem blends in with every purchase of the same face value regardless of later use. Third-party model suppliers serve the listings; displayed prices are their rates multiplied by a single factor of 1.20.

Credits are a Qoura product: usable only on this gateway, with no refund and no transfer.

Anatomy of a credit

Secrets	`nullifier` and `secret`, two field elements drawn from 31 random bytes each on the purchaser's machine. Holding them is owning the credit.
Commitment	`Poseidon(nullifier, secret)`. Published with the payment; a hiding, binding fingerprint of the secrets.
Leaf	`Poseidon(commitment, face)`. Computed by the contract from the amount it actually received, so face value is never self-reported.
Tree	Incremental Poseidon Merkle tree, 20 levels, around 1.05 million slots, stored on chain together with its 100 latest roots.
Spend tag	`Poseidon(nullifier)`. Deterministic per credit, which blocks double redemption, yet unrelated to any leaf since the nullifier itself is never published.

Paying

Paying is deliberately unremarkable: a token transfer that anyone can observe.

The browser generates the secrets, stores them locally, and derives the commitment.
The purchaser signs a USDG ReceiveWithAuthorization (EIP-3009) for the desk's exact quote. The signed nonce is keccak256(desk, commitment, face); replaying the signature with a different commitment fails.
A relayer submits buyWithAuthorization, covering gas. The contract collects the USDG, passes it to the treasury, and inserts the leaf, all in one transaction. A fallback path lets the purchaser approve and call buy themselves.

Preset face values (1, 2, 5, 10 and 25 dollars) concentrate buyers. Any integer up to 1,000 is accepted, with the caveat in what stays visible.

Redeeming

Redemption converts a credit into key balance. Nothing in the request identifies a wallet, a session or a device.

The purchaser creates a key locally (qk- plus 48 hex characters). The server later receives only sha256(key) >> 8 during redemption.
The browser fetches the full leaf list, recomputes the root, and halts unless the contract confirms that root. Requesting a single Merkle path would reveal the leaf, so it never does.
A Noir circuit, proven with UltraHonk over BN254, exposes four public inputs: root, face value, spend tag and key binding. Private inputs are the two secrets and the Merkle path. Browser proving takes roughly two seconds.
The server asks the desk contract, through a read-only call, to confirm the root and verify the proof, then stores the spend tag permanently and credits the binding embedded in the proof. Intercepting a proof is useless: it only pays the original key.

The gateway

Requests follow the OpenAI schema, so the only client change is the base URL and key. Before forwarding, the gateway reserves the maximum the request could cost in a single atomic decrement; after the response it bills the supplier's reported cost times the markup and releases the remainder. Supplier failures bill nothing. The ledger keeps item, token counts and amount per call. Request and response bodies are never persisted.

Who sees what

Zero knowledge covers exactly one relationship, payment to key. The table lists the rest.

	Chain observers	Qoura	Model supplier
Payer address, amount, block time	Visible	Visible	Hidden
Link between a payment and a key	Hidden	Hidden; it learns only the face value	Hidden
API key	Hidden	A 248-bit binding when topping up; the key on each request	Hidden
Request and response content	Hidden	Relayed in memory, never written to storage	Visible, since it runs the model
Item, token counts, charge	Hidden	Visible per key	Visible for its own calls
Network address of the caller	Hidden	Seen by the hosting edge like any website; kept out of the ledger	Hidden

Live tree

Pulled from the contract. Face value is a public input, so each value forms a separate anonymity set.

Reading the desk…

What stays visible

Payments. Address, amount and timestamp of every purchase are on chain.
Thin sets. A face value bought once has an anonymity set of one. Presets exist to avoid that.
Correlated timing. Purchase followed quickly by redemption invites a match, whatever the set size.
IP correlation. Paying and redeeming over one connection ties them together off chain.
Key reuse. All traffic on one key shares a pseudonym. Unrelated workloads deserve separate keys.
Supplier view. The supplier processes request content but receives it from Qoura, without key, wallet or origin address.

Best practice: choose a preset, let the set grow before redeeming, redeem over a different connection, and give each workload its own key.

Trust assumptions

Unlinkability rests on cryptography. Root checking and key binding happen client-side against the contract; operator misbehaviour cannot break them.
Soundness rests on a public setup. UltraHonk relies on a universal reference string from a large multi-party ceremony rather than one produced by this team; one honest participant suffices.
Gateway discretion is a promise. Traffic transits Qoura. The software keeps only metering data, which outsiders cannot independently verify.
Suppliers see content. They are trusted with request bodies and with nothing that identifies callers. Serving inside hardware enclaves is planned, not shipped.
You keep your secrets. Lost backups or keys mean lost balance; there is no recovery path.

Status: contract and circuit are tested and published, but no external audit has been completed.

Agents

Every step above is machine-executable, so a bot holding USDG can run the whole cycle unattended. The agents page covers integration and the controls an operator retains.

Roadmap

Agent tooling: an SDK and an MCP server that purchase, wait for a healthy anonymity set, prove and redeem automatically.
Separate meters for search results and page extraction, then code sandboxes and GPU time.
Multiple suppliers per listing with price and latency competition.
Enclave-backed serving where suppliers offer it.
Shielded payment for the purchase step once the chain supports it.