Search

Search for projects by name or address

Privacy
SummaryProtocol descriptionPrivacyValue LockedFlowsAssets BreakdownRisk summaryUpgrades & GovernanceTrusted setupVerifier IDsUpdatesPermissionsSmart contracts

Privacy Boost logo
Privacy Boost

2 recent updates

About

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

  • Total Value Locked
    $1.44 M0.45%
    across 18 assets and 18 buckets
  • TVL
    $1.44 M0.45%
  • Assets tracked
    18
  • Buckets tracked
    18
  • Deposits 7D
    6325.38%
  • Deposits 30D
    2.83 K
  • Deposits Total
    20.57 K
  • Trusted setup
  • Exit window
  • Privacy
    Link privacy
  • Reproducibility
  • Tracked on
    Base Chain logo
  • Attributes
    ZKTEETransfersDeFiAny amount

    • About

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

    Protocol description

    Privacy Boost is a shielded pool for registered ERC-20 tokens on Base, aimed at institutional users. The operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.’s TEE setup has to be trusted for privacy and livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer., while ZKPs ensure validity and an exit path against a malicious or faulty operator.

    Architecture

    Deposited tokens are represented as notes whose Poseidon2 commitments are appended to an onchain Merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs., 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 Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proof that checks correctness.

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

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

    Users can locally generate and deploy portal deposit EIP-7702 addresses. Anyone can send ERC-20 to such a portal address, the tokens are regularly swept into Privacy Boost escrow for the hidden recipient. Gift notes can be claimed by recipients or refunded by senders after a bound deadline, either privately through a relay or through a permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. public gift exit. Proof-authorized withdrawals can also call approved external gateways for DeFi operations.

    If the operator disappears, no new deposits or private transfers can be processed and the pool effectively enters this exit-only mode, in which the zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information. guarantees alone are sufficient to recover funds.

    Privacy considerations

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

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

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

    Fees

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

    Deposit and withdrawal statistics

    The pool’s own events do not carry per-transfer amounts, so L2BEAT counts every ERC-20 transfer into the pool as a deposit and every transfer out of it as a withdrawal. Besides regular deposits, portal sweeps and withdrawals, this includes refunds of cancelled deposit requests, withdrawal fees forwarded to the treasury, and both legs of DeFi operations executed through approved gateways.

    Compliance

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

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

    Privacy

    What the protocol promises: Hides everything inside the ledger, including which deposits fund a withdrawal. Deposits and withdrawals are public.

    On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note.

    Link private

    Transfers inside publish only encrypted notes. Deposits and withdrawals show address, token and amount. Each epoch's calldata pairs every exit with the nullifiers and the input/output shape of the transfer that funded it.

    Advice: Exit through the operator's relay; a forced exit reveals your account and the notes you spend. A public gift exit names the destination.

    InsideSenderprivateRecipientprivateAmountprivateAssetprivateLinkprivate
    Sources:PrivacyBoostEpoch calldata: withdrawals, nullifiers and transfer shapesForced withdrawal publishes account, destination and notesGift claim and refund are indistinguishable
    Link exposed

    The anonymity set is small, so most withdrawals can be linked to their funding deposits by amount and timing.

    Advice: There is currently no crowd to hide in. Keep funds inside and transfer often, withdraw amounts that match no deposit, and never exit to an address that has deposited.

    Compared with a public observer
    InsideSenderat riskRecipientat riskAmountat riskAssetat riskLinkat risk
    Sources:Operator heartbeat addressWithdrawal fee in basis points
    Link private

    All shielded actions go to the operator's server as an encrypted envelope, and note keys stay in a local vault. Only the operator's relay submits epochs onchain, so nothing of yours reaches a public node.

    Compared with a public observer
    InsideAmountprivateAssetprivateLinkprivate
    Sources:SDK package, closed Rust coreServer info endpointSingle permitted relay
    Link exposed

    The operator runs the enclave that holds every transfer in plaintext and the key to every onchain note. The client fetches that key from the operator's web endpoint and the published SDK checks no enclave attestation, so a substituted key would read every note unnoticed. Appointed auditors can pull any account's history without consent, and the audit log is written by the operator's own unpublished code.

    Advice: Treat everything in the pool as visible to the operator. A forced exit is the only path that does not need it, and it is public.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed
    Sources:AuditGatewayAdmin and operator multisigsTEE key is fetched from the operator endpointNotes wrap an ephemeral key for the TEE alongside the receiver
    Link exposed

    Every note wraps its key to the enclave's long-lived elliptic-curve public key as well as the receiver's. A quantum computer, or a leak of that one key, decrypts the entire history.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed
    Sources:Ciphertext layoutEvery output and deposit ciphertext carries a TEE-wrapped key

    Value Locked

    Flows

    Assets Breakdown

    Asset
    Deposits 7D
    Deposits 30D
    Deposits Total
    Value Locked
    wstETHwstETH
    1
    $49.86
    5
    $1.35 M
    5
    $1.35 M
    		$1.37 M
    USDCUSDC
    16
    $231.68 K
    61
    $299.62 K
    90
    $318.76 K
    		$52.29 K
    gtwethbgtwethb
    0
    $0.00
    5
    $12.54 K
    5
    $12.54 K
    		$13.77 K
    WETHWETH
    614
    $183.44 K
    2.74 K
    $209.32 K
    20.45 K
    $247.96 K
    		$2.55 K
    bbqUSDCbbqUSDC
    0
    $0.00
    2
    $797.87
    2
    $797.87
    		$787.95
    gtusdcfgtusdcf
    0
    $0.00
    5
    $19.35 K
    5
    $19.35 K
    		$241.68
    AAPLcAAPLc
    0
    $0.00
    1
    $7.19
    1
    $7.19
    		$7.39
    USDTUSDT
    0
    $0.00
    7
    $15.80
    7
    $15.80
    		$5.00
    CSUSDCCSUSDC
    0
    $0.00
    2
    $9.19
    2
    $9.19
    		$4.59
    edgeUSDCedgeUSDC
    1
    $1.90
    1
    $1.90
    1
    $1.90
    		$1.91
    BRETTBRETT
    0
    $0.00
    1
    $0.24
    1
    $0.24
    		$0.23
    AEROAERO
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    BasecatBasecat
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    cbBTCcbBTC
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    cbXRPcbXRP
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    EURCEURC
    0
    $0.00
    1
    $0.03
    1
    $0.03
    		—
    SOLSOL
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    TOSHITOSHI
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    Total
    632
    $415.18 K
    2.83 K
    $1.89 M
    20.57 K
    $1.95 M
    		$1.44 M

    Risk summary

    Funds can be stolen if

    1. the zk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. is broken, allowing invalid spends or withdrawals.
    2. the trusted setup is compromised or all ceremony participants collude, allowing invalid spends or withdrawals.
    3. the admin multisig deploys a malicious upgrade or registers a malicious verifying key.

    Funds can be lost if

    1. a user loses their note secrets, or loses access to both the account-owner wallet and any usable authorization keys.

    Privacy can be lost if

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

    Upgrades & Governance

    Privacy Boost is controlled by the 3/4 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, operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. and gateway route manager.

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

    Trusted setup

    Privacy Boost v3

    Gnark

    Detailed description

    CircuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level.-specific trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. for 12 Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. circuits of the Privacy Boost protocol over the BN254 curve, run by Sunnyside Labs as its third production round (prod-ceremony-2026-03, release ceremony/v0.0.5). Its keys were registered onchain on 23 September 2026 and replace the second round keys of the epoch (9 shapes, down from 13), forced withdrawal and gift claim circuits, which were recompiled with gnark v0.16.3 after the EdDSA signature check was rewritten. The deposit and portal deposit circuits keep their second round keys. It reuses the first 80 contributions of the public Perpetual Powers of Tau ceremony (pot28_0080) as Phase 1For Groth16 trusted setup, phase 1 represents circuit-independent part of the trusted setup (e.g. Perpetual Powers of Tau), which could be reused across different circuits. It generates a part of the secret cryptographic data required for Groth16 ZK protocol to work. If the outcome of phase 1 trusted setup ceremony is known, arbitrary proofs could be forged.. Phase 2For Groth16 trusted setup, phase 2 represents circuit-dependent part of the trusted setup. It generates a part of the secret cryptographic data required for Groth16 ZK protocol to work. If the outcome of phase 2 trusted setup ceremony is known, arbitrary proofs could be forged. is a gnark-native MPC ceremony. At the time of writing, the round record still marks the round as in preparation, and neither the public verification bundle nor the bundle digests have been published, so the number of participants and contributions could not be checked.

    Verifier IDs

    Verifier
    Verification
    Used in
    Known deployments
    Privacy Boost epoch verifier, 9 circuits
    Privacy Boost logo
    Description

    Verifies the batched private transfer and withdrawal proofs. The deployed verification keys have not yet been reproduced by L2BEAT.

    Verifier ID:Privacy Boost epoch verifier 23.09.2026
    Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/5792c139b9529ed80643262d75b5489055be11b0/frontend/epoch_circuit.go
    Known deployments

    Deployment #1

    Address:0xB144…b11e
    Used in:
    Privacy Boost logo
    Privacy Boost deposit verifier, 3 circuits
    by
    Privacy Boost logo
    Description

    Verifies the batched deposit epoch proofs.

    Verifier ID:Privacy Boost deposit verifier 09.09.2026
    Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_epoch_circuit.go
    Known deployments

    Deployment #1

    Address:0xac60…627d
    Used in:
    Privacy Boost logo
    Verification steps

    The deposit verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. sources and trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.

    Helper scripts implementing all of the reproduction steps are in the script archive.

    1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the .tar name) and extract it. The archive used for this attestation hashes to 91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a.

      curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar
shasum -a 256 prod-20260902-public.tar
tar xzf prod-20260902-public.tar

    2. Check that the ceremony’s circuit matrix in public/config.snapshot.json matches the circuit shapes registered on the verifier, and that the manifest’s circuitSpecJson for each circuit agrees with them and with circuit-setup/configs/production.ceremony.config.json in privacy-boost-ceremony at commit e645b68d.

    3. Re-derive every key from the transcript. The circuits are the frontend/ package of privacy-boost-protocol at commit 9e3f34e1a91c. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed ceremony/v0.0.x release binaries.

      The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its verify-public command fails at the R1CS hashA fixed-length fingerprint of variable-size input, produced by a hash function. check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2For Groth16 trusted setup, phase 2 represents circuit-dependent part of the trusted setup. It generates a part of the secret cryptographic data required for Groth16 ZK protocol to work. If the outcome of phase 2 trusted setup ceremony is known, arbitrary proofs could be forged. transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments.

      python3 run.py prepare
python3 onchain.py
python3 run.py run --jobs 2

    4. For each circuit, encode the re-derived .vk into the onchain layout (negate beta, gamma, delta; interleave G1.K) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. (equivalent to the Base deployment), recomputing the storage slots from the circuit parameters and cross-checking them against the getters.

    Privacy Boost forced withdrawal verifier, 1 circuit
    Privacy Boost logo
    Description

    Verifies the client-side forced withdrawal proofs. The deployed verification keys have not yet been reproduced by L2BEAT.

    Verifier ID:Privacy Boost forced withdrawal verifier 23.09.2026
    Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/5792c139b9529ed80643262d75b5489055be11b0/frontend/forced_withdraw_circuit.go
    Known deployments

    Deployment #1

    Address:0x40e9…85cE
    Used in:
    Privacy Boost logo
    Privacy Boost portal deposit verifier, 2 circuits
    by
    Privacy Boost logo
    Description

    Verifies the batched hidden-recipient portal deposit proofs.

    Verifier ID:Privacy Boost portal deposit verifier 09.09.2026
    Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_portal_circuit.go
    Known deployments

    Deployment #1

    Address:0x0c8b…CF63
    Used in:
    Privacy Boost logo
    Verification steps

    The portal deposit verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. sources and trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space.

    Helper scripts implementing all of the reproduction steps are in the script archive.

    1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the .tar name) and extract it. The archive used for this attestation hashes to 91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a.

      curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar
shasum -a 256 prod-20260902-public.tar
tar xzf prod-20260902-public.tar

    2. Check that the ceremony’s circuit matrix in public/config.snapshot.json matches the circuit shapes registered on the verifier, and that the manifest’s circuitSpecJson for each circuit agrees with them and with circuit-setup/configs/production.ceremony.config.json in privacy-boost-ceremony at commit e645b68d.

    3. Re-derive every key from the transcript. The circuits are the frontend/ package of privacy-boost-protocol at commit 9e3f34e1a91c. Note that the ceremony coordinator compiled them with gnark v0.15.0 and gnark-crypto v0.20.1, as recorded in the build information embedded in the signed ceremony/v0.0.x release binaries.

      The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its verify-public command fails at the R1CS hashA fixed-length fingerprint of variable-size input, produced by a hash function. check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit’s R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2For Groth16 trusted setup, phase 2 represents circuit-dependent part of the trusted setup. It generates a part of the secret cryptographic data required for Groth16 ZK protocol to work. If the outcome of phase 2 trusted setup ceremony is known, arbitrary proofs could be forged. transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit.

      python3 run.py prepare
python3 onchain.py
python3 run.py run --jobs 2

    4. For each circuit, encode the re-derived .vk into the onchain layout (negate beta, gamma, delta; interleave G1.K) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. (equivalent to the Base deployment), recomputing the storage slots from the circuit parameters and cross-checking them against the getters.

    Privacy Boost gift claim verifier, 2 circuits
    Privacy Boost logo
    Description

    Verifies the batched gift claim, refund and public gift exit proofs. The deployed verification keys have not yet been reproduced by L2BEAT.

    Verifier ID:Privacy Boost gift claim verifier 23.09.2026
    Source:https://github.com/sunnyside-io/privacy-boost-protocol/blob/5792c139b9529ed80643262d75b5489055be11b0/frontend/gift_claim_circuit.go
    Known deployments

    Deployment #1

    Address:0x8f39…DC05
    Used in:
    Privacy Boost logo

    Updates

    2026 October 01, 10:55 UTC
    18changes

    Switched privacy boost discovery to base from op mainnet.

    Switched privacy boost discovery to base from op mainnet.

    New and verified contracts

    + Status: CREATED
    contract ExternalCallGateway (base:0x02Eb6E5779f5780A5ABB354341962d9312b7ABe6) [privacy-boost/ExternalCallGateway]
    +++ description: Gateway executing pool-authorized external calls against an allowlist of target addresses and function selectors, with optional input/output token constraints. Enforces proof-bound settlement receipts and redeposits returned funds into the pool.
    + Status: CREATED
    contract TreasuryMultisig (base:0x04484B6065A43fa286e05E9C28a6c4Db77d917f8) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract Groth16PortalDepositVerifier (base:0x0c8bb018a3d8DF4c5fC86518ca57F8E1445BCF63) [privacy-boost/Groth16PortalDepositVerifier]
    +++ description: Groth16 verifier for PrivacyBoost portal deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract AuthRegistryProxyAdmin (base:0x321e0edAb1b628aEF03DBe19CC9C7dAB844f84bc) [global/ProxyAdmin]
    +++ description: Admin contract of the AuthRegistry proxy.
    + Status: CREATED
    contract TokenRegistryProxyAdmin (base:0x32b0998c86d33b1b6898F486dC78D80FaA27095f) [global/ProxyAdmin]
    +++ description: Admin contract of the TokenRegistry proxy.
    + Status: CREATED
    contract TokenRegistry (base:0x3A0bea3a715881793cFD698dDEBcF03784f0bE03) [privacy-boost/TokenRegistry]
    +++ description: Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.
    + Status: CREATED
    contract Groth16ForcedVerifier (base:0x40e93d3357A5A3d249437717Da936f6141ba85cE) [privacy-boost/Groth16ForcedVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract OperatorMultisig (base:0x420A8a682892bae85cba7fb0e5Cd806807C5Bf95) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract AuthRegistry (base:0x4daC7dA2c8cA097B3e0FF42aBFCebd2833196eB3) [privacy-boost/AuthRegistry_v2]
    +++ description: Registry of PrivacyBoost account authorization keys and onchain spend approvals. Supports BabyJubJub keys authorized by account-owner signatures, approval-only accounts and revocable batches of spend approvals. Tracks current and recently superseded auth roots; forced withdrawals validate live auth records directly.
    + Status: CREATED
    contract PrivacyBoost (base:0x71A0fD3C76E3E937d8275A3cb6a467b70123bD40) [privacy-boost/PrivacyBoost_v2]
    +++ description: Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits.
    + Status: CREATED
    contract AdminMultisig (base:0x78DFf7F33E3d5edD68D13D6d1fE23078062866f7) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract AuditGateway (base:0x7Bb891f7D7c78A8d6770cb273aBC603A148824b6) [privacy-boost/AuditGateway]
    +++ description: Manages the list of auditors authorized to query private user data through the Audit API of the TEE, and stores an onchain log of every audit access so that users can publicly verify whether and when their private data was disclosed.
    + Status: CREATED
    contract AuthPoseidon (base:0x8b72188D4A15661E0a3D232ACecCA7A26757C42D) [privacy-boost/AuthPoseidon]
    +++ description: Poseidon2 hashing helper used by AuthRegistry to compute account IDs, authorization leaves, spend approval commitments and Merkle tree nodes.
    + Status: CREATED
    contract Groth16GiftClaimVerifier (base:0x8f394a08A7544daf39aF38FEA5B2E348180bDC05) [privacy-boost/Groth16GiftClaimVerifier]
    +++ description: Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16DepositVerifier (base:0xac60252EF8dbC139e0da63cE7F2a13D25a5B627d) [privacy-boost/Groth16DepositVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16EpochVerifier (base:0xB144eb785E2CCe17681395Cd475093C01AEeb11e) [privacy-boost/Groth16EpochVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost private transfer and withdrawal epochs. Keys are indexed by (max transfers, inputs per transfer, outputs per transfer). The nested key registry is not enumerable and emits no registration events; discovery monitors the reviewed production circuit configurations.
    + Status: CREATED
    contract AuditGatewayProxyAdmin (base:0xB32ef2884794999e1E260a3f68368A24CEF25b35) [global/ProxyAdmin]
    +++ description: Admin contract of the AuditGateway proxy.
    + Status: CREATED
    contract PrivacyBoostProxyAdmin (base:0xd4C0599a5d9A2CcA46Ee05a03405B3ad3407b15e) [global/ProxyAdmin]
    +++ description: Admin contract of the PrivacyBoost proxy.
    2026 September 28, 14:00 UTC
    High severity
    18changes

    Redeployed identical PrivacyBoost implementation (https://disco.l2beat.com/diff/oeth:0x9CB144D35748932EC44950d0837248fcF8747828/oeth:0x319785d27Bd9889248804FA803FAC3e58D9ca002) together with redeploying three verifiers (Groth16EpochVerifier, Groth16ForcedVerifier and Groth16GiftClaimVerifier). These three verifiers have different verification keys because forced withdrawal and gift claim circuits were recompiled with gnark v0.16.3 after the EdDSA signature check was rewritten to a double-base scalar multiplication (PR 10) and some circuit shapes are no longer supported. New circuits also introduce a new trusted setup. Trusted setup artifacts are not yet published so the verification keys could not be regenerated.

    Redeployed identical PrivacyBoost implementation (https://disco.l2beat.com/diff/oeth:0x9CB144D35748932EC44950d0837248fcF8747828/oeth:0x319785d27Bd9889248804FA803FAC3e58D9ca002) together with redeploying three verifiers (Groth16EpochVerifier, Groth16ForcedVerifier and Groth16GiftClaimVerifier).

    These three verifiers have different verification keys because forced withdrawal and gift claim circuits were recompiled with gnark v0.16.3 after the EdDSA signature check was rewritten to a double-base scalar multiplication (PR #10) and some circuit shapes are no longer supported. New circuits also introduce a new trusted setup.

    Trusted setup artifacts are not yet published so the verification keys could not be regenerated.

    - Status: DELETED
    contract Groth16GiftClaimVerifier (oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4) [privacy-boost/Groth16GiftClaimVerifier]
    +++ description: Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.
    contract AdminMultisig (oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC) [GnosisSafe] {
    +++ description: None
    receivedPermissions.1.from:
    - "oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
    + "oeth:0x3C0028300aA32e5B0069fc4731D367E40BCF4670"
    receivedPermissions.5:
    - {"permission":"interact","from":"oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641","description":"register and replace the Groth16 verification keys used to validate forced withdrawal proofs.","role":".owner"}
    receivedPermissions.6:
    + {"permission":"interact","from":"oeth:0xA307E5d45Dee6F1EF1F7ef67619a0aFE8DcdacFE","description":"register and replace the Groth16 verification keys used to validate forced withdrawal proofs.","role":".owner"}
    receivedPermissions.7.from:
    - "oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6"
    + "oeth:0xac23C35cBA4a6C60EccBef31bC59Eacc2868663B"
    }
    - Status: DELETED
    contract Groth16ForcedVerifier (oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641) [privacy-boost/Groth16ForcedVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.
    - Status: DELETED
    contract Groth16EpochVerifier (oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6) [privacy-boost/Groth16EpochVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost private transfer and withdrawal epochs. Keys are indexed by (max transfers, inputs per transfer, outputs per transfer). The nested key registry is not enumerable and emits no registration events; discovery monitors the reviewed production circuit configurations.
    contract PrivacyBoost (oeth:0xca689828854a422CF1f778be03CA80549408F620) [privacy-boost/PrivacyBoost_v2] {
    +++ description: Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits.
    values.$implementation:
    - "oeth:0x9CB144D35748932EC44950d0837248fcF8747828"
    + "oeth:0x319785d27Bd9889248804FA803FAC3e58D9ca002"
    values.$pastUpgrades.2:
    + ["2026-09-23T22:24:33.000Z","0x5bca65b825c2f2679d0fbe2d3e0285218e9c988e3f0d6484a6baaa879b52ac0f",["oeth:0x319785d27Bd9889248804FA803FAC3e58D9ca002"]]
    values.$upgradeCount:
    - 2
    + 3
    +++ description: Groth16 verifier used for private transfer / withdrawal epoch proofs.
    +++ severity: HIGH
    values.epochVerifier:
    - "oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6"
    + "oeth:0xac23C35cBA4a6C60EccBef31bC59Eacc2868663B"
    +++ description: Groth16 verifier used for forced withdrawal proofs.
    +++ severity: HIGH
    values.forcedVerifier:
    - "oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
    + "oeth:0xA307E5d45Dee6F1EF1F7ef67619a0aFE8DcdacFE"
    +++ description: Groth16 verifier for private gift settlement and public gift exit proofs.
    +++ severity: HIGH
    values.giftClaimVerifier:
    - "oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
    + "oeth:0x3C0028300aA32e5B0069fc4731D367E40BCF4670"
    implementationNames.oeth:0x9CB144D35748932EC44950d0837248fcF8747828:
    - "PrivacyBoost"
    implementationNames.oeth:0x319785d27Bd9889248804FA803FAC3e58D9ca002:
    + "PrivacyBoost"
    }
    + Status: CREATED
    contract Groth16GiftClaimVerifier (oeth:0x3C0028300aA32e5B0069fc4731D367E40BCF4670) [privacy-boost/Groth16GiftClaimVerifier]
    +++ description: Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16ForcedVerifier (oeth:0xA307E5d45Dee6F1EF1F7ef67619a0aFE8DcdacFE) [privacy-boost/Groth16ForcedVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16EpochVerifier (oeth:0xac23C35cBA4a6C60EccBef31bC59Eacc2868663B) [privacy-boost/Groth16EpochVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost private transfer and withdrawal epochs. Keys are indexed by (max transfers, inputs per transfer, outputs per transfer). The nested key registry is not enumerable and emits no registration events; discovery monitors the reviewed production circuit configurations.
    2026 September 15, 09:31 UTC
    4changes

    Added a new member to the admin ms: 2/3 - 3/4.

    Added a new member to the admin ms: 2/3 -> 3/4.

    contract AdminMultisig (oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC) [GnosisSafe] {
    +++ description: None
    values.$members.0:
    + "oeth:0xcf01AB4fa0C5796811Ad939daB8dEd833cf90683"
    values.$members.1:
    - "oeth:0x90d3EbF1bbE3075F41772bB6f0A54e6038C84244"
    + "oeth:0xB30347E816B525453468cC95C17231Ab04a0C0A9"
    values.$threshold:
    - 2
    + 3
    values.multisigThreshold:
    - "2 of 3 (67%)"
    + "3 of 4 (75%)"
    }
    2026 September 07, 13:21 UTC
    High severity
    100changes

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

    Feature upgrade: replaces PrivacyBoost/AuthRegistry logic and all three verifiers, adds portal and gift features + verifiers, an external-call gateway, and expands the token registry to 11 assets. Auth snapshots are removed. New keys remain unverified because the trusted setup records are not yet published.

    external call gateway: whitelisted defi interactions

    portal: reusable recipient addresses

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

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

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

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

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

    contract AuthRegistry (oeth:0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f) [privacy-boost/AuthRegistry_v2] {
    +++ description: Registry of PrivacyBoost account authorization keys and onchain spend approvals. Supports BabyJubJub keys authorized by account-owner signatures, approval-only accounts and revocable batches of spend approvals. Tracks current and recently superseded auth roots; forced withdrawals validate live auth records directly.
    template:
    - "privacy-boost/AuthRegistry"
    + "privacy-boost/AuthRegistry_v2"
    sourceHashes.1:
    - "0x6428f3cd5084b5378b6215a3d5732d338b7579e92f92b364ee6f1db1cd9c9f16"
    + "0x53a840fbb8f7f80637b9be2a5f960b7901c110d9a8e08d65befb06d6532b110a"
    description:
    - "Registry of account authorization keys for the PrivacyBoost pool. Accounts register BabyJubJub approval public keys into Merkle trees with EIP-712 owner signatures (submitted directly or through allowed relays), and can rotate or revoke them. PrivacyBoost snapshots the tree roots and epoch proofs validate spend authorization against them."
    + "Registry of PrivacyBoost account authorization keys and onchain spend approvals. Supports BabyJubJub keys authorized by account-owner signatures, approval-only accounts and revocable batches of spend approvals. Tracks current and recently superseded auth roots; forced withdrawals validate live auth records directly."
    values.$implementation:
    - "oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b"
    + "oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a"
    values.$pastUpgrades.2:
    + ["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a"]]
    values.$upgradeCount:
    - 2
    + 3
    values.AUTH_ROOT_HISTORY_SIZE:
    - 64
    +++ description: External Poseidon2 helper for account IDs, authorization leaves and auth Merkle tree hashing.
    +++ severity: HIGH
    values.authPoseidon:
    + "oeth:0x09257a2B24C27586c2Db2C18c4b53bE459c7e870"
    +++ description: Maximum lifetime of an onchain spend approval, in seconds.
    +++ severity: HIGH
    values.MAX_APPROVAL_LIFETIME:
    + 2592000
    fieldMeta.authPoseidon:
    + {"severity":"HIGH","description":"External Poseidon2 helper for account IDs, authorization leaves and auth Merkle tree hashing."}
    fieldMeta.MAX_APPROVAL_LIFETIME:
    + {"severity":"HIGH","description":"Maximum lifetime of an onchain spend approval, in seconds."}
    implementationNames.oeth:0xcCdF755866c708A4a8D0002DC3f1a574226DF38b:
    - "AuthRegistry"
    implementationNames.oeth:0xA2072F7B4b261F997035f9522648c7c5bAF9370a:
    + "AuthRegistry"
    }
    contract AdminMultisig (oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC) [GnosisSafe] {
    +++ description: None
    receivedPermissions.0:
    + {"permission":"interact","from":"oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5","description":"register and replace the Groth16 verification keys used to validate deposit epoch proofs.","role":".owner"}
    receivedPermissions.1:
    + {"permission":"interact","from":"oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4","description":"register and replace the Groth16 verification keys used to validate gift settlement and public gift exit proofs.","role":".owner"}
    receivedPermissions.2:
    + {"permission":"interact","from":"oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955","description":"set the guardian, install or remove external call policies, pause or unpause the gateway, and sweep stranded tokens back to the pool while paused.","role":".owner"}
    receivedPermissions.4:
    + {"permission":"interact","from":"oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6","description":"register and replace the Groth16 verification keys used to validate portal deposit epoch proofs.","role":".owner"}
    receivedPermissions.1.description:
    - "register and replace the Groth16 verification keys used to validate epoch proofs."
    + "register and replace the Groth16 verification keys used to validate forced withdrawal proofs."
    receivedPermissions.1.from:
    - "oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b"
    + "oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
    receivedPermissions.7:
    + {"permission":"interact","from":"oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6","description":"register and replace the Groth16 verification keys used to validate epoch proofs.","role":".owner"}
    receivedPermissions.4:
    - {"permission":"interact","from":"oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924","description":"register and replace the Groth16 verification keys used to validate deposit proofs.","role":".owner"}
    receivedPermissions.5:
    - {"permission":"interact","from":"oeth:0xca689828854a422CF1f778be03CA80549408F620","description":"replace the epoch, deposit and forced withdrawal proof verifiers, set the withdrawal fee (up to 10%), and set the treasury and operator addresses.","role":".owner"}
    receivedPermissions.6.description:
    - "register and replace the Groth16 verification keys used to validate forced withdrawal proofs."
    + "replace all five proof verifiers, set withdrawal and portal sweep fees (each up to 10%), set token-specific portal minimum sweeps, and change the treasury, operator and gateway route manager."
    receivedPermissions.6.from:
    - "oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
    + "oeth:0xca689828854a422CF1f778be03CA80549408F620"
    }
    - Status: DELETED
    contract Groth16EpochVerifier (oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b) [privacy-boost/Groth16EpochVerifier]
    +++ description: Groth16 verifier for PrivacyBoost private transfer / withdrawal epoch proofs. Verification keys are stored in SSTORE2 data contracts, keyed by circuit configuration (max transfers, inputs and outputs per transfer). Registered epoch keys are not enumerable on-chain.
    EOA (oeth:0x6Bd37032571F47e50f312542ae05D548B69DC9B0) {
    +++ description: None
    receivedPermissions.1.description:
    - "submit epochs of private transfers, withdrawals and deposits with validity proofs, and snapshot auth tree roots."
    + "submit private transfer, withdrawal, deposit, portal deposit and gift settlement epochs with validity proofs, and simulate gateway withdrawals."
    }
    contract OperatorMultisig (oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B) [GnosisSafe] {
    +++ description: None
    receivedPermissions.0:
    + {"permission":"interact","from":"oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955","description":"pause the gateway and remove external call policies.","role":".guardian"}
    receivedPermissions.2:
    + {"permission":"interact","from":"oeth:0xca689828854a422CF1f778be03CA80549408F620","description":"approve or revoke external gateway routes used by proof-authorized withdrawals.","role":".gatewayRouteManager"}
    receivedPermissions.1.description:
    - "manage the relay allowlist and schedule changes of the auth snapshot interval."
    + "manage the allowlist of relays that submit epochs to the pool."
    }
    contract TokenRegistry (oeth:0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6) [privacy-boost/TokenRegistry] {
    +++ description: Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.
    values.$implementation:
    - "oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134"
    + "oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19"
    values.$pastUpgrades.1:
    + ["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19"]]
    values.$upgradeCount:
    - 1
    + 2
    +++ description: Latest token ID assigned; tokens are registered with IDs 1..nextId.
    values.nextId:
    - 4
    + 11
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.4:
    + {"tokenType":0,"tokenAddress":"oeth:0x68f180fcCe6836688e9084f035309E29Bf0A2095","tokenSubId":0}
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.5:
    + {"tokenType":0,"tokenAddress":"oeth:0x1F32b1c2345538c0c6f582fCB022739c4A194Ebb","tokenSubId":0}
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.6:
    + {"tokenType":0,"tokenAddress":"oeth:0x9560e827aF36c94D2Ac33a39bCE1Fe78631088Db","tokenSubId":0}
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.7:
    + {"tokenType":0,"tokenAddress":"oeth:0xDCB612005417Dc906fF72c87DF732e5a90D49e11","tokenSubId":0}
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.8:
    + {"tokenType":0,"tokenAddress":"oeth:0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1","tokenSubId":0}
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.9:
    + {"tokenType":0,"tokenAddress":"oeth:0xC30ce6A5758786e0F640cC5f881Dd96e9a1C5C59","tokenSubId":0}
    +++ description: Registered tokens (token type, token address, sub-id) by token ID.
    values.tokens.10:
    + {"tokenType":0,"tokenAddress":"oeth:0x3d63934715b6D4c4DFbBC1a00Fe2A2145079DD76","tokenSubId":0}
    implementationNames.oeth:0x238e6ec4968c9b00b16293139951c23815Ca1134:
    - "TokenRegistry"
    implementationNames.oeth:0x86A891632594Ae26834275925Eb4Fde37F1eBb19:
    + "TokenRegistry"
    }
    contract AuditGateway (oeth:0xb328535aB3bCe578996AE9af5A7f44f175721118) [privacy-boost/AuditGateway] {
    +++ description: Manages the list of auditors authorized to query private user data through the Audit API of the TEE, and stores an onchain log of every audit access so that users can publicly verify whether and when their private data was disclosed.
    values.$implementation:
    - "oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478"
    + "oeth:0x384D1460107D88b1a21CA202825583c19cb6A808"
    values.$pastUpgrades.1:
    + ["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0x384D1460107D88b1a21CA202825583c19cb6A808"]]
    values.$upgradeCount:
    - 1
    + 2
    implementationNames.oeth:0xfEfb6bD314680BDbc1B00FE2eA5A038655Bb4478:
    - "AuditGateway"
    implementationNames.oeth:0x384D1460107D88b1a21CA202825583c19cb6A808:
    + "AuditGateway"
    }
    - Status: DELETED
    contract Groth16DepositVerifier (oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924) [privacy-boost/Groth16DepositVerifier]
    +++ description: Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts, registered per supported batch size.
    contract PrivacyBoost (oeth:0xca689828854a422CF1f778be03CA80549408F620) [privacy-boost/PrivacyBoost_v2] {
    +++ description: Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits.
    template:
    - "privacy-boost/PrivacyBoost"
    + "privacy-boost/PrivacyBoost_v2"
    sourceHashes.1:
    - "0x0969b8ba50a27e47a32264c554c7bb5f41f38b4371347f61b08d4d8ac55ce613"
    + "0xa93601acbe9c964bab9c061132f2a8b35338b4dfbacee9bf924163d745e04405"
    description:
    - "Main contract of the PrivacyBoost private transfer pool. It escrows registered ERC-20 tokens deposited against note commitments, and lets allowed relays batch private transfers and withdrawals into epochs that are verified with Groth16 proofs against a note Merkle tree. Users can exit without relay cooperation via a delayed forced withdrawal with their own proof."
    + "Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlement proofs. Supports approved external gateway calls and permissionless exits through delayed forced withdrawals or public gift exits."
    values.$implementation:
    - "oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5"
    + "oeth:0x9CB144D35748932EC44950d0837248fcF8747828"
    values.$pastUpgrades.1:
    + ["2026-09-03T02:33:25.000Z","0xdb489f72d2b3e0cdab34535d416d81f14c6ca3d74d30c68e7f02cb2017fc035c",["oeth:0x9CB144D35748932EC44950d0837248fcF8747828"]]
    values.$upgradeCount:
    - 1
    + 2
    values.authSnapshotInterval:
    - 30
    values.authSnapshotScheduleVersion:
    - 0
    values.authSnapshotStartBlock:
    - 0
    values.authSnapshotStartRound:
    - 0
    values.currentAuthSnapshotInterval:
    - 30
    +++ description: Groth16 verifier used for deposit epoch proofs.
    +++ severity: HIGH
    values.depositVerifier:
    - "oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924"
    + "oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5"
    +++ description: Groth16 verifier used for private transfer / withdrawal epoch proofs.
    +++ severity: HIGH
    values.epochVerifier:
    - "oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b"
    + "oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6"
    +++ description: Groth16 verifier used for forced withdrawal proofs.
    +++ severity: HIGH
    values.forcedVerifier:
    - "oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67"
    + "oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641"
    values.latestSnapshotRound:
    - 5195055
    values.maxForcedInputs:
    - 8
    + 13
    values.maxOutputsPerTransfer:
    - 11
    + 201
    values.pendingAuthSnapshotEffectiveBlock:
    - 0
    values.pendingAuthSnapshotInterval:
    - 0
    values.pendingAuthSnapshotStartRound:
    - 0
    values.gatewayRouteManager:
    + "oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B"
    +++ description: Approved synchronous gateway routes for proof-authorized external calls.
    +++ severity: HIGH
    values.gateways:
    + ["oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955"]
    +++ description: Groth16 verifier for private gift settlement and public gift exit proofs.
    +++ severity: HIGH
    values.giftClaimVerifier:
    + "oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4"
    +++ description: Maximum age in blocks of a superseded auth root accepted for epoch and private gift settlement proofs.
    +++ severity: HIGH
    values.maxEpochAuthStalenessBlocks:
    + 300
    +++ description: Maximum age in blocks of a superseded auth root accepted for public gift exits. Despite its legacy name, this does not govern forced withdrawals, which check the live auth record at request time.
    +++ severity: HIGH
    values.maxForcedWithdrawalAuthStalenessBlocks:
    + 500
    +++ description: Groth16 verifier for portal deposit proofs.
    +++ severity: HIGH
    values.portalDepositVerifier:
    + "oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6"
    +++ description: Minimum gross amount per token ID required for a portal sweep, in token base units; defaults to zero.
    values.portalMinimumSweeps:
    + {"1":200000000000000,"2":"5000000000000000000","3":500000,"4":500000,"5":650,"6":170000000000000,"7":"25000000000000000000","8":400000,"9":"500000000000000000"}
    +++ description: Portal sweep fee in basis points, paid to the sweeper and snapshotted when the deposit is requested.
    values.portalSweepFeeBps:
    + 0
    fieldMeta.operator:
    - {"severity":"HIGH"}
    fieldMeta.allowedRelays.severity:
    - "HIGH"
    fieldMeta.authRegistry.description:
    - "Registry of account authorization keys whose tree roots are snapshotted and used to validate spend authorization in epoch proofs."
    + "Registry of account authorization keys and spend approvals used to validate spend authorization."
    fieldMeta.treasury.severity:
    - "HIGH"
    fieldMeta.cancelDelay.severity:
    + "HIGH"
    fieldMeta.forcedWithdrawalDelay.severity:
    + "HIGH"
    fieldMeta.authSnapshotInterval:
    - {"description":"Block interval between snapshots of auth tree roots."}
    fieldMeta.gateways:
    + {"severity":"HIGH","description":"Approved synchronous gateway routes for proof-authorized external calls."}
    fieldMeta.portalMinimumSweeps:
    + {"description":"Minimum gross amount per token ID required for a portal sweep, in token base units; defaults to zero."}
    fieldMeta.portalDepositVerifier:
    + {"severity":"HIGH","description":"Groth16 verifier for portal deposit proofs."}
    fieldMeta.giftClaimVerifier:
    + {"severity":"HIGH","description":"Groth16 verifier for private gift settlement and public gift exit proofs."}
    fieldMeta.maxEpochAuthStalenessBlocks:
    + {"severity":"HIGH","description":"Maximum age in blocks of a superseded auth root accepted for epoch and private gift settlement proofs."}
    fieldMeta.maxForcedWithdrawalAuthStalenessBlocks:
    + {"severity":"HIGH","description":"Maximum age in blocks of a superseded auth root accepted for public gift exits. Despite its legacy name, this does not govern forced withdrawals, which check the live auth record at request time."}
    fieldMeta.portalSweepFeeBps:
    + {"description":"Portal sweep fee in basis points, paid to the sweeper and snapshotted when the deposit is requested."}
    implementationNames.oeth:0x0b9B98d3B95D74487C481e7830ab440896aE62E5:
    - "PrivacyBoost"
    implementationNames.oeth:0x9CB144D35748932EC44950d0837248fcF8747828:
    + "PrivacyBoost"
    }
    - Status: DELETED
    contract Groth16ForcedVerifier (oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67) [privacy-boost/Groth16ForcedVerifier]
    +++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs, used by the permissionless exit path. Verification keys are stored in SSTORE2 data contracts, registered per supported input count.
    + Status: CREATED
    contract AuthPoseidon (oeth:0x09257a2B24C27586c2Db2C18c4b53bE459c7e870) [privacy-boost/AuthPoseidon]
    +++ description: Poseidon2 hashing helper used by AuthRegistry to compute account IDs, authorization leaves, spend approval commitments and Merkle tree nodes.
    + Status: CREATED
    contract Groth16DepositVerifier (oeth:0x16e1dE876dEB1C3251A1E923A206605D084F25C5) [privacy-boost/Groth16DepositVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16GiftClaimVerifier (oeth:0x249ae8887E15e3728187dd4E341a66cb0221B1B4) [privacy-boost/Groth16GiftClaimVerifier]
    +++ description: Groth16 verifier for PrivacyBoost gift settlement and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract ExternalCallGateway (oeth:0x54B576782d3CE325CAc9861E17bB5d7926e41955) [privacy-boost/ExternalCallGateway]
    +++ description: Gateway executing pool-authorized external calls against an allowlist of target addresses and function selectors, with optional input/output token constraints. Enforces proof-bound settlement receipts and redeposits returned funds into the pool.
    + Status: CREATED
    contract Groth16PortalDepositVerifier (oeth:0x6806eA551C3c8350Ab156eC5001D28705dCda2B6) [privacy-boost/Groth16PortalDepositVerifier]
    +++ description: Groth16 verifier for PrivacyBoost portal deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16ForcedVerifier (oeth:0x78ff16aD4D38e560B81A7B33ae06607fe69D6641) [privacy-boost/Groth16ForcedVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.
    + Status: CREATED
    contract Groth16EpochVerifier (oeth:0xab52453B02ca68cfbe7B264d3C4bBa566198C6B6) [privacy-boost/Groth16EpochVerifier_v2]
    +++ description: Groth16 verifier for PrivacyBoost private transfer and withdrawal epochs. Keys are indexed by (max transfers, inputs per transfer, outputs per transfer). The nested key registry is not enumerable and emits no registration events; discovery monitors the reviewed production circuit configurations.
    2026 August 21, 08:53 UTC
    14changes

    Initial discovery of privacy boost.

    Initial discovery of privacy boost.

    Initial discovery

    + Status: CREATED
    contract TokenRegistryProxyAdmin (oeth:0x11B75DE42f6107AE4D5C50e4e34af6E34F63C0dd) [global/ProxyAdmin]
    +++ description: Admin contract of the TokenRegistry proxy.
    + Status: CREATED
    contract AuthRegistry (oeth:0x54e87D7D0E420B24B9FdFE9cFcAe88162093A48f) [privacy-boost/AuthRegistry]
    +++ description: Registry of account authorization keys for the PrivacyBoost pool. Accounts register BabyJubJub approval public keys into Merkle trees with EIP-712 owner signatures (submitted directly or through allowed relays), and can rotate or revoke them. PrivacyBoost snapshots the tree roots and epoch proofs validate spend authorization against them.
    + Status: CREATED
    contract AdminMultisig (oeth:0x6476cBeBbce2673aeDAa464a4b9f31FD284aA0dC) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract Groth16EpochVerifier (oeth:0x67b1bD839203223870fBF51e4CDf2104E3Ca966b) [privacy-boost/Groth16EpochVerifier]
    +++ description: Groth16 verifier for PrivacyBoost private transfer / withdrawal epoch proofs. Verification keys are stored in SSTORE2 data contracts, keyed by circuit configuration (max transfers, inputs and outputs per transfer). Registered epoch keys are not enumerable on-chain.
    + Status: CREATED
    contract OperatorMultisig (oeth:0x78a927114A20Fb34b9d8d9c6a9A75E65f918D52B) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract TokenRegistry (oeth:0x867872f80b1e22D30C4b06FcB474aC10B9DAA2f6) [privacy-boost/TokenRegistry]
    +++ description: Registry mapping compact token IDs to the ERC-20 tokens accepted by the PrivacyBoost pool.
    + Status: CREATED
    contract AuditGatewayProxyAdmin (oeth:0x96f3E5551E1330f31974597217019812667544c8) [global/ProxyAdmin]
    +++ description: Admin contract of the AuditGateway proxy.
    + Status: CREATED
    contract PrivacyBoostProxyAdmin (oeth:0x9d3F3CcD3c7a084eE73C4584CE33e77CEdaEc7E2) [global/ProxyAdmin]
    +++ description: Admin contract of the PrivacyBoost proxy.
    + Status: CREATED
    contract AuditGateway (oeth:0xb328535aB3bCe578996AE9af5A7f44f175721118) [privacy-boost/AuditGateway]
    +++ description: Manages the list of auditors authorized to query private user data through the Audit API of the TEE, and stores an onchain log of every audit access so that users can publicly verify whether and when their private data was disclosed.
    + Status: CREATED
    contract TreasuryMultisig (oeth:0xc82018cbC82A50064e3DdEF79EAdC319710Ffc5e) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract Groth16DepositVerifier (oeth:0xC829061276e95D11aF92E678DE2B767AcFB4e924) [privacy-boost/Groth16DepositVerifier]
    +++ description: Groth16 verifier for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts, registered per supported batch size.
    + Status: CREATED
    contract PrivacyBoost (oeth:0xca689828854a422CF1f778be03CA80549408F620) [privacy-boost/PrivacyBoost]
    +++ description: Main contract of the PrivacyBoost private transfer pool. It escrows registered ERC-20 tokens deposited against note commitments, and lets allowed relays batch private transfers and withdrawals into epochs that are verified with Groth16 proofs against a note Merkle tree. Users can exit without relay cooperation via a delayed forced withdrawal with their own proof.
    + Status: CREATED
    contract Groth16ForcedVerifier (oeth:0xF023c61C5c745Be40fd30B0d48C0929839Ec3C67) [privacy-boost/Groth16ForcedVerifier]
    +++ description: Groth16 verifier for PrivacyBoost forced withdrawal proofs, used by the permissionless exit path. Verification keys are stored in SSTORE2 data contracts, registered per supported input count.
    + Status: CREATED
    contract AuthRegistryProxyAdmin (oeth:0xfB66dfD80B9a96c2BF2bcfDC5E6715C48916eD6C) [global/ProxyAdmin]
    +++ description: Admin contract of the AuthRegistry proxy.

    Permissions

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Base Chain

    Actors:

    OperatorMultisig0x420A…Bf95

    A Multisig with 2/3 threshold.

    • Can interact with ExternalCallGateway
      • pause the gateway and remove external call policies
    • Can interact with AuthRegistry
      • manage the allowlist of relays that can submit key operations to the AuthRegistry on behalf of users
    • Can interact with PrivacyBoost
      • approve or revoke external gateway routes used by proof-authorized withdrawals
      • manage the allowlist of relays that submit epochs to the pool

    Participants (3):

    0x769e…AF1E0x90d3…42440xfEa8…0237
    AdminMultisig0x78DF…66f7

    A Multisig with 3/4 threshold.

    • Can upgrade with no delay
      • TokenRegistry
      • AuthRegistry
      • PrivacyBoost
      • AuditGateway
    • Can interact with ExternalCallGateway
      • set the guardian, install or remove external call policies, pause or unpause the gateway, and sweep stranded tokens back to the pool while paused
    • Can interact with Groth16PortalDepositVerifier
      • register and replace the Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verification keys used to validate portal deposit epoch proofs
    • Can interact with TokenRegistry
      • register new ERC-20 tokens to be accepted by the PrivacyBoost pool
    • Can interact with Groth16ForcedVerifier
      • register and replace the Groth16 verification keys used to validate forced withdrawal proofs
    • Can interact with AuthRegistry
      • set the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. address of the AuthRegistry
    • Can interact with PrivacyBoost
      • replace all five proof verifiers, set withdrawal and portal sweep fees (each up to 10%), set token-specific portal minimum sweeps, and change the treasury, operator and gateway route manager
    • Can interact with AuditGateway
      • manage the list of registered auditors and set the auditLogger address of the AuditGateway
    • Can interact with Groth16GiftClaimVerifier
      • register and replace the Groth16 verification keys used to validate gift settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. and public gift exit proofs
    • Can interact with Groth16DepositVerifier
      • register and replace the Groth16 verification keys used to validate deposit epoch proofs
    • Can interact with Groth16EpochVerifier
      • register and replace the Groth16 verification keys used to validate epoch proofs

    Participants (4):

    0xcf01…06830x769e…AF1E0xB303…C0A90xfEa8…0237
    TreasuryMultisig0x0448…17f8

    A Multisig with 2/3 threshold.

    Participants (3):

    0x769e…AF1E0x90d3…42440xfEa8…0237
    EOA 10x6Bd3…C9B0
    • Can interact with AuthRegistry
      • submit account key registrations, rotations and revocations with valid owner signatures
    • Can interact with PrivacyBoost
      • submit private transfer, withdrawal, deposit, portal deposit and gift settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. epochs with validity proofs, and simulate gateway withdrawals
    EOA 20xE7F9…73eB
    • Can interact with AuditGateway
      • log audit queries performed by registered auditors on the AuditGateway

    Smart contracts

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Base Chain

    ExternalCallGateway0x02Eb…ABe6

    Gateway executing pool-authorized external calls against an allowlist of target addresses and function selectors, with optional input/output token constraints. Enforces proof-bound settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. receipts and redeposits returned funds into the pool.

    • Roles:
      • guardian: OperatorMultisig
      • owner: AdminMultisig
    Groth16PortalDepositVerifier0x0c8b…CF63

    Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for PrivacyBoost portal deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.

    • Roles:
      • owner: AdminMultisig
    AuthRegistryProxyAdmin0x321e…84bc

    Admin contract of the AuthRegistry proxy.

    • Roles:
      • owner: AdminMultisig
    TokenRegistryProxyAdmin0x32b0…095f

    Admin contract of the TokenRegistry proxy.

    • Roles:
      • owner: AdminMultisig
    TokenRegistry0x3A0b…bE03Implementation (Upgradable)Admin

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

    • Roles:
      • admin: TokenRegistryProxyAdmin; ultimately AdminMultisig
      • owner: AdminMultisig
    Can be upgraded by:
    AdminMultisig with no delay
    Groth16ForcedVerifier0x40e9…85cE

    Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for PrivacyBoost forced withdrawal proofs. Verification keys are stored in SSTORE2 data contracts.

    • Roles:
      • owner: AdminMultisig
    AuthRegistry0x4daC…6eB3Implementation (Upgradable)Admin

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

    • Roles:
      • admin: AuthRegistryProxyAdmin; ultimately AdminMultisig
      • allowedRelays: EOA 1
      • operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.: OperatorMultisig
      • owner: AdminMultisig
    Can be upgraded by:
    AdminMultisig with no delay
    PrivacyBoost0x71A0…bD40Implementation (Upgradable)Admin

    Main contract of the PrivacyBoost pool. Escrows ERC-20 tokens and verifies relay-submitted private transfer, withdrawal, deposit, portal deposit and gift settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. proofs. Supports approved external gateway calls and permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. exits through delayed forced withdrawals or public gift exits.

    • Roles:
      • admin: PrivacyBoostProxyAdmin; ultimately AdminMultisig
      • allowedRelays: EOA 1
      • gatewayRouteManager: OperatorMultisig
      • operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.: OperatorMultisig
      • owner: AdminMultisig
    Can be upgraded by:
    AdminMultisig with no delay
    AuditGateway0x7Bb8…24b6Implementation (Upgradable)Admin

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

    • Roles:
      • admin: AuditGatewayProxyAdmin; ultimately AdminMultisig
      • auditLogger: EOA 2
      • owner: AdminMultisig
    Can be upgraded by:
    AdminMultisig with no delay
    AuthPoseidon0x8b72…C42D

    Poseidon2 hashing helper used by AuthRegistry to compute account IDs, authorization leaves, spend approval commitments and Merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. nodes.

    Groth16GiftClaimVerifier0x8f39…DC05

    Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for PrivacyBoost gift settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. and public gift exit proofs. Verification keys are stored in SSTORE2 data contracts.

    • Roles:
      • owner: AdminMultisig
    Groth16DepositVerifier0xac60…627d

    Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for PrivacyBoost deposit epoch proofs. Verification keys are stored in SSTORE2 data contracts.

    • Roles:
      • owner: AdminMultisig
    Groth16EpochVerifier0xB144…b11e

    Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. configurations.

    • Roles:
      • owner: AdminMultisig
    AuditGatewayProxyAdmin0xB32e…5b35

    Admin contract of the AuditGateway proxy.

    • Roles:
      • owner: AdminMultisig
    PrivacyBoostProxyAdmin0xd4C0…b15e

    Admin contract of the PrivacyBoost proxy.

    • Roles:
      • owner: AdminMultisig