A ra:st withdrawal arrives with a cryptographic receipt proving it descends from an association set you trust — and avoids the blocklist. You verify it from public data, with no cooperation from the user and no privileged access.
An opaque mixer severs every link between deposit and withdrawal. That buys privacy — but leaves you unable to distinguish clean funds from laundered ones. To stay compliant you reject the whole pool, and honest users lose access. The privacy is real but unusable.
ra:st keeps the user unlinkable and attaches a compliance receipt: a proof the note descends from a public association set of non-illicit deposits. You accept the exit because you can verify it avoided the blocklist — without learning which deposit it was.
When a user funds their account from ra:st, your system runs these against public chain data. All three are constant-cost and require no user interaction.
Is the receipt’s rt𝒜 a root published by a curator whose policy you accept?
Did the withdrawal proof verify against that root on-chain?
Is the nullifier recorded once — no replay, no double-spend?
# called when a user deposits ra:st-withdrawn funds def accept_deposit(exit_event): root = exit_event.assoc_root # rt𝒜 on the receipt if root not in TRUSTED_ROOTS: # curators you accept return REJECT("untrusted association policy") if not verify_onchain(exit_event.proof): # already checked by contract return REJECT("invalid proof") return ACCEPT # descends from 𝒜, blocklist-clean
Every withdrawal emits a public event. These are the only fields you need — and the only fields that exist.
| Field | Meaning | You use it to |
|---|---|---|
| rt𝒜 | Association root the proof was made against | Match against your trusted curators |
| nf | Nullifier — the one-time spend tag | Confirm the exit is fresh, not replayed |
| π | The zero-knowledge proof (192 B) | Confirm on-chain verification passed |
| recipient | The payout address | Match to the incoming deposit |
Compliance and privacy are not traded off. You get exactly the assurance you need — and nothing that would compromise the user.
Integration guides, trusted-root registries, and the compliance spec are available to institutional partners.