What goes wrong, what is actually happening, and what can be done. Read the honest part first.
There is no account, no order number, no refund and no support channel that can identify you. The clerk does not know which payment is yours, and it is built so that it cannot know. It stores a note id, an amount, a status, and for issued stamps a key id and two timestamps. It never stores your address, your memo or your key.
So nobody can look up "my payment". The only honest answer to "where is my stamp" is a description of how the machine behaves, which is this page. Everything here you can check yourself, from your own wallet and from /status.json.
A payment is consumed when it is processed, whatever the outcome. Underpaid, sold out, no reply address: the ZEC stays with the clerk. There is no refund path, not as a policy but as a mechanism. A shielded payment carries no return address unless you put one in the memo.
The memo is the only copy of your key. It is stored nowhere else and cannot be re-sent.
| STEP | EXPECTED |
|---|---|
| Your payment confirms | 3 confirmations, a few minutes |
| The clerk notices it | it polls every 30 seconds |
| Mint and send | seconds |
| Dust payment reaches your reply address | usually under 10 minutes in total |
The delivery is 0.0001 ZEC carrying an encrypted memo. Some wallets hide amounts that small, or file memo-only transactions separately. Find out where your wallet shows memos before you start waiting.
What you see. The payment confirms on-chain. Nothing comes back, ever.
What is happening. Transparent transactions have no memo field, and exchange withdrawals are transparent. The clerk sees value arrive with an empty memo, so there is no reply address, so there is nowhere to send a stamp. Not even an error, because an error is also a memo to an address it does not have. The note is marked no_reply_address and consumed silently.
Some exchanges refuse to send to a unified address at all. That is the good outcome: the withdrawal fails and you keep your money.
What to do. Nothing can be done. The ZEC is gone. This is the most expensive mistake in the system and it is unrecoverable by design. To pay with coins sitting on an exchange, withdraw to a shielded wallet you control, let it confirm, then send from the shielded pool with the memo.
What you see. Either nothing comes back, or a memo arrives telling you what was missing.
What is happening. Two cases, and the difference is entirely whether a reply address survived.
stamp M, STAMP:M, tier=M, or just M plus an address anywhere in the memo all parse. If the parser still cannot read it, the memo, with your address replaced by {{reply_address}}, is handed to the Claude clerk to interpret.Truncation is the dangerous case, and it happens in the wallet rather than on the wire. The protocol memo is exactly 512 bytes and an oversized memo is refused outright by the sending wallet, not cut in half. But a wallet interface that caps its own input field lower will quietly shorten what you pasted, and a unified address is long. If the field cut it off, either the fragment is too short to look like an address, which is a silent loss, or the fragment still looks like an address, the clerk tries to send to it, and delivery fails. Your payment is consumed and a key was minted that nobody will ever receive.
Read the memo back on the confirmation screen before you send. The whole address must be visible, on one line.
What to do. If a memo came back explaining what was missing, read it and send a new, correct payment. If nothing came back, nothing can be done. Open your sent transaction, look at the memo you actually sent, and fix it for next time.
What you see. Nothing arrives, and in the worst version you never find out why.
What is happening. The clerk verifies the address checksum, which catches most typos. It cannot check that the address is yours. Three outcomes:
What to do. Nothing can be done in any of the three cases. The only defence is upstream: paste from the receive screen, and check the last six characters in the memo preview against your wallet before sending.
What you see. A dust payment with a memo like IVlWVlWI: underpaid: got 0.0041 ZEC, S needs ~0.0046 ZEC.
What is happening. Prices are quoted in ZEC from a live median of three sources, at least two of which must answer and agree, refreshed about every minute. The price applied to your payment is the one in force when the clerk processes the note, after your confirmations, not when you read the page. There is a three percent tolerance for exactly this drift. Beyond it, your payment does not reach tier S and no stamp is issued.
The gap can be much wider than three percent if the clerk was offline for a while and processed your note late, or if ZEC moved sharply between your send and your third confirmation.
What to do. The underpaid amount is consumed. It is not credited and cannot be topped up: a second payment is a second note, priced on its own, never added to the first. To get a stamp, send a fresh, sufficient payment. Next time pay five to ten percent over.
What you see. You asked for S and an M or L stamp arrives.
What is happening. There are no refunds and no change, so the clerk issues the best tier your payment covers, whatever tier you named. The tier letter only shapes the wording when you fall short. Above L, the excess buys nothing and is kept.
What to do. Nothing, if you got a bigger stamp than you asked for. If you badly overpaid past L, that surplus is gone. Overpaying by five to ten percent is deliberate and sensible. Overpaying by ten times is not.
What you see. Two dust payments, two memos, two keys.
What is happening. Deduplication is per note, not per buyer. Each payment is an independent transaction arriving at a system that has no idea the two are related. That unlinkability is the product. Two payments that each cover a tier produce two stamps and consume two payments.
What to do. Nothing is refundable, but nothing is lost either. Both keys are real and their daily caps are separate. Both expiry clocks start at issue, so use the shorter one first. If the double send was two halves of one intended payment, the outcome is worse: each half is priced alone, and if neither reaches tier S you get two underpaid memos and both halves are consumed.
What you see. Your transaction is confirmed. Your wallet shows nothing back.
What is happening. In rough order of likelihood:
What to do. Check your own side first: sync, correct wallet, memo view. Then check /status.json. If the clerk is down, wait. Notes are picked up from chain history when it returns, so waiting is genuinely correct and may take hours rather than minutes. If the clerk is healthy and the memo carried a valid address of yours, delivery has already happened or already failed. There is no queue to ask about.
What you see. A 401, a 403, or a model error from the Venice API.
What is happening. Usually one of these:
key:, with no spaces and nothing from the next line.modelPrivacy: PRIVATE_ONLY. Any model whose privacy is not private is refused.https://api.venice.ai/api/v1, and the key goes in an Authorization: Bearer header.DRYRUN-. That is a test key from a dry-run clerk and was never real. Check /status.json before paying.What to do. Work through that list with one request against a known private model. If a clean request with an undamaged key on a private model still fails immediately after delivery, the key was revoked or the treasury account is in trouble. There is no per-buyer remedy and no refund.
What you see. Requests that worked an hour ago now fail.
What is happening. A stamp has two limits, and both are visible to you.
until: line. After it the key is dead.Less commonly: the treasury revoked the key for abuse, or Venice suspended the account, which would stop every stamp at once.
What to do. If it is the cap, wait for 00:00 UTC or buy another stamp. Two stamps have two independent caps. If it is the expiry, buy another. Nothing renews automatically, and an existing key cannot be extended. Topping up would require linking a new payment to an old key, which is precisely what this system cannot do.
What you see. You have no key and no way to get it.
What is happening. The key exists only in the memo that was sent to you. The ledger holds a key id, a tier, an issue time and an expiry. Enough to count capacity and to revoke, not enough to reconstruct a key. Even with full access to the clerk's database and its Venice account there is no "show key" operation: Venice returns a key once, at mint.
What to do. Nothing can be done, by you or by the operator. Treat the memo as cash. The moment a stamp arrives, copy the key out of the wallet and into wherever you keep secrets.
What you see. Nothing comes back for a long time. The site may be unreachable.
What is happening. Your payment is on the Zcash chain regardless. It is not lost. When the clerk restarts it reads its wallet history, finds notes it has not processed, and processes them. Delivery is late rather than never.
One real consequence: a note is priced when it is processed, not when it was sent. A long outage plus a ZEC rally can turn a payment that was fine into an underpaid one, which is then consumed with an underpaid memo. A fall in ZEC can hand you a higher tier than you paid for. Neither is deliberate.
What to do. Wait. Do not send a second payment to compensate: you will end up with two stamps, or two underpaid memos. If the site has been unreachable for days, treat the payment as lost. There is no escrow and no claim process.
What you see. A memo reading sold out: no M capacity today, try again after 00:00 UTC.
What is happening. Every live stamp reserves part of the treasury's staked daily DIEM. When free capacity is smaller than the tier your payment covers, no key is minted. Your payment is still consumed.
What to do. Nothing recovers that payment. Before sending, read the capacity line on the home page. It comes from /status.json as available against total. If available capacity is below the tier you want, wait.
| SITUATION | RECOVERABLE? |
|---|---|
| Paid from an exchange or transparently | No. Funds gone. |
| Memo missing, no reply address | No. Funds gone, silently. |
| Memo truncated, address unusable | No. A key was minted and delivered to nobody. |
| Reply address mistyped | No. Funds gone, or the stamp went to a stranger. |
| Reply address correct, wallet lost | No. Delivered into a wallet nobody can open. |
| Underpaid | No refund. Send a fresh, sufficient payment. |
| Overpaid below L | Yes, in effect. You receive a higher tier. |
| Overpaid above L | Surplus gone. |
| Paid twice | Not refundable, but you hold two working stamps. |
| Sold out | No refund. Check capacity before paying. |
| Clerk offline | Yes. Delivery is late, not lost, but priced late. |
| Memo lost after delivery | No. The key exists nowhere else. |
| Key hit its daily cap | Yes, at 00:00 UTC. |
| Key expired | No. Buy another. |
Where a line says no, it means no, not "ask nicely". The system is built so the operator cannot tell you apart from anyone else, and that property has exactly this cost.