# v1 vs v2: what changed

> How Privacy Pools v2 differs from v1: UTXO-style notes, private in-pool transfers, a keystore account model, and a unified multi-asset anonymity set.

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](/concepts/notes), private in-pool transfers, and a [keystore-based account model](/operations/accounts-and-keys).

## 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](/concepts/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](/operations/transfer):** move funds within the pool privately.
-   **[On-chain keystore](/operations/accounts-and-keys):** register your account once, which enables you to transfer, withdraw, and receive funds privately. No additional seed phrase to back up.
-   **[Selective disclosure](/concepts/selective-disclosure):** a [three-key model](/concepts/keys) 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](/concepts/asp-attestation)-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](/operations/ragequit):** public exit stays available at all times, so you can always recover a deposit if the ASP declines or revokes its approval.
