Compliant privacy on Solana: viewing keys and selective disclosure
After Tornado Cash, Solana privacy converged on auditability — auditor keys, viewing-key hierarchies, and selective disclosure. The pattern that lets privacy survive contact with regulators.
There's a pattern running through every privacy tool that actually ships on Solana in 2026, and it isn't "hide everything." It's privacy you can selectively disclose — hidden from the public, revealable to an auditor, a counterparty, or yourself. Understanding why is the difference between building privacy that lasts and privacy that gets sanctioned.
Why: the Tornado chill
Tornado Cash was OFAC-sanctioned in 2022. A mixer with no way to prove innocence put its users — and its relayers — in legal jeopardy. It was delisted in 2025 after an appellate court ruled Treasury had overreached in sanctioning immutable open-source contracts, and by 2026 Treasury acknowledged mixers have legitimate uses. But the lesson stuck: unaccountable privacy is a liability. So Solana's privacy ecosystem built the accountability in from the start.
The three disclosure mechanisms
Auditor keys (Token-2022 Confidential Transfers)
The confidential transfer extension bakes in an optional, per-mint auditor key: every transfer amount is encrypted under the sender, the receiver, and the auditor key, so a designated auditor (a compliance team, a regulator) can decrypt amounts without breaking privacy for everyone else. Compliance is a protocol feature, not a bolt-on.
Viewing-key hierarchies (Umbra)
Umbra generalizes this into a tree. A Master Viewing Key can see everything; from it you derive narrower keys — per-address, time-scoped, or even single-transaction. You hand an auditor a key that reveals exactly the window they need and nothing else:
Master Viewing Key (you — sees all your shielded activity)
├─ per-address viewing key (reveal one receiving address's history)
├─ time-scoped viewing key (reveal Jan–Mar 2026 only)
└─ single-tx viewing key (prove ONE transfer to a counterparty)That granularity is the whole pitch: prove a payment to your accountant without exposing your balance, or satisfy an audit for one quarter without surrendering your entire history.
Compliance-aware mixers (Privacy Cash)
Even the shielded-pool model adapted: Privacy Cash markets OFAC-aware, selective-disclosure design rather than pure anonymity — proof-of-innocence-style mechanics that let honest users demonstrate their funds aren't from a sanctioned source. (How much is enforced vs marketed is worth verifying for any specific tool — treat claims skeptically.)
The mental model: who can see what
Public chain Counterparty Auditor (with key) You
amount hidden sees own decrypts sees all
parties varies knows self reveals on disclosure sees all
full history hidden no scoped to the key yesThe design goal is to make each column independently controllable — public sees the minimum, an auditor sees a scoped window, you see everything. That's "selective disclosure": not a weaker privacy, a configurable one.
The honest read
Purists will say this isn't real privacy — a key that can reveal your activity is a key that can be subpoenaed, leaked, or abused, and a designated auditor is a trusted third party by another name. That's a fair critique: selective disclosure trades some censorship-resistance for survivability. But the alternative — unaccountable mixing — has a track record of getting sanctioned and stranding its users. For real money on Solana, especially anything institutional, compliant privacy isn't a compromise of the vision; it's the only version of it that ships. Just be clear-eyed that the auditor key is now part of your threat model.
References
- Confidential Transfers (auditor keys) · Umbra (viewing keys)
- Private payments after Elusiv · The privacy landscape
The most private thing on Solana isn't the thing nobody can see — it's the thing only the right person can, only when they need to, and only as much as they need.