Privacy and compliance in DeFi

1. TL;DR

Every balance and every trade on Ethereum and Solana is public by default, which is exactly what lets strangers trust a smart contract without trusting each other — but it also means anyone can watch anyone else’s entire financial history. Two structurally different fixes have emerged: Ethereum-style privacy pools that hide who made a deposit while letting users cryptographically prove they are not associated with known-bad funds (“proof of innocence”), and Solana’s Token-2022 Confidential Balances extension, which hides how much moved between two still-public addresses and optionally hands a decryption key to a designated auditor. Neither approach can make a shared resource like an AMM pool’s reserves private — zero-knowledge proofs can hide information only one party fully knows, not state that many mutually-untrusting parties must update (barryWhiteHat, 2020-07-24) — and the Tornado Cash saga (OFAC sanctioned it in August 2022, the Fifth Circuit ruled in November 2024 that its immutable code isn’t “property” the U.S. can sanction, OFAC delisted it in March 2025, yet co-founder Roman Storm was still convicted on one charge in July 2025) shows the legal question is not settled just because the cryptographic question increasingly is.

2. Explain it simply

Analogy

Imagine two ways to prove you paid your rent without the whole apartment building seeing your bank balance. The first is Ethereum’s approach: you drop your rent into a shared community box along with everyone else’s contributions, then later withdraw an equivalent amount from the box using a claim ticket that doesn’t say whose deposit it corresponds to — but you can also show the building manager a note proving your ticket isn’t one of the ones flagged as stolen. The second is Solana’s approach: you still hand your rent envelope directly to the landlord in front of everyone, so they and the world know a payment happened between the two of you, but the envelope itself is sealed so only the landlord (and, if configured, a building auditor holding a spare key) can see the amount inside.

ELI5

On most blockchains, anyone can see how much money is in every account and every trade anyone makes, forever. Some tools let you hide the amount you sent, so people can see that a payment happened between two addresses but not how much. Other tools let you hide who made a deposit into a shared pool, so people can see money went in and came out, but not which withdrawal belongs to which deposit. Neither trick can hide a giant shared piggy bank’s total balance, because too many different people need to see that number to agree on what’s true.

Step-by-step walkthrough

Scenario: Alice wants to send 200 confidential USDC tokens to Bob on Solana using the Token-2022 Confidential Balances extension (Solana docs, as of 2026-08 fetch).

1. Before. Alice’s token account shows a public balance of 0 and a confidential balance the public cannot read; she actually holds 500 confidential-enabled USDC tokens encrypted inside her account. Bob’s account exists with Confidential Balances configured but holds nothing yet.
2. Deposit. Alice moves 500 tokens from her public balance into her confidential pending balance, using the Deposit instruction — this step is visible on-chain as a normal transfer amount, since it is the public→confidential boundary.
3. Apply. Alice calls ApplyPendingBalance, converting her 500-token pending balance into her confidential available balance. From here, the 500 is encrypted; the network validates operations on it without learning the value.
4. Confidential transfer. Alice calls Transfer to send 200 (encrypted) tokens to Bob. The transaction is public — everyone can see Alice’s address sent something to Bob’s address — but the amount is not; only Alice, Bob, and (if the mint configured one) an auditor holding the mint’s auditor secret key can decrypt it, since “every confidential transfer includes the amount encrypted for the sender, recipient, and auditor” (Solana docs, 2026-08).
5. After. Alice’s confidential available balance is now 300; Bob’s pending confidential balance is 200 until he applies it, after which he can withdraw some or all of it back to his public balance whenever he chooses. At every step, both account addresses stayed fully public — only the amounts were hidden.

Common misconceptions

• Myth: A privacy pool or confidential-transfer tool is inherently a tool for hiding illicit funds. Reality: The privacy pools design lets users prove their funds are not associated with a known-bad set, which its authors argue gives regulators a better signal than a fully opaque mixer ever could (ameensol, 2025-04-09).
• Myth: Zero-knowledge proofs can make any smart contract fully private. Reality: A ZKP proves what you already know; it cannot make a value private if many mutually-untrusting parties must all update and verify it, which is exactly what an AMM pool’s shared reserves require (barryWhiteHat, 2020-07-24).
• Myth: Solana’s Confidential Balances make a wallet anonymous. Reality: “Token account addresses remain public” — only the transfer amount and balance are hidden, not who is transacting with whom (Solana docs, 2026-08).
• Myth: An auditor key on a confidential mint only sees what it’s told to see. Reality: Once configured, “the holder of the auditor secret key can decrypt transfer amounts for that mint” for every transfer under that mint, and rotating the key only protects future transfers — historical keys must still be safeguarded to preserve past confidentiality (Solana docs, 2026-08).
• Myth: A pseudonymous address is already private. Reality: ml-sudocode calls this “the false sense of privacy” phenomenon, comparing it to early Bitcoin users who “mistook pseudonymity for anonymity” (ethresear.ch, 2025-04-14).

If you only remember one thing

You can hide who did something or how much they did, but no cryptographic trick lets many mutually-distrusting parties share one balance sheet that none of them can see.

3. How it works

The structural limit: private execution vs. private global state

barryWhiteHat’s foundational argument is that the EVM (and by extension any account-based chain) has two components: execution, which mixes private user input with global state; and the global state itself, which every participant able to update the contract must know in order to prove they updated it correctly. A zero-knowledge proof “let[s] you have a private execution. But they don’t let you have private global state” (barryWhiteHat, 2020-07-24). His worked example: a constant-product pool holding 1 ETH and 1 DAI is observed to hold 2 ETH and 0.5 DAI after one unseen transaction — an onlooker who knows only the two states can deduce the depositor added 1 ETH and withdrew 0.5 DAI, with no need to see the transaction itself. Anyone able to act on a pool must know its state to prove their action is valid, and anyone who knows the state before and after a transition can infer what happened inside it. This is why every design discussed below either (a) avoids shared global state (Ethereum’s pools keep only user-specific commitments, not a shared spendable balance) or (b) hides only user-specific amounts while leaving the transacting addresses and instruction structure public (Solana’s Confidential Balances). Ecosystem replies to this 2020 post extended it: order-book exchanges have the same problem via the top-of-book fill state (Recmo, 2020-07-24), and some constructions (ZEXE) can reveal even less — “the only thing onlookers learn is that a party was interested in performing a trade for A to B,” not even the amount (Pratyush, 2020-08-01) — at the cost of much heavier cryptographic machinery.

Ethereum: association sets and proof of innocence

Rather than hiding a shared balance, Ethereum-style privacy pools hide which of many prior deposits corresponds to a given withdrawal, using a Merkle tree of deposit commitments and a zero-knowledge proof of membership (the mechanism Tornado Cash pioneered). The Privacy Pools proposal (Buterin, Nadler, Schär, and ameensol) adds a second proof: on withdrawal, a user proves their deposit is a member of an association set — all deposits except those on a public blocklist of known-illicit addresses — without revealing which specific deposit is theirs (ameensol, 2025-04-09, summarizing the Privacy Pools paper). ameensol’s 2022 post frames the two building blocks generically: an allowlist proactively restricts who may deposit (token-gated, Proof-of-Humanity, or KYC-credential-gated), while a blocklist reactively restricts withdrawals from deposits later found to be tainted, requiring “a time delay (e.g. 1 week) between deposits and withdrawals” so tainted funds can be identified before they can exit (ameensol, 2022-09-04). The withdrawal proof must show three things at once: the deposit is valid and unspent, the time delay has elapsed, and the deposit is not a blocklist member. A 2025 roadmap thread shows the debate has moved from “should this exist” to “should it be a default, protocol-level feature of L1 or an opt-in application” — pcaversaccio’s roadmap argues Ethereum “must provide privacy unconditionally,” while Vitalik Buterin published a parallel, narrower “maximally simple L1 privacy roadmap” the same week, explicitly framed as complementary rather than competing (vbuterin, 2025-04-11).

Solana: confidential balances via encrypted, auditable amounts

Solana’s Token-2022 Confidential Balances extension takes the opposite design point: identities stay fully public, only amounts are hidden, and compliance is built into the mint itself rather than bolted on as an external attestation system. The eight-step flow (create mint → create accounts → mint publicly → deposit to pending confidential balance → apply to available confidential balance → confidentially transfer → apply → withdraw to public balance) uses homomorphically-encrypted balances (ElGamal ciphertexts) so the network can validate that a sender’s balance doesn’t go negative and a receiver’s doesn’t overflow without ever decrypting either value. A mint can optionally register a global auditor public key; every confidential transfer under that mint then carries three parallel encryptions of the same amount — one each for sender, recipient, and auditor — with a proof that all three ciphertexts agree, so “the public still cannot read the amount, but the holder of the auditor secret key can decrypt transfer amounts for that mint” (Solana docs, 2026-08). Because a key rotation “applies only to future transfers,” an issuer that wants durable regulatory visibility must retain every historical auditor secret key it has ever used (Solana docs, 2026-08) — the mirror image of Ethereum’s blocklist, which grows more restrictive over time as more addresses are added, rather than more permissive.

A proposed compliance layer: CRAI

A 2024 EEA-linked framework, summarized on ethresear.ch, proposes attaching “Compliance-Relevant Auxiliary Information” (CRAI) to on-chain transactions via zero-knowledge proofs, verified in real time through a stack of compliance smart-contract wallets, a policy-defining “compliance smart contract system,” and third-party attestation providers (Therecanbeonlyone, 2024-09-11, summarizing the EEA article). The framework is explicitly aspirational — the post lists open questions about proof aggregation, jurisdictional portability, and governance of compliance policies rather than a shipped implementation — but it represents a third pattern distinct from both Ethereum’s association-set model and Solana’s mint-level auditor key: compliance data traveling with the transaction itself as a portable, application-agnostic proof.

4. Worked numeric example

Continuing Alice and Bob’s confidential transfer from §2, made concrete with an auditor configured on the USDC-confidential mint.

1. Alice starts with 500 tokens in her confidential available balance (after the deposit/apply steps in §2); Bob starts at 0.
2. Alice transfers 200 tokens confidentially. The Transfer instruction produces three ElGamal ciphertexts of the value 200: $c_{\text{Alice}} = \text{Enc}(200, pk_{\text{Alice}})$, $c_{\text{Bob}} = \text{Enc}(200, pk_{\text{Bob}})$, and $c_{\text{auditor}} = \text{Enc}(200, pk_{\text{auditor}})$, plus a zero-knowledge proof that all three encrypt the same underlying value and that Alice’s resulting balance ($500 - 200 = 300$) is non-negative.
3. On-chain state after the transfer: Alice’s encrypted available balance updates to represent 300 (nobody but Alice, and the auditor, can decrypt this to confirm it is 300); Bob’s encrypted pending balance updates to represent 200.
4. What each party can see. A public block explorer sees: “Alice’s token account sent an encrypted transfer to Bob’s token account.” It cannot recover the value 200 without either Alice’s, Bob’s, or the auditor’s secret key.
5. What the auditor can see. If a court or regulator compels the auditor (say, the token issuer, holding $sk_{\text{auditor}}$) to decrypt $c_{\text{auditor}}$, they recover exactly 200 — but only for transfers made after that specific auditor key was configured on the mint; transfers made before an auditor key existed, or after it was rotated away, are not covered by that key.
6. Bob later applies his pending balance (200 becomes available) and withdraws 150 of it back to his public balance; that withdrawal instruction, like the original deposit, is visible in cleartext, since it is again a public↔confidential boundary crossing. His remaining 50 stays encrypted.

5. Where it’s used

Ethereum

• Tornado Cash — the original commitment-and-nullifier mixer; historically the largest privacy tool by volume, sanctioned by OFAC in August 2022 and delisted in March 2025 after the Fifth Circuit’s ruling (see §6). [See §6 for the full legal timeline.]
• Privacy Pools / proofofinnocence.com — Buterin, Nadler, Schär, and ameensol’s association-set design, with a public demo implementation letting depositors prove non-membership in a flagged set (ameensol, 2025-04-09).
• Railgun — an exclusion-list-based alternative design referenced in the roadmap debate as a contrasting approach to Privacy Pools’ inclusion-list model (ml-sudocode, 2025-04-14).
• Aztec, Shutter Network, Zama (FHE), Kaleido Paladin, Rayls — a landscape of L2 and mempool-level privacy approaches a 2025 reply lists as prior art Ethereum’s core roadmap should study rather than reinvent (sgrasmann, 2025-04-14).

Solana

• Token-2022 Confidential Balances — the protocol-native extension described in §3, live as a mint-level opt-in feature rather than a separate application (Solana docs, 2026-08).
• Arcium — described in the same 2025 ethresearch reply as “an orthogonal approach to bring in privacy through a separate network,” i.e. confidential computation delegated off the base Solana runtime rather than encrypted in-protocol balances (sgrasmann, 2025-04-14) — cited here as a named contrast, not independently verified against Arcium’s own documentation in this page’s research.

6. Risks, attacks, and incidents

• Tornado Cash sanctions and reversal, August 2022 – March 2025. OFAC’s original designation (2022-08-08) alleged Tornado Cash had laundered “more than $7 billion in virtual currencies,” including $455M linked to the Lazarus Group and $96M linked to the June 2022 Harmony bridge hack (Treasury/OFAC, 2022-08, secondary via Wikipedia). The Fifth Circuit ruled on 2024-11-26 that immutable Tornado Cash smart contracts “do not qualify as ‘property’ under federal law” and that OFAC “lacked authority to sanction Tornado Cash software directly… as opposed to the rogue persons and entities who abuse it” — OFAC formally delisted Tornado Cash on 2025-03-21 while stating it remained “deeply concerned about North Korea’s state-sponsored hacking and money laundering campaign” (secondary, Wikipedia summary, accessed 2026-08-30). Co-founder Roman Storm was nonetheless found guilty on 2025-07 of one charge (conspiracy to operate an unlicensed money-transmitting business) following a three-week trial — the code being ruled outside OFAC’s property-sanctioning authority did not resolve the separate question of a developer’s personal criminal liability for operating it.
• Blocklist governance can be captured. MicahZoltu’s direct rebuttal to the permissioned-pools proposal: “the power to censor individuals will eventually be captured… even though you plan to only use that power for good, eventually bad people will gain control of that power and use it for evil” (MicahZoltu, 2022-09-04) — an unresolved disagreement with ameensol’s own proposal, presented on the same page.
• Anonymity-set quality, not just size, determines real-world usability. ameensol argues that being in an anonymity set that also includes “North Korean hackers” makes it “much harder to get my funds from the anon money system accepted anywhere else (and rightfully so)” — privacy pools try to solve this by letting honest users prove dissociation, but a tool with no dissociation mechanism inherits its worst participants’ reputational risk (ameensol, 2025-04-09).
• Auditor-key compromise or legal compulsion retroactively deanonymizes a mint’s history. Because “auditor keys provide read access” and rotation only protects future transfers (Solana docs, 2026-08), every historical auditor secret key generated for a given mint remains a standing risk: if any one of them is ever leaked, subpoenaed, or brute-forced, every transfer made while it was active becomes readable.
• False sense of privacy. ml-sudocode warns that stacking multiple imperfect privacy tools “even if those tools are misconfigured, outdated, or overlapping ineffectively” can create dangerous overconfidence, comparing it to early Bitcoin users conflating pseudonymity with anonymity (ethresear.ch, 2025-04-14).
• Regulatory tightening on privacy-preserving assets more broadly. A 2025 reply cites reporting on a proposed EU restriction on anonymity-enhancing tokens (referenced as a 2027 effective date in the linked Cointelegraph headline), used by the poster to argue that governments increasingly favor “centralized, surveillance-friendly” designs over genuinely private ones — an opinion attributed to that participant (kladkogex, 2025-05-05), not independently verified against EU legislative text in this page’s research.

7. Open problems

• Should privacy be an L1-enshrined default or an opt-in application-layer feature? pcaversaccio’s roadmap argues for unconditional, default privacy at the base layer; EmperorOrokuSaki counters that “it is also worth considering paths forward that do not depend on protocol-level consensus,” citing probabilistic, non-enshrined systems like Mirage as faster to ship (ethresear.ch, 2025-04-09/2025-04-14) — genuinely unresolved in the source thread itself.
• Can a compliance framework avoid recreating a centralized honeypot? ameensol concedes that requiring all privacy-pool users to reveal transaction history to a financial authority “creates a government-owned honeypot of all the tx history which itself can be leaked or abused, and is thus not an ideal solution” — the association-set design is his attempt to avoid this, but whether it fully succeeds is contested even among privacy advocates (ameensol, 2025-04-09).
• Is a private AMM or order book possible at all, or only weaker approximations? barryWhiteHat’s 2020 impossibility argument for fully private shared state stands largely unrebutted five years later in the roadmap thread; partial constructions (ZEXE-style trade-intent-only privacy) trade off completeness for feasibility, and no source reviewed here claims a full solution exists (barryWhiteHat, 2020-07-24; Pratyush, 2020-08-01).
• What is the actual adoption threshold — the “killer app” for privacy UX? ml-sudocode’s open question — “what’s our killer app?” — remains unanswered in the sources: most people “want privacy, but are not willing to pay the UX cost” absent a forcing function (ethresear.ch, 2025-04-14).
• Whether developer liability can be separated from protocol liability. The Fifth Circuit resolved that Tornado Cash’s code isn’t sanctionable “property,” but Roman Storm’s 2025 conviction on a related but distinct charge shows the question of personal liability for building and operating privacy infrastructure remains open even where the code itself is protected.

8. Ethereum vs Solana

Aspect	Ethereum	Solana
What is hidden	Depositor/withdrawer identity (deposit-withdrawal unlinkability); amounts often exposed via fixed-denomination pools	Transfer amount and balance; sender/recipient addresses stay public
Compliance hook	External association-set / blocklist proofs (Privacy Pools), proposed portable CRAI proofs	Built into the token standard: an optional auditor ElGamal key set at the mint level
Deployment status (as of 2026-08)	Roadmap and application-layer debate (Tornado Cash’s legacy, Privacy Pools demo, Railgun); no L1-enshrined privacy shipped	Shipped as a live Token-2022 extension usable by any issuer today
Structural limit	Cannot hide shared/global contract state (AMM reserves, order-book state) — proven, not just unimplemented	Same limit applies one level down: DEX pool state built on confidential tokens would still leak via the pool’s own public reserves
Legal exposure precedent	Tornado Cash: code ruled not “property” (2024), but a developer still held personally liable (2025)	No comparable Solana Confidential Balances legal test documented in this page’s sources

Ethereum’s privacy tooling has been forged largely in public conflict with regulators and courts, producing a legally battle-tested (if still contested) framework for proving non-association with illicit funds. Solana instead built optional, auditor-aware confidentiality directly into its token standard from the start, trading some of Ethereum’s stronger identity-privacy guarantees for a design that compliance-minded issuers can adopt without needing a separate mixer, an association set, or a court ruling to legitimize it.

9. Reference doc

The reference

Ethereum Privacy: The Road to Self-Sovereignty — pcaversaccio, with extensive community discussion (ameensol, Vitalik Buterin, and others), 9 April 2025. ethresear.ch/t/22115

Summary of the reference

The original post is short and declarative: Ethereum “must provide privacy unconditionally, without forcing users to prove their innocence,” arguing privacy should be “the default state of the network” rather than an opt-in feature, and links out to a longer HackMD roadmap for the specific technical steps (starting with a more privacy-friendly transaction format, since even gas/mana parameters currently leak information). The thread’s value is almost entirely in the reply chain, which surfaces the field’s live disagreements rather than a single settled position.

ameensol’s reply (the most-engaged response) directly challenges the “unconditional” framing: he argues privacy by default at L1 is a bad idea unless paired with tools letting users voluntarily dissociate from bad actors, since without dissociation “we are actually the ones forcing users to provide privacy to other users (including DeFi hackers, terrorists, and… North Korea) just to access privacy themselves.” He roots this in the difference between encryption (works alone) and anonymous money (value is “socially derived from the participation of other users”), and summarizes the Privacy Pools paper’s core idea: let users publicly prove which deposits they are not, avoiding both full transparency and a centralized transaction-history honeypot. EmperorOrokuSaki’s reply pushes back on scope, arguing “privacy” conflates several distinct concerns (anonymity, tool-usage privacy, interaction privacy) and that non-protocol-level, probabilistic approaches (citing his own project, Mirage) can deliver value faster than waiting on L1 consensus. Vitalik Buterin’s reply (2025-04-11) discloses a parallel “maximally simple L1 privacy roadmap,” explicitly framed as complementary. kladkogex raises a UX-and-implementation-complexity objection, arguing big changes are hard to sell and proposing narrower, wallet-level defaults (e.g. MetaMask auto-generating shielded transaction addresses) instead. ml-sudocode’s reply raises the “false sense of privacy” risk and the unresolved UX-adoption question (“what’s our killer app?”). sgrasmann’s reply is a market-awareness corrective, listing Aztec, Rayls, Kaleido’s Paladin, Zama’s FHE approach, Shutter Network, and — pointedly — Solana’s own “Confidential Balances Token Extensions” and Arcium as prior art Ethereum should study rather than reinvent.

Key quotes

“Ethereum must provide privacy unconditionally, without forcing users to prove their innocence.” (original post)

“I think privacy by default at the L1 is a bad idea—unless we also build tools that allow (not force) users to dissociate from other users.” (Reply #2, ameensol)

“So [the] value I get from the anon money system is actually socially derived from the participation of other users, and thus the quality of my anonymity set matters, not just the quantity.” (Reply #2, ameensol)

“Once created, the power to censor individuals will eventually be captured.” (Reply #2 on the related Permissioned Privacy Pools thread, MicahZoltu, 2022-09-04)

How to read the original

Background needed: what a commitment/nullifier mixer (Tornado Cash) does, and roughly what a zero-knowledge membership proof is. What to skip on a first pass: the UI/UX screenshots referenced in kladkogex’s replies (images not reproduced in the archived text) and the tangential closing reply about rollup decentralization, which is unrelated to the privacy roadmap itself. The hardest passage to parse is ameensol’s distinction between encryption and anonymous money — read it slowly, since the claim that anonymity’s value (not just its cryptographic soundness) depends on who else is in your anonymity set is the single idea that most of the thread’s later disagreements trace back to.

What changed since

• Tornado Cash’s legal status changed materially after this thread’s core debate: the Fifth Circuit’s ruling (2024-11) predates this post, but OFAC’s delisting (2025-03) and Roman Storm’s conviction (2025-07) both postdate it, meaning the thread’s real-world backdrop kept shifting even as the roadmap discussion continued.
• Vitalik Buterin’s own parallel roadmap (linked within this thread, 2025-04-11) has since become a more frequently cited reference point than this post itself in later Ethereum privacy discussions, per the thread’s own framing of the two as complementary rather than one superseding the other.
• Solana’s Confidential Balances extension, mentioned only in passing by sgrasmann as market context, is documented in full elsewhere in this page (Solana docs, 2026-08) as a second, independently-canonical reference — see below.

The reference

Confidential Balances — Solana documentation, fetched 2026-08-29. solana.com/docs/tokens/extensions/confidential-transfer

Summary of the reference

This is a live product-documentation page, not a research thread, and its structure is a straightforward mechanism description rather than a debate. It opens by scoping exactly what is and isn’t hidden: “Confidential Balances is a Token-2022 extension that lets you transfer tokens between token accounts without revealing the transfer amount… Only transfer amounts and token balances are private. Token account addresses remain public.” The basic flow is presented as an eight-step sequence (create mint → create accounts → mint → deposit to pending → apply to available → confidential transfer → apply → withdraw), reproduced in full in §3 and §4 of this page. The page then documents “Auditor keys” as a first-class mint-level feature: an optional global ElGamal public key that, when configured, causes every confidential transfer to include a third ciphertext of the amount (alongside the sender’s and recipient’s), verified by the transfer proof to match the other two. The authority controlling this key can rotate or clear it at will, but a rotation is explicitly not retroactive — “retain prior secret keys when historical audit access is required” — placing the durability burden of compliance visibility on whoever manages the keys, not on the protocol. The page closes with a full instruction reference table (InitializeMint, ConfigureAccount, Deposit, Withdraw, Transfer, ApplyPendingBalance, and related enable/disable-credit instructions), and links out to a separate protocol-overview page, a CLI quick-start, a sample-code cookbook, and dedicated issuer and integration guides for wallets, explorers, and exchanges.

Key quotes

“Confidential Balances is a Token-2022 extension that lets you transfer tokens between token accounts without revealing the transfer amount.” (§ What are Confidential Balances?)

“Only transfer amounts and token balances are private. Token account addresses remain public.” (§ What are Confidential Balances?)

“The public still cannot read the amount, but the holder of the auditor secret key can decrypt transfer amounts for that mint.” (§ Auditor keys)

“Auditor keys provide read access; they do not authorize token transfers or reveal an account’s full confidential balance.” (§ Auditor keys)

How to read the original

Background needed: what ElGamal encryption and a zero-knowledge range proof are for at a conceptual level (you don’t need the math, just that “encrypted balance + proof it’s valid” is the pattern). What to skip on a first pass: the full instruction reference table and the linked issuer/integration guides, which are implementation references rather than conceptual material. The hardest part to internalize is the pending-vs-available balance split (§3, steps 2–3 and 7): it exists so that incoming confidential transfers can’t be used to grief an account’s ability to prove correct decryption before the recipient has explicitly “applied” them, but on first read it looks like unnecessary extra steps.

What changed since

• This is current, actively maintained product documentation rather than a historical research artifact — the main change to track going forward is adoption: which issuers (stablecoins, RWA tokens) actually configure an auditor key by default versus leaving transfers unauditable.
• The confidential-balances model is referenced as prior art in Ethereum’s own 2025 privacy roadmap debate (sgrasmann, 2025-04-14, in the reference above), suggesting cross-pollination between the two ecosystems’ approaches is already underway rather than purely hypothetical.

Secondary references

1. ameensol, “Permissioned Privacy Pools” (ethresear.ch, 2022-09-04) — read for the allowlist/blocklist mechanics behind the “proof of innocence” idea in more implementation detail than the 2025 roadmap thread provides.
2. barryWhiteHat, “Why you can’t build a private uniswap with ZKPs” (ethresear.ch, 2020-07-24) — read first if you want the foundational impossibility argument this entire page’s §3 structural-limit section is built on.
3. Therecanbeonlyone, “Resolving the Dichotomy: DeFi Compliance under Zero Knowledge” (ethresear.ch, 2024-09-11) — read if you want the most concrete (if still aspirational) sketch of a portable, application-agnostic ZK compliance layer (CRAI).

10. Sources

• Ethereum Privacy: The Road to Self-Sovereignty — pcaversaccio, ameensol, vbuterin, et al. — 2025-04-09 — https://ethresear.ch/t/ethereum-privacy-the-road-to-self-sovereignty/22115
• Permissioned Privacy Pools — ameensol — 2022-09-04 — https://ethresear.ch/t/permissioned-privacy-pools/13572
• Resolving the Dichotomy: DeFi Compliance under Zero Knowledge — Therecanbeonlyone — 2024-09-11 — https://ethresear.ch/t/resolving-the-dichotomy-defi-compliance-under-zero-knowledge/20413
• Why you can’t build a private uniswap with ZKPs — barryWhiteHat — 2020-07-24 — https://ethresear.ch/t/why-you-cant-build-a-private-uniswap-with-zkps/7754
• Confidential Balances — Solana documentation — fetched 2026-08-29 — https://solana.com/docs/tokens/extensions/confidential-transfer
• Tornado Cash (timeline of OFAC designation, Fifth Circuit ruling, delisting, Roman Storm conviction) — Wikipedia (secondary) — accessed 2026-08-30 — https://en.wikipedia.org/wiki/Tornado_Cash