Privacy Onchain: A Map of the Tradeoff Space

TL;DR: Confidential transactions are becoming a requirement for a growing set of onchain use cases, from payroll to institutional settlement. The good news: there are now many ways to build them, and the field is maturing fast. Every architecture makes different tradeoffs. This post maps the landscape (consortium networks, private chains, validiums, and application-layer designs) and closes with how we think about privacy on the OP Stack: public by default, private where it matters, provable when required.

Transparency was the right default

Public blockchains publish every transaction by design, and that design is what makes them work. Transparency is how a chain proves its own integrity without trusted parties: anyone can verify the rules are being followed, anyone can participate, and liquidity pools in one open venue instead of fragmenting across walled gardens. Verifiability, permissionless access, and network effects all flow from the same property.

That same property makes chains legible in ways some workloads aren't built for. Pay your team from a company wallet and every salary is queryable. Run a trading desk and your order flow is visible to front-running bots in real time. Settle institutional volume and your counterparties can read your positions. Regulators are attentive to this too: GDPR and the EDPB's 2025 blockchain guidelines call for data minimization on public ledgers, with verification done through proofs rather than raw data.

So the interesting question was never transparency or privacy. It's how to keep what transparency provides (verifiability, liquidity, composability) while adding confidentiality where a use case needs it. Every privacy architecture is a different answer to that question, and every answer comes with tradeoffs. Understanding those tradeoffs is the whole game.

Why privacy takes real engineering

Public chains are pseudonymous, not anonymous. Addresses aren't names, but every transaction is published, replicated globally, and stored forever. One link — a KYC'd exchange, an ENS name, a payment to a known party — makes an address's entire history attributable, and analytics firms have industrialized exactly that. The analysis is also retroactive: data published today can be connected by better tooling years from now.

The hard part is that the visibility exists for a reason: it's how the chain verifies that no one is cheating. Privacy has to be built with cryptography that hides the data while still letting the chain check the rules, and each way of doing that shifts cost somewhere: computation, trust assumptions, user experience, or compliance complexity.

What Monero and Zcash proved

Payment privacy was solved a decade ago. Monero (2014) made privacy the default on every transaction. Zcash (2016) built the first ZK shielded pool, the design most modern systems descend from, and pioneered viewing keys, the ancestor of today's selective disclosure.

Their tradeoff was the chain itself: purpose-built L1s for value transfer, with their own wallets and liquidity and no smart contracts. They proved the cryptography works in production. The frontier they left open is the one that matters now: privacy on programmable, EVM-compatible chains, where applications actually live.

Six axes for evaluating any solution

Every privacy design can be read across six dimensions: what's actually hidden (and from whom), usability, cost and performance, compliance path, maturity and trust assumptions, and ecosystem fit. No design leads on all six; the architecture determines which it optimizes.

A few patterns hold across the space. Stronger privacy guarantees usually cost usability or performance. Better performance usually means more trust assumptions, whether hardware or operators. And anonymity with no audit path is a shrinking market: regulation is converging on selective disclosure instead.

The landscape

It helps to arrange the solutions by how far they sit from a public chain, because that distance is the tradeoff.

Consortium networks optimize for need-to-know confidentiality between institutions. There's no global chain at all: each participant stores only the contracts it's party to, and in a multi-party deal each sees only its own leg. The tradeoff is public verifiability and permissionless liquidity: no one outside can independently check system-wide rules, and every counterparty is someone already onboarded. It's excellent plumbing between institutions that already know each other; a public chain is a market open to everyone else.

Permissioned EVM chains keep the EVM and run it as a members-only network. The tradeoff is Ethereum anchoring and ecosystem access, and the category's flagship privacy tooling has been deprecated, which is why many teams running these chains are re-evaluating their architecture.

Private L1s and L2s build privacy into the chain cryptographically, and the results are the deepest in the field: the newest entrants offer private smart contract execution with client-side proving, so data never leaves the user's device. The two differ in anchoring (a private L2 settles to Ethereum, a private L1 stands alone), but the adoption tradeoff is the same: it's a migration, not an integration. New chain, new languages, separate liquidity. The category is also early; the first network offering full private smart contracts went live in March 2026 at roughly 1 TPS.

Private validiums keep the validity proof public and route transaction data to a permissioned data-availability layer. That's whole-chain privacy from outsiders with the simplest compliance story available (auditors can be granted full access), and it's winning institutional pilots. Two tradeoffs to weigh: everyone inside the permission set sees everything, so there's no confidentiality between counterparties, and users depend on the data provider to reconstruct state and exit.

The two loudest institutional privacy models (a consortium network and an operator-run private validium) spent early 2026 publicly debating each other, and the exchange was clarifying: the consortium trades global verifiability for peer confidentiality; the validium trades operator-independence for global verifiability. Keep that fork in mind. We'll come back to it.

Application-layer designs add privacy to the public chain you already run, each with a different scope.

• Stealth addresses (Fluidkey, Umbra) hide the link between recipients and their identities: cheap and lightweight, though amounts and senders stay visible.
• Encrypted tokens (the emerging ERC-7984 standard, with a JPMorgan Kinexys proof of concept) hide amounts while keeping the transaction graph public. For a regulated venue receiving third-party flows, that's exactly the right shape: every inbound transfer arrives from a visible, screenable address.
• Mixers break the link between source and destination; their compliant evolution, Privacy Pools, lets users prove their deposit isn't from illicit sources without revealing which deposit is theirs.
• Shielded pools, the largest category on the Ethereum Foundation's PSE tracker, offer full transfer privacy: assets deposit into a contract holding encrypted notes, transfers happen inside with ZK proofs verifying correctness, and only entries and exits are public. Their tradeoffs are a cash-like "notes" model instead of account balances, proof costs, visible edges, and privacy that strengthens as more people use the pool.

The technologies underneath — and why hybrids are winning

Beneath those architectures sit a handful of enforcement technologies, each strong where another is weak. Trusted execution environments deliver near-native throughput with a trust anchor in hardware vendors; 2025's enclave attacks showed why no serious design leans on hardware alone. MPC committees remove the hardware dependency but hold only while the committee doesn't collude. FHE computes directly on encrypted data. It reached Ethereum mainnet in late 2025 and fits low-frequency, high-value flows today, with throughput improving on a clear roadmap.

Zero-knowledge proofs deserve a special note, because "we use ZK" has become the most overloaded claim in the industry. A ZK proof has two separable properties: succinctness (verify a computation cheaply) and zero-knowledge (the proof reveals nothing about its inputs). Most ZK rollups use only the first: the proof shows the chain ran correctly while every transaction stays public. That's what OP Stack ZK Proofs, the multi-prover validity-proving system coming to the OP Stack, brings: scaling and security, complementary to privacy rather than a form of it. Privacy systems use both properties, so the proof shows the state transition is valid and hides who paid whom. The useful question for any system is not whether it uses ZK, but what the proof hides.

Because each technology is strongest in a different place, the designs shipping today combine them so that one anchors integrity while another covers its blind spot. Three questions cut through any privacy architecture: which technology anchors funds, which anchors privacy, and what happens when each one fails.

Regulation is converging, and that's good news

Two regulatory currents have historically pointed in different directions. Privacy frameworks (GDPR, Singapore's PDPC, the EDPB guidelines) call for less personal data on public ledgers. Traceability frameworks (MiCA and the EU's AMLR, which restricts anonymous accounts for regulated service providers from July 2027) call for reliable auditability. The Tornado Cash years showed what happens when a design answers only one of them.

The synthesis the market has now converged on answers both: privacy from the public, auditability for authorized parties, through viewing keys, selective disclosure, association sets, and auditor gateways with onchain access logs. Private by default, provable when required. This is the first time the regulatory picture and the technical picture have pointed the same way, and it makes privacy a much easier conversation for institutions than it was even two years ago.

Ethereum itself has landed here. The Ethereum Foundation now treats privacy as a core network property, and its approach is to guarantee the application layer can deliver it: the same playbook that worked for scaling. That's a strong signal that onchain privacy is normal, institutional, and application-layer.

How we think about it on the OP Stack

Recall the consortium–validium fork: each architecture bakes one tradeoff into the foundation. Our view is that the tradeoff shouldn't live in the foundation at all. It should be a choice each chain and each application makes.

That's why the OP Stack starts public. A public foundation keeps the properties that can't be added later (verifiability, liquidity, network effects) and adds confidentiality where a use case calls for it. The internet followed the same path: an open network with security layered on beat every purpose-built private network, because openness is where the users and the innovation were. In one line: privacy is a feature you can add; verifiability, liquidity, and network effects aren't.

Privacy Boost, built and operated by Sunnyside Labs, is the first privacy SDK for the OP Stack and a working example of the hybrid philosophy above. It's a shielded pool using ZK and TEE together, live on OP Mainnet since April 2026, rolling out on Soneium, and part of a Korean-won-stablecoin proof of concept with Toss. The protocol is audited by OpenZeppelin, with TRM Labs integrated for sanctions screening. ZK anchors funds: signatures are verified inside the circuit and the proof onchain, so even a compromised TEE can't touch assets, and users can always exit with only their keys and onchain data. The TEE anchors throughput (hundreds of TPS via epoch batching) and the audit layer, where registered auditors get scoped access through viewing keys and every query is logged immutably onchain. When funds first enter the pool, that deposit is visible onchain; once inside, everything is private. Call it an honest consequence of building privacy on a public chain rather than a private one.

The bigger picture is that privacy on the OP Stack is a dial, not a single setting. Read access, validation, and application privacy are each configurable on one stack: fully public; public with shielded flows, live today; permissioned-read chains for institutions that want validium-style isolation; and, as validity proving matures on the OP Stack, permissioned chains with shielded flows inside — a combination that delivers counterparty confidentiality and public verifiability, resolving the fork that consortium networks and private validiums each solve only half of. Privacy Boost is the first solution on that dial, not the only one. If your requirements look different, talk to us.

Five questions to ask any privacy vendor (including us)

If you're evaluating privacy solutions, these questions route the conversation faster than any feature comparison. Your answers effectively pick the architecture.

1. What must be hidden? If it's amounts only, encrypted tokens may be enough. Counterparties too, and you're in shielded-pool territory. Business logic itself points to private chains or encrypted compute.
2. Hidden from whom? The public, other participants, or the infrastructure operator? Each step up narrows the field and raises the cost.
3. What's the compliance requirement? If you're a regulated entity, auditability is non-negotiable. Ask every vendor how authorized parties get access and whether that access is provable.
4. What volume and latency do you need? High-throughput payments strain pure-ZK designs and rule out encrypted compute today; batched and hybrid designs fit.
5. How much UX change can your users tolerate? Solutions differ widely here, from ordinary wallets with new address types to dedicated apps. Ambient, wallet-native privacy across all of EVM is the frontier the whole ecosystem is still building toward.

The takeaway

Privacy onchain is no longer a question of whether, but of which tradeoffs fit which use case. Dedicated private chains trade ecosystem access for depth. Consortium networks trade public verifiability for peer confidentiality. Validiums trade counterparty confidentiality for simplicity. Application-layer designs trade some UX polish for keeping everything a public chain already provides.

The encouraging part is how navigable the space has become: regulation has converged on selective disclosure, Ethereum has committed to privacy as a core property, and production systems are live today. The tradeoffs are real (they always will be), but for the first time, you get to choose them per use case instead of per platform.

Public by default, private where it matters, provable when required.

Where to go from here

If you're working through these tradeoffs for your own chain or application, the OP Enterprise team runs these conversations every week: schedule a meeting. For more on Privacy Boost, read the announcement and the architecture deep dive, or go straight to the technical documentation.

Privacy Boost is built and operated independently by Sunnyside Labs.