IVlWVlWI

Trust model

This is unlinkable, not trustless. We cannot connect a stamp to a person, and that property is real and mechanical. Everything you are trusting beyond it is written out below.

Keys are minted from one treasury Venice account. That account can revoke them, and Venice can close the account. You are trusting us not to do the first and Venice not to do the second.

WHAT WE CLAIM

We cannot link a stamp to a person. Payment is shielded ZEC. We see a note arrive and we send a note out. No account, email, IP, cookie or session exists on our side.
We never hold your key. Venice generates it, it is written into one memo, and it is dropped. The ledger stores the key's id so a stamp can be revoked on abuse and counted against capacity.
We never see your prompts. You talk to Venice directly. Nothing here proxies inference. This is also why we cannot meter your usage or help when a model misbehaves.
Anthropic never sees a secret. A Claude clerk reads memos the parser cannot. Anything sensitive is encrypted locally and replaced with a placeholder before it reaches Claude. One tool re-inflates a placeholder, inside a Venice private-model request, and its output is scrubbed on the way back. A test asserts no tool can leak plaintext.
The website keeps nothing in your browser and calls nothing outside its own origin. No cookies, no local storage, no analytics, no fonts, no CDN. The private-window test writes one temporary IndexedDB database and deletes it before the page renders. The server sets a strict content security policy, no-referrer and no-store, and keeps no access log.

WHAT WE DO NOT CLAIM

Not non-custodial, and not trustless. Keys come from a single treasury Venice account. We can revoke any key. Venice can suspend the account and every stamp with it. This is the single largest thing you are trusting.
Not refundable. There are no refunds, and that is not a policy we could reverse. A shielded payment carries no return address. We could not refund you if we decided to.
Not settled with Venice. Venice's terms grant a personal, non-commercial, non-transferable and non-sublicensable license, and prohibit selling or transferring the access granted under them. They also reserve the right to revoke or rotate any key at Venice's sole discretion. We have not obtained written confirmation that selling stamps is permitted. Price in the possibility that your stamp is revoked for reasons that have nothing to do with you. We would rather say that than have you find it out at a 401.
Not a guarantee against Venice. Zero data retention is Venice's policy, backed on TEE models by hardware attestation. It is not a cryptographic guarantee that no prompt is ever observed in flight.
Not protection against a compromised clerk host. Whoever controls the host can mint keys to themselves and read memos as they arrive. Our own wallet also retains the memos it has sent, and those memos contain keys. The ledger does not hold them, but the wallet file does. Someone who seizes the host and its wallet can read keys delivered in the past.
Not immune to timing correlation. An observer watching both the Zcash network and Venice traffic could correlate a memo delivery with a burst of calls from a fresh key. The clerk reaches Venice, the price sources and its lightwalletd from one fixed egress IP, permanently, which sharpens that correlation rather than blurring it.
Not protection against the layers under us. The reverse proxy, the VPS provider, the network between them and the DNS operator all see the connection regardless of what the clerk logs. An onion address avoids the DNS and TLS layers entirely and is the honest answer for anyone who needs more than our restraint.
Not anonymous on the burn lane. A burn transaction is public and linked to the burning wallet. Only the delivery is shielded.
Not usable without scripting, as a website. The private-window test needs JavaScript, so Tor Browser at Safest sees the gate and no further. The memo format is printed in the no-script block for exactly this reason, and the status document can be fetched without running our code.
Not a support channel. There is no private way to reach us and no way for us to identify your payment. The X account is public, and anything you post there is public and linkable to you.
Not monitored. If a delivery fails, no alert fires and no job reconciles it. We will not know your stamp was lost.

WHAT THE LEDGER STORES

TABLE	COLUMNS
`notes`	txid, output index, height, value, status, reason, seen at
`stamps`	key id, tier, source, source ref, issued at, expires at, delivered txid, dry-run flag
`burns`	tx hash, sender address, amount, tier, claimed at, stamp id
`kv`	operational flags

Not present anywhere: API keys, memo text, reply addresses, IP addresses, user agents, page views.

ONE NUANCE WORTH STATING

The stamps row links the transaction that paid us to the transaction that delivered your stamp. Both are shielded, so a third party learns nothing from those ids alone. But you know your own txid. If you ever reveal it, that row identifies your stamp, its tier and its lifetime. Anyone holding the clerk's viewing key, or the host itself, can walk the link in both directions without your help.

The burn table is different in kind. It stores a public sender address, because the burn is public. That is inherent to that lane, not a leak.

WHAT EACH LAYER CAN SEE

LAYER	SEES	DOES NOT SEE
Zcash network	that a shielded transaction happened, and its fee	sender, recipient, amount, memo
Anyone with your viewing key	every memo sent to your address, including your key	nothing more, but that is plenty
Your own wallet	every memo you sent, retained until you remove it
Our wallet and host	your memo, your reply address, your amount, your key at mint	who you are, your IP, your prompts
Our ledger	tier, timestamps, txids, key id	keys, memos, addresses
Venice	your key, your prompts, your token counts, your IP unless you use Tor	who bought the stamp, or that it was bought
Anthropic	memos with addresses replaced by placeholders	keys, addresses, prompts
Proxy, VPS, DNS, the network	that your browser connected here	anything the clerk does, since it logs nothing
A timing observer on both sides	correlation between a delivery and a fresh key's first call	the content of either

The memo is private on the chain. It is only as private as our host afterwards. Zcash guarantees that nobody but us can read your order. It does not guarantee anything about what we do with it, and no amount of cryptography will.

WHO CAN READ YOUR MEMO

Viewing keys. Anyone holding your incoming or full viewing key can read every memo sent to your address, including the one carrying your key. If you have ever handed a viewing key to a tax tool, an accountant, an exchange for proof of funds, or a block explorer, those parties can read your stamp. This is the most likely real-world leak in the entire flow and it has nothing to do with us.

Your own wallet. Sent memos are retained by the sending wallet, and removal is manual in the wallets that support it at all. Device seizure or a wallet backup exposes what you sent us.

The fee is public. Fees scale with the number of logical actions in a transaction, so an unusual action count is weakly observable. This is minor. It is not literally zero.

THE THREAT MODEL

ADVERSARY	WHAT THEY GET	WHAT STOPS THEM
A chain observer	a shielded transaction and its fee	the shielded pool
Someone reading this site's traffic	that you loaded a page	no log, no cookie, no third party, and Tor if you use it
Someone who seizes the clerk host	future memos, past delivered keys from the wallet file, the ledger	nothing. Assume total loss if the host falls.
Venice	your prompts and your key's activity, tied to your IP unless you use Tor	a private or TEE model, and Tor
Anthropic	placeholders	the vault boundary, enforced in code and tested
Someone correlating timing	a probable link between a delivery and a key's first use	waiting a random interval before first use
Us, acting badly	revocation of your key	nothing. This is the trust you are extending.

WHAT YOU SHOULD DO

Pay from a shielded pool, from a wallet you control. Transparent payments carry no memo, buy nothing, and expose you on top of it.
Use a fresh reply address per stamp if your wallet supports it.
Verify the clerk address out of band against the X account before sending. A swapped address on a privacy-branded checkout is the obvious attack.
Use the stamp over Tor, and not from a network identity you use for anything attributable. Test that it works before you depend on it.
Wait a random interval between receiving a stamp and first using it.
Prefer TEE and E2EE models, and verify the attestation yourself rather than trusting a field that says it was verified.
Never hand your viewing key to a third party if the memos to that address matter to you.
Assume the stamp can die early. Do not buy a tier L if losing thirty days of access would hurt. Buy an S first and find out whether this service behaves.

WHAT WOULD MAKE THIS BETTER, AND HAS NOT BEEN DONE

Stating these is cheaper than being caught by them.

A failed delivery is not retried and not reported. The key is minted before the send is attempted, so a send failure leaves a live key nobody holds and capacity reserved until it expires.
A checksum is not proof of ownership. Reply addresses are now checksum-verified, so a mistyped address is refused rather than delivered into nothing. But a typo that happens to produce a valid address still delivers your stamp to a stranger. Nothing on our side can detect that, because we have no idea which address is yours.
Newer address prefixes are not recognised in bare form. Writing reply: in front rescues the case, which is why the buy page insists on it, but that is a workaround and not a fix.
Unified addresses can carry an expiry. A reply address stored for a later delivery can go stale. We do not handle this.
The Venice terms question is open. See the third item under what we do not claim.

None of this is hidden in a changelog. If any of it changes, this page changes with it.