Snarket Whitepaper

Abstract

Intelligence is becoming something that buys. An AI agent at work needs models to think with, tools to make things, a way to look things up and somewhere to run code, and it increasingly gets them by itself. It cannot open an account or hold a card. It can hold stablecoins.

Snarket is a marketplace built for that buyer. Payment is a stablecoin transfer on a public chain. What is bought is used through an API key that was never attached to the wallet that paid: between the two stands a zero-knowledge proof that a credit was bought, which does not say which one. The seller is paid, the buyer is served, and nothing public connects the two.

This paper describes the system as it runs today, including the parts that are not private.

The thesis

Three things are true at once.

Agents are becoming buyers. A working agent makes thousands of small purchases: a model call, a search, an image, a few seconds of compute. Each is too small and too frequent for a person to approve.
The existing rails were built for people. An account needs an email, a card and often an identity check. An agent has none of them, so today it borrows its operator's, and every purchase is made in the operator's name.
What you buy says what you are building. Which models a team calls, what it searches for and how much compute it rents are a map of its work. On a public chain that map is open to anyone, forever.

Stablecoins solve the first two: an agent can hold and spend them with no account. They make the third worse, because every payment is public. Snarket is the missing piece: a market where an agent can pay with what it holds, by itself, without publishing what it bought or who it is working for.

Design goals

No accounts. Nothing to sign up for. A wallet pays; a key spends. Neither is a login.
Buyable by a program. Every step is an HTTP call a machine can make. No step needs a browser or a person.
Unlinkable use. The key that spends must not be traceable to the payment that funded it, by Snarket or by anyone reading the chain.
No custody on the request path. The service that takes payments holds no private key. Money moves from the buyer straight to the treasury.
Exact money. Prices and charges are whole numbers of a stablecoin's smallest unit, rounded up, never floating point.
Claims backed by the system. Where something is not private, this paper and the site say so.

What is sold

The marketplace is organised by what an AI needs to do its work.

Think: models: Inference on open models, charged per token. Each runs inside a hardware enclave on a confidential GPU.
Create: media: Image generation, charged per image. Speech and video are planned.
Know: search and data: Web search, reading a page as text, and short answers with sources, charged per call.
Run: compute: A fresh Linux machine that runs a program and returns its output, charged per second. GPU jobs are planned.

Everything is bought with one thing, a credit, and used with one thing, an API key. A credit is not tied to an item: a dollar of credit can be spent on any of them. That is a privacy decision as much as a convenience. The crowd a buyer hides in is everyone who bought the same amount, whatever they went on to use it for.

Credits are issued by Snarket and redeemable only on Snarket. They are not balances with any model developer, and they are not refundable or transferable.

The credit

A credit is two random numbers that the buyer makes and keeps. Snarket never receives them.

The creditnullifier, secret: Two random numbers of 31 bytes each, made on the buyer's device. Whoever holds them can redeem the credit, which is why Snarket cannot recover one that is lost.
The commitmentPoseidon(nullifier, secret): A one-way hash of the two numbers. It travels with the payment and commits the buyer to the credit without revealing it.
The treeleaf = Poseidon(commitment, amount): A public, append-only Merkle tree of every credit ever bought, 20 levels deep, so it holds about a million. Snarket writes the amount into the leaf from what it was actually paid, so a credit can never claim more than it cost. Anyone can download every leaf and rebuild the root.
The spend tagPoseidon(nullifier): The same for every proof of one credit, so a second redeem is refused. It is computed from the nullifier alone, which appears nowhere in the tree, so it cannot be matched to a leaf.

Buying

A purchase is an ordinary payment, and it is public.

The buyer asks to buy a credit of some amount and sends the commitment. The server answers 402 Payment Required with its terms, following the x402 standard: the token, the chain, the amount and the treasury's address.
The buyer signs one EIP-3009 authorization for exactly that amount of USDG on Robinhood Chain. Signing costs no gas.
The server checks that what was signed matches its own terms, then hands it to a facilitator, which verifies it, broadcasts the transfer and pays the gas. The token moves from the buyer straight to the treasury. The server holds no key at any point.
Only after the transfer has settled does the server add the credit's leaf to the tree. A signed payment is accepted once: its nonce is recorded, and the chain refuses it a second time.

Credits are offered in a few fixed amounts, from one dollar. A buyer may also choose another whole-dollar amount, at a cost described under what it does not hide.

Redeeming

Redeeming turns a credit into spendable balance. It is the private half, and it carries no wallet, no signature and no cookie.

Purchase

Public, like any transfer onchain.

Make two random numbers. Keep them.
Send their commitment with a USDG payment.
A leaf joins the public tree.

Only a proof crosses this line.

Use

Private: it names no purchase.

Make an API key. Download the whole tree.
Prove one leaf is yours, not which.
The key is funded. Spend with it.

The buyer makes an API key on their own device and downloads the entire tree. They never ask for the path of their own leaf, because asking would say which leaf it is. They rebuild the root from the leaves and refuse to continue if it does not match the one Snarket publishes.

They then build a Groth16 zk-SNARK over the BN254 curve. It has four public values: the tree's root, the amount, the spend tag, and a value derived from the hash of the key being funded. It proves that the buyer knows the nullifier and secret of some leaf under that root, for that amount. The two numbers and the leaf's position stay on the device. Building it takes a second or two in a browser.

Snarket checks that the root is one its tree has had, that the spend tag has not been seen, and that the proof verifies. In a single database transaction it records the spend tag and credits the key. Because the key's hash is inside the proof, a proof copied off the wire cannot fund anyone else's key. Only the hash of the key is sent; the key itself first reaches Snarket on the call that spends it.

The gateway

Every item is used through one gateway with one key. For models and images it speaks the OpenAI wire format, so existing clients work unchanged.

Holding, then charging. Before a call is served, the worst case it could cost is held against the key's balance in one atomic update, so two calls can never spend the same balance. When the call ends, the hold is settled to the real charge and the rest returned.
Per token, or per unit. Models are charged for the tokens they use. Images are charged per picture and search per call. A call that fails, or a picture that is not made, costs nothing.
What is kept. For each call the gateway records the item, the token or unit counts and the charge. It does not store or log prompts, answers, pictures, queries or results.
Receipts. A model call returns a receipt signed by a key that the enclave's attestation report publishes, so a caller can check that the call ran inside the enclave.

An item's price is its supplier's price multiplied by one marketplace-wide markup.

Who sees what

The proof protects one fact: which purchase a key came from. Here is everything else, party by party.

	Anyone reading the chain	Snarket	Whoever runs the model
The wallet that paid, the amount, the time	Yes.	Yes.	No.
Which purchase a key came from	No.	No. Only that it is one of the purchases of that amount.	No.
The API key	No.	Its hash at redeem. The key itself on each call.	No.
Prompts, queries and results	No.	They pass through. Nothing is stored or logged.	Yes. For models that is a hardware enclave. For images and search it is a standard cloud supplier.
Items used, counts, charges	No.	Yes, per key.	For the call it serves.
The caller's IP address	No.	Reaches the network in front of Snarket, as on any site. Snarket's ledger does not record it.	No.

The tree, right now

These numbers are read live from the public API. Each amount is its own crowd, because the amount is visible in a proof.

Credits bought
Bought, by amount
Current root
Check it yourself: Every leaf, and the tree and the prover's files.

What it does not hide

The purchase. Anyone can see that a wallet bought a credit, for how much, and when.
A small crowd. A buyer who is the only one at an amount is the only one who could have redeemed it. The offered amounts gather the largest crowds; an amount typed in may have none.
Timing. A redeem seconds after a purchase is an easy guess, however large the crowd.
The network address. Buying and redeeming from the same IP address links them outside the proof.
Calls on one key. Every call made with a key is tied to that key. A key is a pseudonym, not a fresh identity per call.
Images and search, at the supplier. Those items are not served in an enclave. The supplier sees the prompt or the query. It does not see a wallet, a key or an address: every request reaches it from Snarket.

A buyer gets the most from the system by buying a common amount, waiting for others to buy the same amount before redeeming, redeeming from a different network, and using separate keys for work that should not be tied together.

What you are trusting

The math, for the link: The buyer's device downloads the whole tree, rebuilds the root and binds the proof to its own key. None of that depends on Snarket behaving.
The setup, for supply: Groth16 needs a one-time setup. The keys in use today come from a setup run by the team, not a public ceremony, and the circuit and keys are shared with OffRouter, a sister project. Whoever ran a setup could forge proofs and mint credits for free. That would be a loss to Snarket, not to buyers, and it cannot reveal which credit is whose.
The enclave, for models: Models run in an Intel TDX and NVIDIA confidential GPU enclave. The trust is in that hardware and its attestation, which a caller can check through the receipt.
Suppliers, for images and search: A standard cloud supplier is trusted with the content of those requests, and with nothing about the caller.
Snarket, for the gateway: Requests pass through the gateway on the way to a supplier. It is built to store only counts and charges. That is a promise that cannot be verified from outside.
The buyer, for the credit: A credit and a key live with the buyer and nowhere else. Losing them loses the balance.

Agents

Because no step needs a person, an agent with a funded wallet can use all of this by itself. It reads the listings, signs a payment, builds the proof and calls the gateway. An SDK and an MCP server package those steps, and the MCP server enforces a cap per purchase and a budget per session, so an agent cannot spend past what its operator allowed.

An agent that buys and redeems in one go is easy to link by timing. One that cares can buy early and redeem later, and can refuse to redeem until a crowd of a chosen size exists at its amount. The agents page has the details.

What comes next

More compute. Longer jobs, GPU jobs and fine-tuning, sold the same way as a second of code.
More than one seller. Suppliers listing side by side and competing on price and latency, which is what makes this a market and not a store.
A public setup. Replacing today's keys with ones from a ceremony anyone can join.
Private settlement. Hiding the purchase itself, where the chain can support it. Today only the link between purchase and use is hidden.
Enclaves for more items. Bringing the confidential serving that models have to the other categories.