v1 vs v2: what changed
The mechanism of Privacy Pools v1 is simple and straightforward: deposit, wait for approval, then withdraw privately if approved. Privacy Pools v2 is a new shielded pool design built around UTXO-style notes, private in-pool transfers, and a keystore-based account model.
The new mental model
| v1 | v2 |
|---|---|
| Deposits create private commitments that can later be partially or fully withdrawn | Notes are the unit of value, and deposit, transfer, and withdraw are operations on notes |
| To benefit from privacy, users need to withdraw to a fresh address | Users can transfer funds within the pool privately as well as withdraw privately |
| A mnemonic-derived account generates commitment nullifiers and secrets | Keystore registration separates nullifying, authorization, and viewing keys |
| Users backed up a separate Privacy Pools seed phrase | Keystore-backed accounts remove that separate seed phrase |
| Users can generate viewing keys to reveal account activity | Users can generate per-transaction receipts as well as viewing keys for account activity |
| One pool and anonymity set per asset | Multi-asset pool and unified anonymity set for all assets on a given chain |
| ASP approval gates private withdrawals | ASP approval gates every private spend, and extends to all notes descended from an approved deposit |
New primitives
- Notes: a note is a private record of value that only you can spend. In-pool transfers spend your notes and create new ones for the recipient and for your change.
- Private transfers: move funds within the pool privately.
- On-chain keystore: register your account once, which enables you to transfer, withdraw, and receive funds privately. No additional seed phrase to back up.
- Selective disclosure: a three-key model separates viewing from spending, so you can share a viewing key to reveal your whole account, or a receipt to prove a single payment, without giving up spend control.
What stayed the same
- ZK-based privacy via Groth16 proofs (different circuits, same proof system).
- ASP-based compliance: a 0xbow-operated ASP screens every deposit before it can be spent privately.
- Non-custodial: only your keys can spend your funds, and the protocol cannot move them for you.
- Ragequit: public exit stays available at all times, so you can always recover a deposit if the ASP declines or revokes its approval.