How Privacy Boost Works #01: ZK proofs keep the money safe. TEEs make it fast.

Every team building onchain privacy eventually hits the same wall. Zero-knowledge cryptography gives you guarantees that reduce to math and a user experience that reduces to waiting. Trusted hardware gives you speed and simplicity, along with a single point of failure that has repeatedly embarrassed the industry. Most projects pick a side and inherit that side's problems.

Privacy Boost is a shielded transfer protocol for EVM chains, built by us at Sunnyside Labs: people move ERC-20 tokens with amounts and counterparties hidden from public view, and the system can still answer to a regulator when required. It is live in production today. We built it on both ZK and TEEs, on purpose.

Two schools of onchain privacy

Pure ZK: trustless but heavy

Zcash pioneered shielded payments, Railgun brought them to EVM chains, and Aztec is building an entire L2 around the idea. In all of these systems the user's own device does the cryptographic heavy lifting. That is the point: no one else can be trusted with plaintext, so no one else can help you.

In practice, proving a private transfer takes a few seconds on a good laptop and tens of seconds on a phone, painful for paying someone back at dinner. Balances are worse: a shielded wallet cannot ask a server where its money is without revealing whose it is, so it downloads and trial-decrypts every note onchain, and Zcash's mobile sync pain spawned entire protocols just to make wallets open quickly. Keys are awkward too. Ethereum's ECDSA costs one to two orders of magnitude more constraints to verify in a circuit than circuit-friendly schemes, so these protocols ship new key types, which for the user means another wallet and another seed phrase to lose. And disclosure is all-or-nothing: a user either hands an auditor a viewing key that opens their entire history forever or hands over nothing, which is not something a regulated business can build on.

All of that is the honest price of assuming no trusted party exists anywhere. Our question was whether every guarantee in a payments product actually needs that assumption.

Pure TEE: everything rides on the hardware

The opposite camp runs everything inside a trusted execution environment. The longest-running example is Secret Network, which has executed private smart contracts inside Intel SGX enclaves since 2020. The UX is excellent, because the enclave computes on plaintext the way any server would.

The catch is that the money only moves while the enclaves do. In these designs the enclave executes the ledger itself: every transfer and withdrawal passes through it, and if the nodes go down or the operator walks away, your funds become unreachable, with no proof you can generate on your own to get them out. TEEs are also demanding to operate (specific hardware, attestation, delicate upgrades), so these networks are hard to decentralize and in practice a small group keeps the lights on. Hardware liveness becomes fund access.

And hardware does fail. In 2022, researchers used the ÆPIC Leak CPU vulnerability to extract Secret Network's consensus seed, the key material protecting the entire network's private state. Notably, the exploit required a privileged position on the machine itself, a position Secret's permissionless validators held by default because they ran enclaves on their own hardware. What we took from it was simple: control who can get near the hardware, and never let funds or exit depend on the enclave.

Where we drew the line

So we combined the schools rather than picking one: the ZK school's guarantees, the TEE school's speed, each covering the other's weakness. The interesting question is where to draw the line, and we drew it by asking what happens when each part fails. Stolen or counterfeited funds cannot be undone, so custody and integrity rest on ZK proofs the chain verifies, and never on the enclave. Leaked metadata and downtime are painful but recoverable, so privacy, liveness, and the audit view are the only things we let depend on the TEE.

How a private transfer actually works

Concretely, Privacy Boost is a UTXO shielded pool, the same basic shape as Zcash or Railgun. Balances live as hidden notes and spending produces nullifiers, so nobody watching the chain can link who paid whom. The edges stay public by design: deposits and withdrawals show their addresses and amounts. What makes it different is where the enclave sits.

A transfer works like this:

1. The SDK generates an EdDSA auth key and registers it onchain under the user's existing EOA wallet.
2. The user signs the transfer and sends it, end-to-end encrypted, to the enclave. The encryption key is bound into the enclave's published attestation, so anyone can check what code they are encrypting to.
3. The enclave validates the request and returns a preconfirmation immediately, so the app can show the transfer as accepted while settlement is in flight.
4. The request joins the current epoch batch. When the batch closes, the prover generates one Groth16 proof (over BN254, with Poseidon2 hashing) covering every transfer in it.
5. The aggregated proof lands onchain. The contract checks the proof, the Merkle roots, and every nullifier. Verification gas grows only slightly with batch size, so the per-transfer cost collapses as batches fill, pushing throughput past 2,100 transfers per second at current L2 gas limits.

The contract never takes the server's word for anything.

Four things the enclave buys

Auditability a regulator can verify. This is the feature the enclave made possible in the first place: because the only decrypted view of the pool lives inside one attested machine, authorized access could be built as a real system rather than a promise. Registered auditors query specific accounts through signed requests, and every access is logged immutably onchain, so anyone can see who examined what, and when. There is no blanket export, and we cannot quietly widen the scope: the hardware holds us to the same isolation as everyone else, and the auditor list and approved code hashes live onchain, where any change is a public transaction. Where pure ZK designs offer viewing keys at all, they are the same all-or-nothing grant; here access is per-account and per-query, and it does not need the account holder's cooperation. For stablecoin issuers and fintechs, this is usually the difference between a pilot and a launch.

Transfers that feel instant. The phone only signs, and the server proves, turning the tens-of-seconds wait of client-side proving into an interaction that feels like a normal app, even on low-end phones.

Balances that just appear. The hardest UX problem in shielded systems is finding your own money. Our indexer runs inside the enclave, decrypts note metadata there, and answers balance and history queries instantly. The operator has no direct access to any of it.

Users keep their wallets. The protocol does need its own circuit-friendly signing key, but the SDK generates it, the enclave vault stores it client-encrypted, and the user's EOA governs it onchain, rotation and revocation included. In practice that means connecting an existing wallet, with no new seed phrase to back up.

Now break the enclave

Suppose someone is reading enclave memory, or we turn malicious, or both.

The list of things they could actually do is short. They cannot mint money, since every epoch proof has to show that inputs equal outputs plus fees. They cannot double-spend, because the contract keeps its own nullifier registry. They could try to move someone else's notes, but that takes the owner's EdDSA signature, which is verified in-circuit and never leaves the owner's device in plaintext. The one real lever left is refusing to process withdrawals, and forced withdrawal exists for exactly that case.

That last mechanism is the one to be skeptical about, since exit guarantees are where hybrid designs usually cheat. Every note's metadata lands on calldata encrypted twice, once to the enclave and once to the recipient's viewing key. The second copy lets users rebuild their notes from public data alone, generate a small ZK proof locally on consumer hardware, and withdraw straight from the contract. No step in this path touches our infrastructure.

The thought experiment is also hard to run in real life. Every TEE break made public so far has started from a privileged position on the machine, and our enclaves run inside Azure Confidential Computing (currently on AMD SEV-SNP), with the host, the hypervisor, and the physical machine all behind Microsoft's datacenter security.

Verification covers the rest. The enclave publishes a hardware attestation proving the silicon is genuine and the code inside matches an expected measurement, and its keys arrive through Secure Key Release, which only hands them to code matching an approved hash recorded in a public onchain registry. If the code changes, the measurement changes, attestation fails, and the keys are never released.

The trade-offs we chose

No architecture is free, and we would rather name our costs than have someone else name them for us.

The first is that normal-path transfers run through our server, on batch cadence: an epoch waits to fill or hit its timeout before the onchain record lands, and preconfirmations cover that gap in the app. The dependency is real, but it is a dependency for service rather than for money. Even if our infrastructure vanished permanently, every user could still exit in full through forced withdrawal, and pending deposits become cancellable after a delay.

The second is that privacy rests on a hardware assumption. A serious break in the enclave hardware could expose metadata for the affected window, which is why we run only in hardened cloud datacenters and rotate keys to bound that window. Fund safety would be unaffected either way.

Pick both

Split the guarantees by how badly their failure hurts, and the old choice between trustless-but-painful and smooth-but-trusted mostly goes away. The worst a hardware failure can do here is make the product slower and less private for a window; it cannot reach the funds.

The result is something apps can actually ship, and people already do: Privacy Boost is live on OP Mainnet and Soneium, with Base and Ethereum next. We work with teams like Optimism, Startale, and Soneium. You can use it today in our own app, or ship it in yours with SDKs for TypeScript, React Native, iOS, Android, and Rust; most teams integrate in about a day.

If you are building a wallet, a stablecoin, or anything that has to move money privately and answer for it, the docs are at docs.privacyboost.io. We are happy to walk through the threat model in as much depth as you like — as you can probably tell, it is our favorite subject. Get in touch.