{
"badges": [],
"description": "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.",
"detailedDescription": "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.\n\n### Architecture\n\nDeposited 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.\n\nEach 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.\n\nIf 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.\n\n### Privacy considerations\n\nAll 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.\n\nA 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.\n\nPractical 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](/publications/privacy-best-practices).\n\n### Fees\n\nDeposits 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.\n\n### Compliance\n\nRegistered 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.\n\nCurrently the source code running within TEE is not published, so it is impossible to verify the onchain audit attestation.",
"detailedDescription": "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.\n\n### Architecture\n\nDeposited 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.\n\nAccounts 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.\n\nUsers 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.\n\nUsers 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.\nGift 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.\n\nIf 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.\n\n### Privacy considerations\n\nAll 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.\n\nA 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.\n\nPractical 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](/publications/privacy-best-practices).\n\n### Fees\n\nStandard 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.\n\n### Compliance\n\nRegistered 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.\n\nThe source code running within the TEE is not published, so it is impossible to verify the onchain audit attestation mechanism.",
"links": {
"websites": [
"https://www.privacyboost.io/"
],
"documentation": [
"https://docs.privacyboost.io/"
],
"repositories": [
"https://github.com/sunnyside-io/privacy-boost-protocol",
"https://github.com/sunnyside-io/privacy-boost-ceremony"
]
}
}
{
"creator": "Sunnyside Labs",
"projectsForTvs": [
{
"projectId": "privacy-boost",
"sinceTimestamp": 1776188243
}
],
"proofSystemInfo": "Privacy Boost proves every state transition with **Groth16 over BN254**. The circuits are written\nin Go against the [gnark](https://github.com/Consensys/gnark) R1CS frontend. There is no recursion and no proof\naggregation.\n\nThere are three circuit families:\n\n- **Epoch** — a batch of private N-in/M-out transfers plus fee notes; spends (nullifies) inputs and\n appends outputs.\n- **Deposit epoch** — mints commitments for confirmed deposit requests and appends them to the note\n tree.\n- **Forced withdrawal** — the permissionless exit path, a single-signer manual exit spending up to\n eight notes to an EOA.\n\nCircuit shape (batch size, max inputs and outputs per transfer, tree depths, max roots per proof)\nis fixed at compile time, and every distinct shape is a distinct circuit with a distinct trusted\nsetup and verifying key. Privacy Boost has 18 registered shapes: fourteen epoch shapes, three\ndeposit shapes and one forced withdrawal shape.",
"proofSystemInfo": "Privacy Boost uses **Groth16 over BN254**, with circuits written in Go against the [gnark](https://github.com/Consensys/gnark) R1CS frontend. There is no recursive proof aggregation; batching happens inside each circuit.\n\nThere are five verifier families:\n\n- **Epoch**: private transfers, withdrawals and gateway withdrawals; 13 reviewed configurations.\n- **Deposit epoch**: standard deposit batches of 1, 4 or 14.\n- **Portal deposit epoch**: hidden-recipient portal deposit batches of 1 or 6.\n- **Forced withdrawal**: a permissionless delayed exit spending up to 13 notes, using a live auth key or spend approval checked at request time.\n- **Gift claim**: private gift claims/refunds and public gift exits, with registered batch sizes 1 and 3.\n\nFor each of the verifier contracts, different configurations can be allowed with the according verifier keys. There are 21 verifier keys currently registered (13 epoch + 3 deposit + 2 portal + 1 forced withdrawal + 2 gift).",
"techStack": {
"zkVM": [
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
},
{
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
{
"id": "R1CS",
"type": "Arithmetization",
"name": "R1CS",
"description": "Rank 1 constraint system defined by a set of quadratic conditions on the circuit input."
},
{
"id": "CustomCircuits",
"type": "Other",
"name": "App-specific circuits",
"description": "This project uses custom app-specific ZK circuits."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"id": "PrivacyBoost",
"name": "Privacy Boost",
"id": "PrivacyBoostv2",
"name": "Privacy Boost September 2026",
"risk": "red",
"participantCount": 23,
"shortDescription": "Circuit-specific trusted setup for the 18 Groth16 Privacy Boost circuits. It was built on top of 80 Perpetual Powers of Tau phase 1 contributions, with a publicly announced phase 2 that drew 23 to 25 participants depending on the circuit. The proving system could be broken if either phase 1 or 2 is compromised.",
"longDescription": "Circuit-specific trusted setup for the 18 Groth16 circuits of the Privacy Boost protocol over the\nBN254 curve, run by Sunnyside Labs and finalised on 1 April 2026.\nIt reuses the first 80 contributions of the public\n[Perpetual Powers of Tau](https://github.com/privacy-ethereum/perpetualpowersoftau) ceremony as Phase 1.\nPhase 2 is a gnark-native MPC ceremony, the published manifest records **25 participants** and **425 contributions** in total, between 23 and\n25 per circuit. Participants are identified by GitHub username.\n\n- Phase 1 ceremony (first 80 contributions are used): .\n- Ceremony repository and contributor tooling: [https://github.com/sunnyside-io/privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony)\n- Offline verification procedure: [https://github.com/sunnyside-io/privacy-boost-ceremony/blob/main/PUBLIC_VERIFICATION.md](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/main/PUBLIC_VERIFICATION.md)\n- Public verification bundle: [https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz](https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz)\n- Derived key bundle: [https://file.ceremony.privacyboost.io/prod-20260401-keys.tar.gz](https://file.ceremony.privacyboost.io/prod-20260401-keys.tar.gz)"
"shortDescription": "Circuit-specific trusted setup for the deployed verifiers. L2BEAT has not verified the ceremony files.",
"longDescription": "The deployed protocol uses 21 circuit configurations across five verifier families. Circuit and ceremony configuration sources are public, but L2BEAT has not identified the exact source revision and ceremony artifacts used to generate the deployed verification keys. Reproduction is blocked until these inputs are available. The participant count and contribution history for the deployed keys remain unverified."
}
],
"verifierHashes": [
{
"hash": "Privacy Boost epoch verifier 18.08.2026",
"name": "Privacy Boost epoch verifier, 14 circuits",
"description": "Verifies the batched private transfer and withdrawal proofs.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/7b2a01864a706a6d440ada20a92e4ae75dcbfc0a/frontend/epoch_circuit.go",
"hash": "Privacy Boost epoch verifier 03.09.2026",
"name": "Privacy Boost epoch verifier (September 2026)",
"description": "Verifies private transfer and withdrawal epochs. The deployed verification keys have not yet been reproduced by L2BEAT.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/23907eeebf0e50cd18da42a287671189e61ecb0f/frontend/epoch_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b"
"address": "oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6"
}
],
"verificationStatus": "successful",
"attesters": [
"verificationStatus": "notVerified"
},
{
"hash": "Privacy Boost deposit verifier 03.09.2026",
"name": "Privacy Boost deposit verifier (September 2026)",
"description": "Verifies deposit epochs. The deployed verification keys have not yet been reproduced by L2BEAT.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/23907eeebf0e50cd18da42a287671189e61ecb0f/frontend/deposit_epoch_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
"address": "oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5"
}
],
"verificationSteps": "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.\n\nHelper scripts implementing all of the reproduction steps are in the\n[script archive](https://trusted-setup-hosting.l2beat.com/privacy/privacy-boost/privacy_boost_vk_digest.zip).\n\n1. Download the V1 production ceremony public bundle (about 33 GB) and extract it. The archive\n used for this attestation hashes to\n `3b6a9bfc4e88c135aa34fecce30a6073cc96be50d9baac6dd75a0bbf03078c4c`.\n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz\n shasum -a 256 prod-20260401-public.tar.gz\n tar xzf prod-20260401-public.tar.gz\n ```\n\n2. Check that the ceremony's circuit matrix in `public/config.snapshot.json` matches the circuit\n shapes registered on the verifier, and that the manifest's `circuitSpecJson` for each circuit\n agrees with them.\n\n3. Re-derive every key from the transcript. Clone\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at tag `v0.1.9`. Then run:\n\n ```\n CGO_ENABLED=0 go build -o ./bin/ceremony ./cmd/ceremony\n ./bin/ceremony verify-public --bundle-dir \n ```\n\n This recomputes every artifact digest, the bundle root and the transcript adjacency chain, then\n recompiles each circuit's R1CS from its spec, fetches the pinned Perpetual Powers of Tau artifact\n for the required power, and re-derives the proving and verifying keys from the ordered phase 2\n outputs, comparing them to the manifest commitments.\n\n On a smaller machine the same derivation can be done circuit by circuit, which brings the peak down to\n roughly 10 GB at the cost of running the circuits one at a time\n rather than in one pass. The script archive includes a helper that does this.\n\n4. For each circuit, encode the re-derived `public/circuits//keys/.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain."
"verificationStatus": "notVerified"
},
{
"hash": "Privacy Boost deposit verifier 18.08.2026",
"name": "Privacy Boost deposit verifier, 3 circuits",
"description": "Verifies the batched deposit epoch proofs.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/7b2a01864a706a6d440ada20a92e4ae75dcbfc0a/frontend/deposit_epoch_circuit.go",
"hash": "Privacy Boost forced withdrawal verifier 03.09.2026",
"name": "Privacy Boost forced withdrawal verifier (September 2026)",
"description": "Verifies forced withdrawals. The deployed verification keys have not yet been reproduced by L2BEAT.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/23907eeebf0e50cd18da42a287671189e61ecb0f/frontend/forced_withdraw_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924"
"address": "oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
}
],
"verificationStatus": "successful",
"attesters": [
"verificationStatus": "notVerified"
},
{
"hash": "Privacy Boost portal deposit verifier 03.09.2026",
"name": "Privacy Boost portal deposit verifier (September 2026)",
"description": "Verifies portal deposits. The deployed verification keys have not yet been reproduced by L2BEAT.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/23907eeebf0e50cd18da42a287671189e61ecb0f/frontend/deposit_portal_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
"address": "oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6"
}
],
"verificationSteps": "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.\n\nHelper scripts implementing all of the reproduction steps are in the\n[script archive](https://trusted-setup-hosting.l2beat.com/privacy/privacy-boost/privacy_boost_vk_digest.zip).\n\n1. Download the V1 production ceremony public bundle (about 33 GB) and extract it. The archive\n used for this attestation hashes to\n `3b6a9bfc4e88c135aa34fecce30a6073cc96be50d9baac6dd75a0bbf03078c4c`.\n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz\n shasum -a 256 prod-20260401-public.tar.gz\n tar xzf prod-20260401-public.tar.gz\n ```\n\n2. Check that the ceremony's circuit matrix in `public/config.snapshot.json` matches the circuit\n shapes registered on the verifier, and that the manifest's `circuitSpecJson` for each circuit\n agrees with them.\n\n3. Re-derive every key from the transcript. Clone\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at tag `v0.1.9`. Then run:\n\n ```\n CGO_ENABLED=0 go build -o ./bin/ceremony ./cmd/ceremony\n ./bin/ceremony verify-public --bundle-dir \n ```\n\n This recomputes every artifact digest, the bundle root and the transcript adjacency chain, then\n recompiles each circuit's R1CS from its spec, fetches the pinned Perpetual Powers of Tau artifact\n for the required power, and re-derives the proving and verifying keys from the ordered phase 2\n outputs, comparing them to the manifest commitments.\n\n On a smaller machine the same derivation can be done circuit by circuit, which brings the peak down to\n roughly 10 GB at the cost of running the circuits one at a time\n rather than in one pass. The script archive includes a helper that does this.\n\n4. For each circuit, encode the re-derived `public/circuits//keys/.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain."
"verificationStatus": "notVerified"
},
{
"hash": "Privacy Boost forced withdrawal verifier 18.08.2026",
"name": "Privacy Boost forced withdrawal verifier, 1 circuit",
"description": "Verifies the client-side forced withdrawal proofs.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/7b2a01864a706a6d440ada20a92e4ae75dcbfc0a/frontend/forced_withdraw_circuit.go",
"hash": "Privacy Boost gift claim verifier 03.09.2026",
"name": "Privacy Boost gift claim verifier (September 2026)",
"description": "Verifies gift settlements and public gift exits. The deployed verification keys have not yet been reproduced by L2BEAT.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/23907eeebf0e50cd18da42a287671189e61ecb0f/frontend/gift_claim_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
"address": "oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "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.\n\nHelper scripts implementing all of the reproduction steps are in the\n[script archive](https://trusted-setup-hosting.l2beat.com/privacy/privacy-boost/privacy_boost_vk_digest.zip).\n\n1. Download the V1 production ceremony public bundle (about 33 GB) and extract it. The archive\n used for this attestation hashes to\n `3b6a9bfc4e88c135aa34fecce30a6073cc96be50d9baac6dd75a0bbf03078c4c`.\n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260401-public.tar.gz\n shasum -a 256 prod-20260401-public.tar.gz\n tar xzf prod-20260401-public.tar.gz\n ```\n\n2. Check that the ceremony's circuit matrix in `public/config.snapshot.json` matches the circuit\n shapes registered on the verifier, and that the manifest's `circuitSpecJson` for each circuit\n agrees with them.\n\n3. Re-derive every key from the transcript. Clone\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at tag `v0.1.9`. Then run:\n\n ```\n CGO_ENABLED=0 go build -o ./bin/ceremony ./cmd/ceremony\n ./bin/ceremony verify-public --bundle-dir \n ```\n\n This recomputes every artifact digest, the bundle root and the transcript adjacency chain, then\n recompiles each circuit's R1CS from its spec, fetches the pinned Perpetual Powers of Tau artifact\n for the required power, and re-derives the proving and verifying keys from the ordered phase 2\n outputs, comparing them to the manifest commitments.\n\n On a smaller machine the same derivation can be done circuit by circuit, which brings the peak down to\n roughly 10 GB at the cost of running the circuits one at a time\n rather than in one pass. The script archive includes a helper that does this.\n\n4. For each circuit, encode the re-derived `public/circuits//keys/.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain."
"verificationStatus": "notVerified"
}
]
}
privacyInfo+11-6
{
"attributes": [
{
"id": "zk",
"label": "ZK",
"description": "Uses zero-knowledge proofs to prove private actions without revealing private data."
},
{
"id": "tee",
"label": "TEE",
"description": "Privacy assumptions of this project are secured by trusted hardware."
},
{
"id": "transfers",
"label": "Transfers",
"description": "Private transfers within the shielded pool."
},
{
"id": "defi",
"label": "DeFi",
"description": "Interop with DeFi (swaps, vaults) from within the shielded pool."
},
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
}
],
"exitWindow": {
"value": "None",
"sentiment": "bad",
"orderHint": 0,
"description": "The pool and both registries sit behind transparent proxies whose ProxyAdmins are owned by the admin multisig, which can upgrade them with no delay. Users get no window to exit before a change takes effect.",
"walkawayTest": {
"passed": false,
"reason": "If the TEE operators disappear, no new deposits or private transfers can be processed and the system enters exit-only mode."
}
},
"privacy": {
"value": "Auditable admin API",
"value": "Admin API",
"sentiment": "bad",
"description": "All private data lives as plaintext within a TEE server. Registered auditors can use the TEE's Audit API to fetch the balance and transaction history of any address, and the TEE produces an auditable onchain record on the AuditGateway smart contract."
"description": "Registered 'auditors' can query the TEE's Audit API to retrieve the balance and transaction history of any address. These queries can be logged publicly on the AuditGateway smart contract, but there is no verifiable guarantee that all queries are logged."
},
"reproducibility": {
"value": "Reproducible",
"value": "Not verified",
"sentiment": "warning",
"description": "ZK circuits guaranteeing user fund security are published and reproduced, however the TEE sources guaranteeing privacy are not yet published. TEE logic could not be verified for correctness."
"description": "Circuit sources are published, but the verification keys deployed in September 2026 have not yet been reproduced by L2BEAT. TEE sources are not published, so the privacy logic has not been verified."
},
"riskSummary": "## Funds can be stolen if\n1. the zk proof system is broken, allowing invalid spends or withdrawals.\n2. the [trusted setup](#trusted-setups) is compromised or all ceremony participants collude, allowing invalid spends or withdrawals.\n3. the admin multisig deploys a malicious [upgrade](#upgrades-and-governance) or registers a malicious verifying key.\n \n## Funds can be lost if\n1. a user loses the note secrets or the approval key required to spend their notes.\n2. the operator and relays stop before a user's approval key is included in an auth snapshot.\n \n## Privacy can be lost if\n1. the TEE is compromised.\n2. a registered auditor fetches the user's balance and transaction history through the Audit API.\n3. 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.",
"riskSummary": "## Funds can be stolen if\n1. the zk proof system is broken, allowing invalid spends or withdrawals.\n2. the [trusted setup](#trusted-setups) is compromised or all ceremony participants collude, allowing invalid spends or withdrawals.\n3. the admin multisig deploys a malicious [upgrade](#upgrades-and-governance) or registers a malicious verifying key.\n \n## Funds can be lost if\n1. a user loses their note secrets, or loses access to both the account-owner wallet and any usable authorization keys.\n \n## Privacy can be lost if\n1. the TEE is compromised.\n2. a registered auditor fetches the user's balance and transaction history through the Audit API.\n3. 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.",
"tokens": [],
"upgradesAndGovernance": {
"content": "Privacy Boost is controlled by the 2/3 admin multisig that can upgrade core smart contracts,\nreplace the epoch, deposit and forced withdrawal verifiers,\nregister or replace verifying keys for individual circuit shapes, set the withdrawal fee up to 10%,\nand change the treasury and operator addresses."
"content": "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.\n\nThe 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."
}
}
permissions+3-3
{
"optimism": {
"roles": [],
"actors": [
{
"id": "AdminMultisig",
"name": "AdminMultisig",
"description": "A Multisig with 2/3 threshold. \n* Can upgrade **with no delay**\n * AuthRegistry [via: AuthRegistryProxyAdmin]\n * TokenRegistry [via: TokenRegistryProxyAdmin]\n * AuditGateway [via: AuditGatewayProxyAdmin]\n * PrivacyBoost [via: PrivacyBoostProxyAdmin]\n* Can interact with AuthRegistry\n * set the operator address of the AuthRegistry \n* Can interact with Groth16EpochVerifier\n * register and replace the Groth16 verification keys used to validate epoch proofs \n* Can interact with TokenRegistry\n * register new ERC-20 tokens to be accepted by the PrivacyBoost pool \n* Can interact with AuditGateway\n * manage the list of registered auditors and set the auditLogger address of the AuditGateway \n* Can interact with Groth16DepositVerifier\n * register and replace the Groth16 verification keys used to validate deposit proofs \n* Can interact with PrivacyBoost\n * replace the epoch, deposit and forced withdrawal proof verifiers, set the withdrawal fee (up to 10%), and set the treasury and operator addresses \n* Can interact with Groth16ForcedVerifier\n * register and replace the Groth16 verification keys used to validate forced withdrawal proofs ",
"description": "A Multisig with 2/3 threshold. \n* Can upgrade **with no delay**\n * AuthRegistry [via: AuthRegistryProxyAdmin]\n * TokenRegistry [via: TokenRegistryProxyAdmin]\n * AuditGateway [via: AuditGatewayProxyAdmin]\n * PrivacyBoost [via: PrivacyBoostProxyAdmin]\n* Can interact with Groth16DepositVerifier\n * register and replace the Groth16 verification keys used to validate deposit epoch proofs \n* Can interact with Groth16GiftClaimVerifier\n * register and replace the Groth16 verification keys used to validate gift settlement and public gift exit proofs \n* Can interact with ExternalCallGateway\n * set the guardian, install or remove external call policies, pause or unpause the gateway, and sweep stranded tokens back to the pool while paused \n* Can interact with AuthRegistry\n * set the operator address of the AuthRegistry \n* Can interact with Groth16PortalDepositVerifier\n * register and replace the Groth16 verification keys used to validate portal deposit epoch proofs \n* Can interact with Groth16ForcedVerifier\n * register and replace the Groth16 verification keys used to validate forced withdrawal proofs \n* Can interact with TokenRegistry\n * register new ERC-20 tokens to be accepted by the PrivacyBoost pool \n* Can interact with Groth16EpochVerifier\n * register and replace the Groth16 verification keys used to validate epoch proofs \n* Can interact with AuditGateway\n * manage the list of registered auditors and set the auditLogger address of the AuditGateway \n* Can interact with PrivacyBoost\n * 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 ",
"accounts": [
{
"address": "oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC",
"type": "Contract",
"isVerified": true,
"name": "0x6476…A0dC",
"url": "https://optimistic.etherscan.io/address/0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC"
}
],
"chain": "optimism",
"references": [],
"participants": [
{
"address": "oeth:0x769ef261964f1eDe0a554b74e9bB900d3Fb4AF1E",
"type": "EOA",
"isVerified": true,
"name": "0x769e…AF1E",
"url": "https://optimistic.etherscan.io/address/0x769ef261964f1eDe0a554b74e9bB900d3Fb4AF1E"
},
{
"address": "oeth:0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244",
"type": "EOA",
"isVerified": true,
"name": "0x90d3…4244",
"url": "https://optimistic.etherscan.io/address/0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244"
},
{
"address": "oeth:0xfEa8d7D07365a1A429319EF7A7a265CB4F530237",
"type": "EOA",
"isVerified": true,
"name": "0xfEa8…0237",
"url": "https://optimistic.etherscan.io/address/0xfEa8d7D07365a1A429319EF7A7a265CB4F530237"
}
],
"discoveryDrivenData": true
},
{
"id": "OperatorMultisig",
"name": "OperatorMultisig",
"description": "A Multisig with 2/3 threshold. \n* Can interact with AuthRegistry\n * manage the allowlist of relays that can submit key operations to the AuthRegistry on behalf of users \n* Can interact with PrivacyBoost\n * manage the relay allowlist and schedule changes of the auth snapshot interval ",
"description": "A Multisig with 2/3 threshold. \n* Can interact with ExternalCallGateway\n * pause the gateway and remove external call policies \n* Can interact with AuthRegistry\n * manage the allowlist of relays that can submit key operations to the AuthRegistry on behalf of users \n* Can interact with PrivacyBoost\n * approve or revoke external gateway routes used by proof-authorized withdrawals \n * manage the allowlist of relays that submit epochs to the pool ",
"accounts": [
{
"address": "oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B",
"type": "Contract",
"isVerified": true,
"name": "0x78a9…D52B",
"url": "https://optimistic.etherscan.io/address/0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B"
}
],
"chain": "optimism",
"references": [],
"participants": [
{
"address": "oeth:0x769ef261964f1eDe0a554b74e9bB900d3Fb4AF1E",
"type": "EOA",
"isVerified": true,
"name": "0x769e…AF1E",
"url": "https://optimistic.etherscan.io/address/0x769ef261964f1eDe0a554b74e9bB900d3Fb4AF1E"
},
{
"address": "oeth:0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244",
"type": "EOA",
"isVerified": true,
"name": "0x90d3…4244",
"url": "https://optimistic.etherscan.io/address/0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244"
},
{
"address": "oeth:0xfEa8d7D07365a1A429319EF7A7a265CB4F530237",
"type": "EOA",
"isVerified": true,
"name": "0xfEa8…0237",
"url": "https://optimistic.etherscan.io/address/0xfEa8d7D07365a1A429319EF7A7a265CB4F530237"
}
],
"discoveryDrivenData": true
},
{
"id": "TreasuryMultisig",
"name": "TreasuryMultisig",
"description": "A Multisig with 2/3 threshold. ",
"accounts": [
{
"address": "oeth:0xc82018cbC82A50064e3DdEF79EAdC319710Ffc5e",
"type": "Contract",
"isVerified": true,
"name": "0xc820…fc5e",
"url": "https://optimistic.etherscan.io/address/0xc82018cbC82A50064e3DdEF79EAdC319710Ffc5e"
}
],
"chain": "optimism",
"references": [],
"participants": [
{
"address": "oeth:0x769ef261964f1eDe0a554b74e9bB900d3Fb4AF1E",
"type": "EOA",
"isVerified": true,
"name": "0x769e…AF1E",
"url": "https://optimistic.etherscan.io/address/0x769ef261964f1eDe0a554b74e9bB900d3Fb4AF1E"
},
{
"address": "oeth:0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244",
"type": "EOA",
"isVerified": true,
"name": "0x90d3…4244",
"url": "https://optimistic.etherscan.io/address/0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244"
},
{
"address": "oeth:0xfEa8d7D07365a1A429319EF7A7a265CB4F530237",
"type": "EOA",
"isVerified": true,
"name": "0xfEa8…0237",
"url": "https://optimistic.etherscan.io/address/0xfEa8d7D07365a1A429319EF7A7a265CB4F530237"
}
],
"discoveryDrivenData": true
},
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "oeth:0x6Bd37032571F47e50f312542ae05D548B69DC9B0",
"type": "EOA",
"isVerified": true,
"name": "0x6Bd3…C9B0",
"url": "https://optimistic.etherscan.io/address/0x6Bd37032571F47e50f312542ae05D548B69DC9B0",
"displayName": "EOA 1"
}
],
"chain": "optimism",
"description": "* Can interact with AuthRegistry\n * submit account key registrations, rotations and revocations with valid owner signatures \n* Can interact with PrivacyBoost\n * submit epochs of private transfers, withdrawals and deposits with validity proofs, and snapshot auth tree roots ",
"description": "* Can interact with AuthRegistry\n * submit account key registrations, rotations and revocations with valid owner signatures \n* Can interact with PrivacyBoost\n * submit private transfer, withdrawal, deposit, portal deposit and gift settlement epochs with validity proofs, and simulate gateway withdrawals ",
"discoveryDrivenData": true
},
{
"id": "EOA-2",
"name": "EOA 2",
"accounts": [
{
"address": "oeth:0xE7F9E649b5406bf0751EA242CAc712151e1c73eB",
"type": "EOA",
"isVerified": true,
"name": "0xE7F9…73eB",
"url": "https://optimistic.etherscan.io/address/0xE7F9E649b5406bf0751EA242CAc712151e1c73eB",
"displayName": "EOA 2"
}
],
"chain": "optimism",
"description": "* Can interact with AuditGateway\n * log audit queries performed by registered auditors on the AuditGateway ",
"discoveryDrivenData": true
}
]
}
}
contracts+133-43
{
"addresses": {
"optimism": [
{
"name": "AuthPoseidon",
"isVerified": true,
"address": "oeth:0x09257a2B24C27586c2Db2C18c4b53bE459c7e870",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Poseidon2 hashing helper used by AuthRegistry to compute account IDs, authorization leaves, spend approval commitments and Merkle tree nodes.\n",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x09257a2B24C27586c2Db2C18c4b53bE459c7e870#code"
},
{
"name": "TokenRegistryProxyAdmin",
"isVerified": true,
"address": "oeth:0x11B75DE42f6107AE4D5C50e4e34af6E34F63C0dd",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Admin contract of the TokenRegistry proxy.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x11B75DE42f6107AE4D5C50e4e34af6E34F63C0dd#code"
},
{
"name": "Groth16DepositVerifier",
"isVerified": true,
"address": "oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x16e1dE876dEB1C3251A1E923A206605D084F25C5#code"
},
{
"name": "Groth16GiftClaimVerifier",
"isVerified": true,
"address": "oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x249ae8887E15e3728187dd4E341a66cb0221B1B4#code"
},
{
"name": "ExternalCallGateway",
"isVerified": true,
"address": "oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"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.\n* Roles:\n * **guardian**: OperatorMultisig\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x54B576782d3CE325CAc9861E17bB5d7926e41955#code"
},
{
"name": "AuthRegistry",
"isVerified": true,
"address": "oeth:0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0xfB66dfD80B9a96c2BF2bcfDC5E6715C48916eD6C"
],
"implementations": [
"oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b"
"oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776186491,
"transactionHash": "0x641f9c6a837b145e5a8a9f7d6cb35e080bd128eaaec7827c1665c090a22535d5",
"implementations": [
"oeth:0x2b32CD80464bE013007Ff35bBEEA29478194eA56"
]
},
{
"timestamp": 1779816339,
"transactionHash": "0xb9fbb085beef52c1c553f428b94180fc54ebdf3a50a3616b0efbae4756b572c3",
"implementations": [
"oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b"
]
},
{
"timestamp": 1788402805,
"transactionHash": "0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",
"implementations": [
"oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a"
]
}
],
"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.\n* Roles:\n * **admin**: AuthRegistryProxyAdmin; ultimately AdminMultisig\n * **allowedRelays**: EOA 1\n * **operator**: OperatorMultisig\n * **owner**: AdminMultisig",
"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.\n* Roles:\n * **admin**: AuthRegistryProxyAdmin; ultimately AdminMultisig\n * **allowedRelays**: EOA 1\n * **operator**: OperatorMultisig\n * **owner**: AdminMultisig",
"upgradableBy": [
{
"name": "AdminMultisig",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f#code"
},
{
"name": "Groth16EpochVerifier",
"name": "Groth16PortalDepositVerifier",
"isVerified": true,
"address": "oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b",
"address": "oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"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.\n* Roles:\n * **owner**: AdminMultisig",
"description": "Groth16 verifier for PrivacyBoost portal deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x67b1bD839203223870fBF51e4CDf2104E3Ca966b#code"
"url": "https://optimistic.etherscan.io/address/0x6806eA551C3c8350Ab156eC5001D28705dCda2B6#code"
},
{
"name": "Groth16ForcedVerifier",
"isVerified": true,
"address": "oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x78ff16aD4D38e560B81A7B33ae06607fe69D6641#code"
},
{
"name": "TokenRegistry",
"isVerified": true,
"address": "oeth:0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0x11B75DE42f6107AE4D5C50e4e34af6E34F63C0dd"
],
"implementations": [
"oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134"
"oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776186485,
"transactionHash": "0x969857c177e78cddd77fb7d52805242d5af5b357e33e3ba282e67aa416457f9e",
"implementations": [
"oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134"
]
},
{
"timestamp": 1788402805,
"transactionHash": "0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",
"implementations": [
"oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19"
]
}
],
"description": "Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.\n* Roles:\n * **admin**: TokenRegistryProxyAdmin; ultimately AdminMultisig\n * **owner**: AdminMultisig",
"upgradableBy": [
{
"name": "AdminMultisig",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6#code"
},
{
"name": "AuditGatewayProxyAdmin",
"isVerified": true,
"address": "oeth:0x96f3E5551E1330f31974597217019812667544c8",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Admin contract of the AuditGateway proxy.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x96f3E5551E1330f31974597217019812667544c8#code"
},
{
"name": "PrivacyBoostProxyAdmin",
"isVerified": true,
"address": "oeth:0x9d3F3CcD3c7a084eE73C4584CE33e77CEdaEc7E2",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Admin contract of the PrivacyBoost proxy.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x9d3F3CcD3c7a084eE73C4584CE33e77CEdaEc7E2#code"
},
{
"name": "Groth16EpochVerifier",
"isVerified": true,
"address": "oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"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.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6#code"
},
{
"name": "AuditGateway",
"isVerified": true,
"address": "oeth:0xb328535aB3bCe578996AE9af5A7f44f175721118",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0x96f3E5551E1330f31974597217019812667544c8"
],
"implementations": [
"oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478"
"oeth:0x384D1460107D88b1a21CA202825583c19cb6A808"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776188259,
"transactionHash": "0x28dd62c9d8f9ca9dfc48db609c540d5269aaa33a4b4067a401ddec3ea65f2909",
"implementations": [
"oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478"
]
},
{
"timestamp": 1788402805,
"transactionHash": "0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",
"implementations": [
"oeth:0x384D1460107D88b1a21CA202825583c19cb6A808"
]
}
],
"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.\n* Roles:\n * **admin**: AuditGatewayProxyAdmin; ultimately AdminMultisig\n * **auditLogger**: EOA 2\n * **owner**: AdminMultisig",
"upgradableBy": [
{
"name": "AdminMultisig",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0xb328535aB3bCe578996AE9af5A7f44f175721118#code"
},
{
"name": "Groth16DepositVerifier",
"isVerified": true,
"address": "oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts, registered per supported batch size.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0xC829061276e95D11aF92E678DE2B767AcFB4e924#code"
},
{
"name": "PrivacyBoost",
"isVerified": true,
"address": "oeth:0xca689828854a422CF1f778be03CA80549408F620",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0x9d3F3CcD3c7a084eE73C4584CE33e77CEdaEc7E2"
],
"implementations": [
"oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5"
"oeth:0x9CB144D35748932EC44950d0837248fcF8747828"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776188243,
"transactionHash": "0xdcf02ee332e61ef9468f869e0f309ec445008906b5419c660a5fab69e2424b8d",
"implementations": [
"oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5"
]
},
{
"timestamp": 1788402805,
"transactionHash": "0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",
"implementations": [
"oeth:0x9CB144D35748932EC44950d0837248fcF8747828"
]
}
],
"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.\n* Roles:\n * **admin**: PrivacyBoostProxyAdmin; ultimately AdminMultisig\n * **allowedRelays**: EOA 1\n * **operator**: OperatorMultisig\n * **owner**: AdminMultisig",
"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.\n* Roles:\n * **admin**: PrivacyBoostProxyAdmin; ultimately AdminMultisig\n * **allowedRelays**: EOA 1\n * **gatewayRouteManager**: OperatorMultisig\n * **operator**: OperatorMultisig\n * **owner**: AdminMultisig",
"upgradableBy": [
{
"name": "AdminMultisig",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0xca689828854a422CF1f778be03CA80549408F620#code"
},
{
"name": "Groth16ForcedVerifier",
"isVerified": true,
"address": "oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"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.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67#code"
},
{
"name": "AuthRegistryProxyAdmin",
"isVerified": true,
"address": "oeth:0xfB66dfD80B9a96c2BF2bcfDC5E6715C48916eD6C",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "optimism",
"description": "Admin contract of the AuthRegistry proxy.\n* Roles:\n * **owner**: AdminMultisig",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0xfB66dfD80B9a96c2BF2bcfDC5E6715C48916eD6C#code"
}
]
},
"risks": [],
"zkVerifiers": [
"oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924",
"oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b",
"oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
"oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5",
"oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6",
"oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641",
"oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6",
"oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
]
}
{
"attributes": [
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
},
{
"id": "stealthAddresses",
"label": "Stealth addresses",
"description": "Uses fresh, one-time recipient addresses to obscure who controls the receiving address."
}
],
"exitWindow": {
"value": "Infinite",
"sentiment": "good",
"orderHint": 9007199254740991,
"description": "The core contracts are immutable. The owner can change the toll for future payments, but cannot stop recipients from accessing payments that have already been sent.",
"walkawayTest": {
"passed": true
}
},
"noteDiscovery": {
"description": "Each Umbra payment emits an `Announcement` containing a one-time stealth address and encrypted data for the recipient. The recipient downloads all announcement events and checks them locally with their viewing key; a successful check identifies a payment and lets the recipient derive the key controlling its stealth address. The indexer or RPC provider does not learn which announcements belong to the user from the queries alone, because all announcements are fetched.\n\nUmbra Advanced mode allows setting start and end block numbers for transfer discovery scan. Using this feature could degrade your privacy against an RPC provider, who would be able to narrow down potential window for your incoming transfers. It is recommended to use this feature only with a trusted (e.g. your own) RPC node."
},
"privacy": {
"value": "Recipient privacy",
"sentiment": "good",
"sentiment": "warning",
"description": "There is no protocol-level compliance mechanism or privileged view key. Umbra hides who controls the receiving address, but the sender, amount, and stealth address remain public and privacy can be weakened by transaction patterns or poor withdrawal hygiene."
},
"reproducibility": {
"value": "Reproducible",
"sentiment": "good",
"description": "The immutable core contracts, cryptographic library, and frontend are published and can be built and run locally."
},
"riskSummary": "## Funds can be lost if\n1. an unsupported ERC-20, such as a fee-on-transfer or rebasing token, causes the Umbra contract's internal accounting to diverge from its token balance.\n \n## Privacy can be lost if\n1. a recipient sends funds from a stealth address to a publicly linked address or consolidates payments in a recognizable way.\n2. public timing, amount, token, or ENS registration patterns let an observer narrow down the possible recipient.\n \n## New payments can be stopped if\n1. the Umbra owner sets an arbitrarily high toll for contract-routed payments.",
"summaryTrackedItemName": "token",
"tokens": [
{
"token": {
"address": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"iconUrl": "https://assets.coingecko.com/coins/images/9956/large/Badge_Dai.png?1696509996",
"symbol": "DAI",
"decimals": 18,
"priceId": "dai",
"sinceTimestamp": 1619813937
},
"buckets": [
{
"id": "umbra-DAI",
"type": "pool",
"label": "DAI",
"address": "eth:0xFb2dc580Eed955B528407b4d36FfaFe3da685401",
"sinceTimestamp": 1619813937,
"deposit": {
"event": "0x29877766fa2bfe3b90008d6d92f965eca91cbc5757ed775740e460799fb92219",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0x6B175474E89094C44Da98b954EedeAC495271d0F"
}
},
"withdrawal": {
"event": "0x30eb3583ad09933b693a45452ab07512244cdbc5868701aa004c27b7b267c249",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0x6B175474E89094C44Da98b954EedeAC495271d0F"
}
}
}
]
},
{
"token": {
"address": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE",
"iconUrl": "https://assets.coingecko.com/coins/images/279/large/ethereum.png?1595348880",
"symbol": "ETH",
"decimals": 18,
"priceId": "ethereum",
"sinceTimestamp": 1619813937
},
"buckets": [
{
"id": "umbra-ETH",
"type": "pool",
"label": "ETH",
"address": "eth:0xFb2dc580Eed955B528407b4d36FfaFe3da685401",
"sinceTimestamp": 1619813937,
"deposit": {
"event": "0x29877766fa2bfe3b90008d6d92f965eca91cbc5757ed775740e460799fb92219",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"
}
},
"withdrawal": {
"event": "0x29877766fa2bfe3b90008d6d92f965eca91cbc5757ed775740e460799fb92219",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"
}
}
}
]
},
{
"token": {
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"iconUrl": "https://assets.coingecko.com/coins/images/6319/large/usdc.png?1696506694",
"symbol": "USDC",
"decimals": 6,
"priceId": "usd-coin",
"sinceTimestamp": 1619813937
},
"buckets": [
{
"id": "umbra-USDC",
"type": "pool",
"label": "USDC",
"address": "eth:0xFb2dc580Eed955B528407b4d36FfaFe3da685401",
"sinceTimestamp": 1619813937,
"deposit": {
"event": "0x29877766fa2bfe3b90008d6d92f965eca91cbc5757ed775740e460799fb92219",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
}
},
"withdrawal": {
"event": "0x30eb3583ad09933b693a45452ab07512244cdbc5868701aa004c27b7b267c249",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
}
}
}
]
},
{
"token": {
"address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
"iconUrl": "https://assets.coingecko.com/coins/images/325/large/Tether.png?1696501661",
"symbol": "USDT",
"decimals": 6,
"priceId": "tether",
"sinceTimestamp": 1619813937
},
"buckets": [
{
"id": "umbra-USDT",
"type": "pool",
"label": "USDT",
"address": "eth:0xFb2dc580Eed955B528407b4d36FfaFe3da685401",
"sinceTimestamp": 1619813937,
"deposit": {
"event": "0x29877766fa2bfe3b90008d6d92f965eca91cbc5757ed775740e460799fb92219",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0xdAC17F958D2ee523a2206206994597C13D831ec7"
}
},
"withdrawal": {
"event": "0x30eb3583ad09933b693a45452ab07512244cdbc5868701aa004c27b7b267c249",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0xdAC17F958D2ee523a2206206994597C13D831ec7"
}
}
}
]
},
{
"token": {
"address": "0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599",
"iconUrl": "https://assets.coingecko.com/coins/images/7598/large/wrapped_bitcoin_wbtc.png?1696507857",
"symbol": "WBTC",
"decimals": 8,
"priceId": "wrapped-bitcoin",
"sinceTimestamp": 1619813937
},
"buckets": [
{
"id": "umbra-WBTC",
"type": "pool",
"label": "WBTC",
"address": "eth:0xFb2dc580Eed955B528407b4d36FfaFe3da685401",
"sinceTimestamp": 1619813937,
"deposit": {
"event": "0x29877766fa2bfe3b90008d6d92f965eca91cbc5757ed775740e460799fb92219",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599"
}
},
"withdrawal": {
"event": "0x30eb3583ad09933b693a45452ab07512244cdbc5868701aa004c27b7b267c249",
"extractor": "umbraAmount",
"params": {
"tokenAddress": "0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599"
}
}
}
]
}
],
"upgradesAndGovernance": {
"content": "Umbra has no governance process or contract upgrade mechanism. The Umbra and StealthKeyRegistry contracts are immutable.\n\nThe Umbra contract has a permissioned owner that can immediately set the ETH toll charged on every contract-routed payment and change the addresses that collect and receive those tolls. Because the toll has no upper bound, the owner can effectively stop new payments through the Umbra contract at any time. The owner cannot change the payment or withdrawal logic and cannot prevent recipients from accessing payments already sent to them, so the exit window is infinite and the protocol passes the walkaway test."
}
}