Why Crypto Privacy Tooling Fragmented — and What Aggregation Solves

TL;DR

• Privacy protocols fragment because they optimize for different guarantees.
• Their anonymity sets, infrastructure, and chain coverage cannot simply be merged.
• Aggregation improves route discovery and access, but it does not standardize privacy guarantees.

Anyone who has tried to move value privately on-chain runs into the same wall. You find a protocol that does exactly what you need, and then discover it only works on one chain. Or it supports one asset. Or it handles same-chain transfers but not the cross-chain move you actually wanted. So you find a second tool. Then a third.

Crypto privacy tooling did not fragment because every project failed at the same goal. It is fragmented because different systems place privacy in different parts of the stack and accept different constraints in exchange. The practical question is therefore not only which protocol is strongest, but how a user reaches the appropriate privacy model for a specific transfer.

How the landscape ended up this way

Four distinct approaches emerged, each solving something the previous one couldn't.

Chain-native privacy

Chain-native privacy builds concealment into the base layer. Monero applies ring signatures, stealth addresses, and confidential amounts to every transaction, with no opt-in step. The design decision that matters most here is the absence of a choice: because privacy is mandatory, every user contributes to everyone else's. Opt-in systems have the opposite property, and it costs them — a privacy feature that most users skip produces a small crowd to hide in.

The constraint is that this privacy lives in the protocol, so it applies to that protocol's asset on that protocol's chain. It does nothing for the USDC in your Ethereum wallet.

Shielded pools

Shielded pools brought zero-knowledge privacy to chains with transparent ledgers. Zcash pioneered the model with zk-SNARKs, maintaining a shielded environment alongside a public one.

The instructive detail is what happened next. Zcash has run more than one shielded pool over its lifetime — Sprout, then Sapling, then Orchard — with each cryptographic upgrade introducing a new pool rather than extending the old one. Funds have to be migrated between them, and until they are, the anonymity set is split across pools.

This is fragmentation occurring inside a single protocol on a single chain, driven purely by the need to improve the cryptography. It is not a mistake anyone made. It is what upgrading a privacy system costs.

Confidential computation

Confidential computation takes a different route: keep data encrypted while computing on it, rather than concealing transactions after the fact. Fully homomorphic encryption and multi-party computation make private application state possible, not just private transfers.

The constraint is arithmetic. Operating on encrypted data is dramatically more expensive than operating on plaintext, and the gap is large enough that these systems start with narrow use cases and expand as the cost curve improves.

Compliance-aware designs

Compliance-aware designs address a problem the earlier generations largely ignored. The Privacy Pools model proposed by Buterin, Illum, Nadler, Schär, and Soleimani lets a user prove their funds do belong to an approved set of deposits — or do not belong to a flagged one — without revealing which deposit is theirs.

The mechanism is a membership proof against an association set, and it separates two things that had previously been bundled: concealment from the public, and the ability to answer a legitimate question.

The constraint is that this only works where someone maintains the association sets, which introduces a party the earlier designs didn't have.

What each generation was actually optimizing for

Read as a sequence, these look like successive attempts at one goal. They aren't. Each maximizes something different, and the trade-off it accepts determines which transfers it suits.

• Chain-native privacy optimizes for default coverage. It requires control of the base layer, which is why it comes with its own chain. It sacrifices asset flexibility entirely — you get one asset, in one execution environment. It suits users willing to stay inside that environment, and it is the strongest option available when they are.

• Shielded pools optimize for asset flexibility on existing chains. They require per-chain contract deployment, provers, and often relayer infrastructure. They sacrifice set concentration, since every deployment starts a new anonymity set from zero. They suit users whose value already sits on a smart contract chain and who transact repeatedly enough to benefit from a pool that has accumulated depth.

• Confidential computation optimizes for programmability. It requires a new execution environment rather than a contract on an existing one. It sacrifices cost efficiency and, for now, ecosystem maturity. It suits applications where the private thing is the logic or the state — a sealed auction, a confidential position — rather than a transfer.

• Compliance-aware designs optimize for institutional viability. They require an association set provider or an equivalent attestation layer. They sacrifice the property some users specifically want, which is concealment from everyone without exception. They suit anyone whose funds will eventually touch a regulated venue, which is most people moving meaningful value.

No design maximizes more than one of these. That isn't a shortcoming in any individual project; it's what specialization means.

Why the gaps don't close

One force explains most of the fragmentation, and it is not the one people usually cite.

Anonymity sets don't merge

A shielded pool's privacy is a function of how many users share it — your transaction is concealed among the others. Two pools on two chains do not combine their sets. Deploying the same protocol across ten chains produces ten smaller pools rather than one large one, and each is weaker than the single pool would have been.

The gap between nominal and effective set size is larger than most users assume. Empirical analysis of Zcash by Kappos, Yousaf, Maller and Meiklejohn found that a substantial share of shielded activity could be attributed to founders and miners, whose behaviour followed predictable patterns and could therefore be excluded from analysis — shrinking the effective anonymity set available to ordinary users well below the headline figure.

The set you are actually hiding in is not the set you can count.

This has an uncomfortable implication that runs against most privacy marketing. Fragmentation is not purely an implementation failure. In some cases it is a deliberate privacy decision: concentrating activity in fewer deployments may produce stronger privacy than maximizing nominal chain coverage.

A protocol that supports three chains well may offer better real privacy than one advertising twenty.

Two further forces compound the problem rather than explaining it.

Deployment is expensive and repetitive

A privacy protocol is not a token that can be bridged. It is contracts, provers, relayers, and frequently off-chain infrastructure, each of which must be redeployed, re-audited, and supported per chain.

Teams prioritize by demand, which concentrates coverage where volume already is.

Cross-chain privacy is a harder problem

It involves two public ledgers, something in between, and correlation risk at both endpoints. Most privacy protocols are built for one chain.

Some use other approaches — intent-based routing, intermediary assets, coordinated shielded transfers.

What aggregation changes

Consider a specific transfer. A user wants to move an asset from one chain to another, and three routes are technically available:

• A shielded pool with strong concealment that doesn't support the destination chain.
• An intermediary route with much broader coverage but visible endpoints.
• A compliance-aware provider that supports selective disclosure but requires an association set.

These are not equivalent options with different prices. They conceal different things, expose different things, and suit different intentions.

• The first is unusable for this transfer regardless of its quality.
• The second works but leaves a correlatable trail at both ends.
• The third works and preserves the ability to demonstrate provenance later, at the cost of a dependency.

Aggregation does not make these routes equivalent. It makes the differences visible before the user commits to one — which is the actual problem, because the alternative is discovering the constraint after the transfer, or never learning that the third option existed.

Aggregation in practice

This is the layer Baltex works in, and the reason we work in it: routing across privacy providers rather than building another protocol to add to the pile.

We are not the only ones who reached that conclusion, and the model is worth understanding independently of any one implementation.

Rubic Private Mode is a useful reference point for the argument, not because it replaces the underlying privacy providers, but because it exposes several of them through routing layers.

The user still inherits the privacy assumptions, coverage limits, and metadata exposure of whichever provider the selected route uses.

It is designed for users who want their trading activity shielded from other market participants while remaining compatible with selective disclosure to auditors and counterparties, and transactions remain pseudonymous rather than anonymous.

What the product changes is discovery and access. What it does not change is that heterogeneous privacy methods stay heterogeneous — aggregation does not convert them into one uniform guarantee.

What aggregation doesn't change

The limits of the model are also, read correctly, the criteria for judging anyone operating in it.

The provider defines the privacy model

The aggregator must name it. Routing to a protocol doesn't improve that protocol. If a route uses a pool with a thin anonymity set, aggregating it does not thicken the set.

An aggregator that presents routes without identifying which provider is behind each one has removed the only information the user needs to evaluate what they're getting.

Coverage cannot be manufactured

Gaps should be stated rather than papered over. If no protocol supports a chain, no aggregator can route there.

Presenting a weaker substitute without saying it is a substitute misleads.

Metadata correlation survives every route

It belongs in the disclosure. Timing patterns and distinctive amounts link transactions regardless of the cryptography involved.

Depositing an unusual amount and withdrawing the same unusual amount shortly afterward is correlatable whatever sits in between.

Zcash's own documentation is direct about this, recommending against leaking amounts, transaction identifiers, and counterparty details even when using shielded addresses.

Endpoints stay exposed

This makes off-ramp behaviour part of the picture. Where funds originate and where they land are usually visible.

Academic work on tracing transactions across ledgers demonstrates how much can be reconstructed from the transparent segments surrounding a private one.

There is a further consequence that is inconvenient for anyone selling this category, including us.

A responsible aggregator should sometimes return no suitable route.

If every available provider exposes a property the user specifically needs to conceal, presenting the least-bad option as "private" is not a service.

It is a misrepresentation that the user will only discover after it matters.

The realistic picture

Privacy tooling is fragmented because the underlying problems are genuinely different, and because the economics of anonymity sets actively reward staying narrow.

Neither of those is reversing. A single protocol covering every chain, asset, and transfer type is not on the horizon, and the incentives point away from one appearing.

That makes the relevant question about aggregators different from the one usually asked. It is not whether a layer offers "privacy" in the abstract — every product in this category claims that.

It is whether it:

• Identifies the provider behind each route.
• Explains what that provider conceals.
• Discloses what remains observable.
• Declines to route when nothing available actually fits.

Aggregation becomes valuable at the point where it makes heterogeneous privacy guarantees legible rather than flattening them into a single label.

Whether any given implementation clears that bar is a question worth asking directly, and the answer should be checkable in the interface rather than in the marketing.