Revocation
Screening happens at the door. Revocation is what happens when a source turns out to be illicit after it already got in — a deposit whose provenance only becomes clear weeks later.
What revocation is
The ASP drops the origin from the approved set and publishes a new root. That's the entire operation. There is no on-chain seizure instruction, no freeze flag, and no administrator anywhere in the system who can touch a note.
From the moment the new root is published, notes descending from that deposit can no longer produce a valid membership proof. They stop being privately spendable. They do not stop being yours.
What happens to a note whose origin is revoked
- A private transfer, swap, consolidation or withdrawal of it will no longer go through. Your wallet cannot build a proof the program will accept, and it tells you so in plain language rather than failing mid-flow.
- The emergency exit still works. It always does — it skips the membership check by design. You withdraw to a public address of your choosing, and that note's origin is published on-chain. Your money comes out; the privacy of that lineage does not survive it.
- Nothing else of yours is affected. Revocation targets one lineage. Notes you hold from other deposits are untouched, and your keys, balance and history are unaffected.
- A combine you already did carries through. If you combined several sources into one note and one of the inputs is later revoked, the merged note is dropped from the list too. The ASP reconstructs that relationship from the chain, so it holds even if the ASP's own records were lost.
What nobody learns
Revocation happens by editing a list, not by tracing anyone. When an origin is dropped:
- Nobody walks the transaction graph.
- The ASP does not learn who held notes from that deposit, how many there were, or what they were worth.
- Other users see only that the published list is one entry shorter.
The entire lineage is cut off in one move, and the fan-out stays hidden inside users' own proofs.
The honest limit: it only bites money still unspent
This is worth stating flatly, because it is a real property of the design and not a detail.
Retroactive flagging only affects funds that haven't moved yet. If a deposit is flagged after its funds have already been spent onward and withdrawn, revoking the origin does nothing to them — the money is gone from the pool and a list can't reach it.
This is inherent to every privacy pool that works this way, on any chain. It's mitigated by deposit screening, which stops known-bad sources entering in the first place, and by publishing roots frequently so the window between a flag and its effect stays short. It isn't eliminated, and no privacy pool eliminates it.
False positives
They're possible — a list is a human artefact. The remedy is the emergency exit, which needs no one's cooperation. It is deliberately privacy-forfeiting for the lineage it exits, which is exactly why revocation should carry a citable reason and be contestable in public. See the transparency commitment in How the ASP works.