Why Privacy Projects Are Shifting to Selective Disclosure
Because talking only about absolute privacy no longer works. Either regulators cut off liquidity, or the market marginalizes you. Adopting selective disclosure is the necessary path to transform privacy from a "prohibited item" into a "compliance tool." Behind this is the evolution of the privacy narrative from "complete anonymity" to "privacy by default, with authorized visibility." Here's a breakdown of why this shift is happening and how you, as a user, should recognize and respond to it.
1. First, determine which generation your privacy project belongs to
Different generations of privacy solutions face completely different compliance fates.
- First generation: Absolute privacy Tools like Tornado Cash and Monero create a fully opaque "privacy pool" where all transaction data is encrypted and invisible to outsiders, including regulators. The problem: mixing dirty money and legitimate funds through the same privacy channel turns privacy tools into money-laundering instruments. In 2022, Tornado Cash was sanctioned by the U.S. Treasury, developers were arrested, and front-end interfaces, integrators, and custodians withdrew, shrinking the ecosystem and weakening the actual protection of privacy systems.
- Second generation: Opt-in Privacy Zcash's dual-address approach (transparent + shielded) lets users choose: use shielded addresses for absolute privacy, or transparent addresses for compliance. But adoption is difficult — using shielded addresses when transparent ones exist is like pinning a "hidden secret" sign on yourself, making privacy a privilege for the few rather than a default for all.
- Third generation: Privacy by Default + Selective Disclosure This is the current mainstream direction. Privacy is the default, while allowing users to prove necessary information to auditors, counterparties, or regulators when compliance requires. Aztec, Umbra, Starknet's STRK20 standard, and Circle's upcoming Arc Privacy all follow this path.
2. Understand what "selective disclosure" solves
The core contradiction: under traditional frameworks, compliance and privacy are in conflict — you can't have privacy while cooperating with regulators, and to be compliant you must hand over all data. Selective disclosure breaks this binary opposition.
- Regulatory pressure: Europe's Anti-Money Laundering Regulation, effective 2027, sets a clear timetable for anonymous wallets and "privacy-enhancing tools." The U.S. Treasury, under the GENIUS Act, is seeking input on digital identity verification. If a privacy solution has no compliance outlet, it will be isolated from the financial system.
- Barriers to institutional adoption: Circle explicitly notes that blockchain's default full transparency hinders institutional adoption. Institutions cannot accept "anyone can see my clients' transaction details," nor can they accept "complete inability to audit." Selective disclosure sits right in the middle.
- User autonomy: Academic research proposes a "Grant-Verify-Revoke" lifecycle model, turning compliance from "permanently surrendering data" into "revocable authorized sessions." Aztec goes further: users hold data, generate proofs locally, and disclose only a single fact (e.g., "my profit is X") when needed, without revealing the entire portfolio.
3. How to discern whether "selective disclosure" is implemented technically
Not all projects claiming "selective disclosure" are created equal. You need to judge along three dimensions whether the switch is truly in your hands or handed to an intermediary.
| Dimension | User-controlled | Intermediary-controlled |
|---|---|---|
| Who can see your raw data? | Only you (client-side encryption, local proofs) | Operator/node reads in plaintext |
| Who can verify the network runs by the rules? | Any third party via on-chain proofs | Must trust the operator is honest |
| Who controls the timing of disclosure? | You generate proofs on demand, selectively disclose | Operator or auditor holding a "viewing key" can decrypt at any time |
Aztec is currently the only network that answers all three layers with user control — no operator reads plaintext, no persistent viewing key exists, and users precisely control who sees what, and within which application scope, via application-specific tagging keys. In contrast, Starknet's STRK20 uses client-side proofs but includes a "persistent viewing key" that allows a designated auditor to decrypt a user's entire history. Solutions like Canton and Tempo have nodes reading data in plaintext, with user privacy relying on the promise that "the operator looked but pretended not to see."
4. Common misconceptions and risk reminders
- Misconception: selective disclosure = anyone can see at will. It doesn't mean "anyone can look anytime," but "you actively choose under what conditions, to whom, and what information to disclose." Umbra's model is "privacy by default, with the ability to disclose necessary information to auditors, counterparties, or competent authorities when legally required."
- Risk: who controls the "viewing authority"? If viewing authority exists, someone must control it. The real tough issues aren't technical but operational and legal: who can authorize disclosure? Who can be compelled to disclose? If denied, who bears the legal liability? The answers determine whether your privacy switch is truly in your hands.
- Cross-application correlation risk: If you use the same zero-knowledge identity proof (the same nullifier) across multiple applications, these applications could infer that operations come from the same person through public fields, partially deanonymizing you. Some schemes have solved this with "application-specific nullifiers," but it's not universally implemented — confirm before use.
How to confirm you've correctly understood and made the right operational choices:
Next time you see a project claiming "privacy + compliance," ask it three questions: Who can see my raw data? Who can prove the network runs by the rules? Who controls the timing and target of information disclosure? If the answers point to an operator, audit node, or any third party, the privacy switch isn't in your hands. If the answers are all "yourself," and it can demonstrate specific client-side proof flows and verifiable on-chain audit mechanisms, only then does it truly implement selective disclosure correctly. There are already real-world use cases: Aztec has a PnL proof scheme based on tagging-key disclosure, allowing an auditor to verify the profit figure without seeing your full holdings.
