On-chain Privacy: What Monero and Zcash Can Teach Ethereum

Zcash

Launched in 2016 as a fork of Bitcoin Core, Zcash is a blockchain built around a hybrid approach. Like the vast majority of public blockchains, transactions are fully transparent by default.

That said, users have the option to conceal their on-chain activity by using "shielded" addresses. This transaction anonymization relies on a pool system powered by zk-SNARKs.

Transparent vs. Shielded Addresses

In practice, Zcash operates on the coexistence of two address types:

• Transparent addresses (t-addr), identical to Bitcoin's, where sender, recipient, and amount are all visible;
• Shielded addresses (z-addr), where all information is encrypted and invisible to any outside observer.

Privacy on Zcash is therefore optional, and it is entirely possible to use the network without ever touching its privacy features via z-addr.

Pools

Shielded addresses are organized into distinct pools (Sprout, Sapling, and Orchard), each corresponding to a successive iteration of the protocol. These iterations have progressively reduced the cost and complexity of creating transactions.

When a user deposits ZEC into a pool, those funds are said to be "shielded." They can then be transferred to other addresses within that same pool in a fully anonymous manner. Each pool is, however, an isolated environment, meaning the anonymity set is bounded by the volume of ZEC it holds.

To put the evolution of privacy on Zcash into perspective: at the start of 2025, only 12% of ZEC resided in pools. That figure has grown significantly, reaching 30.4% today, with 87.3% of that sitting in the Orchard pool, the protocol's latest iteration.

zk-SNARKs

Within Zcash's privacy pools, all transaction data is encrypted. zk-SNARKs are used to prove validity, including amount consistency and the absence of double-spending, without revealing the underlying content.

The protocol also relies on the concept of "notes," which encode an amount alongside an ownership key. These notes are stored in encrypted form within a Merkle tree whose root is public. In practice, when a user wants to spend a note, they generate a zk-SNARK proof attesting that the note exists in the tree and that they are its rightful owner, without revealing which note it is.

A "nullifier" is also published alongside the proof. It corresponds to a hash of the note and is automatically checked against the set of all existing nullifiers. If it appears for the first time, this proves the note has never been spent before. This mechanism resolves the double-spend problem without ever exposing any information about the transaction.

Limitations of the Zcash Model

Despite theoretically perfect anonymity within a given pool, Zcash has several notable limitations:

• The first pool, Sprout, relied on a trusted setup involving six participants. Had they colluded, they could have minted ZEC out of thin air with no way to detect it. Sapling expanded this process to 90 participants, significantly reducing the risk. The latest pool, Orchard, eliminated this requirement entirely, but it remains formally impossible to prove the exact number of ZEC present in each pool.
• Since privacy is opt-in, the anonymity set is limited to users who have chosen to shield their funds, which can paradoxically make shielded transactions appear more suspicious;
• Transitions between transparent (t-addr) and shielded (z-addr) addresses remain visible, which can allow certain flows to be traced, especially when amounts are identical;
• Despite successive improvements, zk-SNARK computation remains relatively intensive, which can degrade the user experience, particularly on mobile.

---

Monero

Unlike Zcash, Monero enforces mandatory transaction obfuscation. Concretely, this works by burying sender information among a large number of other potential transactions, while simultaneously masking both the transferred amount and the destination address.

The result is probabilistic privacy, whose strength can vary depending on how the system is used, but where every transaction actively contributes to the anonymity set.

Monero's privacy mechanism rests on three pillars: Stealth Addresses, Ring Signatures, and RingCT.

Stealth Addresses

When a Monero user sends XMR, they generate a stealth address, a one-time address derived from the recipient's public key. This address is never reused, and it is impossible for an outside observer to link it back to the recipient's public key.

To identify transactions destined for them, the recipient must "scan" the blockchain using their private key. If they can decrypt a transaction, the funds belong to them. All other transactions remain indecipherable.

Ring Signatures

When signing a transaction, the real output is mixed with fifteen decoys drawn from actual outputs already present on the blockchain, forming a ring of potential signers.

Ring signatures prove that a transaction originated from one member of the group, without making it possible to identify which one. This is precisely what gives Monero its probabilistic privacy character.

Decoy selection is a critical parameter: poorly chosen decoys can significantly increase the probability of identifying the real sender. A recent study found that with certain algorithms, the odds of identifying the correct output could be brought down to roughly 1 in 4.2 on average, highlighting some of the model's inherent limitations.

RingCT

While ring signatures conceal the sender's address, they do not hide transaction amounts, and could potentially be used to identify the output of a given transaction. This is where RingCT, the third pillar of Monero's privacy architecture, steps in.

Introduced in 2017, RingCT hides transaction amounts on Monero through what are known as Pedersen commitments. These allow the protocol to prove that a transaction's inputs and outputs are balanced and that no XMR has been created or destroyed, all without revealing the underlying values in the process.

Limitations of the Monero Model

• Poor decoy selection can increase the probability of identifying the real sender when multiple Stealth Addresses are consolidated within a single transaction. In that scenario, since each output has its own ring, the transaction would reveal that a given output belongs to the same person across multiple rings. This issue is partly addressed by the FCMP++ upgrade, scheduled for 2026, which aims to extend rings to encompass the full set of blockchain outputs;
• Identifying incoming transactions requires scanning the blockchain, which remains more computationally intensive than on Zcash, despite the introduction of view tags in 2022.

---

Zcash or Monero?

Ultimately, these two models are built on radically different philosophies. Zcash offers theoretically perfect confidentiality through zk-SNARKs, but one that depends heavily on pool adoption. In practice today, only 30% of ZEC is shielded, which significantly constrains the anonymity set.

Monero, by contrast, provides generalized privacy where every transaction contributes to the security of the whole, at the cost of probabilistic rather than absolute anonymity. That said, the fact that the entire network participates in the process substantially mitigates the identified limitations.

In the context of a blockchain purpose-built for anonymous payments, Monero's approach appears better suited today. But can this logic be transposed to Ethereum?

---

What Solution for Ethereum?

Two competing proposals have emerged, each drawing on models fairly similar to Monero and Zcash: ERC-5564 and Strawmap.

ERC-5564

Published in August 2022, ERC-5564 proposes introducing stealth addresses similar to those used in Monero. Under this standard, when a user sends funds, a unique address is generated from the recipient's private key.

To avoid having to scan the entire blockchain, these transactions are recorded in a dedicated smart contract. The standard also incorporates view tags to streamline ownership verification.

Limitations of the model

• Unlike Monero, no data is masked: sender, recipient, and amount all remain visible;
• Since stealth addresses are grouped within a single contract, identifying them is trivial, which significantly shrinks the anonymity set;
• These addresses do not hold gas by default, creating usability issues. One potential solution would be to natively include the required gas in the total amount sent in the transaction. Another alternative could involve backing the transaction with a paymaster built on zk-SNARKs, which would theoretically allow gas for a stealth address to be paid without revealing the originating address;
• Since all information is public, consolidating or spending the funds would reveal the true owner of these stealth addresses.

ERC-5564 offers a very partial implementation of the privacy techniques used in Monero. The result is a solution that is ill-suited to the problem, and one that ultimately creates more issues than it solves.

The core reason for this failure is that probabilistic obfuscation techniques only work when applied uniformly across all transactions and all their associated data. For a blockchain like Ethereum, where privacy is not currently a primary objective, this approach has little chance of working in any meaningful way.

Strawmap

Unveiled in February 2026, the Strawmap is a document published by the Ethereum Foundation laying out the five "North Stars" that will guide Ethereum's development through 2029. This paper, which is not set in stone and may evolve over time, positions privacy as one of those five pillars.

To achieve this goal, the envisioned approach draws more from the Zcash model than Monero's. In practice, ETH could be shielded in a pool where transaction details are concealed using cryptographic proofs.

Where it diverges from Zcash, however, is in its use of recursive STARK proofs rather than SNARKs. STARKs, while more computationally intensive to generate, are theoretically resistant to quantum computing, which is why they represent the Ethereum Foundation's preferred approach.

From a privacy standpoint, this is a key differentiator, and would avoid the need to develop new pools in the protocol's early years.

Limitations of the model

• Since STARK proofs are heavier than SNARK proofs, the user experience would be somewhat degraded. The Strawmap does envision integrating precompiles (standardized code snippets) to reduce on-chain gas costs and computational overhead for verifying these proofs;
• The opt-in nature risks limiting adoption, and therefore the number of ETH deposited in the pool, and by extension the anonymity set;
• Only ETH transfers are currently envisioned, with no stablecoin support at this stage;
• Pool entries and exits remain traceable, just as they are on Zcash.

This last point points to a broader problem: privacy is not a door you simply keep closed. It is more like a long, winding corridor. From the moment funds are received to the moment they are sent, there are multiple intermediaries along the way (wallet, RPC, internet service providers, etc.) that can extract information before the blockchain even becomes aware of the transaction.

---

Conclusion

Even if the implementation details remain to be worked out, the Strawmap represents the most robust approach to date for introducing privacy on Ethereum. At this stage, a generalized obfuscation model along the lines of Monero appears difficult to reconcile with the sheer diversity of use cases on the network.

But despite this theoretically sound cryptography, the real challenge will be making these transfers easy to use and affordable, otherwise adoption will remain minimal, mechanically limiting the feature's practical value. This will also require developing ancillary technologies to ensure that privacy holds end-to-end, from the moment a transaction is broadcast to its inclusion in a block.

Finally, tightening compliance requirements, both for retail users on centralized platforms and for institutional investors, will be yet another headwind to contend with on the path to meaningful privacy adoption on Ethereum.