{
"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.",
"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.",
"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",
"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)"
}
],
"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",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"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."
},
{
"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",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"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."
},
{
"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",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
}
],
"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."
}
]
}
interopConfig+1-0
null
privacyInfo+49-0
{
"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": "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",
"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."
},
"reproducibility": {
"value": "Reproducible",
"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."
},
"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.",
"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."
}
}
defiInfo+1-0
null
externalDependencies+1-0
null
tvsInfo+4-0
{
"associatedTokens": [],
"warnings": []
}
tvsConfig+1-0
null
activityConfig+1-0
null
livenessInfo+1-0
null
livenessConfig+1-0
null
costsInfo+1-0
null
trackedTxsConfig+1-0
null
daTrackingConfig+1-0
null
ecosystemInfo+1-0
null
ecosystemConfig+1-0
null
permissions+161-0
{
"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 ",
"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 ",
"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 ",
"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+256-0
{
"addresses": {
"optimism": [
{
"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": "AuthRegistry",
"isVerified": true,
"address": "oeth:0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0xfB66dfD80B9a96c2BF2bcfDC5E6715C48916eD6C"
],
"implementations": [
"oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776186491,
"transactionHash": "0x641f9c6a837b145e5a8a9f7d6cb35e080bd128eaaec7827c1665c090a22535d5",
"implementations": [
"oeth:0x2b32CD80464bE013007Ff35bBEEA29478194eA56"
]
},
{
"timestamp": 1779816339,
"transactionHash": "0xb9fbb085beef52c1c553f428b94180fc54ebdf3a50a3616b0efbae4756b572c3",
"implementations": [
"oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b"
]
}
],
"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",
"upgradableBy": [
{
"name": "AdminMultisig",
"delay": "no"
}
],
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f#code"
},
{
"name": "Groth16EpochVerifier",
"isVerified": true,
"address": "oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b",
"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",
"discoveryDrivenData": true,
"url": "https://optimistic.etherscan.io/address/0x67b1bD839203223870fBF51e4CDf2104E3Ca966b#code"
},
{
"name": "TokenRegistry",
"isVerified": true,
"address": "oeth:0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0x11B75DE42f6107AE4D5C50e4e34af6E34F63C0dd"
],
"implementations": [
"oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776186485,
"transactionHash": "0x969857c177e78cddd77fb7d52805242d5af5b357e33e3ba282e67aa416457f9e",
"implementations": [
"oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134"
]
}
],
"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": "AuditGateway",
"isVerified": true,
"address": "oeth:0xb328535aB3bCe578996AE9af5A7f44f175721118",
"upgradeability": {
"proxyType": "EIP1967 proxy",
"admins": [
"oeth:0x96f3E5551E1330f31974597217019812667544c8"
],
"implementations": [
"oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776188259,
"transactionHash": "0x28dd62c9d8f9ca9dfc48db609c540d5269aaa33a4b4067a401ddec3ea65f2909",
"implementations": [
"oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478"
]
}
],
"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"
]
},
"chain": "optimism",
"pastUpgrades": [
{
"timestamp": 1776188243,
"transactionHash": "0xdcf02ee332e61ef9468f869e0f309ec445008906b5419c660a5fab69e2424b8d",
"implementations": [
"oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5"
]
}
],
"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",
"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"
]
}
{
"redWarning": {
"text": "The tornado.cash website linked from the official project GitHub is malicious. Using it will result in the loss of deposited funds. Visit the official TORN DAO telegram channel for more info: https://t.me/TornadoCashOfficialDAO."
},
"unverifiedContracts": [
"eth:0xD82ed8786D7c69DC7e052F7A542AB047971E73d2",
"eth:0x6234c4C2734D2B246AE074492F402D8f58ff3226",
"eth:0xbFA347D89Ac54F7C2De2433458cb98A85fc03CEd"
]
}
display+3-0
{
"badges": [],
"description": "A classic Ethereum mixer design based on fixed-denomination pools and zk withdrawals.",
"detailedDescription": "Tornado Cash is a non-custodial mixer on Ethereum built around separate fixed-denomination pools, which prevents linking deposits and withdrawals via the amount. A deposit publishes a commitment into a Merkle tree producing a secret note, and a later withdrawal uses a zk-SNARK proof and the note to send the same denomination to a different address, breaking the deposit-withdrawal link. The note represents ownership of tokens in a Tornado cash pool, and losing it will effectively mean losing the tokens.\n\nThe core mixer contracts are immutable and have no admin, pause, or upgrade path, so funds can only move out with a valid proof. However Tornado cash features TORN token governance, which controls peripheral smart contracts: official pool registry, relayer registration requirement and TORN tokenomics.\n\n### Privacy considerations\n\nTornado cash introduces a permissionless relayer network, which is essential for practical privacy. Relayers process withdrawals from Tornado cash pools on user's behalf for a fee, which enables withdrawals to fresh addresses without funding them before the withdrawal. Without an active relayer network, practical privacy of Tornado cash deteriorates significantly.\n\nPractical privacy also depends on the timing of deposits and withdrawals, underlying network and browser used to interact with Tornado cash frontend (if used), RPC providers used to send transactions and query public blockchain state. Users are advised to research [OPSEC best practice](/publications/privacy-best-practices).\n\n### Fees\n\nThe immutable Tornado Cash pools do not charge a protocol-level deposit or withdrawal fee. Withdrawals can include a relayer fee chosen offchain between the user and the relayer and passed to the pool withdrawal call.\n\n### Compliance\n\nTornado cash does not have any protocol-level compliance features. However, it provides an optional [Compliance Tool](https://docs.tornado.cash/tornado-cash-classic/compliance-tool), which allows users to generate a proof linking a withdrawal to a specific deposit without revealing this information publicly onchain. This enables users to selectively disclose the origin of funds to third parties, such as exchanges or regulators.\n\nProtocol pools were [sanctioned by OFAC in August 2022](https://home.treasury.gov/news/press-releases/jy0916), flagging funds moved through these smart contracts as illicit and resulting in broad censorship (mainly by block builders) of transactions touching the contracts. Sanctions were lifted on March 21, 2025.\n\n### Anonymity set\n\nA user's anonymity set consists of all previous deposits into the same bucket (i.e. deposits of the same token and amount). Deposits can be mixed only with other deposits of the same token and denomination. To maximize the anonymity set, users are advised to deposit into the buckets with the most usage.\n\n### Secure frontend\n\nFor average users, the Tornado Cash frontend must be recognized as a critical part of the privacy protocol. If compromised, it can steal user assets and violate user privacy, which [was exploited in 2024](https://www.coindesk.com/business/2024/02/26/tornado-cash-reportedly-suffers-backend-exploit-user-deposits-at-risk).\n\nThe frontend's root of trust is the IPFS content hash registered for [tornadocash.eth](https://app.ens.domains/tornadocash.eth?tab=records) in the ENS smart contract on Ethereum. \nThe latest hash can be fetched from a trusted ethereum node (e.g. your own or trusted light node rpc). \nThere were incidents of malicious frontend hash updates passing onchain governance proposals before, so using a publicly audited or self-audited IPFS hash is advised. \nAn example of an audit process with useful links can be found [here](https://gist.github.com/pcaversaccio/ea7f62fd21b6e22f301980007f7c767e) or [here](https://notes.ethereum.org/@GW1ZUbNKR5iRjjKYx6_dJQ/Bk8zsJ9xj).\nThe frontend can then be accessed by running a local IPFS node that automatically fetches the verified frontend hash (e.g. [dapp3.eth](https://github.com/apoorvlathey/dapp3) or [kubo](https://github.com/ipfs/kubo) + [ipfs-companion](https://github.com/ipfs/ipfs-companion) and serves it in the browser locally.",
"links": {
"websites": [
"https://app.ens.domains/tornadocash.eth?tab=records"
],
"socialMedia": [
"https://t.me/TornadoCashOfficialDAO"
]
}
}