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

ZKTEETransfersDeFiAny 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.

Accounts can authorize spending with registered approval keys or with explicit onchain spend approvals, including batches and approval-only smart-wallet accounts. Epoch proofs use current auth roots or roots superseded no more than 10 minutes ago.

Users can locally prove a forced withdrawal of up to 13 notes. The contract checks that the referenced auth key or spend approval is live and unexpired when the request is submitted, and records the authorized withdrawal and fee. Anyone can execute it 3 days later if the notes remain unspent, without cooperation from the TEE or relays. The account owner can cancel a pending request.

Users can locally generate and deploy portal deposit EIP-7702 addresses. Anyone can send ERC-20 to such a portal address, the tokens are regularly swept into Privacy Boost escrow for the hidden recipient. Gift notes can be claimed by recipients or refunded by senders after a bound deadline, either privately through a relay or through a permissionless public gift exit. Proof-authorized withdrawals can also call approved external gateways for DeFi operations.

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. The source code running within the TEE is not published.

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

Standard deposits are free of protocol fees. Portal deposits can charge a separate sweeper fee, capped at 10% and currently set to 0%, and have token-specific minimum sweep amounts. Withdrawals, including forced withdrawals and public gift exits, pay a 0.4% fee forwarded to the treasury; a forced withdrawal records the fee at request time.

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 that users can publicly verify whether and when their private data was disclosed.

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

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 their note secrets, or loses access to both the account-owner wallet and any usable authorization keys.

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, which can upgrade the pool, registries and AuditGateway without delay. It can replace all five proof verifiers and register or replace their verification keys, set withdrawal and portal sweep fees up to 10% each, configure portal minimum sweeps, and change the treasury, operator and gateway route manager.

The external-call gateway owner manages target/selector policies, selects its guardian, and can pause or unpause execution. The guardian can pause and remove policies. Stranded gateway tokens can only be swept back to the pool while paused.

Trusted setup

Privacy Boost v2

Gnark

Detailed description

Circuit-specific trusted setup for the 21 Groth16 circuits of the Privacy Boost protocol over the BN254 curve, run by Sunnyside Labs and finalised on 2 September 2026. It replaces the first round whose 18 circuits were retired with the September 2026 upgrade. 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 26 participants and 490 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
Round record with the independently published bundle digests: rounds/2026-02.md
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-20260902-public.tar
Derived key bundle: https://file.ceremony.privacyboost.io/prod-20260902-keys.tar

Verifier IDs

Verifier	Verification	Known deployments

Privacy Boost epoch verifier, 13 circuits	by	0xab52…C6B6
Description Verifies the batched private transfer and withdrawal proofs. Verifier ID:`Privacy Boost epoch verifier 09.09.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/epoch_circuit.go Known deployments Deployment #1 Address:0xab52…C6B6 Used in: Verification steps The epoch verifier stores verification keys for 13 different batched private transfer and withdrawal circuits with varying `(maxTransfers, maxInputsPerTransfer, maxOutputsPerTransfer)` (`s1`, `s5`, `s12`, `s25`, `m1`, `m4`, `m8`, `l1`, `l3`, `l6`, `sp1`, `w51`, `w201`). The steps below reproduce all 13 verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar` 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 and with `circuit-setup/configs/production.ceremony.config.json` in privacy-boost-ceremony at commit `e645b68d`. Re-derive every key from the transcript. The circuits are the `frontend/` package of privacy-boost-protocol at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit. `python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2` For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from the circuit parameters and cross-checking them against the getters.
Privacy Boost deposit verifier, 3 circuits	by	0x16e1…25C5
Description Verifies the batched deposit epoch proofs. Verifier ID:`Privacy Boost deposit verifier 09.09.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_epoch_circuit.go Known deployments Deployment #1 Address:0x16e1…25C5 Used in: Verification steps The deposit verifier stores verification keys for 3 different batched deposit circuits across 3 registered batch sizes (`d1`, `d4`, `d14`). The steps below reproduce all 3 verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar` 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 and with `circuit-setup/configs/production.ceremony.config.json` in privacy-boost-ceremony at commit `e645b68d`. Re-derive every key from the transcript. The circuits are the `frontend/` package of privacy-boost-protocol at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. `python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2` For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from the circuit parameters and cross-checking them against the getters.
Privacy Boost forced withdrawal verifier, 1 circuit	by	0x78ff…6641
Description Verifies the client-side forced withdrawal proofs. Verifier ID:`Privacy Boost forced withdrawal verifier 09.09.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/forced_withdraw_circuit.go Known deployments Deployment #1 Address:0x78ff…6641 Used in: Verification steps The forced verifier stores a verification key for the forced withdrawal circuit (`f13`). The steps below reproduce it from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar` 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 and with `circuit-setup/configs/production.ceremony.config.json` in privacy-boost-ceremony at commit `e645b68d`. Re-derive every key from the transcript. The circuits are the `frontend/` package of privacy-boost-protocol at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. `python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2` For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from the circuit parameters and cross-checking them against the getters.
Privacy Boost portal deposit verifier, 2 circuits	by	0x6806…a2B6
Description Verifies the batched hidden-recipient portal deposit proofs. Verifier ID:`Privacy Boost portal deposit verifier 09.09.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_portal_circuit.go Known deployments Deployment #1 Address:0x6806…a2B6 Used in: Verification steps The portal deposit verifier stores verification keys for 2 different batched portal deposit circuits across 2 registered batch sizes (`p1`, `p6`). The steps below reproduce both verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar` 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 and with `circuit-setup/configs/production.ceremony.config.json` in privacy-boost-ceremony at commit `e645b68d`. Re-derive every key from the transcript. The circuits are the `frontend/` package of privacy-boost-protocol at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit. `python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2` For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from the circuit parameters and cross-checking them against the getters.
Privacy Boost gift claim verifier, 2 circuits	by	0x249a…B1B4
Description Verifies the batched gift claim, refund and public gift exit proofs. Verifier ID:`Privacy Boost gift claim verifier 09.09.2026` Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/gift_claim_circuit.go Known deployments Deployment #1 Address:0x249a…B1B4 Used in: Verification steps The gift claim verifier stores verification keys for 2 different batched gift claim circuits across 2 registered batch sizes (`g1`, `g3`). The steps below reproduce both verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the script archive. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. `curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar` 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 and with `circuit-setup/configs/production.ceremony.config.json` in privacy-boost-ceremony at commit `e645b68d`. Re-derive every key from the transcript. The circuits are the `frontend/` package of privacy-boost-protocol at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit. `python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2` For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from the circuit parameters and cross-checking them against the getters.

Updates

2026 September 07, 13:21 UTC

High severity

100changes

Feature upgrade: replaces PrivacyBoost/AuthRegistry logic and all three verifiers, adds portal and gift features + verifiers, an external-call gateway, and expands the token registry to 11 assets. Auth snapshots are removed . New keys remain unverified because the trusted setup records are not yet published. external call gateway: whitelisted defi interactions portal: reusable recipient addresses gift: claim to a custom address (private or public) using a 'gift note' AuthRegistry: https://disco.l2beat.com/diff/oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b/oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a TokenRegistry: https://disco.l2beat.com/diff/oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134/oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19 AuditGateway: https://disco.l2beat.com/diff/oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478/oeth:0x384D1460107D88b1a21CA202825583c19cb6A808 PrivacyBoost: https://disco.l2beat.com/diff/oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5/oeth:0x9CB144D35748932EC44950d0837248fcF8747828

external call gateway: whitelisted defi interactions

portal: reusable recipient addresses

gift: claim to a custom address (private or public) using a ‘gift note’

AuthRegistry: https://disco.l2beat.com/diff/oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b/oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a

TokenRegistry: https://disco.l2beat.com/diff/oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134/oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19

AuditGateway: https://disco.l2beat.com/diff/oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478/oeth:0x384D1460107D88b1a21CA202825583c19cb6A808

PrivacyBoost: https://disco.l2beat.com/diff/oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5/oeth:0x9CB144D35748932EC44950d0837248fcF8747828

	contract AuthRegistry (oeth:0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f) [privacy-boost/AuthRegistry_v2] {
	+++ description: Registry of PrivacyBoost account authorization keys and onchain spend approvals. Supports BabyJubJub keys authorized by account-owner signatures, approval-only accounts and revocable batches of spend approvals. Tracks current and recently superseded auth roots; forced withdrawals validate live auth records directly.
	template:
-	"privacy-boost/AuthRegistry"
+	"privacy-boost/AuthRegistry_v2"
	sourceHashes.1:
-	"0x6428f3cd5084b5378b6215a3d5732d338b7579e92f92b364ee6f1db1cd9c9f16"
+	"0x53a840fbb8f7f80637b9be2a5f960b7901c110d9a8e08d65befb06d6532b110a"
	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."
+	"Registry of PrivacyBoost account authorization keys and onchain spend approvals. Supports BabyJubJub keys authorized by account-owner signatures, approval-only accounts and revocable batches of spend approvals. Tracks current and recently superseded auth roots; forced withdrawals validate live auth records directly."
	values.$implementation:
-	"oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b"
+	"oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a"
	values.$pastUpgrades.2:
+	["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a"]]
	values.$upgradeCount:
-	2
+	3
	values.AUTH_ROOT_HISTORY_SIZE:
-	64
	+++ description: External Poseidon2 helper for account IDs, authorization leaves and auth Merkle tree hashing.
	+++ severity: HIGH
	values.authPoseidon:
+	"oeth:0x09257a2B24C27586c2Db2C18c4b53bE459c7e870"
	+++ description: Maximum lifetime of an onchain spend approval, in seconds.
	+++ severity: HIGH
	values.MAX_APPROVAL_LIFETIME:
+	2592000
	fieldMeta.authPoseidon:
+	{"severity":"HIGH","description":"External Poseidon2 helper for account IDs, authorization leaves and auth Merkle tree hashing."}
	fieldMeta.MAX_APPROVAL_LIFETIME:
+	{"severity":"HIGH","description":"Maximum lifetime of an onchain spend approval, in seconds."}
	implementationNames.oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b:
-	"AuthRegistry"
	implementationNames.oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a:
+	"AuthRegistry"
	}

	contract AdminMultisig (oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC) [GnosisSafe] {
	+++ description: None
	receivedPermissions.0:
+	{"permission":"interact","from":"oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5","description":"register and replace the Groth16 verification keys used to validate deposit epoch proofs.","role":".owner"}
	receivedPermissions.1:
+	{"permission":"interact","from":"oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4","description":"register and replace the Groth16 verification keys used to validate gift settlement and public gift exit proofs.","role":".owner"}
	receivedPermissions.2:
+	{"permission":"interact","from":"oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955","description":"set the guardian, install or remove external call policies, pause or unpause the gateway, and sweep stranded tokens back to the pool while paused.","role":".owner"}
	receivedPermissions.4:
+	{"permission":"interact","from":"oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6","description":"register and replace the Groth16 verification keys used to validate portal deposit epoch proofs.","role":".owner"}
	receivedPermissions.1.description:
-	"register and replace the Groth16 verification keys used to validate epoch proofs."
+	"register and replace the Groth16 verification keys used to validate forced withdrawal proofs."
	receivedPermissions.1.from:
-	"oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b"
+	"oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
	receivedPermissions.7:
+	{"permission":"interact","from":"oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6","description":"register and replace the Groth16 verification keys used to validate epoch proofs.","role":".owner"}
	receivedPermissions.4:
-	{"permission":"interact","from":"oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924","description":"register and replace the Groth16 verification keys used to validate deposit proofs.","role":".owner"}
	receivedPermissions.5:
-	{"permission":"interact","from":"oeth:0xca689828854a422CF1f778be03CA80549408F620","description":"replace the epoch, deposit and forced withdrawal proof verifiers, set the withdrawal fee (up to 10%), and set the treasury and operator addresses.","role":".owner"}
	receivedPermissions.6.description:
-	"register and replace the Groth16 verification keys used to validate forced withdrawal proofs."
+	"replace all five proof verifiers, set withdrawal and portal sweep fees (each up to 10%), set token-specific portal minimum sweeps, and change the treasury, operator and gateway route manager."
	receivedPermissions.6.from:
-	"oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
+	"oeth:0xca689828854a422CF1f778be03CA80549408F620"
	}

-	Status: DELETED
	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.

	EOA (oeth:0x6Bd37032571F47e50f312542ae05D548B69DC9B0) {
	+++ description: None
	receivedPermissions.1.description:
-	"submit epochs of private transfers, withdrawals and deposits with validity proofs, and snapshot auth tree roots."
+	"submit private transfer, withdrawal, deposit, portal deposit and gift settlement epochs with validity proofs, and simulate gateway withdrawals."
	}

	contract OperatorMultisig (oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B) [GnosisSafe] {
	+++ description: None
	receivedPermissions.0:
+	{"permission":"interact","from":"oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955","description":"pause the gateway and remove external call policies.","role":".guardian"}
	receivedPermissions.2:
+	{"permission":"interact","from":"oeth:0xca689828854a422CF1f778be03CA80549408F620","description":"approve or revoke external gateway routes used by proof-authorized withdrawals.","role":".gatewayRouteManager"}
	receivedPermissions.1.description:
-	"manage the relay allowlist and schedule changes of the auth snapshot interval."
+	"manage the allowlist of relays that submit epochs to the pool."
	}

	contract TokenRegistry (oeth:0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6) [privacy-boost/TokenRegistry] {
	+++ description: Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.
	values.$implementation:
-	"oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134"
+	"oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19"
	values.$pastUpgrades.1:
+	["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19"]]
	values.$upgradeCount:
-	1
+	2
	+++ description: Latest token ID assigned; tokens are registered with IDs 1..nextId.
	values.nextId:
-	4
+	11
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.4:
+	{"tokenType":0,"tokenAddress":"oeth:0x68f180fcCe6836688e9084f035309E29Bf0A2095","tokenSubId":0}
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.5:
+	{"tokenType":0,"tokenAddress":"oeth:0x1F32b1c2345538c0c6f582fCB022739c4A194Ebb","tokenSubId":0}
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.6:
+	{"tokenType":0,"tokenAddress":"oeth:0x9560e827aF36c94D2Ac33a39bCE1Fe78631088Db","tokenSubId":0}
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.7:
+	{"tokenType":0,"tokenAddress":"oeth:0xDCB612005417Dc906fF72c87DF732e5a90D49e11","tokenSubId":0}
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.8:
+	{"tokenType":0,"tokenAddress":"oeth:0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1","tokenSubId":0}
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.9:
+	{"tokenType":0,"tokenAddress":"oeth:0xC30ce6A5758786e0F640cC5f881Dd96e9a1C5C59","tokenSubId":0}
	+++ description: Registered tokens (token type, token address, sub-id) by token ID.
	values.tokens.10:
+	{"tokenType":0,"tokenAddress":"oeth:0x3d63934715b6D4c4DFbBC1a00Fe2A2145079DD76","tokenSubId":0}
	implementationNames.oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134:
-	"TokenRegistry"
	implementationNames.oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19:
+	"TokenRegistry"
	}

	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.
	values.$implementation:
-	"oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478"
+	"oeth:0x384D1460107D88b1a21CA202825583c19cb6A808"
	values.$pastUpgrades.1:
+	["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0x384D1460107D88b1a21CA202825583c19cb6A808"]]
	values.$upgradeCount:
-	1
+	2
	implementationNames.oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478:
-	"AuditGateway"
	implementationNames.oeth:0x384D1460107D88b1a21CA202825583c19cb6A808:
+	"AuditGateway"
	}

-	Status: DELETED
	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.

	contract PrivacyBoost (oeth:0xca689828854a422CF1f778be03CA80549408F620) [privacy-boost/PrivacyBoost_v2] {
	+++ description: Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits.
	template:
-	"privacy-boost/PrivacyBoost"
+	"privacy-boost/PrivacyBoost_v2"
	sourceHashes.1:
-	"0x0969b8ba50a27e47a32264c554c7bb5f41f38b4371347f61b08d4d8ac55ce613"
+	"0xa93601acbe9c964bab9c061132f2a8b35338b4dfbacee9bf924163d745e04405"
	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."
+	"Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits."
	values.$implementation:
-	"oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5"
+	"oeth:0x9CB144D35748932EC44950d0837248fcF8747828"
	values.$pastUpgrades.1:
+	["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0x9CB144D35748932EC44950d0837248fcF8747828"]]
	values.$upgradeCount:
-	1
+	2
	values.authSnapshotInterval:
-	30
	values.authSnapshotScheduleVersion:
-	0
	values.authSnapshotStartBlock:
-	0
	values.authSnapshotStartRound:
-	0
	values.currentAuthSnapshotInterval:
-	30
	+++ description: Groth16 verifier used for deposit epoch proofs.
	+++ severity: HIGH
	values.depositVerifier:
-	"oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924"
+	"oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5"
	+++ description: Groth16 verifier used for private transfer / withdrawal epoch proofs.
	+++ severity: HIGH
	values.epochVerifier:
-	"oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b"
+	"oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6"
	+++ description: Groth16 verifier used for forced withdrawal proofs.
	+++ severity: HIGH
	values.forcedVerifier:
-	"oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
+	"oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
	values.latestSnapshotRound:
-	5195055
	values.maxForcedInputs:
-	8
+	13
	values.maxOutputsPerTransfer:
-	11
+	201
	values.pendingAuthSnapshotEffectiveBlock:
-	0
	values.pendingAuthSnapshotInterval:
-	0
	values.pendingAuthSnapshotStartRound:
-	0
	values.gatewayRouteManager:
+	"oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B"
	+++ description: Approved synchronous gateway routes for proof-authorized external calls.
	+++ severity: HIGH
	values.gateways:
+	["oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955"]
	+++ description: Groth16 verifier for private gift settlement and public gift exit proofs.
	+++ severity: HIGH
	values.giftClaimVerifier:
+	"oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
	+++ description: Maximum age in blocks of a superseded auth root accepted for epoch and private gift settlement proofs.
	+++ severity: HIGH
	values.maxEpochAuthStalenessBlocks:
+	300
	+++ description: Maximum age in blocks of a superseded auth root accepted for public gift exits. Despite its legacy name, this does not govern forced withdrawals, which check the live auth record at request time.
	+++ severity: HIGH
	values.maxForcedWithdrawalAuthStalenessBlocks:
+	500
	+++ description: Groth16 verifier for portal deposit proofs.
	+++ severity: HIGH
	values.portalDepositVerifier:
+	"oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6"
	+++ description: Minimum gross amount per token ID required for a portal sweep, in token base units; defaults to zero.
	values.portalMinimumSweeps:
+	{"1":200000000000000,"2":"5000000000000000000","3":500000,"4":500000,"5":650,"6":170000000000000,"7":"25000000000000000000","8":400000,"9":"500000000000000000"}
	+++ description: Portal sweep fee in basis points, paid to the sweeper and snapshotted when the deposit is requested.
	values.portalSweepFeeBps:
+	0
	fieldMeta.operator:
-	{"severity":"HIGH"}
	fieldMeta.allowedRelays.severity:
-	"HIGH"
	fieldMeta.authRegistry.description:
-	"Registry of account authorization keys whose tree roots are snapshotted and used to validate spend authorization in epoch proofs."
+	"Registry of account authorization keys and spend approvals used to validate spend authorization."
	fieldMeta.treasury.severity:
-	"HIGH"
	fieldMeta.cancelDelay.severity:
+	"HIGH"
	fieldMeta.forcedWithdrawalDelay.severity:
+	"HIGH"
	fieldMeta.authSnapshotInterval:
-	{"description":"Block interval between snapshots of auth tree roots."}
	fieldMeta.gateways:
+	{"severity":"HIGH","description":"Approved synchronous gateway routes for proof-authorized external calls."}
	fieldMeta.portalMinimumSweeps:
+	{"description":"Minimum gross amount per token ID required for a portal sweep, in token base units; defaults to zero."}
	fieldMeta.portalDepositVerifier:
+	{"severity":"HIGH","description":"Groth16 verifier for portal deposit proofs."}
	fieldMeta.giftClaimVerifier:
+	{"severity":"HIGH","description":"Groth16 verifier for private gift settlement and public gift exit proofs."}
	fieldMeta.maxEpochAuthStalenessBlocks:
+	{"severity":"HIGH","description":"Maximum age in blocks of a superseded auth root accepted for epoch and private gift settlement proofs."}
	fieldMeta.maxForcedWithdrawalAuthStalenessBlocks:
+	{"severity":"HIGH","description":"Maximum age in blocks of a superseded auth root accepted for public gift exits. Despite its legacy name, this does not govern forced withdrawals, which check the live auth record at request time."}
	fieldMeta.portalSweepFeeBps:
+	{"description":"Portal sweep fee in basis points, paid to the sweeper and snapshotted when the deposit is requested."}
	implementationNames.oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5:
-	"PrivacyBoost"
	implementationNames.oeth:0x9CB144D35748932EC44950d0837248fcF8747828:
+	"PrivacyBoost"
	}

-	Status: DELETED
	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 AuthPoseidon (oeth:0x09257a2B24C27586c2Db2C18c4b53bE459c7e870) [privacy-boost/AuthPoseidon]
	+++ description: Poseidon2 hashing helper used by AuthRegistry to compute account IDs, authorization leaves, spend approval commitments and Merkle tree nodes.

+	Status: CREATED
	contract Groth16DepositVerifier (oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5) [privacy-boost/Groth16DepositVerifier_v2]
	+++ description: Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.

+	Status: CREATED
	contract Groth16GiftClaimVerifier (oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4) [privacy-boost/Groth16GiftClaimVerifier]
	+++ description: Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.

+	Status: CREATED
	contract ExternalCallGateway (oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955) [privacy-boost/ExternalCallGateway]
	+++ description: Gateway executing pool-authorized external calls against an allowlist of target addresses and function selectors, with optional input/output token constraints. Enforces proof-bound settlement receipts and redeposits returned funds into the pool.

+	Status: CREATED
	contract Groth16PortalDepositVerifier (oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6) [privacy-boost/Groth16PortalDepositVerifier]
	+++ description: Groth16 verifier for PrivacyBoost portal deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.

+	Status: CREATED
	contract Groth16ForcedVerifier (oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641) [privacy-boost/Groth16ForcedVerifier_v2]
	+++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.

+	Status: CREATED
	contract Groth16EpochVerifier (oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6) [privacy-boost/Groth16EpochVerifier_v2]
	+++ description: Groth16 verifier for PrivacyBoost private transfer and withdrawal epochs. Keys are indexed by (max transfers, inputs per transfer, outputs per transfer). The nested key registry is not enumerable and emits no registration events; discovery monitors the reviewed production circuit configurations.

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 Groth16DepositVerifier
- register and replace the Groth16 verification keys used to validate deposit epoch proofs
Can interact with Groth16GiftClaimVerifier
- register and replace the Groth16 verification keys used to validate gift settlement and public gift exit proofs
Can interact with ExternalCallGateway
- set the guardian, install or remove external call policies, pause or unpause the gateway, and sweep stranded tokens back to the pool while paused
Can interact with AuthRegistry
- set the operator address of the AuthRegistry
Can interact with Groth16PortalDepositVerifier
- register and replace the Groth16 verification keys used to validate portal deposit epoch proofs
Can interact with Groth16ForcedVerifier
- register and replace the Groth16 verification keys used to validate forced withdrawal proofs
Can interact with TokenRegistry
- register new ERC-20 tokens to be accepted by the PrivacyBoost pool
Can interact with Groth16EpochVerifier
- register and replace the Groth16 verification keys used to validate epoch proofs
Can interact with AuditGateway
- manage the list of registered auditors and set the auditLogger address of the AuditGateway
Can interact with PrivacyBoost
- replace all five proof verifiers, set withdrawal and portal sweep fees (each up to 10%), set token-specific portal minimum sweeps, and change the treasury, operator and gateway route manager

Participants (3):

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

OperatorMultisig0x78a9…D52B

A Multisig with 2/3 threshold.

Can interact with ExternalCallGateway
- pause the gateway and remove external call policies
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
- approve or revoke external gateway routes used by proof-authorized withdrawals
- manage the allowlist of relays that submit epochs to the pool

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 private transfer, withdrawal, deposit, portal deposit and gift settlement epochs with validity proofs, and simulate gateway withdrawals

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

AuthPoseidon0x0925…e870

Poseidon2 hashing helper used by AuthRegistry to compute account IDs, authorization leaves, spend approval commitments and Merkle tree nodes.

TokenRegistryProxyAdmin0x11B7…C0dd

Admin contract of the TokenRegistry proxy.

Roles:
- owner: AdminMultisig

Groth16DepositVerifier0x16e1…25C5

Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.

Roles:
- owner: AdminMultisig

Groth16GiftClaimVerifier0x249a…B1B4

Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.

Roles:
- owner: AdminMultisig

ExternalCallGateway0x54B5…1955

Gateway executing pool-authorized external calls against an allowlist of target addresses and function selectors, with optional input/output token constraints. Enforces proof-bound settlement receipts and redeposits returned funds into the pool.

Roles:
- guardian: OperatorMultisig
- owner: AdminMultisig

AuthRegistry0x54e8…A48f Implementation (Upgradable)Admin

Registry of PrivacyBoost account authorization keys and onchain spend approvals. Supports BabyJubJub keys authorized by account-owner signatures, approval-only accounts and revocable batches of spend approvals. Tracks current and recently superseded auth roots; forced withdrawals validate live auth records directly.

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

Can be upgraded by:

AdminMultisig with no delay

Groth16PortalDepositVerifier0x6806…a2B6

Groth16 verifier for PrivacyBoost portal deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.

Roles:
- owner: AdminMultisig

Groth16ForcedVerifier0x78ff…6641

Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.

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

Groth16EpochVerifier0xab52…C6B6

Groth16 verifier for PrivacyBoost private transfer and withdrawal epochs. Keys are indexed by (max transfers, inputs per transfer, outputs per transfer). The nested key registry is not enumerable and emits no registration events; discovery monitors the reviewed production circuit configurations.

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

PrivacyBoost0xca68…F620 Implementation (Upgradable)Admin

Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits.

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