Privacy Boost: A Deeper Look
tl;dr Last month we announced Privacy Boost (the first privacy SDK for the OP Stack, built by Sunnyside Labs). This post goes one level deeper: why the ZK+TEE hybrid is the right architectural choice, where every prior approach hit a ceiling, and why regulators are now pointing in the same direction.
Our original announcement covered what Privacy Boost is: confidential token transfers, private smart contract logic, compliance-compatible architecture, drop-in SDK. If you haven't read it, start there.
The history of blockchain privacy is roughly a decade of forced tradeoffs. Every solution before this one made you give something up: composability, performance, ecosystem access, or compliance readiness. Understanding why Privacy Boost doesn't require that tradeoff means understanding what each prior approach tried and where it ran into a wall.
How the industry tried to solve privacy before - three approaches
Privacy by isolation
The legacy approach: permissioned chains. Hyperledger Fabric, R3 Corda, Avalanche Evergreen subnets restrict ledger access to approved participants: privacy by controlling who can see it, not by encrypting what's there. That means no Ethereum composability, no shared liquidity, no ecosystem access, plus validator operations and separate infrastructure that don't exist when you're adding a layer to a chain you're already running.
But there's a second problem inside that first one. Everyone inside the permissioned network still sees everything. On Avalanche's Spruce subnet (the institutional testnet with T. Rowe Price, WisdomTree, Wellington Management, and Cumberland all testing simultaneously), each participant's transactions are visible to every other approved participant. T. Rowe Price's positions are readable by WisdomTree. That's a smaller audience, not privacy. For asset managers specifically, counterparty confidentiality within the network matters as much as confidentiality from outsiders.
Privacy by ZK
Aztec, Aleo, and Zcash all take this route. ZK proofs handle correctness and confidentiality mathematically (no trusted third party, no hardware dependency). The guarantees are strong. The performance costs at enterprise volume are real: Aztec's Groth16 proofs cost roughly 0.15 Mgas to verify, which is prohibitive for high-throughput payment infrastructure. Aleo requires a new language (Leo) and operates on a separate chain that isn't EVM-compatible. You're not adding privacy to your existing infrastructure; you're replacing it entirely. For an enterprise architecture team that built on EVM and has no plans to leave, that's a platform migration conversation, not a privacy one.
Privacy by TEE alone
Oasis Network and Secret Network take this approach. Trusted execution environments (secure enclaves inside processors, like Intel SGX) process data privately without exposing it to the host system. Throughput is good; Oasis claims over 1,000 TPS. The problem is that the privacy guarantee rests entirely on the hardware. Physical attacks on Intel SGX in 2025 showed what that single point of trust looks like when it fails. If the hardware is compromised, the privacy is compromised.
Why the Hybrid Model Changes the Tradeoffs
Privacy Boost uses ZK and TEE together, and the combination isn't arbitrary.
ZK handles correctness and confidentiality. The guarantee doesn't depend on trusting any hardware manufacturer, or any third party; it's in the proof. TEE handles throughput, integration simplicity, and the compliance audit layer (the piece that makes regulated deployment actually possible). Proof generation stays under 500ms at scale. Sunnyside runs the ZK prover infrastructure to get there. TEE also enables viewing keys and selective disclosure: how authorized parties (regulators, auditors, internal compliance teams) can trace transactions without those transactions being public, each scoped by role.
If pure ZK is too slow for a given workload, the TEE keeps throughput viable, while the ZK layer keeps correctness verifiable without trusting any single operator.
When a user first deposits public balances into Privacy Boost, that initial action is visible onchain. Once funds are inside the protocol, everything is private. If a user onboards from an already-private balance, it's private end to end. Call it an honest consequence of building privacy on a public chain rather than a private one.
The regulatory tension this resolves
Privacy Boost is the first architecture to satisfy two sets of mandates that have been pointing in opposite directions.
GDPR, Singapore's PDPC, and the EDPB's 2025 blockchain guidelines all emphasize data minimization. Personal data should stay off-chain or encrypted. Verification should happen through proofs that don't expose the underlying data. HIPAA treats public blockchains as a hostile environment for health-adjacent information. Each framework pushes toward less data on the public ledger.
MiCA and AMLR push the other way. Full transaction traceability is required. The EU is banning anonymous accounts by 2027. Regulators need to audit reliably; contingent on voluntary user disclosure isn't acceptable.
These mandates have been in direct conflict. Architect for GDPR or architect for MiCA. Doing both on the same public chain hasn't had a clean answer.
The TEE layer resolves this. Transactions are private by default: no public exposure of amounts, counterparties, or balances. Authorized parties access transaction data through viewing keys and selective disclosure, scoped to what they're authorized to see. Privacy from competitors, front-runners, and block explorers; auditability for the parties with legitimate access. Same architecture, different layers.
What's next
Privacy Boost is the first privacy offering on the OP Stack. OP will support multiple privacy solutions as this space develops; the goal is covering the full range of enterprise privacy requirements.
One note on attribution: Sunnyside Labs builds and operates Privacy Boost independently. OP Labs' role is building the infrastructure that makes offerings like this possible. For integration conversations, contact the OP Enterprise team. Technical documentation is at docs.privacyboost.io.