The Bank Vault In The Dark: A Plain-English Metaphor For Private Pool V2

RelAI Team
May 10, 2026 · 6 min read
The Bank Vault In The Dark: A Plain-English Metaphor For Private Pool V2

Most explainers for zero-knowledge privacy pools start with phrases like "Poseidon hash commitments," "merkle inclusion proofs," and "nullifier derivation." These are accurate, and useless if you've never written a SNARK. So here's a metaphor that gets the intuition right without the cryptography vocabulary — and one important correction to the obvious version of it.

The Vault

Imagine a bank vault on Solana. Anyone can register an account. Registering doesn't cost anything and doesn't ask for ID — you just generate a key on your own device and tell the bank "I exist, here's my address." From that moment, anyone can send you USDC into the vault, and you can send USDC out of the vault.

Inside the vault are thousands of sealed drawers. Each drawer holds some USDC, addressed to someone — but you can't tell from the outside how much is inside, or who owns it. You see the drawer exists. That's all you see.

When you want to pay someone privately, you walk into the vault, open two of your own drawers, take their contents, and reseal everything into two new drawers — one addressed to the person you're paying, one addressed back to you (your change). The drawers you opened are gone. Two new drawers exist. The vault as a whole has the same total amount of USDC.

To anyone watching from outside the vault, every transfer looks identical: "someone opened two drawers and sealed two new ones." No amount visible. No sender visible. No recipient visible.

That's Private Pool V2.

What's Hidden, What's Not

Visible to everyoneHidden from everyone except the owner
The vault itself (the on-chain pool program)Who owns each drawer
Every drawer's existence (sealed commitment)How much USDC each drawer holds
That a transfer happenedWhich drawers were the input
The total amount that ever entered the vaultWhich drawers are the new outputs
Per-transfer protocol fee (the bank's flat cut)The graph of who-paid-whom
The drawers are public. Their contents and ownership are not. Crucially, the links between drawers — "this new one came from those two old ones" — are also not public.

The One Big Correction To The Obvious Version Of This Metaphor

The intuitive way to picture this is "you walk into the vault alone, the door closes behind you, nobody else sees what you do." That feels right — it's the way physical privacy works in real life. And it's the opposite of how cryptographic privacy actually works.

Privacy in this system does not come from being alone. It comes from being one of a crowd.

Imagine the vault is dark, and everyone inside is wearing an identical mask. At any moment, dozens of people are walking in, opening drawers, sealing new ones, and walking out. From the outside, you can see that someone moved value, but you cannot tell who did it or between which drawers. The more people are in the vault simultaneously, the better your privacy gets — because there are more drawers being touched, more masks in the room, more plausible explanations for any given drawer's history.

This is called the anonymity set, and it's the single most important property of any privacy pool. A pool with one user has no privacy. A pool with ten thousand users has serious privacy. Counterintuitively: the worst thing for your privacy is being the only person in the vault.

This is why you should want other people using the same pool you use. Their transfers protect yours.

Two More Corrections, While We're Here

1. The "bank" has no manager. No human can open your drawer. No human can freeze the vault. The vault is a smart contract on Solana — it accepts the kinds of transactions the code allows and rejects everything else. You hold the only key to your drawers. Lose the key and the contents are unrecoverable. 2. Transfers aren't really moves. They're burn-and-recreate. When you "transfer between drawers," what actually happens is: your old drawers get permanently invalidated (the system records "these drawers were opened, they cannot be opened again"), and brand-new drawers appear with the new contents. This is what prevents double-spending — once a drawer is opened, the system remembers, forever, that it can't be opened a second time.

If you've ever wondered how Bitcoin's UTXO model works, this is exactly the same idea. Notes don't have balances; you destroy notes and create new ones with the right values to make the math work out.

Mapping The Metaphor To The Real Thing

For the technically curious, here's the one-to-one translation:

MetaphorPrivate Pool V2
Bank vaultThe pool program on Solana (single PDA, one per asset)
Account / addressPayment address (registered viewing key + spending key)
DrawerCommitment leaf (Poseidon4 hash of value, owner_pk, blinding, memo)
Drawer's contentsThe note plaintext, encrypted under the recipient's viewing key
Sealing a drawerInserting a new commitment into the merkle tree
Opening drawers + creating new onesA JoinSplit2x2 transaction (2 inputs spent, 2 outputs created)
"This drawer was opened, can't be opened again"Nullifier marker PDA (one per spent note)
The dark, masked crowdThe anonymity set — every other note in the pool's merkle tree
Bank's protocol fee5% on JoinSplit transfers, 0% on deposits and exact-match withdrawals
The cryptographic guarantee is enforced by a Groth16 zero-knowledge proof that runs in the user's browser before submitting the transaction. The proof asserts seven things at once — that the user owns the input drawers, that the new drawers are well-formed, that the math balances, that the input drawers haven't been opened before, that the input drawers were OFAC-screened at deposit time, and so on — without revealing any of the underlying values to the verifier on-chain.

If you want the cryptographic detail, the protocol overview is here. For everything below, you don't need it.

Why This Matters

Most blockchain payment apps leak everything. Open a transaction on Solscan and you see the sender's address, the recipient's address, the exact amount, the time, and — by chaining transactions together — a history of every payment those wallets ever made. There's no privacy on a public ledger by default. You don't get any.

For consumer payments, this is genuinely strange. You wouldn't accept a credit card whose every charge was published to a public website attached to your name. But that is exactly what every "send USDC" app does today.

Private Pool V2 is one answer. It's not the only answer, and it's not the final answer — multi-party trusted setup is queued, EVM parity is queued, and per-payment recipient unlinkability is open research. But it's a working primitive on Solana devnet right now, and the user experience is as boring as it should be: you click Send, you sign once in your wallet, and the recipient gets paid.

The vault is real. The drawers are sealed. The masks are on. Walk in.


Try it now: open the wizard, generate a payment address, top up a dollar, and send some USDC privately. Watch the transaction on Solscan — nothing on the page will tell you what moved, or to whom. That's the point.
Written by the RelAI Team.

Understand x402 before you implement

This guide uses payment primitives from the x402 standard. Read the protocol overview for a complete flow, terminology, and integration FAQ.

    The Bank Vault In The Dark: A Plain-English Metaphor For Private Pool V2 | RelAI