Search

Search for projects and tokens by name or address

Privacy
SummaryProtocol descriptionPrivacyValue LockedFlowsAssets BreakdownMilestones & IncidentsRisk summaryUpgrades & GovernanceTrusted setupVerifier IDsUpdatesPermissionsSmart contracts

Privacy Boost logo
Privacy Boost

About

A shielded ledger for ERC-20 tokens on Base, aimed at institutional users, whose privacy rests on the operator's TEE.

  • Total Value Locked
    $737.85 K25.0%
    across 18 assets and 18 buckets
  • TVL
    $737.85 K25.0%
  • Assets tracked
    18
  • Buckets tracked
    18
  • Deposits 7D
    3703.93%
  • Deposits 30D
    1.82 K
  • Deposits Total
    21.64 K
  • Privacy
    Link privacy
  • Trusted setup
  • Exit window
  • Reproducibility
  • Tracked on
    Base Chain logo
  • Attributes
    ZKTEETransfersDeFiAny amount
    • Public observerChain analystNetwork observerPrivileged insiderFuture adversary

    About

    A shielded ledger for ERC-20 tokens on Base, aimed at institutional users, whose privacy rests on the operator's TEE.

    Protocol description

    Privacy Boost lets apps on Base give their users a private ERC-20 balance. The user deposits tokens, sends them privately to other users, uses them in DeFi through approved gateways and withdraws to any address. Everything inside stays hidden from the chain, while 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 enclave sees every transfer in plaintext.

    Users trust the operator, Sunnyside Labs, whose TEE processes and whose relay submits every transaction. They also trust the admin multisig, which can upgrade every contract instantly. If the operator stops, a forced withdrawal takes funds out after 3 days, in public.

    Architecture

    Deposits become notes whose Poseidon2 commitments enter 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. The TEE collects the transfers and withdrawals users approve and batches them into epochs. A permissioned relay submits each epoch 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. validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed.. The TEE’s code is unpublished, so what it does with the plaintext cannot be checked. Its isolation rests on the hardware vendor and on resistance to attacks by anyone with physical access.

    Flow

    1. Deposit. You deposit tokens directly, or anyone sends them to a portal address (EIP-7702) you generate locally. A sweep then moves them into the pool for you. Depositor, token and amount are public.
    2. Transfer. You approve a spend, and the TEE includes it in the next epoch.
    3. Gift. A gift note goes to its recipient, or back to the sender after a deadline. Either way runs privately through the relay or through a public gift exit.
    4. Withdraw. The pool pays out to any address and can call an approved gateway for DeFi. Recipient, token and amount are public.

    Keys

    The closed SDK can derive the private account’s keys from a wallet signature, which links that wallet to the account. The hosted wallet uploads a backup of the private keys to the operator by default, encrypted with a key from one wallet signature, which restores them in any browser. Accounts approve spends with registered keys or with onchain spend approvals. Both are leaves of an auth Merkle tree in the AuthRegistry contract. Epoch proofs may use a tree root up to 10 minutes old, so a revoked key or approval stays usable that long.

    App

    Apps integrate the Privacy Boost SDK, whose core ships as closed-source WebAssembly. The ratings assume the operator’s hosted wallet at app.privacyboost.io, the only public app. It runs that core and reads the chain through Alchemy under the operator’s key.

    Exits

    Forced withdrawal. If operator turns malicious or stops processing withdrawals, a user can prove a forced withdrawal of up to 13 notes locally. The contract checks the authorization at request time, and anyone can execute the withdrawal 3 days later if the notes are still unspent. The account owner can cancel it. It publishes the spent notes and exposes the linked account.

    Compliance

    Auditors appointed by the admin multisig can query the TEE’s Audit API for the balance and history of any address, without the user’s consent. The AuditGateway lists 0 auditors today. The TEE is meant to record each access on that contract, but with its code unpublished this is unverifiable.

    Fees

    Standard deposits pay no protocol fee. Portal deposits pay a sweeper fee of 0%, capped at 10%, and have token-specific minimum sweep amounts. Withdrawals, forced withdrawals and public gift exits pay 0.4% to the treasury. A forced withdrawal fixes its fee at request time.

    Privacy

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

    Ethereum is public by default. Each protocol is rated on its main privacy promise, like hiding who paid, who received, how much, or which deposit became which withdrawal. Against each adversary, the colour says whether it holds for a careful user with the app's own settings: green yes, yellow only with significant extra work, red no. Fields marked at risk stay private only under the condition in their note.

    Public observerChain analystNetwork observerPrivileged insiderFuture adversary
    Public observer
    Private

    Transfers inside publish only encrypted notes. Deposits and withdrawals show address, token and amount. Each epoch pairs every exit with the nullifiers and note shape of the transfer that funded it. Forced withdrawals publish the spent notes and the account, public gift exits the destination.

    Advice: Exit through the operator's relay.

    InsideSenderprivateRecipientprivateAmountat riskAssetat riskLinkprivate
    Sources:PrivacyBoostEpoch calldata: withdrawals, nullifiers and transfer shapesForced withdrawal publishes account and notesPublic gift exit names the destination
    Chain analyst
    Exposed

    The anonymity setIn privacy protocols, anonymity set denotes all users, to which a particular withdrawal could be plausibly attributed. Anonymity set depends on a particular withdrawal, the size of the anonymity set is a metric for level of user's privacy. is very small. Most pool activity is one address that keeps depositing and withdrawing 0.001 WETH, which an analyst can filter out.

    Compared with a public observer
    InsideSenderat riskRecipientat riskAmountat riskAssetat riskLinkexposed
    Sources:Address with 0.001 WETH round trips
    Network observer
    Exposed

    Alchemy, under 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 key, sees the signed-in wallet in the session that submits each withdrawal, pairing them by timing. The hosted wallet works over Tor but has no RPC setting to leave Alchemy out. Its key core runs in an iframe without networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. access and reaches only the operator’s server and Alchemy through the page. Other third parties get token ids or nothing.

    Compared with a public observer
    InsideLinkat risk
    Sources:Operator endpointSDK 1.2.5, configured with one server URLThe compiled core builds and sends every request, its Rust source is unpublished
    Privileged insider
    Exposed

    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 enclave holds every transfer in plaintext and a key to every note. The SDK trusts the enclave key it fetches from the operator’s endpoint. Auditors appointed by the admin can pull any account’s history without consent.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed
    Sources:AuditGatewayAdmin and operator multisigsSDK fetches the enclave key from the endpointNotes wrap a key for the enclave beside the receiver
    Future adversary
    Exposed

    Every note wraps its key to the enclave’s long-lived elliptic-curve public key as well as the receiver’s. Whoever breaks elliptic-curve cryptography decrypts the entire history.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed
    Sources:Every output and deposit ciphertext carries an enclave key

    Value Locked

    Flows

    Assets Breakdown

    Asset
    Deposits 7D
    Deposits 30D
    Deposits Total
    Value Locked
    wstETHwstETH
    1
    $2.11 K
    3
    $4.65 K
    7
    $1.36 M
    		$704.25 K
    USDCUSDC
    27
    $245.72 K
    60
    $791.30 K
    133
    $878.37 K
    		$18.79 K
    gtwethbgtwethb
    0
    $0.00
    0
    $0.00
    5
    $12.54 K
    		$9.63 K
    bbqUSDCbbqUSDC
    1
    $260.14
    1
    $260.14
    3
    $1.05 K
    		$1.04 K
    WETHWETH
    340
    $1.16 K
    1.75 K
    $207.31 K
    21.47 K
    $271.50 K
    		$130.97
    AAPLcAAPLc
    0
    $0.00
    0
    $0.00
    1
    $7.19
    		$7.68
    USDTUSDT
    1
    $89.91
    4
    $188.87
    10
    $199.67
    		$6.20
    gtusdcfgtusdcf
    0
    $0.00
    0
    $0.00
    5
    $19.35 K
    		$4.80
    CSUSDCCSUSDC
    0
    $0.00
    1
    $4.59
    2
    $9.19
    		$4.59
    edgeUSDCedgeUSDC
    0
    $0.00
    1
    $1.90
    1
    $1.90
    		$1.91
    BRETTBRETT
    0
    $0.00
    0
    $0.00
    1
    $0.24
    		$0.18
    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
    0
    $0.00
    1
    $0.03
    		—
    SOLSOL
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    TOSHITOSHI
    0
    $0.00
    0
    $0.00
    0
    $0.00
    		—
    Total
    370
    $249.36 K
    1.82 K
    $1.00 M
    21.64 K
    $2.54 M
    		$733.88 K

    Milestones & Incidents

    Pool deployed on Base

    2026 Sep 3rd

    The pool tracked here goes live on Base.

    Learn more

    Privacy Boost live on OP Mainnet

    2026 Apr 20th

    Sunnyside Labs opens Privacy Boost to its customers on OP Mainnet.

    Learn more

    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. all trusted setup participants collude or leak their secrets, allowing forged proofs.
    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 both the account-owner wallet and every usable authorization key.

    Privacy can be lost if

    1. the TEE or its hardware vendor is compromised (see privileged insider).
    2. an auditor appointed by the admin multisig fetches the user’s history through the Audit API (see privileged insider).
    3. a user exits through a forced withdrawal (see public observer).
    4. a user relies on today’s anonymity setIn privacy protocols, anonymity set denotes all users, to which a particular withdrawal could be plausibly attributed. Anonymity set depends on a particular withdrawal, the size of the anonymity set is a metric for level of user's privacy., which is too small to hide in (see chain analyst).
    5. 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. changes the SDK’s closed-source core to send user data elsewhere (see privileged insider).
    6. Alchemy pairs the signed-in wallet with the withdrawal by timing (see networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. observer).
    7. elliptic-curve cryptography is broken, which decrypts every note through the enclave’s long-lived public key (see future adversary).

    Upgrades & Governance

    The 3/4 admin multisig upgrades the pool, registries and AuditGateway instantly. It can replace all five verifiers and their keys, set withdrawal and portal fees up to 10% each, configure portal minimum sweeps, appoint auditors, 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 gateway owner manages target and selector policies, picks the guardian and can pause execution. The guardian can pause and remove policies. Stranded gateway tokens return to the pool only 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