How privacy works

Paying for a credit and using it are two separate acts. A zero-knowledge proof is the only thing between them, and it does not say which payment was yours.

Two acts, and nothing that connects them.

Most payments are private only until someone looks at the ledger. Snarket leaves the payment public and breaks the link after it: the key you call with was never attached to the wallet that paid.

Purchase

Public, like any transfer onchain.

Your browser picks two random numbers and keeps them. They are the credit.
It sends a fingerprint of them, the commitment, with a USDG payment.
Snarket adds one leaf to a public tree: the commitment and the amount paid.

No wallet, no signature and no account cross this line. Only a proof.

Use

Private: it names no purchase.

Your browser makes an API key and downloads the whole tree.
It proves that one leaf in the tree is yours, without showing which.
Snarket checks the proof and funds the key. You call models with it.

The five parts that make it work.

The creditnullifier, secret: Two random numbers of 31 bytes each, made in your browser. Whoever holds them can redeem the credit, which is why Snarket never receives them and cannot recover one you lose.
The commitmentPoseidon(nullifier, secret): A one-way hash of the two numbers. It is what travels with your payment. It commits you to the credit without revealing it, and nobody can work backwards from it.
The treeleaf = Poseidon(commitment, amount): A public, append-only Merkle tree of every credit ever bought, 20 levels deep. 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 proofGroth16 zk-SNARK, BN254: Made in your browser in a second or two. It shows four public values: the tree's root, the amount, a spend tag, and the hash of the key being funded. It proves you know the two numbers behind some leaf under that root for that amount. The numbers and the leaf's position stay on your device.
The spend tagPoseidon(nullifier): The same for every proof of one credit, so Snarket can refuse a second redeem. It is computed from the nullifier alone, which appears nowhere in the tree, so it cannot be matched to a leaf.

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. It is a normal USDG transfer.	Yes.	No.
Which purchase a key came from	No.	No. The proof shows only that it is one of the purchases of that amount.	No.
Your API key	No. Keys never touch the chain.	Its hash when you redeem. The key itself when you call.	No.
Your prompts and answers	No.	They pass through the gateway. Nothing is stored or logged.	Yes. For models that is a hardware enclave. For image and search items it is a standard cloud supplier.
Items used, token and image counts, charges	No.	Yes, per key. That is how the balance is kept.	For the call it serves.
Your IP address	No.	Reaches the network in front of Snarket, as on any site. Snarket's own ledger does not record it.	No.

The tree, right now.

A credit hides among the purchases of the same amount, because the amount is visible in a proof. These are read live from the public API, and you can check every number yourself.

credits bought so far

Bought, by amount
Current root
Check it yourself: Every leaf Tree and prover files

What the proof does not hide.

Limits

The purchase is publicAnyone can see that your wallet bought a credit, for how much, and when.
Small crowdsIf you are the only buyer of an amount, a redeem of that amount is yours. The crowd is what hides you.
TimingA redeem seconds after a purchase is an easy guess, however large the crowd.
Your network addressBuying and redeeming from the same IP address links them outside the proof.
Calls on one keyEvery call made with a key is tied to that key. A key is a pseudonym, not a new identity per call.

Getting the most from it

Buy a common amountThe offered amounts gather the largest crowds. A typed amount may have none.
Wait before you redeemLet other purchases of the same amount land first. Your dashboard shows the count.
Redeem from another networkA different connection, a VPN or Tor keeps your IP address from linking the two acts.
Keep the credit safeDownload it when you buy. It lives in your browser and nowhere else.
One key per purposeUse separate keys for activity you do not want tied together.

What you are trusting.

Less than usual, and not nothing.

The math, not Snarket, for the link: Your browser downloads the whole tree instead of asking for its own leaf, rebuilds the root, and refuses to prove against one that does not match. The proof is bound to your key's hash, so a copy of it cannot fund anyone else's key. None of that depends on Snarket behaving.
The setup, for supply: Groth16 needs a one-time setup. Whoever ran it could forge proofs, which would mean minting credits for free: a loss to Snarket, not to buyers. It cannot be used to find out which credit is yours.
Cloud suppliers, for images and search: Image items and search items are not served in an enclave. A standard cloud supplier does the work and sees your prompt, query or page address. It does not see who you are: every request reaches it from Snarket, with no key, wallet or address of yours attached. Snarket passes the result back and keeps no copy of it.
The enclave, for models: Models run inside a hardware enclave on a confidential GPU. Each response comes with a receipt signed by a key that the enclave's attestation report publishes, so you can check that a call ran there. The receipt holds hashes and timestamps, never content.
Snarket, for the gateway: Requests pass through Snarket's gateway on the way to the provider. It is built to store only the item, the token or image counts and the charge. That part is a promise you cannot verify from outside, and we would rather say so.