{
"creator": "Sunnyside Labs",
"projectsForTvs": [
{
"projectId": "privacy-boost",
"sinceTimestamp": 1776188243
}
],
"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": "PrivacyBoostv2",
"name": "Privacy Boost September 2026",
"name": "Privacy Boost v2",
"risk": "red",
"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."
"participantCount": 23,
"shortDescription": "Circuit-specific trusted setup for the 21 Groth16 Privacy Boost circuits deployed in September 2026. It was built on top of 80 Perpetual Powers of Tau phase 1 contributions, with a publicly announced phase 2 that drew 26 participants and 23 to 25 contributions per circuit. The proving system could be broken if either phase 1 or 2 is compromised.",
"longDescription": "Circuit-specific trusted setup for the 21 Groth16 circuits of the Privacy Boost protocol over the\nBN254 curve, run by Sunnyside Labs and\nfinalised on 2 September 2026. It replaces the first round whose 18 circuits were retired with the\nSeptember 2026 upgrade.\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 **26 participants** and **490 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- Round record with the independently published bundle digests: [rounds/2026-02.md](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/e645b68d367c6c87ba77790b5a8db71808b1756f/rounds/2026-02.md)\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-20260902-public.tar](https://file.ceremony.privacyboost.io/prod-20260902-public.tar)\n- Derived key bundle: [https://file.ceremony.privacyboost.io/prod-20260902-keys.tar](https://file.ceremony.privacyboost.io/prod-20260902-keys.tar)"
}
],
"verifierHashes": [
{
"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",
"hash": "Privacy Boost epoch verifier 09.09.2026",
"name": "Privacy Boost epoch verifier, 13 circuits",
"description": "Verifies the batched private transfer and withdrawal proofs.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/epoch_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6"
}
],
"verificationStatus": "notVerified"
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The epoch verifier stores verification keys for 13 different batched private transfer and withdrawal circuits with varying `(maxTransfers, maxInputsPerTransfer, maxOutputsPerTransfer)` (`s1`, `s5`, `s12`, `s25`, `m1`, `m4`, `m8`, `l1`, `l3`, `l6`, `sp1`, `w51`, `w201`). The steps below reproduce all 13 verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.\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_v2.zip).\n\n1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the\n `.tar` name) and extract it. The archive used for this attestation hashes to\n `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. \n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar\n shasum -a 256 prod-20260902-public.tar\n tar xzf prod-20260902-public.tar\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 and with `circuit-setup/configs/production.ceremony.config.json` in\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`.\n\n3. Re-derive every key from the transcript. The circuits are the `frontend/` package of\n [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit\n `9e3f34e1a91c`. Note that the ceremony\n coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the\n build information embedded in the signed `ceremony/v0.0.x` release binaries. \n \n The public ceremony\n repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its\n `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit\n helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it\n against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for\n the required power, recomputes the origin of the phase 2 transcript, verifies every contribution\n against its predecessor, and seals the proving and verifying keys, comparing them to the manifest\n commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit.\n\n ```\n python3 run.py prepare\n python3 onchain.py\n python3 run.py run --jobs 2\n ```\n\n4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`,\n `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper\n reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from\n the circuit parameters and cross-checking them against the getters."
},
{
"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",
"hash": "Privacy Boost deposit verifier 09.09.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/9e3f34e1a91c20497bc7d8f47492761bc868843c/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:0x16e1dE876dEB1C3251A1E923A206605D084F25C5"
}
],
"verificationStatus": "notVerified"
"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`, `d4`, `d14`). The steps below reproduce all 3 verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.\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_v2.zip).\n\n1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the\n `.tar` name) and extract it. The archive used for this attestation hashes to\n `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`.\n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar\n shasum -a 256 prod-20260902-public.tar\n tar xzf prod-20260902-public.tar\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 and with `circuit-setup/configs/production.ceremony.config.json` in\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`.\n\n3. Re-derive every key from the transcript. The circuits are the `frontend/` package of\n [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit\n `9e3f34e1a91c`. Note that the ceremony\n coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the\n build information embedded in the signed `ceremony/v0.0.x` release binaries. \n \n The public ceremony\n repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its\n `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit\n helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it\n against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for\n the required power, recomputes the origin of the phase 2 transcript, verifies every contribution\n against its predecessor, and seals the proving and verifying keys, comparing them to the manifest\n commitments.\n\n ```\n python3 run.py prepare\n python3 onchain.py\n python3 run.py run --jobs 2\n ```\n\n4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`,\n `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper\n reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from\n the circuit parameters and cross-checking them against the getters."
},
{
"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",
"hash": "Privacy Boost forced withdrawal verifier 09.09.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/9e3f34e1a91c20497bc7d8f47492761bc868843c/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:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
}
],
"verificationStatus": "notVerified"
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The forced verifier stores a verification key for the forced withdrawal circuit (`f13`). The steps below reproduce it from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.\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_v2.zip).\n\n1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the\n `.tar` name) and extract it. The archive used for this attestation hashes to\n `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`.\n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar\n shasum -a 256 prod-20260902-public.tar\n tar xzf prod-20260902-public.tar\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 and with `circuit-setup/configs/production.ceremony.config.json` in\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`.\n\n3. Re-derive every key from the transcript. The circuits are the `frontend/` package of\n [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit\n `9e3f34e1a91c`. Note that the ceremony\n coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the\n build information embedded in the signed `ceremony/v0.0.x` release binaries. \n \n The public ceremony\n repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its\n `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit\n helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it\n against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for\n the required power, recomputes the origin of the phase 2 transcript, verifies every contribution\n against its predecessor, and seals the proving and verifying keys, comparing them to the manifest\n commitments.\n\n ```\n python3 run.py prepare\n python3 onchain.py\n python3 run.py run --jobs 2\n ```\n\n4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`,\n `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper\n reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from\n the circuit parameters and cross-checking them against the getters."
},
{
"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",
"hash": "Privacy Boost portal deposit verifier 09.09.2026",
"name": "Privacy Boost portal deposit verifier, 2 circuits",
"description": "Verifies the batched hidden-recipient portal deposit proofs.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_portal_circuit.go",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6"
}
],
"verificationStatus": "notVerified"
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The portal deposit verifier stores verification keys for 2 different batched portal deposit circuits across 2 registered batch sizes (`p1`, `p6`). The steps below reproduce both verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.\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_v2.zip).\n\n1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the\n `.tar` name) and extract it. The archive used for this attestation hashes to\n `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. \n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar\n shasum -a 256 prod-20260902-public.tar\n tar xzf prod-20260902-public.tar\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 and with `circuit-setup/configs/production.ceremony.config.json` in\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`.\n\n3. Re-derive every key from the transcript. The circuits are the `frontend/` package of\n [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit\n `9e3f34e1a91c`. Note that the ceremony\n coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the\n build information embedded in the signed `ceremony/v0.0.x` release binaries. \n \n The public ceremony\n repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its\n `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit\n helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it\n against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for\n the required power, recomputes the origin of the phase 2 transcript, verifies every contribution\n against its predecessor, and seals the proving and verifying keys, comparing them to the manifest\n commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit.\n\n ```\n python3 run.py prepare\n python3 onchain.py\n python3 run.py run --jobs 2\n ```\n\n4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`,\n `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper\n reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from\n the circuit parameters and cross-checking them against the getters."
},
{
"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",
"hash": "Privacy Boost gift claim verifier 09.09.2026",
"name": "Privacy Boost gift claim verifier, 2 circuits",
"description": "Verifies the batched gift claim, refund and public gift exit proofs.",
"sourceLink": "https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/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:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
}
],
"verificationStatus": "notVerified"
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The gift claim verifier stores verification keys for 2 different batched gift claim circuits across 2 registered batch sizes (`g1`, `g3`). The steps below reproduce both verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.\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_v2.zip).\n\n1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the\n `.tar` name) and extract it. The archive used for this attestation hashes to\n `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. \n\n ```\n curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar\n shasum -a 256 prod-20260902-public.tar\n tar xzf prod-20260902-public.tar\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 and with `circuit-setup/configs/production.ceremony.config.json` in\n [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`.\n\n3. Re-derive every key from the transcript. The circuits are the `frontend/` package of\n [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit\n `9e3f34e1a91c`. Note that the ceremony\n coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the\n build information embedded in the signed `ceremony/v0.0.x` release binaries. \n \n The public ceremony\n repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its\n `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit\n helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it\n against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for\n the required power, recomputes the origin of the phase 2 transcript, verifies every contribution\n against its predecessor, and seals the proving and verifying keys, comparing them to the manifest\n commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit.\n\n ```\n python3 run.py prepare\n python3 onchain.py\n python3 run.py run --jobs 2\n ```\n\n4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`,\n `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper\n reads all registered keys at one finalized OP Mainnet block, recomputing the storage slots from\n the circuit parameters and cross-checking them against the getters."
}
]
}
privacyInfo+2-2
{
"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": "Admin API",
"sentiment": "bad",
"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": "Not verified",
"value": "Partially reproducible",
"sentiment": "warning",
"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."
"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 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, 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."
}
}