Search
Search projects, tokens and protocols by name or address
Pin a project to keep it here. Saved only in this browser.
Privacy Pools v2Privacy Pools
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 deposit ETH, USDC or USDT, 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 a multisig that can upgrade every core contract without delay. The ASP can withhold or revoke approval for any deposit. Users also trust Aave, which holds the assets behind the yield shares. 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 ragequit it from the vault, losing their privacy, unless that multisig 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. it.
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 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
0xbow hosts the app, built from public source. 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. Privacy Pools v2 is deployed on BNB Chain, Citrea, Optimism, Base, Arbitrum and Robinhood Chain, which ETHBEAT 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, 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 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. 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. Notes that transfers and reshields created from them count too. 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.
- privacypools.comReference
The ratings assume this app, since 2026-10-23 · Source 6c292b4
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.
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 amount, or a share count only one deposit day produces, pairs a deposit with its withdrawal. 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 ppETH or ppUSDC, the pools with the most depositors. 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, led by Alchemy under 0xbow’s key, see the account at sign-in and can time it against the withdrawal. An IP-hiding route does not hide that timing, a local nodeA software client that participates in the network. does. Tor Browser and the app’s Tor option cannot reach a local node, so the route must carry all traffic.
Advice: Send all traffic through an IP-hiding route and set a local node as the endpoint before signing in. Withdraw signed in with the account key instead of a wallet.
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 ASP feeds see every session’s IP and its relayer every exit’s IP and recipient, so 0xbow can pair deposit and exit sessions. 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. 0xbow can change the hosted app at any time, and a multisig can upgrade the four core contracts without delay.
Advice: Exit as the network observer advice says, after checking the size of the approved list that the ASPRegistry's latest root links on IPFS. Run an inspected local build of the app instead of the hosted frontend.
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 | 95 $90.81 K | 216 $660.62 K | 239 $661.65 K | $260.83 K |
 ppUSDT | 30 $173.54 K | 61 $207.92 K | 76 $208.28 K | $176.79 K |
 ppUSDC | 40 $45.59 K | 120 $140.01 K | 148 $141.03 K | $74.91 K |
 ETH | 0 $0.00 | 0 $0.00 | 18 $642.71 | $167.48 |
| Total | 165 $309.94 K | 397 $1.00 M | 481 $1.01 M | $512.71 K |
Privacy Pools v2 public launch
20 Oct 2026
The v2 app opens at privacypools.com with transfers, swaps and yield inside the pool.
Beta verifiers used single-contributor keys
20 Oct 2026
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 admin multisig 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.
Funds can be frozen if
- the admin multisig lets the state tree fill by lowering its capacity, which stops every ragequit, deposit and spend, with no delay.
- Aave pauses a reserve behind the yield shares, which stops redeeming them for the underlying asset.
Use can be stopped if
- the admin multisig pauses deposits and spends, or raises the vetting fee on deposits up to 99.99% of their value.
- Aave freezes the reserves behind the yield shares, which stops every deposit through the app.
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 and privileged insider).
- elliptic-curve cryptography is broken, which decrypts every onchain note from the published viewing keys (see future adversary).
A 2/4 multisig 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 and replace the verifiers. It can pause deposits and spends, which leaves ragequit open, or let the state tree fill by lowering its capacity, which stops ragequit too. It enables assets, sets a vetting fee of up to 99.99% on deposits and caps relayer fees. It also administers the three yield shares, with a fee of at most 20% of the yield. An EOA holds the postman role that publishes approved-label roots. Another owns RelaySwaps and curates its routers and zaps. None of these roles has a delay, so every change applies at once.
The shares hold Aave v3 deposits, whose contracts Aave governance can upgrade after a public vote and delay. Aave’s guardian multisig can instantly freeze a reserve, 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. the app’s deposits into its shares, or pause it, which also blocks redeeming them.
Privacy Pools v2
- 1Phase 1 · Universal61contributions
- 2Phase 2 · Circuit-specific597participants
500 contributions per circuit, followed by a beacon.
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. uses ppot_0080_18.ptau from the
Perpetual Powers of Tau ceremony, prepared for 2^18 constraints.
It contains 61 participant contributions and one public randomness beacon. Its
contribution IDs are 0001–0058 and 0078–0080: contribution 0078 resumes from 0058
after a fork, so 0080 is an identifier rather than a count.
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.
- Phase 1 fork and included contribution IDs: https://github.com/privacy-ethereum/perpetualpowersoftau/blob/b077232729db7c9eb65b63c4aaaa0ac4a1b0bba2/README.md#note-on-chain-fork.
- 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/61fac03acd1fc306164ddc234f7fac4147d04493/packages/circuits/CEREMONY.md.
- Final keys and transcript: https://github.com/0xbow-io/privacy-pools-v2-monorepo/releases/tag/v1.0.0.
Verification | Used in | Known deployments | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Privacy Pools v2 verifiers v1.0.1 | by | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Verifier ID: Privacy Pools v2 verifiers 20.10.2026Known deployments27 Used in 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
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
High severity32changesEvery AccessRouter admin role and the three yield shares moved from an EOA to a 2/4 Safe, without a delay. RelaySwaps is verified now and gets a template. maxStateTreeSize is HIGH, since lowering it stops ragequit.
Every AccessRouter admin role and the three yield shares moved from an EOA to a 2/4 Safe, without a delay. RelaySwaps is verified now and gets a template. maxStateTreeSize is HIGH, since lowering it stops ragequit.
| EOA (eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92) { | |
| +++ description: None | |
| receivedPermissions: | |
| - | [{"permission":"interact","from":"eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160","description":"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.","role":".entrypointManagers"},{"permission":"interact","from":"eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160","description":"grant and revoke the ops admin, upgrader, unpauser and depositor roles.","role":".defaultAdmins"},{"permission":"interact","from":"eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160","description":"grant and revoke the pauser, entrypoint manager and postman roles.","role":".opsAdmins"},{"permission":"interact","from":"eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160","description":"pause deposits and transacts in the PoolVault.","role":".pausers"},{"permission":"interact","from":"eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160","description":"unpause the PoolVault.","role":".unpausers"},{"permission":"interact","from":"eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160","description":"upgrade the PoolVault, Entrypoint, Keystore and ASPRegistry, and replace the vault's verifiers, registries and tree limits.","role":".upgraders"},{"permission":"interact","from":"eth:0x66051920D25af4E3596A8a46309F4D045F9D83B7","description":"set the yield fee up to 20%, claim fees, pause minting, set a rewards controller and rescue tokens other than the backing aToken.","role":".owner"},{"permission":"interact","from":"eth:0xA4cF419558Ef36CC6FfB666195684dC963910426","description":"set the yield fee up to 20%, claim fees, pause minting, set a rewards controller and rescue tokens other than the backing aToken.","role":".owner"},{"permission":"interact","from":"eth:0xC246aFb23482fF9596E9cee5f1f678eFe0EB1ad6","description":"set the yield fee up to 20%, claim fees, pause minting, set a rewards controller and rescue tokens other than the backing aToken.","role":".owner"}] |
| } | |
| contract AccessRouter (eth:0x40a6bC296D87f71Ab31Ca3Bfb50513441fBD5160) [privacy-pools-v2/AccessRouter] { | |
| +++ description: Role registry the Privacy Pools v2 core contracts check. No role has a delay. | |
| values.accessControl.DEFAULT_ADMIN_ROLE.members.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.accessControl.PAUSER_ROLE.members.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.accessControl.ENTRYPOINT_MANAGER_ROLE.members.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.accessControl.OPS_ADMIN_ROLE.members.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.accessControl.UPGRADER_ROLE.members.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.accessControl.UNPAUSER_ROLE.members.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| +++ severity: HIGH | |
| values.defaultAdmins.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| +++ severity: MEDIUM | |
| values.entrypointManagers.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| +++ severity: HIGH | |
| values.opsAdmins.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| +++ severity: MEDIUM | |
| values.pausers.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| +++ severity: MEDIUM | |
| values.unpausers.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| +++ severity: HIGH | |
| values.upgraders.0: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| } | |
| 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. | |
| values.admin: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.owner: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| } | |
| 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. | |
| values.admin: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.owner: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| } | |
| 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. | |
| values.admin: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| values.owner: | |
| - | "eth:0x12Dbd6335d7f529F8922420Ba9c15c9E7A324c92" |
| + | "eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6" |
| } | |
| + | Status: CREATED |
| EOA (eth:0x98AdDcc75931795eB66c52cA954541c18535E3c0) | |
| +++ description: None | |
| + | Status: CREATED |
| contract SafeL2 (eth:0xd563affc5ccA233514426e725c2d0b12C516a3e6) [GnosisSafe] | |
| +++ description: None | |
New and verified contracts
| contract RelaySwaps (eth:0xd0395c08DD8eA7671a7A65bDca8E473e8E8260a8) [privacy-pools-v2/RelaySwaps] { | |
| +++ description: Withdrawal processor that swaps the withdrawn asset through an approved aggregator router, unwrapping yield shares through an approved zap first where needed, with the swap calldata bound into the proof. | |
| unverified: | |
| - | true |
| description: | |
| - | "Withdrawal processor that swaps the withdrawn asset through an approved aggregator router, with the swap calldata bound into the proof." |
| + | "Withdrawal processor that swaps the withdrawn asset through an approved aggregator router, unwrapping yield shares through an approved zap first where needed, with the swap calldata bound into the proof." |
| values.approvedZapList: | |
| + | ["eth:0x9Ea986BcDF6784D85B518b15bEEE1E65b585817B","eth:0xDC3D922df81FC7B7f58229431ED91acB0482f3A5","eth:0x33c1eEf370bBb447414156CFc4fDABD434776EAf"] |
| values.ENTRYPOINT: | |
| + | "eth:0xca1e072236D231130059eeA6Bfceb7F4e9a1F0C3" |
| values.NATIVE_ASSET: | |
| + | "eth:0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" |
| values.POOL: | |
| + | "eth:0x0Eb42804BF897662aF851370eaeAdcDBEC1b97ed" |
| values.ROUTING_TYPEHASH: | |
| + | "0xe11f9c010588c4c3c1b43d85f2825f9bb06ba076295d1e7b89d5e0a8b3ad1f7e" |
| implementationNames.eth:0xd0395c08DD8eA7671a7A65bDca8E473e8E8260a8: | |
| - | "" |
| + | "RelaySwaps" |
| template: | |
| + | "privacy-pools-v2/RelaySwaps" |
| sourceHashes: | |
| + | ["0xd7dea0ccf32266bccfea5f538324c1c915194aaf691347720a0f2f5a26e91459"] |
| category: | |
| + | {"name":"Local Infrastructure","priority":5} |
| } | |
45changesInitial 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:
A Multisig with 2/4 threshold.
- 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 a 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 a 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 a rewards controller and rescue tokens other than the backing aToken
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 RelaySwaps
- approve the aggregator routers and yield zaps that RelaySwaps sends withdrawn funds through, and rescue any token it holds, such as bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. refunds
- Can interact with AccessRouter
- publish the approved-label root every private spend must match
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: SafeL2
- depositors: Entrypoint
- entrypointManagers: SafeL2
- opsAdmins: SafeL2
- pausers: SafeL2
- postmen: EOA 2
- unpausers: SafeL2
- upgraders: SafeL2
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: SafeL2
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: SafeL2
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: SafeL2
Withdrawal processor that swaps the withdrawn asset through an approved aggregator router, unwrapping yield shares through an approved zap first where needed, with the swap calldata bound into the proof.
- 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.