Update Privacy Pools vendor file to reflect v1 deployment#92
Conversation
- Replace vendors/privacypools.md with accurate v1 deployment info - Add viewing keys, enterprise use cases, progressive ASP decentralisation - Add Privacy Pools to private payments approach and vendor recommendations - Add cross-references in L1 ZK commitment pool and shielding patterns - Add Association Set and ASP glossary entries
| - [Shielded ERC-20 Transfers](../patterns/pattern-shielding.md) with commitment/nullifier schemes | ||
| - Higher per-transaction costs but battle-tested infrastructure | ||
|
|
||
| **L1 Compliance-Friendly Shielding (Privacy Pools):** |
There was a problem hiding this comment.
I suggest that instead of having a new category, we add an extra bullet point to the above.
- Extends the shielded pool model with association set proofs for regulatory compliance signaling with Privacy Pools
|
|
||
| ## See also | ||
| - pattern-dvp-erc7573.md · pattern-regulatory-disclosure-keys-proofs.md | ||
| - Privacy Pools (vendor): ../vendors/privacypools.md — production L1 implementation of this pattern with compliance extensions |
There was a problem hiding this comment.
Can we add a link instead?
Privacy Pools (vendor):
| - Railgun: https://docs.railgun.org/wiki | ||
| - Aztec docs: https://docs.aztec.network/ | ||
| - Zama fhEVM: https://docs.zama.org/protocol/protocol/overview | ||
| - Privacy Pools: https://privacypools.com (compliance-friendly shielded pool with association set proofs) |
There was a problem hiding this comment.
The description in parentheses is redundant with line 27.
|
|
||
| **Association Set**: A defined subset of deposits in a shielded pool, constructed by an Association Set Provider (ASP) according to compliance policies (e.g., excluding sanctioned addresses). Users prove membership or exclusion in an association set during withdrawal to signal compliance without revealing their specific deposit. | ||
|
|
||
| **Association Set Provider (ASP)**: An entity that defines, computes, and publishes association sets for a shielded pool. ASPs apply screening rules (sanctions lists, chain analytics, KYC credentials) to classify deposits and publish the resulting set as a Merkle root that users can prove against. |
|
Thanks for the PR @0xmikemcc You can run the linter locally with the following: |
|
Hi @0xmikemcc |
Use whitelisted "only supports" phrasing where it preserves meaning; rephrase the rest to neutral language. No semantic changes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
WalkthroughThis PR adds and refines documentation for Privacy Pools and Association Set Providers (ASPs) across the knowledge base. The glossary is expanded with new terminology definitions, a new Privacy Pools subsection is introduced as a privacy approach, pattern documents are updated to reference the new concept, and the Privacy Pools vendor document is substantially rewritten with specific deployment details and technical architecture. ChangesPrivacy Pools Documentation Layer
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes The changes span multiple files with consistent additions to a coherent topic, but the Privacy Pools vendor document rewrite contains specific technical claims about deployment details, contract addresses, architecture, and gas costs that warrant careful validation against production specifications. Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
patterns/pattern-l1-zk-commitment-pool.md (1)
1-17:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winMissing required crops_profile in frontmatter.
Per coding guidelines, pattern cards MUST include a
crops_profilefield with all four scores (cr, os, privacy, security). This pattern implements a concrete privacy primitive and is not a meta/evaluation pattern, socrops_profileis required.Additionally, the
maturity: pilotvalue appears to be from the v1 schema. Based on the presence of v2 fields (layer, privacy_goal, assumptions), this pattern should use v2 maturity values:research | concept | testnet | production.Add crops_profile and update maturity
--- title: "Pattern: L1 ZK commitment pool (low volume)" status: ready -maturity: pilot +maturity: production +crops_profile: + cr: medium + os: yes + privacy: full + security: medium layer: L1 privacy_goal: Hide amounts and positions on L1 via shielded pool with commitments and nullifiersRationale suggestion:
- cr: medium - Users can exit with proofs but prover infrastructure may be centralized
- os: yes - ZK commitment pool implementations are typically open source
- privacy: full - Shielded pool hides amounts and linkages
- security: medium - Depends on ZK proof system security and contract implementation
Adjust scores based on specific implementation details.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patterns/pattern-l1-zk-commitment-pool.md` around lines 1 - 17, Add a crops_profile frontmatter entry with all four scores (cr, os, privacy, security) and update the maturity value to a v2 token (research | concept | testnet | production) instead of "pilot"; specifically edit the YAML frontmatter at the top of this pattern card (fields like title, status, layer, privacy_goal) to insert crops_profile: { cr: medium, os: yes, privacy: full, security: medium } (adjust values if implementation details differ) and replace maturity: pilot with the appropriate v2 maturity token (e.g., testnet).patterns/pattern-shielding.md (1)
1-17:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winMissing required crops_profile in frontmatter.
Per coding guidelines, pattern cards MUST include a
crops_profilefield with all four scores. This pattern implements shielded ERC-20 transfers and requires CROPS evaluation.Additionally,
maturity: PoCis a v1 value. With v2 fields present (layer, privacy_goal, assumptions), use v2 maturity values:research | concept | testnet | production.Add crops_profile and update maturity
--- title: "Pattern: Shielded ERC-20 Transfers" status: draft -maturity: PoC +maturity: production +crops_profile: + cr: medium + os: yes + privacy: full + security: medium layer: hybrid privacy_goal: Confidential ERC-20 transfers hiding balances and metadata with selective disclosureRationale suggestion:
- cr: medium - User can exit with notes but may depend on relayer/prover infrastructure
- os: yes - Multiple open source implementations (Railgun, Privacy Pools)
- privacy: full - Shielded pool hides amounts, balances, and counterparties
- security: medium - Depends on proof system and contract security
Adjust based on specific implementation details.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patterns/pattern-shielding.md` around lines 1 - 17, Add a crops_profile frontmatter field with the four CROPS scores (cr, os, privacy, security) and update maturity from the v1 value "PoC" to a v2 value (choose one of: research, concept, testnet, production); specifically, insert a frontmatter entry named crops_profile mapping to the four keys (cr, os, privacy, security) with appropriate numeric/qualitative values (suggested: cr: medium, os: yes, privacy: full, security: medium) and replace maturity: PoC with the chosen v2 maturity string so the pattern card conforms to v2 frontmatter requirements and CROPS evaluation.vendors/privacypools.md (1)
7-94:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winCRITICAL: Missing required CROPS profile section.
Per the coding guidelines for
vendors/**/*.md, vendor cards MUST include a## CROPS profilesection with a table evaluating each product. The table should have columns: Product | CR | OS | Privacy | Security | Context, with scores validated against the rubrics inCONTRIBUTING.md § CROPS Evaluation.As per coding guidelines: "Vendor cards MUST include a
## CROPS profilesection with a table evaluating each product. Table columns: Product | CR | OS | Privacy | Security | Context. Validate scores against the rubrics inCONTRIBUTING.md § CROPS Evaluation. CROPS is assessed per product, not per vendor."📋 Add the required CROPS profile section
Add this section after the "Privacy domains" section and before "Enterprise demand and use cases":
+## CROPS profile + +| Product | CR | OS | Privacy | Security | Context | +|---------|----|----|---------|----------|---------| +| Privacy Pools v1 | medium | yes | full | medium | Association-set based shielded pool on Ethereum L1; upgradeable proxy with admin control; Groth16 trusted setup; production deployment with viewing keys planned | + +**Rationale:** +- **CR (medium)**: Users can exit with their funds via standard withdrawal proof, but association set construction is controlled by centralized ASP (currently 0xbow). +- **OS (yes)**: Core contracts and circuits are open source (GitHub link provided). +- **Privacy (full)**: Commitment/nullifier scheme hides deposit-withdrawal linkage; amounts and identities are shielded. +- **Security (medium)**: Upgradeable proxy introduces admin key risk; Groth16 requires trusted setup; production deployment but relatively new (2025).Note: Adjust the scores based on the actual implementation details and your evaluation against the CROPS rubrics.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@vendors/privacypools.md` around lines 7 - 94, The vendor card is missing the required "## CROPS profile" section; add a CROPS table (columns: Product | CR | OS | Privacy | Security | Context) inserted after the "Privacy domains" heading and before "Enterprise demand and use cases", include one row per product (e.g., Privacy Pools v1) with scores validated against the CROPS rubrics in CONTRIBUTING.md § CROPS Evaluation, and ensure the table text follows the exact column order and per-product assessment rule.
♻️ Duplicate comments (3)
patterns/pattern-l1-zk-commitment-pool.md (1)
45-45: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUse proper Markdown link syntax.
The vendor reference should use standard Markdown link formatting for consistency.
Suggested link format
-- Privacy Pools (vendor): ../vendors/privacypools.md — production L1 implementation of this pattern with compliance extensions +- [Privacy Pools](../vendors/privacypools.md) — production L1 implementation of this pattern with compliance extensions🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patterns/pattern-l1-zk-commitment-pool.md` at line 45, Replace the plain-text vendor reference "Privacy Pools (vendor): ../vendors/privacypools.md" with a proper Markdown link using square brackets and parentheses (e.g., change the line containing Privacy Pools (vendor): ../vendors/privacypools.md to something like [Privacy Pools (vendor)](../vendors/privacypools.md)) so the reference is a clickable, standards-compliant Markdown link.approaches/approach-private-payments.md (1)
45-52: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winConsider Meyanis95's suggestion to merge rather than create new subsection.
The previous reviewer suggested adding Privacy Pools as a bullet point under the "L1 Shielded Payments" section rather than creating a separate subsection, which would maintain better document flow.
Alternative structure following Meyanis95's suggestion
Merge into the "L1 Shielded Payments" section:
**L1 Shielded Payments:** - Maximum security using Ethereum L1 consensus - Provides **anonymity** (unlinkable addresses) but limited **privacy** (amounts/patterns may still leak) - [Shielded ERC-20 Transfers](../patterns/pattern-shielding.md) with commitment/nullifier schemes - Higher per-transaction costs but battle-tested infrastructure +- Extends the shielded pool model with association set proofs for regulatory compliance signaling via [Privacy Pools](../vendors/privacypools.md) -**L1 Compliance-Friendly Shielding (Privacy Pools):** - -[... remove separate subsection ...]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@approaches/approach-private-payments.md` around lines 45 - 52, The new subsection titled "L1 Compliance-Friendly Shielding (Privacy Pools)" should be merged into the existing "L1 Shielded Payments" section instead of existing as a separate subsection: move the bullet list (the lines starting with "- Extends the shielded pool model..." through "- Trade-off: v1 only supports ETH, higher gas costs (~2M)") into the "L1 Shielded Payments" section as a single bullet or sub-bullet under that heading, remove the separate "L1 Compliance-Friendly Shielding (Privacy Pools)" heading, and ensure the link to "../vendors/privacypools.md" and the "Best for" / "Trade-off" lines remain intact and formatted consistently with other bullets in "L1 Shielded Payments".patterns/pattern-shielding.md (1)
62-62: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueSimplify redundant description.
The parenthetical description repeats information from line 27. Consider simplifying.
Suggested simplification
-- Privacy Pools: https://privacypools.com (compliance-friendly shielded pool with association set proofs) +- Privacy Pools: https://privacypools.comOr if description is needed:
-- Privacy Pools: https://privacypools.com (compliance-friendly shielded pool with association set proofs) +- Privacy Pools: https://privacypools.com (L1 production deployment)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patterns/pattern-shielding.md` at line 62, The parenthetical on the "Privacy Pools: https://privacypools.com (compliance-friendly shielded pool with association set proofs)" line is redundant with the earlier description; remove or shorten the parenthesis so the line reads simply "Privacy Pools: https://privacypools.com" or, if a brief descriptor is desired, replace the parenthetical with a single short phrase like "(shielded pool)" to avoid repeating the detailed wording from line 27.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@patterns/pattern-l1-zk-commitment-pool.md`:
- Around line 1-17: Add a crops_profile frontmatter entry with all four scores
(cr, os, privacy, security) and update the maturity value to a v2 token
(research | concept | testnet | production) instead of "pilot"; specifically
edit the YAML frontmatter at the top of this pattern card (fields like title,
status, layer, privacy_goal) to insert crops_profile: { cr: medium, os: yes,
privacy: full, security: medium } (adjust values if implementation details
differ) and replace maturity: pilot with the appropriate v2 maturity token
(e.g., testnet).
In `@patterns/pattern-shielding.md`:
- Around line 1-17: Add a crops_profile frontmatter field with the four CROPS
scores (cr, os, privacy, security) and update maturity from the v1 value "PoC"
to a v2 value (choose one of: research, concept, testnet, production);
specifically, insert a frontmatter entry named crops_profile mapping to the four
keys (cr, os, privacy, security) with appropriate numeric/qualitative values
(suggested: cr: medium, os: yes, privacy: full, security: medium) and replace
maturity: PoC with the chosen v2 maturity string so the pattern card conforms to
v2 frontmatter requirements and CROPS evaluation.
In `@vendors/privacypools.md`:
- Around line 7-94: The vendor card is missing the required "## CROPS profile"
section; add a CROPS table (columns: Product | CR | OS | Privacy | Security |
Context) inserted after the "Privacy domains" heading and before "Enterprise
demand and use cases", include one row per product (e.g., Privacy Pools v1) with
scores validated against the CROPS rubrics in CONTRIBUTING.md § CROPS
Evaluation, and ensure the table text follows the exact column order and
per-product assessment rule.
---
Duplicate comments:
In `@approaches/approach-private-payments.md`:
- Around line 45-52: The new subsection titled "L1 Compliance-Friendly Shielding
(Privacy Pools)" should be merged into the existing "L1 Shielded Payments"
section instead of existing as a separate subsection: move the bullet list (the
lines starting with "- Extends the shielded pool model..." through "- Trade-off:
v1 only supports ETH, higher gas costs (~2M)") into the "L1 Shielded Payments"
section as a single bullet or sub-bullet under that heading, remove the separate
"L1 Compliance-Friendly Shielding (Privacy Pools)" heading, and ensure the link
to "../vendors/privacypools.md" and the "Best for" / "Trade-off" lines remain
intact and formatted consistently with other bullets in "L1 Shielded Payments".
In `@patterns/pattern-l1-zk-commitment-pool.md`:
- Line 45: Replace the plain-text vendor reference "Privacy Pools (vendor):
../vendors/privacypools.md" with a proper Markdown link using square brackets
and parentheses (e.g., change the line containing Privacy Pools (vendor):
../vendors/privacypools.md to something like [Privacy Pools
(vendor)](../vendors/privacypools.md)) so the reference is a clickable,
standards-compliant Markdown link.
In `@patterns/pattern-shielding.md`:
- Line 62: The parenthetical on the "Privacy Pools: https://privacypools.com
(compliance-friendly shielded pool with association set proofs)" line is
redundant with the earlier description; remove or shorten the parenthesis so the
line reads simply "Privacy Pools: https://privacypools.com" or, if a brief
descriptor is desired, replace the parenthetical with a single short phrase like
"(shielded pool)" to avoid repeating the detailed wording from line 27.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1672d028-0114-44f9-b167-7858350c6216
📒 Files selected for processing (5)
GLOSSARY.mdapproaches/approach-private-payments.mdpatterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.mdvendors/privacypools.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
patterns/pattern-*.md
⚙️ CodeRabbit configuration file
patterns/pattern-*.md: This is a pattern card.Structure & frontmatter: Validate against the template at
patterns/_template.md.
File naming rules are inpatterns/README.md. Filename must start withpattern-in kebab-case.
Pattern names must be vendor-neutral (no vendor-specific names like aztec, nightfall, railgun, etc.).CROPS alignment (CRITICAL):
crops_profilewith all four fields (cr,os,privacy,security) is required — CI will reject patterns missing it.
Exception: meta/evaluation patterns that do not implement privacy directly may setcrops_profile: "n/a"— flag if this is used on a pattern that clearly does implement a privacy primitive.
Valid enum values are defined inCONTRIBUTING.md § CROPS Evaluationand enforced by the JSON schema atscripts/schemas/pattern.json.Your job is to review CROPS scores for plausibility, which CI cannot check:
- A pattern requiring a centralized operator should not claim
cr: high.- If the pattern involves I2U context, check that the CR score accounts for user escape paths per the CR rubric in CONTRIBUTING.md.
- A pattern using proprietary components should not claim
os: yes.- A pattern where the operator sees all user operations should not claim
privacy: full.Word limits: warn > 800, error > 1500.
Tone: factual and neutral per house style. No marketing language.
Files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
approaches/**/*.md
⚙️ CodeRabbit configuration file
approaches/**/*.md: This is an approach card.Structure: Validate against the template at
approaches/_template.md.
File naming and conventions are inapproaches/README.md. Filename must start withapproach-in kebab-case.Approach cards MUST link to both the use case they address and the patterns they combine.
Flag if no pattern or use case cross-references are present.Word limits: warn > 2000, error > 3000.
Files:
approaches/approach-private-payments.md
vendors/**/*.md
⚙️ CodeRabbit configuration file
vendors/**/*.md: This is a vendor card.Structure & frontmatter: Validate against the template at
vendors/_template.md.Ethereum alignment (CRITICAL):
Pervendors/README.md, IPTF only lists vendors whose products are Ethereum-aligned.
Check that the product is built for or deployed on Ethereum mainnet or production L2s,
or is a multichain solution that benefits the Ethereum ecosystem (supports EIPs/ERCs,
advances shared privacy patterns, or brings institutional adoption to Ethereum).
Flag products that primarily serve non-Ethereum L1s without meaningful Ethereum integration.CROPS evaluation (CRITICAL):
Vendor cards MUST include a## CROPS profilesection with a table evaluating each product.
Table columns: Product | CR | OS | Privacy | Security | Context.
Validate scores against the rubrics inCONTRIBUTING.md § CROPS Evaluation.
CROPS is assessed per product, not per vendor — a single vendor may have products with different profiles.
For vendors, the Security score should also consider: audit status, upgrade key controls, admin key scope, incident history, and bug bounty program.Tone (CRITICAL): Must be neutral and factual per
vendors/README.mdhouse style.
Vendor cards describe capabilities objectively — they do not endorse products.
Flag any promotional language, superlatives, or marketing copy.Word limits: warn > 1000, error > 1800.
Files:
vendors/privacypools.md
🧠 Learnings (12)
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation should keep the Protocol section high-level and concise. Do not include granular implementation steps (e.g., explicit point-validation sub-steps). If such concerns must be mentioned, use lightweight callouts in a separate Security Notes or Caveats section. Apply this guideline to all pattern docs under the patterns directory.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-03-20T05:29:08.871Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:19-23
Timestamp: 2026-03-20T05:29:08.871Z
Learning: When reviewing Ethereum iPTF-Map pattern documentation, distinguish clearly between **censorship** and **liveness**: treat censorship as the operator blocking user inputs from being processed (this impacts CR score), while treat liveness as the operator withholding outputs after protocol participation (this does not directly affect CR score). For garbled-circuit PSI patterns specifically, if the **garbler withholds the output decoding table**, classify this as a **liveness** concern—not censorship—and therefore **do not** flag it as a “CR justification gap.”
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:49:47.740Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-lean-ethereum.md:4-4
Timestamp: 2026-05-04T14:49:47.740Z
Learning: In ethereum/iptf-map, pattern card markdown files under `patterns/` use v2 front-matter for the `maturity` field. When reviewing these files, treat `maturity` as a v2 enum and only consider it valid if it is one of: `research`, `concept`, `testnet`, or `production`. Do not flag `research` as invalid.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:50:03.967Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-privacy-l2s.md:4-4
Timestamp: 2026-05-04T14:50:03.967Z
Learning: In ethereum/iptf-map pattern cards using schema v2 (introduced in PR `#152`), validate the `maturity` field against the v2 enum values only: `research | concept | testnet | production`. The v1 enum (`PoC | pilot | prod`) is no longer applicable to v2-migrated pattern cards. When reviewing v2 pattern files, do not flag `production` as non-canonical (it is a valid v2 value).
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:50:03.935Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-mixnet-anonymity.md:4-4
Timestamp: 2026-05-04T14:50:03.935Z
Learning: In this repo’s pattern files under `patterns/`, the IPtF map schema maturity enum must use the v2 values only: `research | concept | testnet | production`. The legacy v1 values `PoC | pilot | prod` are invalid after the v2 schema migration (PR `#152`). Therefore, when reviewing `patterns/**/*.md`, do not flag `testnet` or `production` as invalid maturity values; instead, flag any remaining usage of the old v1 enum values (`PoC`, `pilot`, `prod`) as incorrect.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:50:06.756Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-compliance-monitoring.md:4-4
Timestamp: 2026-05-04T14:50:06.756Z
Learning: In ethereum/iptf-map, for v2 pattern cards under the `patterns/` directory, validate the `maturity` field against the v2 enum only: `research | concept | testnet | production`. Do not treat `testnet` or `production` as invalid maturity values for v2 pattern cards (the v1 enum `PoC | pilot | prod` is obsolete for content migrated to v2).
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:50:06.734Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-private-contract-dsl.md:4-4
Timestamp: 2026-05-04T14:50:06.734Z
Learning: For ethereum/iptf-map v2 pattern cards in the `patterns/` directory, validate the `maturity` field against the v2 enum defined in `scripts/schemas/pattern.json`: `research`, `concept`, `testnet`, `production`. Do NOT flag `maturity: production` as non-standard in v2 pattern files. Conversely, do not accept the v1 enum values (`PoC`, `pilot`, `prod`) for v2 pattern cards.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T19:17:00.734Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 155
File: patterns/pattern-private-stablecoin-shielded-payments.md:38-43
Timestamp: 2026-05-04T19:17:00.734Z
Learning: In this repo’s IPtF map pattern Markdown files, the v2 frontmatter key `visibility:` is part of the approved schema (defined by `patterns/_template.md`). It encodes the four-slot visibility matrix (counterparty, chain, regulator, public) for transaction-level pattern cards. Do not flag `visibility` as an unknown/ad-hoc/non-schema frontmatter key in `patterns/**/*.md`; only treat it as an issue if it violates the expected schema/format.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-03-19T10:42:48.438Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:48.438Z
Learning: In ethereum/iptf-map, when reviewing documentation files in the `patterns/` directory (e.g., `patterns/*.md`), do not flag frontmatter fields `layer`, `privacy_goal`, or `assumptions` as invalid/non-schema fields. These fields are explicitly defined as valid properties in `scripts/schemas/pattern.json` with the expected types/constraints: `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings).
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:49:53.905Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-co-snark.md:4-4
Timestamp: 2026-05-04T14:49:53.905Z
Learning: In ethereum/iptf-map, for pattern markdown files under `patterns/` that use the v2 schema (introduced in PR `#152`), the `maturity` field must be one of: `research | concept | testnet | production`. Do not flag `testnet` or `production` as invalid in these v2-migrated pattern cards, and treat the old v1 values (`PoC | pilot | prod`) as not valid for v2 patterns.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:49:53.905Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-co-snark.md:4-4
Timestamp: 2026-05-04T14:49:53.905Z
Learning: When reviewing `patterns/*.md` in the `ethereum/iptf-map` repository that have been migrated to schema v2, interpret and validate the `maturity` field using the v2 enum values: `research | concept | testnet | production` (and do not accept legacy values `PoC | pilot | prod`). Also verify that `maturity` describes the repository’s Ethereum integration readiness (e.g., readiness of the native Ethereum execution-client integration represented in the repo), not the general real-world production readiness of the underlying technology.
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
📚 Learning: 2026-05-04T14:50:02.790Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 154
File: patterns/pattern-icma-bdt-data-model.md:4-4
Timestamp: 2026-05-04T14:50:02.790Z
Learning: When reviewing `maturity` fields in v2 pattern-card files under `patterns/` (v2 schema introduced in PR `#152` for `ethereum/iptf-map`), use the v2 enum values only: `research | concept | testnet | production`. Do not flag `production` as non-conformant in v2 pattern files, and do not recommend replacing `production` with the v1 value `prod` (v1 enum `PoC | pilot | prod` is obsolete for v2).
Applied to files:
patterns/pattern-l1-zk-commitment-pool.mdpatterns/pattern-shielding.md
🪛 LanguageTool
vendors/privacypools.md
[style] ~25-~25: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ion (operates as L1 smart contracts). - Not an identity system (relies on external ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~26-~26: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rs for association set construction). - Not a universal compliance layer (complianc...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~27-~27: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...n ASP set construction and policies). - Not a general-purpose shielded token system...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~76-~76: Do not mix variants of the same word (‘centralize’ and ‘centralise’) within a single text.
Context: ...*: No mandatory global allowlisting, no centralized backdoors. Users choose when and to who...
(EN_WORD_COHERENCY)
🔇 Additional comments (4)
GLOSSARY.md (1)
5-8: LGTM: Clear definitions for Privacy Pools terminology.The Association Set and ASP definitions accurately support the Privacy Pools documentation and match the technical usage in the vendor card.
approaches/approach-private-payments.md (1)
45-52: LGTM: Factual and neutral tone.The Privacy Pools subsection maintains neutral, technical language appropriate for the knowledge base. The claims align with the vendor card details.
vendors/privacypools.md (2)
73-73: No issue found. The phrase "Sole live implementation of the association set model on Ethereum mainnet" is factually accurate. Web research confirms Privacy Pools is the only deployed implementation of the Association Set model on Ethereum mainnet; competing privacy protocols (Tornado Cash, Railgun, Hinkal, zkBob, Incognito) use different architectures or mechanisms. This is a technical distinguishing feature, not promotional language.
33-34: Contract addresses verified as accurate. Both the Entrypoint proxy (0x6818809EefCe719E480a7526D76bD3e561526b46) and ETH Pool (0xF241d57C6DebAe225c0F2e6eA1529373C9A9C9fB) are confirmed as correct mainnet deployments per official Privacy Pools documentation.
2 participants
Summary
The current
vendors/privacypools.mdwas written from the 2023 SSRN paper, not the actual v1 deployment. This PR updates it to reflect the production state and adds cross-references across the repo.Key issues fixed:
ameensol/privacy-pools(research repo) instead of0xbow-io/privacy-pools-coreChanges:
vendors/privacypools.md— Full rewrite with:approaches/approach-private-payments.md— Added:patterns/pattern-l1-zk-commitment-pool.md— Added vendor cross-reference to Privacy Pools in See alsopatterns/pattern-shielding.md— Added:GLOSSARY.md— Added definitions for:Context
This PR is submitted by 0xbow, the developer and operator of the Privacy Pools protocol. We want to ensure the IPTF map accurately represents the current production state of the protocol for institutional evaluators.
Summary by CodeRabbit