Privacy

Summary Protocol description Risk summary Upgrades & Governance Trusted setup Verifier IDs Updates Permissions Smart contracts

Privacy Boost

1 recent update

About

A shielded pool for ERC-20 tokens on OP Mainnet, designed for institutional users. Provides TEE-backed privacy, balancing better UX with worse privacy trust assumptions.

Live metrics

Not trackedOnchain monitoring is not available for this project.

Trusted setup

Exit window

Privacy

Reproducibility

Attributes

ZKTEETransfersAny amount

About

A shielded pool for ERC-20 tokens on OP Mainnet, designed for institutional users. Provides TEE-backed privacy, balancing better UX with worse privacy trust assumptions.

Protocol description

Privacy Boost is a shielded pool for registered ERC-20 tokens on OP Mainnet, aimed at institutional users. The operator’s TEE setup has to be trusted for privacy and liveness, while ZKPs ensure validity and an exit path against a malicious or faulty operator.

Architecture

Deposited tokens are represented as notes whose Poseidon2 commitments are appended to an onchain Merkle tree, and spending a note publishes its nullifier. Users can privately transfer deposited tokens to other users. The TEE collects user-approved transfers and withdrawals, batches them into epochs, and a permissioned relay submits each epoch onchain with a Groth16 proof that checks correctness.

Each user registers an approval public key in the AuthRegistry, and the pool normally snapshots the registry’s Merkle roots every 1 minute. Any user whose approval key is included in the snapshot can locally generate a forced withdrawal to an address of their choice, executable 3 days after it is requested. A forced withdrawal is generated locally and executed onchain, with no cooperation from the TEE or relays.

If the operator disappears, no new deposits or private transfers can be processed and the pool effectively enters this exit-only mode, in which the zero-knowledge guarantees alone are sufficient to recover funds.

Privacy considerations

All private data exists in plaintext inside the operator’s TEE. This privacy depends on the hardware security of the TEE against actors with physical access (side-channel and microarchitectural attacks could expose the full plaintext ledger), as well as vendor vulnerabilities. Currently the source code running within TEE is not published, so it is impossible to verify the TEE node.

A permissionless forced withdrawal publishes the commitments of the spent notes and the registered account ID, publicly linking the exit of specific notes with the EOA that registered auth keys. It is a fallback mechanism that reclaims the user’s tokens but strips the privacy.

Practical privacy also depends on the timing and amounts of deposits and withdrawals, as well as on the frontend used to interact with the pool. Normal withdrawals and transfers within the private pool are not submitted as onchain transactions via RPC nodes, but directly to the TEE, thus not leaking anything to the RPC. Users are advised to research OPSEC best practice.

Fees

Deposits into the pool are free of protocol fees. All withdrawals pay a 0.4% fee on the withdrawn amount, which is forwarded to the treasury.

Compliance

Registered auditors can query the Audit API of the TEE to fetch the balance and transaction history of any address. The TEE serves such requests without user consent, but is supposed to emit a record of every access on the AuditGateway smart contract, so users can publicly verify whether and when their private data was disclosed.

Currently the source code running within TEE is not published, so it is impossible to verify the onchain audit attestation.

Risk summary

Funds can be stolen if

the zk proof system is broken, allowing invalid spends or withdrawals.
the trusted setup is compromised or all ceremony participants collude, allowing invalid spends or withdrawals.
the admin multisig deploys a malicious upgrade or registers a malicious verifying key.

Funds can be lost if

a user loses the note secrets or the approval key required to spend their notes.
the operator and relays stop before a user’s approval key is included in an auth snapshot.

Privacy can be lost if

the TEE is compromised.
a registered auditor fetches the user’s balance and transaction history through the Audit API.
a user exits through a forced withdrawal, which publicly links the spent notes and the withdrawal address to the account that registered the approval key.

Upgrades & Governance

Privacy Boost is controlled by the 2/3 admin multisig that can upgrade core smart contracts, replace the epoch, deposit and forced withdrawal verifiers, register or replace verifying keys for individual circuit shapes, set the withdrawal fee up to 10%, and change the treasury and operator addresses.

Trusted setup

Privacy Boost

Gnark

Detailed description

Circuit-specific trusted setup for the 18 Groth16 circuits of the Privacy Boost protocol over the BN254 curve, run by Sunnyside Labs and finalised on 1 April 2026. It reuses the first 80 contributions of the public Perpetual Powers of Tau ceremony as Phase 1. Phase 2 is a gnark-native MPC ceremony, the published manifest records 25 participants and 425 contributions in total, between 23 and 25 per circuit. Participants are identified by GitHub username.

Phase 1 ceremony (first 80 contributions are used): https://github.com/privacy-ethereum/perpetualpowersoftau.
Ceremony repository and contributor tooling: https://github.com/sunnyside-io/privacy-boost-ceremony
Offline verification procedure: https://github.com/sunnyside-io/privacy-boost-ceremony/blob/main/PUBLIC_VERIFICATION.md
Public verification bundle: https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz
Derived key bundle: https://file.ceremony.privacyboost.io/prod-20260401-keys.tar.gz

Verifier IDs

Verifier	Verification	Known deployments

Privacy Boost epoch verifier, 14 circuits	by	0x67b1…966b
Description Verifies the batched private transfer and withdrawal proofs. Verifier ID:`Privacy Boost epoch verifier 18.08.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/7b2a01864a706a6d440ada20a92e4ae75dcbfc0a/frontend/epoch_circuit.go Known deployments Deployment #1 Address:0x67b1…966b Used in: Verification steps The epoch verifier stores verification keys for 14 different batched private transfer and withdrawal circuits with varying `(maxTransfers, maxInputsPerTransfer, maxOutputsPerTransfer)` (`s1`, `s4`, `s8`, `s16`, `s32`, `s64`, `s100`, `m1`, `m4`, `m8`, `l1`, `l4`, `l8`, `sp1`). The steps below reproduce all 14 verification keys from circuit sources and trusted setup files. They require 36-64 GiB RAM and ~90 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the V1 production ceremony public bundle (about 33 GB) and extract it. The archive used for this attestation hashes to `3b6a9bfc4e88c135aa34fecce30a6073cc96be50d9baac6dd75a0bbf03078c4c`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz shasum -a 256 prod-20260401-public.tar.gz tar xzf prod-20260401-public.tar.gz` Check that the ceremony’s circuit matrix in `public/config.snapshot.json` matches the circuit shapes registered on the verifier, and that the manifest’s `circuitSpecJson` for each circuit agrees with them. Re-derive every key from the transcript. Clone privacy-boost-ceremony at tag `v0.1.9`. Then run: `CGO_ENABLED=0 go build -o ./bin/ceremony ./cmd/ceremony ./bin/ceremony verify-public --bundle-dir <BUNDLE_DIR>` This recomputes every artifact digest, the bundle root and the transcript adjacency chain, then recompiles each circuit’s R1CS from its spec, fetches the pinned Perpetual Powers of Tau artifact for the required power, and re-derives the proving and verifying keys from the ordered phase 2 outputs, comparing them to the manifest commitments. On a smaller machine the same derivation can be done circuit by circuit, which brings the peak down to roughly 10 GB at the cost of running the circuits one at a time rather than in one pass. The script archive includes a helper that does this. For each circuit, encode the re-derived `public/circuits/<id>/keys/<id>.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain.
Privacy Boost deposit verifier, 3 circuits	by	0xC829…e924
Description Verifies the batched deposit epoch proofs. Verifier ID:`Privacy Boost deposit verifier 18.08.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/7b2a01864a706a6d440ada20a92e4ae75dcbfc0a/frontend/deposit_epoch_circuit.go Known deployments Deployment #1 Address:0xC829…e924 Used in: Verification steps The deposit verifier stores verification keys for 3 different batched deposit circuits across 3 registered batch sizes (`d1`, `d8`, `d32`). The steps below reproduce all 3 verification keys from circuit sources and trusted setup files. They require 36-64 GiB RAM and ~90 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the V1 production ceremony public bundle (about 33 GB) and extract it. The archive used for this attestation hashes to `3b6a9bfc4e88c135aa34fecce30a6073cc96be50d9baac6dd75a0bbf03078c4c`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz shasum -a 256 prod-20260401-public.tar.gz tar xzf prod-20260401-public.tar.gz` Check that the ceremony’s circuit matrix in `public/config.snapshot.json` matches the circuit shapes registered on the verifier, and that the manifest’s `circuitSpecJson` for each circuit agrees with them. Re-derive every key from the transcript. Clone privacy-boost-ceremony at tag `v0.1.9`. Then run: `CGO_ENABLED=0 go build -o ./bin/ceremony ./cmd/ceremony ./bin/ceremony verify-public --bundle-dir <BUNDLE_DIR>` This recomputes every artifact digest, the bundle root and the transcript adjacency chain, then recompiles each circuit’s R1CS from its spec, fetches the pinned Perpetual Powers of Tau artifact for the required power, and re-derives the proving and verifying keys from the ordered phase 2 outputs, comparing them to the manifest commitments. On a smaller machine the same derivation can be done circuit by circuit, which brings the peak down to roughly 10 GB at the cost of running the circuits one at a time rather than in one pass. The script archive includes a helper that does this. For each circuit, encode the re-derived `public/circuits/<id>/keys/<id>.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain.
Privacy Boost forced withdrawal verifier, 1 circuit	by	0xF023…3C67
Description Verifies the client-side forced withdrawal proofs. Verifier ID:`Privacy Boost forced withdrawal verifier 18.08.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/7b2a01864a706a6d440ada20a92e4ae75dcbfc0a/frontend/forced_withdraw_circuit.go Known deployments Deployment #1 Address:0xF023…3C67 Used in: Verification steps The forced verifier stores a verification key for the forced withdrawal circuit. The steps below reproduce it from circuit sources and trusted setup files. They require 36-64 GiB RAM and ~90 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the V1 production ceremony public bundle (about 33 GB) and extract it. The archive used for this attestation hashes to `3b6a9bfc4e88c135aa34fecce30a6073cc96be50d9baac6dd75a0bbf03078c4c`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz shasum -a 256 prod-20260401-public.tar.gz tar xzf prod-20260401-public.tar.gz` Check that the ceremony’s circuit matrix in `public/config.snapshot.json` matches the circuit shapes registered on the verifier, and that the manifest’s `circuitSpecJson` for each circuit agrees with them. Re-derive every key from the transcript. Clone privacy-boost-ceremony at tag `v0.1.9`. Then run: `CGO_ENABLED=0 go build -o ./bin/ceremony ./cmd/ceremony ./bin/ceremony verify-public --bundle-dir <BUNDLE_DIR>` This recomputes every artifact digest, the bundle root and the transcript adjacency chain, then recompiles each circuit’s R1CS from its spec, fetches the pinned Perpetual Powers of Tau artifact for the required power, and re-derives the proving and verifying keys from the ordered phase 2 outputs, comparing them to the manifest commitments. On a smaller machine the same derivation can be done circuit by circuit, which brings the peak down to roughly 10 GB at the cost of running the circuits one at a time rather than in one pass. The script archive includes a helper that does this. For each circuit, encode the re-derived `public/circuits/<id>/keys/<id>.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain.

Updates

2026 August 21, 08:53 UTC

14changes

Initial discovery of privacy boost.

Initial discovery

+	Status: CREATED
	contract TokenRegistryProxyAdmin (oeth:0x11B75DE42f6107AE4D5C50e4e34af6E34F63C0dd) [global/ProxyAdmin]
	+++ description: Admin contract of the TokenRegistry proxy.

+	Status: CREATED
	contract AuthRegistry (oeth:0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f) [privacy-boost/AuthRegistry]
	+++ description: Registry of account authorization keys for the PrivacyBoost pool. Accounts register BabyJubJub approval public keys into Merkle trees with EIP-712 owner signatures (submitted directly or through allowed relays), and can rotate or revoke them. PrivacyBoost snapshots the tree roots and epoch proofs validate spend authorization against them.

+	Status: CREATED
	contract AdminMultisig (oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC) [GnosisSafe]
	+++ description: None

+	Status: CREATED
	contract Groth16EpochVerifier (oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b) [privacy-boost/Groth16EpochVerifier]
	+++ description: Groth16 verifier for PrivacyBoost private transfer / withdrawal epoch proofs. Verification keys are stored in SSTORE2 data contracts, keyed by circuit configuration (max transfers, inputs and outputs per transfer). Registered epoch keys are not enumerable on-chain.

+	Status: CREATED
	contract OperatorMultisig (oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B) [GnosisSafe]
	+++ description: None

+	Status: CREATED
	contract TokenRegistry (oeth:0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6) [privacy-boost/TokenRegistry]
	+++ description: Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.

+	Status: CREATED
	contract AuditGatewayProxyAdmin (oeth:0x96f3E5551E1330f31974597217019812667544c8) [global/ProxyAdmin]
	+++ description: Admin contract of the AuditGateway proxy.

+	Status: CREATED
	contract PrivacyBoostProxyAdmin (oeth:0x9d3F3CcD3c7a084eE73C4584CE33e77CEdaEc7E2) [global/ProxyAdmin]
	+++ description: Admin contract of the PrivacyBoost proxy.

+	Status: CREATED
	contract AuditGateway (oeth:0xb328535aB3bCe578996AE9af5A7f44f175721118) [privacy-boost/AuditGateway]
	+++ description: Manages the list of auditors authorized to query private user data through the Audit API of the TEE, and stores an onchain log of every audit access so that users can publicly verify whether and when their private data was disclosed.

+	Status: CREATED
	contract TreasuryMultisig (oeth:0xc82018cbC82A50064e3DdEF79EAdC319710Ffc5e) [GnosisSafe]
	+++ description: None

+	Status: CREATED
	contract Groth16DepositVerifier (oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924) [privacy-boost/Groth16DepositVerifier]
	+++ description: Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts, registered per supported batch size.

+	Status: CREATED
	contract PrivacyBoost (oeth:0xca689828854a422CF1f778be03CA80549408F620) [privacy-boost/PrivacyBoost]
	+++ description: Main contract of the PrivacyBoost private transfer pool. It escrows registered ERC-20 tokens deposited against note commitments, and lets allowed relays batch private transfers and withdrawals into epochs that are verified with Groth16 proofs against a note Merkle tree. Users can exit without relay cooperation via a delayed forced withdrawal with their own proof.

+	Status: CREATED
	contract Groth16ForcedVerifier (oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67) [privacy-boost/Groth16ForcedVerifier]
	+++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs, used by the permissionless exit path. Verification keys are stored in SSTORE2 data contracts, registered per supported input count.

+	Status: CREATED
	contract AuthRegistryProxyAdmin (oeth:0xfB66dfD80B9a96c2BF2bcfDC5E6715C48916eD6C) [global/ProxyAdmin]
	+++ description: Admin contract of the AuthRegistry proxy.

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

OP Mainnet

Actors:

AdminMultisig0x6476…A0dC

A Multisig with 2/3 threshold.

Can upgrade with no delay
- AuthRegistry AuthRegistryProxyAdmin
- TokenRegistry TokenRegistryProxyAdmin
- AuditGateway AuditGatewayProxyAdmin
- PrivacyBoost PrivacyBoostProxyAdmin
Can interact with AuthRegistry
- set the operator address of the AuthRegistry
Can interact with Groth16EpochVerifier
- register and replace the Groth16 verification keys used to validate epoch proofs
Can interact with TokenRegistry
- register new ERC-20 tokens to be accepted by the PrivacyBoost pool
Can interact with AuditGateway
- manage the list of registered auditors and set the auditLogger address of the AuditGateway
Can interact with Groth16DepositVerifier
- register and replace the Groth16 verification keys used to validate deposit proofs
Can interact with PrivacyBoost
- replace the epoch, deposit and forced withdrawal proof verifiers, set the withdrawal fee (up to 10%), and set the treasury and operator addresses
Can interact with Groth16ForcedVerifier
- register and replace the Groth16 verification keys used to validate forced withdrawal proofs

Participants (3):

0x769e…AF1E 0x90d3…4244 0xfEa8…0237

OperatorMultisig0x78a9…D52B

A Multisig with 2/3 threshold.

Can interact with AuthRegistry
- manage the allowlist of relays that can submit key operations to the AuthRegistry on behalf of users
Can interact with PrivacyBoost
- manage the relay allowlist and schedule changes of the auth snapshot interval

Participants (3):

0x769e…AF1E 0x90d3…4244 0xfEa8…0237

TreasuryMultisig0xc820…fc5e

A Multisig with 2/3 threshold.

Participants (3):

0x769e…AF1E 0x90d3…4244 0xfEa8…0237

EOA 10x6Bd3…C9B0

Can interact with AuthRegistry
- submit account key registrations, rotations and revocations with valid owner signatures
Can interact with PrivacyBoost
- submit epochs of private transfers, withdrawals and deposits with validity proofs, and snapshot auth tree roots

EOA 20xE7F9…73eB

Can interact with AuditGateway
- log audit queries performed by registered auditors on the AuditGateway

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

OP Mainnet

TokenRegistryProxyAdmin0x11B7…C0dd

Admin contract of the TokenRegistry proxy.

Roles:
- owner: AdminMultisig

AuthRegistry0x54e8…A48f Implementation (Upgradable)Admin

Registry of account authorization keys for the PrivacyBoost pool. Accounts register BabyJubJub approval public keys into Merkle trees with EIP-712 owner signatures (submitted directly or through allowed relays), and can rotate or revoke them. PrivacyBoost snapshots the tree roots and epoch proofs validate spend authorization against them.

Roles:
- admin: AuthRegistryProxyAdmin; ultimately AdminMultisig
- allowedRelays: EOA 1
- operator: OperatorMultisig
- owner: AdminMultisig

Can be upgraded by:

AdminMultisig with no delay

Groth16EpochVerifier0x67b1…966b

Groth16 verifier for PrivacyBoost private transfer / withdrawal epoch proofs. Verification keys are stored in SSTORE2 data contracts, keyed by circuit configuration (max transfers, inputs and outputs per transfer). Registered epoch keys are not enumerable on-chain.

Roles:
- owner: AdminMultisig

TokenRegistry0x8678…A2f6 Implementation (Upgradable)Admin

Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.

Roles:
- admin: TokenRegistryProxyAdmin; ultimately AdminMultisig
- owner: AdminMultisig

Can be upgraded by:

AdminMultisig with no delay

AuditGatewayProxyAdmin0x96f3…44c8

Admin contract of the AuditGateway proxy.

Roles:
- owner: AdminMultisig

PrivacyBoostProxyAdmin0x9d3F…c7E2

Admin contract of the PrivacyBoost proxy.

Roles:
- owner: AdminMultisig

AuditGateway0xb328…1118 Implementation (Upgradable)Admin

Manages the list of auditors authorized to query private user data through the Audit API of the TEE, and stores an onchain log of every audit access so that users can publicly verify whether and when their private data was disclosed.

Roles:
- admin: AuditGatewayProxyAdmin; ultimately AdminMultisig
- auditLogger: EOA 2
- owner: AdminMultisig

Can be upgraded by:

AdminMultisig with no delay

Groth16DepositVerifier0xC829…e924

Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts, registered per supported batch size.

Roles:
- owner: AdminMultisig

PrivacyBoost0xca68…F620 Implementation (Upgradable)Admin

Main contract of the PrivacyBoost private transfer pool. It escrows registered ERC-20 tokens deposited against note commitments, and lets allowed relays batch private transfers and withdrawals into epochs that are verified with Groth16 proofs against a note Merkle tree. Users can exit without relay cooperation via a delayed forced withdrawal with their own proof.

Roles:
- admin: PrivacyBoostProxyAdmin; ultimately AdminMultisig
- allowedRelays: EOA 1
- operator: OperatorMultisig
- owner: AdminMultisig

Can be upgraded by:

AdminMultisig with no delay

Groth16ForcedVerifier0xF023…3C67

Groth16 verifier for PrivacyBoost forced withdrawal proofs, used by the permissionless exit path. Verification keys are stored in SSTORE2 data contracts, registered per supported input count.