Privacy Pools is not just a generic privacy protocol; its materials repeatedly separate three layers: pool contracts and custody/state, zero-knowledge proofs, and an Association Set Provider policy layer that governs which deposits remain eligible for private withdrawal.
The contract and protocol docs make the flow concrete. Users deposit publicly into a pool, creating a commitment from value, label, nullifier, and secret; later they privately withdraw by proving commitment ownership, valid state-root membership, and ASP-root inclusion.
The label is especially important. The docs describe it as keccak256(scope, nonce) generated per pool deposit, and the ASP layer manages approved labels rather than just generic addresses or accounts. This makes withdrawal eligibility a distinct policy object inside the protocol.
The key fallback is ragequit: when a label is not approved or later removed, the original depositor can publicly recover the full remaining deposit value. That keeps ASP policy from becoming straightforward confiscation even though it can remove private-withdrawal eligibility.
The Entrypoint contract is a major operational chokepoint. The docs describe it as the central access point for deposits, registry management, ASP-root updates, fee collection, relaying, and protocol-wide settings.
The ASP layer is also explicitly operationalized. Only authorized postmen can update roots, those roots carry timestamps and IPFS references, and withdrawals validate against the latest ASP root tracked by Entrypoint.
The implementation docs reinforce that this is a full stack rather than just a paper idea: contracts, Circom circuits, SDK, and relayer tooling are all exposed in the monorepo/developer guide.
The GitHub design repo adds the higher-level conceptual frame that is easy to lose in the product docs: withdrawals associate with arbitrary subsets of deposits, including via inclusion in curated good subsets or exclusion from curated bad subsets, with the project explicitly positioning this as a crypto-native alternative to blanket privacy bans.
Specific source signals worth retaining
docs.privacypools.com/: best concise overview of the three-layer architecture and the compliance-plus-ragequit framing.
overview/core-concepts: best concise source for the commitment, precommitment, and nullifier structure.
layers/contracts and layers/contracts/privacy-pools: most useful for mapping actual control surfaces — Entrypoint authority, pool state, verifier roles, ASP-root validation, and the dead/wind-down path.
layers/asp: clearest summary of what the Association Set Provider actually does: maintain approved labels, publish roots through authorized postmen, and effectively decide private-withdrawal eligibility.
protocol/deposit: useful for the exact label-generation and fee-flow framing.
protocol/ragequit: useful because it makes the public exit path explicit rather than implicit.
dev-guide and reference/sdk: useful for confirming the exposed implementation stack and proving this is not just conceptual research.
github.com/ameensol/privacy-pools: useful because it preserves the earlier subset-merkle-root design rationale and the project’s explicit framing around licit/illicit subset curation.
Why this entry belongs in the corpus
It gives the corpus a concrete comparison point for privacy systems that try to preserve non-custodial asset recovery while still importing external policy into anonymity-set formation.
It strengthens comparison work across mixer-style privacy pools, stealth-address systems, and shielded-intent systems by making the policy layer legible instead of burying it inside vague compliance language.
The durable mechanism insight is that Privacy Pools moves control from deposit admission to withdrawal-privacy eligibility, then partially constrains that control with a public original-depositor exit path.