Search
Search for projects and tokens by name or address
Privacy Pools v2Privacy Pools v2
Privacy Pools v2 opened to the public on 2026-10-20 after a capped beta. We are still early, so the ratings rest on the design and ignore the small 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..
About
A shielded ledger with private transfers, swaps and Aave yield inside the pool, where only deposits the ASP approves can be spent privately.
About
A shielded ledger with private transfers, swaps and Aave yield inside the pool, where only deposits the ASP approves can be spent privately.
Privacy Pools v2 by 0xbow lets you shield ETH, USDC or USDT in one pool, then send, swap, earn Aave yield and withdraw without a visible link to the deposit. Only deposits that 0xbow’s association set provider (ASP)An Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending. approves can be spent privately. Depositors, recipients, amounts and timing at the pool’s edges stay public.
Users trust 0xbow, which runs the ASP, the only relayer and the website, and one key that can upgrade every core contract without delay. The ASP can withhold or revoke approval for any deposit. Exiting is 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.: a note’s owner can always ragequit it from the vault, losing their privacy.
Architecture
A note is a private record of value in one asset, owned by an Ethereum address and carrying the label of its deposit. The PoolVault holds all assets and a state tree of note commitments and spent nullifiers. The Keystore holds each account’s registration: a hashA fixed-length fingerprint of variable-size input, produced by a hash function. of its nullifying key, its auth policy and an X25519 viewing public key. The ASPRegistry holds the latest root of the approved labels. USDC, USDT and ETH enter as yield shares, ppUSDC, ppUSDT and ppETH, which wrap Aave v3 deposits.
Labels
Each deposit gets a label, a private ID that only the depositor and the ASP can tie to the deposit. Every note created from the deposit’s funds carries the same label, including notes paid to others, so each recipient learns it. Notes from different deposits never merge. Each private spend proves that its notes’ labels are on the ASP’s latest list. Anyone who knows a label can hash it, find the list update that first approved it and look at the deposits made just before.
Flow
- Register. Two transactions from your wallet add your account to the Keystore and publish your viewing public key.
- Shield. You deposit through the Entrypoint. USDC, USDT and ETH pass through a PPRouter that supplies Aave and deposits the shares. Your address, asset and amount are public, and the data that ties the deposit to its label goes onchain encrypted to the ASP.
- Approval. The ASP screens the depositor, adds the label’s hash to its list and posts the root onchain, with the list on IPFS.
- Send. A transact proof spends your notes and creates one for the recipient, encrypted to their viewing key and published onchain, plus change for you. An unregistered recipient gets a claim link instead. 0xbow’s relayer submits the proof onchain and takes its fee as a public withdrawal.
- Withdraw. The relayer pays any address, minus its fee. Change stays as a note.
Keys
All keys derive from one signature of the user’s wallet. Contract wallets and signers that cannot sign the same way twice can use a passkey instead. The derived account key can be exported from the app. Sharing the viewing private key reveals every incoming note, a receipt reveals one payment. The revocable key can be rotated, and the old one stays valid for 20m.
App
The ratings assume the website at privacypools.com, built from public source and hosted by 0xbow. It reads the chain from Alchemy under 0xbow’s key unless the user sets an endpoint per chain. It downloads the pool’s events whole from the ASP but offers only 0xbow’s relayer. Its Tor option requires a user-run Tor gateway and covers only RPC calls. It does not support connecting a local nodeA software client that participates in the network. with Tor enabled. Privacy Pools v2 is deployed on BNB Chain, Citrea, Optimism, Base, Arbitrum and Robinhood Chain, which L2BEAT does not track.
Swaps and yield
The yield shares keep a fixed share count while their value grows, so the share count encodes the exchange rate on the deposit day. Withdraw-and-swap sends the withdrawn asset through LI.FI to another token or chain, with the route bound into the proof. A reshield swaps into another pool asset and deposits again in the same transaction, as a fresh deposit that needs approval again.
Exits
Ragequit. The note’s current owner can take out its full value at any time, approved or not, directly from the vault, also while it is paused. It publishes the owner, the amount, the label and the commitment, which names the transaction that created the note.
Claim link. A payment to an unregistered address can only be claimed with the link the payer holds. Until then the funds can neither move nor exit.
Relaying. The contracts accept a proof from any address, and no relayer can change its recipient. A relayer other than 0xbow’s needs the user’s own build of the website or another clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients..
Compliance
The ASP screens each depositor before approving the deposit, under 0xbow’s own due diligence, and may reject it. A later list can drop an approved label, which freezes every note that carries it. A rejected deposit can leave only by ragequit.
Fees
Deposits pay no vetting fee today. The relayer quotes its fee per request and takes it from the sent or withdrawn asset. You accept the fee before sending, and the relayer cannot raise it. A private transfer pays that fee as a public payout from the vault. The yield shares keep 20% of the Aave yield for 0xbow.
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.
One vault holds every asset, but a withdrawal names its asset. The set is therefore the ASP-approved deposits of that asset whose notes still hold at least the withdrawn amount, including the notes that transfers and reshields created from them. We count every depositor of the asset, approved or not.
What the protocol promises: Hides which deposit funds which withdrawal and who pays whom inside the pool, for deposits the ASP approves. 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.
A 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. proof hides which approved notes a withdrawal or transfer spends, and a transfer publishes only encrypted notes. A relayed transfer pays its fee as a public withdrawal to the relayer, so transfers are visible as events. A ragequit publishes the owner, the amount, the label and the commitment, which names the transaction that created the note. Claiming a payment to an unregistered address registers that wallet.
Advice: Exit through a relayer, so none of your wallets pay gas for the receiving address. Ragequit only notes you deposited and never spent from. On any other note, a ragequit names the private transaction that created it.
A note’s label passes to every later payee, and the ASPAn Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending. update that first approved it often leaves one candidate deposit. The ASP adds ten labels per update, decoys included, so an update that follows a single deposit names it. Without a payee, a relayed exit of a common amount hides among every approved deposit of its asset. Any amount is allowed, so an unusual one pairs a deposit with its withdrawal, and a yield deposit’s share count encodes the day it was made. Paying gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. from the user’s wallet instead of a relayer exposes its fingerprint, account implementation and fee habits, even from a fresh address.
Advice: Reshield into another asset before paying someone who should not learn the deposit, since the reshield deposits the funds again under a new label. Use a pool with a large anonymity set. Withdraw common amounts rather than everything at once. Wait before exiting and pick a different time of day than the deposit. Exit to a fresh address every time and spend from it with a different wallet than the one that deposited.
The default RPCs, Alchemy under 0xbow’s key with a public nodeA software client that participates in the network. as fallback, see the account at sign-in and can time it against the withdrawal. NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. services like the LI.FI swap service and Sentry error reporting receive your IP address unless the app is used over Tor or a VPN, while the Tor mode is not compatible with a local Ethereum node. The app confirms a relayed withdrawal from bulk reads, so no request names it, and the pairing rests on timing, which Tor does not hide. The app downloads the pool’s events whole from the ASPAn Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending. and matches notes locally. The relayer learns the recipient at quote time. Tor Browser works, but the relayer refuses many Tor exits and the app offers no other relayer.
Advice: Set your own node, served over https, as the endpoint for the chain before signing in. Withdraw in a new Tor Browser session signed in with your account key, so no wallet is connected, and retry on a new circuit when the relayer refuses.
The ASPAn Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending. postman can publish a new approved list at any time with no delay, and every private spend must prove against the latest one. A list without a deposit’s label freezes every note descending from it, and a list with few labels narrows the set to them. 0xbow’s relayer sees the IP and recipient of every private exit and its ASP feeds see the IP of every session, so one 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. can pair a deposit session with its withdrawal. The request logs of its Alchemy key show it the account each sign-in looks up, which it can time against the withdrawals its relayer submits. One key holds every admin role and can upgrade the four core contracts without delay.
Advice: Before withdrawing, check the size of the approved list behind the latest root, which the ASPRegistry links on IPFS. Exit as the network observer advice says, so 0xbow sees no IP it saw at the deposit and no account lookup.
Every registered account’s viewing public key sits in the Keystore, so whoever breaks elliptic-curve cryptography decrypts every note ever sent to it from the chain. A decrypted note holds value, token and deposit lineage, which pairs each transfer’s commitments with their deposit and recipient. Accounts created from a wallet signature reduce to that wallet’s key. Breaking the ASPAn Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending.’s key the same way decrypts the data that ties each deposit to its label.
30 day historic anonymity set
How many unique depositors you could have blended in with if you withdrew on a particular day after depositing during the previous 30 days. This metric is a proxy for the historic anonymity set and shows how it developed over time.
The metric looks backwards: it counts deposits that already happened, including from addresses that have since withdrawn. Your real anonymity also depends on deposits made after yours, which cannot be known in advance.
Estimated anonymity set by holding duration
An estimate of how many unique depositors you blend in with, depending on how long you leave your deposit in the pool. It is based on historic data of past deposits: each point counts depositors from the preceding period, so holding for up to 30 days effectively means blending in with everyone who deposited during the last 30 days.
Asset | Deposits 7D | Deposits 30D | Deposits Total | Value Locked |
|---|---|---|---|---|
 ppETH | 49 $114.59 K | 77 $115.84 K | 97 $199.35 K | $186.36 K |
 ppUSDC | 37 $49.17 K | 62 $49.89 K | 84 $52.12 K | $21.80 K |
 ppUSDT | 9 $8.68 K | 27 $9.04 K | 36 $11.32 K | $9.65 K |
 ETH | 0 $0.00 | 1 $10.74 | 18 $642.71 | $305.80 |
| Total | 95 $172.44 K | 167 $174.79 K | 235 $263.44 K | $218.13 K |
Privacy Pools v2 public launch
2026 Oct 20th
The v2 app opens at privacypools.com with transfers, swaps and yield inside the pool.
Beta verifiers used single-contributor keys
2026 Oct 20th
From 2026-09-01 until this rotation, every verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. held a developer key, not the ceremony key.
Funds can be stolen if
- 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.
- all trusted setup participants collude or leak their secrets, allowing forged proofs.
- the upgrader key deploys a malicious upgrade of the PoolVault, which holds every deposit, or a verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. that accepts any proof, with no delay.
Funds can be lost if
- a user loses the wallet whose signature derives their keys and the exported account key.
- the payer loses a claim link before the recipient claims it.
- Aave suffers a loss on the reserve behind a yield share.
Use can be stopped if
- the upgrader key pauses deposits and spends, or raises the vetting fee on deposits up to 99.99% of their value.
Privacy can be lost if
- the ASPAn Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending. leaves deposits out of its latest list, which freezes every note from them, up to halting all private spends (see privileged insider).
- the ASP keeps only a few labels in its latest list, so spends proven against it point to one of them (see privileged insider).
- 0xbow’s relayer refuses a withdrawal, so the user must self-relay from a public wallet (see chain analyst).
- a note’s label, which passes to every later payee, links to its deposit when timed against the ASP’s updates (see chain analyst).
- 0xbow pairs the IP of a deposit session with the IP of a withdrawal request across its ASP and relayer (see privileged insider).
- a user keeps the default RPCs, which see their account at sign-in and can time it against the withdrawal (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).
- elliptic-curve cryptography is broken, which decrypts every onchain note from the published viewing keys (see future adversary).
One EOA holds the default admin, ops admin, upgrader, pauser, unpauser and entrypoint manager roles in the AccessRouter. It can upgrade the PoolVault, Entrypoint, Keystore and ASPRegistry, replace the verifiers, pause deposits and spends, enable assets, set a vetting fee of up to 99.99% on deposits and cap relayer fees, all without delay. It also administers the three yield shares, with a fee of at most 20% of the yield. The shares hold Aave v3 deposits, whose contracts Aave governance can upgrade after a public vote and delay. Aave’s guardian multisig can pause a reserve instantly, which blocksAn 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. redeeming its shares. A second EOA holds the postman role that publishes approved-label roots. A third owns RelaySwaps and curates its routers. No timelock or multisig is deployed. Ragequit cannot be paused, so funds already in the vault can leave to their owners as long as the implementation is not changed.
Privacy Pools v2
Detailed description
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 the 27 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. Privacy Pools v2 circuits: deposit, ragequit and 25 transact circuits, one per combination of 1 to 5 spent notes and 1 to 5 created notes.
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. is the 80th contribution to the Perpetual Powers of Tau ceremony, prepared for 2^18 constraints.
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., named ppv2-ceremony, ran publicly from 2026-07-08 to 2026-07-14 with 500 contributions per 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. from 597 distinct participants, followed by one beacon contribution from the RANDAO reveal of beacon-chain slot 14767039. Participants are pseudonymous in the published transcript. The final proving keys, their verification keys and the transcript are published with release v1.0.0 of the monorepo, and the ceremony code is open source.
- Phase 1 ceremony: https://github.com/privacy-ethereum/perpetualpowersoftau.
- Ceremony code and UI: https://github.com/0xbow-io/v2-ceremony.
- Ceremony description and key hashes: https://github.com/0xbow-io/privacy-pools-v2-monorepo/[blob](/glossary#blobs?description=The data that a rollup publishes to its L1%2Fdata availability (DA) layer. They consist of the L2 transactions that are rolled up%2C along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844%2C and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.)/61fac03acd1fc306164ddc234f7fac4147d04493/packages/circuits/CEREMONY.mdThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.)/61fac03acd1fc306164ddc234f7fac4147d04493/packages/circuits/CEREMONY.md.
- Final keys and transcript: https://github.com/0xbow-io/privacy-pools-v2-monorepo/releases/tag/v1.0.0.
Verifier | Verification | Used in | Known deployments | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Privacy Pools v2 verifiers v1.0.1 | by | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Verifier ID: Privacy Pools v2 verifiers 20.10.2026Known deployments Verification steps Privacy Pools v2 uses 27 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: Steps, all on monorepo tag
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2026 October 21, 05:05 UTC45changesInitial discovery of Privacy Pools v2 on Ethereum: Entrypoint, PoolVault, Keystore, ASPRegistry, AccessRouter, PrivacyPoolRelay, RelaySwaps, the yield routers, shares and zaps, and the 27 Groth16 verifiers.
Initial discovery of Privacy Pools v2 on Ethereum: Entrypoint, PoolVault, Keystore, ASPRegistry, AccessRouter, PrivacyPoolRelay, RelaySwaps, the yield routers, shares and zaps, and the 27 Groth16 verifiers.
Initial discovery
| + | Status: CREATED |
| contract PrivacyPoolRelay (eth:0x01a8Fa4dbb60187aD8d3c3d08E7Fb8C14198A461) [privacy-pools-v2/PrivacyPoolRelay] | |
| +++ description: Withdrawal processor that submits the transact proof and pays the recipient and the relayer's fee, capped per asset. | |
| + | Status: CREATED |
| contract Transact4x5Verifier (eth:0x01b4954E3b3C1F68785f60D7465c38C31266bfab) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| EOA (eth:0x0967755AfA2016866D12EefB820705026842dCe8) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Transact1x2Verifier (eth:0x0e13d94235d8a0d8f9fC3B63BB41D666eF0677Ed) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract PoolVault (eth:0x0Eb42804BF897662aF851370eaeAdcDBEC1b97ed) [privacy-pools-v2/PoolVault] | |
| +++ description: Holds every pool asset and the state tree of note commitments and spent nullifiers. | |
| + | Status: CREATED |
| EOA (eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92) | |
| +++ description: None | |
| + | Status: CREATED |
| contract PPRouterUSDT (eth:0x13a0b86bac3e0C29bd64fED7BCD2EE84f371f41C) [privacy-pools-v2/PPRouter] | |
| +++ description: Yield router for one share token. It wraps deposits of the underlying into shares, and unwraps withdrawn shares to pay the recipient and the relayer fee. | |
| + | Status: CREATED |
| contract Transact5x3Verifier (eth:0x20D4B794A2A1ae7A34AF184172dd931d3ff2Fa32) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact1x1Verifier (eth:0x21347145497569b34efAB7d73952208866520042) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract ASPRegistry (eth:0x259C0BEa1d783c202509BD3b2688d23b8AEf58B0) [privacy-pools-v2/ASPRegistry] | |
| +++ description: Publishes the association set provider's approved-label roots with their IPFS CIDs, and receives the data that ties each deposit to its label, encrypted to the ASP. | |
| + | Status: CREATED |
| contract Transact2x1Verifier (eth:0x338625F2199675D2aC4Fbf7A89567864ac990710) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract PPYieldTokenZapETH (eth:0x33c1eEf370bBb447414156CFc4fDABD434776EAf) [privacy-pools-v2/PPYieldTokenZap] | |
| +++ description: Converts between a share token and its underlying in one call, through Aave v3. | |
| + | Status: CREATED |
| contract Transact1x4Verifier (eth:0x3ee4A00e0ba1AC0Ef8aD3e4b541CA42FBB4592c3) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract AccessRouter (eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160) [privacy-pools-v2/AccessRouter] | |
| +++ description: Role registry the Privacy Pools v2 core contracts check. No role has a delay. | |
| + | Status: CREATED |
| contract Transact4x2Verifier (eth:0x454F1Da26DD4c7c89a849019BeC4c7C7C404d3A4) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact4x4Verifier (eth:0x4Cb752CEF56a5095321Ed72699cD7A699D48F4b5) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact3x1Verifier (eth:0x579f6734d35937b8432BA8FfC17C3120eb657c82) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract RagequitVerifier (eth:0x5a06582115953E2cAbeD8e6A0EeAE35BA430118f) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact5x1Verifier (eth:0x61573Cf3c3A20C9739b68B8e742Ca51971387Cb5) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact2x5Verifier (eth:0x62Cf8963300F284016daE0cD19f5D9BC60846a46) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract ppETH (eth:0x66051920D25af4E3596A8a46309F4D045F9D83B7) [privacy-pools-v2/PPYieldToken] | |
| +++ description: ERC-4626 share token over an Aave v3 aToken, the asset the pool holds for a yield deposit. The admin's fee applies to the yield only. | |
| + | Status: CREATED |
| contract Keystore (eth:0x6E463391c79b7e1A88eF26E0B023f9A6C9938a71) [privacy-pools-v2/Keystore] | |
| +++ description: Account registry of Privacy Pools v2: one leaf per account with its nullifying key hash and auth policy, plus an optional X25519 viewing public key. | |
| + | Status: CREATED |
| contract Transact5x4Verifier (eth:0x766c2F31483935CD55355fcE00fc5eDB82A15acC) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact3x2Verifier (eth:0x76D574559765fd4b90903fFa682964Ae7e7e878a) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract PPRouterETH (eth:0x77613D670BB9fD48A9898D0eac8ebf21B566F960) [privacy-pools-v2/PPRouter] | |
| +++ description: Yield router for one share token. It wraps deposits of the underlying into shares, and unwraps withdrawn shares to pay the recipient and the relayer fee. | |
| + | Status: CREATED |
| contract Transact5x5Verifier (eth:0x7BeE2554970A749D7671424DFa3fAbE15d7e4BD8) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact5x2Verifier (eth:0x8ABfb288dAc87392EaFdD59F6809825fcA0e8b85) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact4x1Verifier (eth:0x909ECAF2A4959726a2BC3d82Fc837B8D3F1c61d3) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact4x3Verifier (eth:0x95dEC97ac78E8C0FfDc6315FDc0A0791238b93A3) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract PPYieldTokenZapUSDC (eth:0x9Ea986BcDF6784D85B518b15bEEE1E65b585817B) [privacy-pools-v2/PPYieldTokenZap] | |
| +++ description: Converts between a share token and its underlying in one call, through Aave v3. | |
| + | Status: CREATED |
| contract ppUSDT (eth:0xA4cF419558Ef36CC6FfB666195684dC963910426) [privacy-pools-v2/PPYieldToken] | |
| +++ description: ERC-4626 share token over an Aave v3 aToken, the asset the pool holds for a yield deposit. The admin's fee applies to the yield only. | |
| + | Status: CREATED |
| contract Transact2x2Verifier (eth:0xAc716f21626994c4264eA457Fe208071050611B5) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact3x3Verifier (eth:0xAeCDf3E27A602f23cEc2E5CE250093b3E806D041) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact2x3Verifier (eth:0xB8aa00333b8D6958da72A15D59179BbDD1e49064) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract ppUSDC (eth:0xC246aFb23482fF9596E9cee5f1f678eFe0EB1ad6) [privacy-pools-v2/PPYieldToken] | |
| +++ description: ERC-4626 share token over an Aave v3 aToken, the asset the pool holds for a yield deposit. The admin's fee applies to the yield only. | |
| + | Status: CREATED |
| contract Transact1x3Verifier (eth:0xC5E1D9D9CF12E796Ec8E072646c6BF29A1e55382) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Entrypoint (eth:0xca1e072236D231130059eeA6Bfceb7F4e9a1F0C3) [privacy-pools-v2/Entrypoint] | |
| +++ description: Deposit gate of Privacy Pools v2. It checks each deposit against its asset's configuration and keeps the vetting fee. | |
| + | Status: CREATED |
| contract RelaySwaps (eth:0xd0395c08DD8eA7671a7A65bDca8E473e8E8260a8) [N/A] | |
| +++ description: Withdrawal processor that swaps the withdrawn asset through an approved aggregator router, with the swap calldata bound into the proof. | |
| + | Status: CREATED |
| contract PPYieldTokenZapUSDT (eth:0xDC3D922df81FC7B7f58229431ED91acB0482f3A5) [privacy-pools-v2/PPYieldTokenZap] | |
| +++ description: Converts between a share token and its underlying in one call, through Aave v3. | |
| + | Status: CREATED |
| contract Transact3x4Verifier (eth:0xe0aec1eE10eBfCDcB09b6e5a7ea6Ae34D066219d) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract PPRouterUSDC (eth:0xe76E793d776c1e207aD7a7fa7C57d27420d85110) [privacy-pools-v2/PPRouter] | |
| +++ description: Yield router for one share token. It wraps deposits of the underlying into shares, and unwraps withdrawn shares to pay the recipient and the relayer fee. | |
| + | Status: CREATED |
| contract DepositVerifier (eth:0xEe96Ca04d2Ab2eC9A8803eb78F39b2875dFF6fdf) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact2x4Verifier (eth:0xF1C6c55B70EC3Df923f5E9bcd64aee5c3073C42c) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact1x5Verifier (eth:0xfa0138C5dE45E520AbA349BE38a827DAb470f70A) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
| + | Status: CREATED |
| contract Transact3x5Verifier (eth:0xFdF4EbC7645E1F4c04aE33285b6e3f78e4A3a275) [privacy-pools-v2/Groth16Verifier] | |
| +++ description: Groth16 verifier for one Privacy Pools v2 circuit, with that circuit's trusted-setup verification key hard-coded. | |
Ethereum
Actors:
Deposit gate of Privacy Pools v2. It checks each deposit against its asset’s configuration and keeps the vetting fee.
- Can interact with AccessRouter
- deposit into the PoolVault on behalf of users
- Can interact with AccessRouter
- enable or disable assets, set minimum deposits, vetting fees of up to 99.99% and relayer fee caps, and sweep fees held by the Entrypoint
- grant and revoke the ops admin, upgrader, unpauser and depositor roles
- grant and revoke the pauser, entrypoint manager and postman roles
- pause deposits and transacts in the PoolVault
- unpause the PoolVault
- upgrade the PoolVault, Entrypoint, Keystore and ASPRegistry, and replace the vault’s verifiers, registries and tree limits
- Can interact with ppETH
- set the yield fee up to 20%, claim fees, pause minting, set the Aave rewards controller and rescue tokens other than the backing aToken
- Can interact with ppUSDT
- set the yield fee up to 20%, claim fees, pause minting, set the Aave rewards controller and rescue tokens other than the backing aToken
- Can interact with ppUSDC
- set the yield fee up to 20%, claim fees, pause minting, set the Aave rewards controller and rescue tokens other than the backing aToken
- Can interact with AccessRouter
- publish the approved-label root every private spend must match
- Can interact with RelaySwaps
- approve the aggregator routers and yield zaps that RelaySwaps sends withdrawn funds through
Ethereum
Withdrawal processor that submits the transact proof and pays the recipient and the relayer’s fee, capped per asset.
Holds every pool asset and the state tree of note commitments and spent nullifiers.
Yield router for one share token. It wraps deposits of the underlying into shares, and unwraps withdrawn shares to pay the recipient and the relayer fee.
Publishes the association set providerAn Association Set Provider (ASP) is the compliance layer used in Privacy Pools. It maintains the set of approved deposits and updates the corresponding roots used by withdrawal proofs, allowing users to prove in zero knowledge that their withdrawal belongs to an approved set without revealing which deposit they are spending.’s approved-label roots with their IPFS CIDs, and receives the data that ties each deposit to its label, encrypted to the ASP.
Converts between a share token and its underlying in one call, through Aave v3.
Role registry the Privacy Pools v2 core contracts check. No role has a delay.
- Roles:
- defaultAdmins: EOA 1
- depositors: Entrypoint
- entrypointManagers: EOA 1
- opsAdmins: EOA 1
- pausers: EOA 1
- postmen: EOA 2
- unpausers: EOA 1
- upgraders: EOA 1
ERC-4626 share token over an Aave v3 aToken, the asset the pool holds for a yield deposit. The admin’s fee applies to the yield only.
- Roles:
- owner: EOA 1
Account registry of Privacy Pools v2: one leaf per account with its nullifying key hashA fixed-length fingerprint of variable-size input, produced by a hash function. and auth policy, plus an optional X25519 viewing public key.
Yield router for one share token. It wraps deposits of the underlying into shares, and unwraps withdrawn shares to pay the recipient and the relayer fee.
Converts between a share token and its underlying in one call, through Aave v3.
ERC-4626 share token over an Aave v3 aToken, the asset the pool holds for a yield deposit. The admin’s fee applies to the yield only.
- Roles:
- owner: EOA 1
ERC-4626 share token over an Aave v3 aToken, the asset the pool holds for a yield deposit. The admin’s fee applies to the yield only.
- Roles:
- owner: EOA 1
Converts between a share token and its underlying in one call, through Aave v3.
Yield router for one share token. It wraps deposits of the underlying into shares, and unwraps withdrawn shares to pay the recipient and the relayer fee.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
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 one Privacy Pools v2 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., with that circuit’s trusted-setup verification key hard-coded.
Withdrawal processor that swaps the withdrawn asset through an approved aggregator router, with the swap calldata bound into the proof.
- Roles:
- owner: EOA 3 The source code of this contract is not verified on Etherscan.
The current deployment carries some associated risks:
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).