feat(audit): merge audit trail and fixes#130
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughQ2 2026 audit pass across repository docs and validation config. It adds a QA audit tracker, updates validation and template rules, rewrites jurisdiction cards into a shorter developer-oriented format, corrects approach and pattern content, and promotes use-case and vendor documents to ChangesQ2 2026 IPTF Map Content Audit
Estimated code review effort: 5 (Critical) | ~120 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
LMK when ready for review |
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@Meyanis95 how can we get this to be ready for review and mergeable? Would be good if we can get it reviewed and merged before EOW. Right now it is WIP draft. |
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai help |
|
@coderabbitai full review |
✅ Action performedFull review finished. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 27
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (18)
vendors/fhenix.md (2)
14-20: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse relative paths for internal pattern links.
The pattern links use absolute GitHub URLs (
https://github.com/ethereum/iptf-map/blob/master/patterns/...). Relative paths (../patterns/pattern-...) are preferred for internal cross-references — they work locally, in forks, and don't hardcode branch names.- [Selective disclosure (viewing keys + ZK proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md) + [Selective disclosure (viewing keys + ZK proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md)(Apply to all pattern links in this file.)
🤖 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/fhenix.md` around lines 14 - 20, The internal pattern references in the Fhenix markdown use hardcoded GitHub blob URLs, which should be changed to relative links. Update all pattern links in this section to use relative paths to the corresponding files under patterns so the references work in forks and local previews without depending on a specific branch. Keep the link targets consistent across every occurrence in this file and use the existing pattern filenames as the source of truth.
1-63: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winAdd a CROPS profile section. This vendor card is missing the required
## CROPS profiletable for CR, OS, Privacy, Security, and Context; add it to match the vendor template and scoring rules.🤖 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/fhenix.md` around lines 1 - 63, The Fhenix vendor card is missing the required CROPS profile section. Add a "## CROPS profile" table in this document with rows for CR, OS, Privacy, Security, and Context, matching the existing vendor template and scoring format used by other vendor profiles. Use the current content in the vendor card to populate the scores and short justifications, and place the new section in the standard position alongside the other top-level vendor metadata sections.Source: Path instructions
vendors/fireblocks.md (1)
1-61: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winAdd the missing
## CROPS profilesection. This vendor card still needs the required product-level CROPS table to matchvendors/_template.md.🤖 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/fireblocks.md` around lines 1 - 61, The Fireblocks vendor card is missing the required product-level CROPS profile section from the vendor template. Add a new “## CROPS profile” section in this document, using the same structure and fields as vendors/_template.md, and place it in a sensible spot alongside the other top-level sections such as “What it is” and “Fits with patterns.” Ensure the new section is complete and consistent with the existing Fireblocks content.Source: Path instructions
vendors/fairblock.md (1)
1-88: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winAdd the
## CROPS profilesection.vendors/fairblock.mdcurrently ends at Links and is missing the required CROPS table withProduct | CR | OS | Privacy | Security | Context.🤖 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/fairblock.md` around lines 1 - 88, The Fairblock vendor doc is missing the required CROPS profile section at the end of the file. Add a new “## CROPS profile” section after the Links content in vendors/fairblock.md, and include the required table with the columns Product, CR, OS, Privacy, Security, and Context, using the existing Fairblock/FairyRing details from the document.Source: Path instructions
vendors/flashbots.md (1)
45-65: 🔒 Security & Privacy | 🔴 Critical | 🏗️ Heavy liftCritical: Missing required CROPS profile section.
Per the vendor template and
vendors/README.md, vendor cards MUST include a## CROPS profilesection with a table evaluating CR, OS, Privacy, Security, and Context for each product. This card has no CROPS profile and cannot be markedreadywithout it.Additionally, soften promotional phrasing in Strengths:
- "significant adoption" → "substantial adoption" or "notable adoption"
- "strong relationship" → "established integration" or "close collaboration"
- "next-generation infrastructure" → "new infrastructure" or remove
📝 Proposed CROPS profile addition (verify values before using)
## CROPS profile | Product | CR | OS | Privacy | Security | Context | |---------|----|----|---------|----------|---------| | Flashbots Auction | medium | yes | none | medium | i2i | | SUAVE/BuilderNet | medium | partial | partial | medium | i2u | - **CR**: Medium (user can choose builders, but builder set is centralized) - **OS**: Yes for Auction (open APIs), partial for SUAVE (under development) - **Privacy**: None for Auction (transactions visible after inclusion); partial for SUAVE (intent privacy until execution) - **Security**: Medium (established operational security, but trust in builders)🤖 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/flashbots.md` around lines 45 - 65, Add the missing required ## CROPS profile section to the Flashbots vendor card, using the vendor template in vendors/README.md and the existing Strengths/Risks structure as a guide; include a table for each product with CR, OS, Privacy, Security, and Context, and ensure the card is not marked ready until this section exists. While editing the same card, tone down the promotional language in the Strengths bullets referenced by the Flashbots section so terms like “significant adoption,” “strong relationship,” and “next-generation infrastructure” are replaced with more neutral wording, keeping the content aligned with the template.Source: Path instructions
vendors/paladin.md (2)
1-112: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMissing required
## Privacy domainssection.Per
vendors/_template.md, the required section headings include "Privacy domains". The file mentions privacy domains in passing (line 17) but does not have a dedicated## Privacy domainssection. Add this section before## Enterprise demand and use cases.🤖 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/paladin.md` around lines 1 - 112, The vendor page is missing the required dedicated Privacy domains section. Add a new “## Privacy domains” section in paladin.md before “## Enterprise demand and use cases,” and move or summarize the existing mentions of Zeto, Noto, and Pente there so the document matches the required headings from vendors/_template.md.
1-112: 🗄️ Data Integrity & Integration | 🔴 Critical | 🏗️ Heavy liftMissing required
## CROPS profilesection.Per
vendors/_template.mdand path instructions, vendor cards MUST include a## CROPS profilesection with a table evaluating CR, OS, Privacy, Security, and Context. This file is missing the section entirely and cannot bereadywithout it.📋 Required addition
## CROPS profile | Product | CR | OS | Privacy | Security | Context | |---------|----|----|---------|----------|---------| | Paladin | ... | ... | ... | ... | ... |🤖 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/paladin.md` around lines 1 - 112, The Paladin vendor card is missing the required CROPS profile section, so add a new “## CROPS profile” section in the Paladin markdown and include the evaluation table for CR, OS, Privacy, Security, and Context. Place it alongside the existing sections in this vendor doc so the card can be marked ready; use the current content in vendors/paladin.md to fill the row for the Paladin entry.vendors/peer.md (2)
1-67: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMissing required
## Privacy domainssection.Per
vendors/_template.md, vendor cards must include a## Privacy domainssection. This file lacks it. Add between## Architectureand## Enterprise demand and use cases.🤖 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/peer.md` around lines 1 - 67, Add the missing required Privacy domains section in the Peer vendor card, using the same style as the existing sections. Place the new ## Privacy domains heading between the Architecture and Enterprise demand and use cases sections in vendors/peer.md, and ensure it summarizes the relevant privacy domains for Peer consistently with the rest of the document.
1-67: 🗄️ Data Integrity & Integration | 🔴 Critical | ⚡ Quick winCROPS profile table was removed—this is required.
The path instructions and
vendors/_template.mdrequire vendor cards to include a## CROPS profilesection with a CROPS evaluation table. This file previously had one (per change description) and it was removed in this PR. Restore it before markingready.📋 Required restoration
## CROPS profile | Product | CR | OS | Privacy | Security | Context | |---------|----|----|---------|----------|---------| | Peer | ... | ... | ... | ... | ... |🤖 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/peer.md` around lines 1 - 67, Restore the missing CROPS profile section in the Peer vendor card, since `vendors/_template.md` and the vendor path rules require it before the file can stay ready. Add back the `## CROPS profile` heading and the CROPS evaluation table in the `Peer` document, keeping the existing vendor summary intact and making sure the section appears with the rest of the card content.vendors/soda-labs.md (3)
41-41: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFix typo: "Cirtcuit" → "Circuit".
🤖 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/soda-labs.md` at line 41, The typo in the Soda Labs description should be corrected in the Garbled Circuit + ZK phrase. Update the text in the affected markdown entry so the term is spelled “Circuit” instead of “Cirtcuit,” keeping the rest of the sentence unchanged.
32-32: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFix typo: "posession" → "possession".
🤖 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/soda-labs.md` at line 32, Fix the typo in the Soda Labs documentation text by updating the misspelled word in the sentence about Evaluators and garbled circuits; specifically, correct the wording in the markdown content that contains “posession” so it reads “possession” while keeping the rest of the paragraph unchanged.
59-59: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winReplace superlative with neutral phrasing.
"lowest latency" is promotional. Use "lower latency" or specify the comparative basis factually.
🤖 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/soda-labs.md` at line 59, The wording in the Soda Labs description uses a promotional superlative (“lowest latency”); update the affected sentence in the markdown copy to neutral, factual phrasing such as “lower latency” or a clearly qualified comparison, keeping the rest of the text unchanged.vendors/tx-shield.md (1)
6-136: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFlag marketing language and verify CROPS profile.
The vendor card contains promotional phrasing that violates the neutral tone requirement per
vendors/README.md:
- Line 57: "high performance" → consider "MPC-based payment layer with threshold key control"
- Line 82: "Ideal for" → consider "Suited for" or remove
- Line 105: "delivers institutional-grade" → consider "provides"
- Line 106: "enables privacy-preserving" → consider "supports"
Also verify:
## CROPS profiletable exists pervendors/_template.md.- Word count is under 1800 (warn if >1000).
- Ethereum alignment: TX-SHIELD mentions "on-chain" settlement but specify which chain(s).
#!/bin/bash # Check for CROPS profile section rg -n -A 10 "## CROPS profile" vendors/tx-shield.md # Check word count wc -w vendors/tx-shield.md # Check Ethereum mentions rg -n -i "ethereum|evm|eip|erc" vendors/tx-shield.md🤖 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/tx-shield.md` around lines 6 - 136, The vendor card in tx-shield.md uses promotional wording that should be replaced with neutral descriptions, especially in the Architectural, Enterprise demand, and Strengths sections; update phrases like “high performance,” “Ideal for,” “delivers institutional-grade,” and “enables privacy-preserving” in the relevant TX-SHIELD, OpenTMP LLM, and Collab-Key descriptions. Also verify that a ## CROPS profile section/table exists per the vendor template, confirm the document stays within the word-count guidance, and clarify the Ethereum/alignment claim by naming the specific chain(s) for the on-chain settlement mention.Source: Path instructions
vendors/zksync.md (1)
50-53: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winRemove superlatives and fix typo.
- "Comprehensive enterprise features" → remove superlative, state features factually.
- "Efficient ZK Proving" → quantify or remove vague praise.
- "accross" → "across"
🤖 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/zksync.md` around lines 50 - 53, Revise the bullet list in the vendor description to use factual, non-promotional wording: remove the superlative from the enterprise features line, replace the vague “Efficient ZK Proving” phrasing with a neutral concrete description or drop it, and correct the typo in the interoperability bullet from “accross” to “across”; update the text where these bullets appear in the markdown content.Source: Path instructions
approaches/approach-white-label-deployment.md (1)
1-261: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winTrim this approach card to under 2000 words.
approaches/approach-white-label-deployment.mdis 2651 words, which exceeds the approach-card warning threshold.🤖 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-white-label-deployment.md` around lines 1 - 261, The approach card is over the 2000-word limit and needs to be shortened without losing the core decision guidance. Trim repetitive detail in the long narrative sections of approach-white-label-deployment.md, especially the repeated trust/threat/implementation prose under Vendor-Managed Deployment, Institution-Controlled Deployment, and the Legal & risk/Technical perspective sections, while preserving the summary, comparison table, and recommendation. Keep the unique identifying section headers intact so the card remains easy to scan.approaches/approach-private-identity.md (1)
300-304: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueAvoid marketing language: "only."
Per house style (
IPTF.Marketing), avoid "only" as marketing language. The claim that Issuer-Independent OPRF is "the only category designed to survive single-issuer failure" is a strong uniqueness claim that should be verified or softened to neutral, factual terms.- but is the only category designed to survive single-issuer failure + but is the category most explicitly designed to survive single-issuer failure🤖 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-identity.md` around lines 300 - 304, Update the wording in the “Technical perspective” section to remove the uniqueness claim around Issuer-Independent OPRF; in the sentence in the approach-private-identity discussion that currently says it is “the only category designed to survive single-issuer failure,” rewrite it in neutral factual terms or qualify it as one option rather than the sole one. Keep the rest of the comparison intact and preserve the technical positioning of Issuer-Independent OPRF, Registry Membership, Document ZK, TLS Transcript Proofs, On-Chain Attestation, and POD2.Source: Linters/SAST tools
approaches/approach-private-trade-settlement.md (1)
1-35: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winSet
use_casetoprivate-trade-settlement.
The frontmatter currently points this approach card atprivate-bonds, which breaks the required use-case cross-reference for this file.🤖 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-trade-settlement.md` around lines 1 - 35, Update the frontmatter in approach-private-trade-settlement so the use_case matches the document’s own topic; replace the current private-bonds value with private-trade-settlement. Keep the rest of the metadata unchanged, and verify the related_use_cases and other approach fields still align with the Private Trade Settlement card.vendors/_template.md (1)
42-43: 📐 Maintainability & Code Quality | 🟠 Major | ⚖️ Poor tradeoffRestore the CROPS profile section.
The template removes the mandatory
## CROPS profiletable, but path instructions require vendor cards to include this evaluation. Pervendors/README.mdandCONTRIBUTING.md § CROPS Evaluation, CROPS is assessed per product with columns Product | CR | OS | Privacy | Security | Context. Removing it from the template will cause new vendor cards to omit required scoring.If the project is intentionally dropping CROPS from vendors, update the path instructions first; otherwise restore the section in the template.
🤖 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/_template.md` around lines 42 - 43, The vendor card template is missing the required CROPS profile section, so restore the `## CROPS profile` table in the template used for new vendor cards. Update the markdown in the template so it includes the full evaluation columns for Product, CR, OS, Privacy, Security, and Context, matching the guidance referenced by the template and the contributing rules. If CROPS is being removed intentionally, update the path instructions first; otherwise keep the section in place for consistency with vendor card requirements.Source: Path instructions
🤖 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.
Inline comments:
In @.github/workflows/audit-check.yml:
- Around line 17-29: The checkout step in the audit workflow is keeping
repository credentials available longer than needed. Update the existing
actions/checkout step in the audit-check job to disable persisted credentials,
and add a top-level permissions block that limits the job to contents: read.
Keep the rest of the job, including the Fetch master and scripts/audit-sync.js
steps, unchanged.
In `@approaches/approach-dvp-atomic-settlement.md`:
- Around line 198-210: Update the Default recommendation in the atomic
settlement approach to avoid implying ERC-3643 is production-ready; in the
section describing Escrow with Dual Approval, explicitly qualify the reference
to ERC-3643 by noting it is Draft or only applicable where available. Keep the
wording aligned with the existing terminology in the document so the Default,
Decision factors, and Hybrid guidance remain consistent.
- Around line 40-52: The standard-status wording in the atomic-settlement
approach is inaccurate because ERC-6123 is Draft but ERC-3643 is Final. Update
the requirements text to reflect the correct status for both standards, and keep
the reference to ERC-6123 and ERC-3643 in the same section so the status
statement is clear and consistent.
In `@approaches/approach-private-identity.md`:
- Line 256: Update the TACEO:OPRF status text in approach-private-identity.md so
it no longer says “currently in public beta”; replace it with the correct
production/live status in the “How it works” section where TACEO operates the
threshold OPRF network, keeping the rest of the enrollment flow unchanged.
- Around line 314-320: The phrase in the decision factors list should use the
hyphenated form “on-chain” to match the rest of the document’s terminology.
Update the wording in the sentence under the TLS Transcript Proofs bullet so it
reads “brought on-chain” while leaving the rest of the guidance unchanged; use
the surrounding “Decision factors” section and the “TLS Transcript Proofs”
bullet to locate it.
In `@CHANGELOG.md`:
- Line 7: Update the CHANGELOG entry in CHANGELOG.md so it includes a markdown
link to the changed file as required by the path instructions. Keep the existing
chore/PR reference, and add a link to the relevant markdown file reference
within the same entry so the changelog item satisfies the file-link rule.
In `@jurisdictions/_template.md`:
- Around line 12-27: The jurisdiction template in the markdown card structure is
missing the required Actionable Best Practices section and its subsections, so
either restore those subsections in the template or update the path instructions
that govern jurisdiction cards to no longer require them. Use the template’s
existing headings like At a Glance, What to Watch, and See also to locate the
restructuring, and make the guidance consistent with whichever format is
intended.
In `@jurisdictions/int-banking-secrecy.md`:
- Around line 15-30: The jurisdiction card content is out of the required
template because it is missing the mandatory `## Actionable Best Practices`
section and the six required subsections. Update the
`jurisdictions/int-banking-secrecy.md` card structure to match the standard
jurisdiction-card contract by adding `## Actionable Best Practices` with
Payments, Trading, Funds & Assets, Custody, Identity & Compliance, and Data &
Oracles, while keeping the existing banking-secrecy guidance under the
appropriate headings.
In `@jurisdictions/us-SEC.md`:
- Around line 30-31: The reference label for the SEC document is overstated,
since the linked PDF is a public submission to the SEC rather than an
SEC-authored proposal. Update the markdown entry in us-SEC.md to use a neutral,
accurate title for that citation, keeping the White House Digital Assets Report
entry unchanged and adjusting only the second bullet so the label matches the
document’s true origin.
- Around line 17-31: The jurisdiction card content is using the old “At a Glance
/ What to Watch / See also” layout and no longer matches the required template.
Update the `jurisdictions/us-SEC.md` card to follow the standard
jurisdiction-card structure used by the other rewritten cards: keep the overview
concise, add `## Actionable Best Practices`, and include the six required
subsections for Payments, Trading, Funds & Assets, Custody, Identity &
Compliance, and Data & Oracles so it conforms to `jurisdictions/**/*.md`.
In `@patterns/pattern-cross-chain-privacy-bridge.md`:
- Line 101: In the deployment topologies list, the privacy-to-privacy
description uses marketing language with “maximum privacy”; rephrase that part
in pattern-cross-chain-privacy-bridge.md using neutral wording such as “privacy
on both sender and receiver ends” or “end-to-end shielding,” while keeping the
rest of the topology descriptions unchanged.
In `@patterns/pattern-lean-ethereum.md`:
- Line 61: Update the client-team count wording in the lean Ethereum pattern so
it only refers to consensus clients, not all clients. Replace the unsupported
“eight independent client teams” claim with a source-backed statement that names
or counts the consensus-layer teams, and adjust the surrounding phrasing in the
relevant markdown section to avoid including execution clients like Besu and
Erigon.
In `@patterns/pattern-recipient-derived-receive-addresses.md`:
- Around line 3-6: The frontmatter for
pattern-recipient-derived-receive-addresses is missing the required type field.
Update the document’s frontmatter to include type with the correct
classification, using type: standard unless this pattern should be meta, and
keep the existing frontmatter keys like status, maturity, layer, and
last_reviewed intact.
In `@scripts/audit-sync.js`:
- Around line 108-130: `check()` and `buildRows()` need to enforce exactly one
active row per master file before syncing. Update the validation in `check()` so
it rejects duplicate entries for the same file and flags any row whose file
still exists in `masterFiles(section.dir)` if its status is `deprecated`. Then
make `buildRows()` avoid silently collapsing duplicates via the `byFile` Map,
and ensure `--sync` only proceeds after these constraints are satisfied so each
master file has one live row.
In `@scripts/validate-patterns.js`:
- Around line 133-141: The jurisdiction validation in validate-patterns.js is
now too permissive because REQUIRED_JURISDICTION_SECTIONS no longer enforces the
documented card contract. Update the jurisdiction checks so
jurisdictions/**/*.md still require ## Actionable Best Practices and all
mandated subsections (Payments, Trading, Funds & Assets, Custody, Identity &
Compliance, and Data & Oracles), and make sure the logic tied to
RECOMMENDED_JURISDICTION_SECTIONS does not replace the required validation in
the jurisdiction card path.
In `@use-cases/resilient-civic-participation.md`:
- Around line 2-5: The frontmatter in the resilient civic participation use case
uses a shortened domain label; update the primary_domain value to the full
governance domain name while leaving secondary_domain unchanged. Locate the
frontmatter fields in the markdown file and ensure the existing title/status
entries stay intact, with primary_domain set to Civic Coordination & Governance.
In `@use-cases/resilient-identity-continuity.md`:
- Around line 2-4: The frontmatter for the Resilient Identity Continuity
use-case is missing the required secondary_domain field, so the file no longer
matches the use-case template. Update the markdown frontmatter in
resilient-identity-continuity.md to include secondary_domain alongside title,
status, and primary_domain, using the same naming pattern as the template in
_template.md.
In `@vendors/fhenix.md`:
- Around line 11-12: The vendor description in the Fhenix markdown is too
promotional and should be rewritten in a neutral, factual tone. Update the copy
in the Fhenix card to remove marketing qualifiers like “fast” and “easy,” and
keep the wording focused on what CoFHE is and does; use the existing description
text to identify the affected sentence and replace it with a concise, objective
summary.
In `@vendors/flashbots.md`:
- Around line 25-44: The Flashbots vendor card is missing the template-mandated
“Privacy domains” section, so update the markdown structure in the Flashbots
content to include that heading alongside the existing Architecture, Enterprise
demand and use cases, and Technical details sections. Keep the current facts,
but add a dedicated “Privacy domains” section in the same style as the other
headings so the vendor-card format is complete.
In `@vendors/hinkal.md`:
- Around line 13-18: The Hinkal vendor card is missing the required CROPS
profile section from the template. Add a new “## CROPS profile” section in this
document and include the per-product CROPS table alongside the existing sections
like “## Fits with patterns” so the card matches the standard vendor-card
structure.
In `@vendors/iexec.md`:
- Line 3: The iExec vendor template is missing the required CROPS profile
section, so add the mandatory “## CROPS profile” table to the markdown alongside
the existing template sections. Update vendors/iexec.md to include the full
CROPS entry in the same style as the other vendor docs, using the document’s
existing section structure so it remains consistent and discoverable.
In `@vendors/privacypools.md`:
- Around line 14-19: The privacypools vendor doc is missing the mandatory CROPS
profile section. Update the `vendors/privacypools.md` content by adding a `##
CROPS profile` section with the required table, and keep the existing pattern
links unchanged since they already resolve correctly. Use the existing document
structure in `privacypools.md` to place the new section in the appropriate spot.
In `@vendors/railgun.md`:
- Around line 14-19: Add the missing CROPS profile section to railgun.md using
the vendor template structure, placing the required CROPS table in the
appropriate spot near the existing top-level sections. Keep the surrounding
sections like Fits with patterns intact, and ensure the new section follows the
same heading and table conventions used by other vendor docs so the document
matches the expected template.
In `@vendors/renegade.md`:
- Around line 14-18: The vendor card is missing the required CROPS profile
section, so update the markdown in renegade.md to add a `## CROPS profile` block
that matches the standard vendor template. Use the existing pattern links under
`## Fits with patterns` as context, and ensure the new section includes the
CROPS table content in the expected format so the card conforms to the template.
In `@vendors/taceo-merces.md`:
- Around line 1-3: The TACEO Merces vendor card is missing the required CROPS
profile content and the Ethereum-alignment note is incomplete. Update the
markdown in the vendor document to add the ## CROPS profile section with the
Product | CR | OS | Privacy | Security | Context table, and revise the existing
note so it explicitly states the Ethereum-alignment basis rather than mentioning
only Base and Arc testnets. Refer to the existing heading structure in the
document so the new section is placed consistently.
In `@vendors/zksync.md`:
- Around line 28-29: Fix the typo and grammar in the architecture description
for the ZKsync Gateway sentence: update the misspelled “setllement” to
“settlement” and rewrite the clause around “who ZK commit blocks” to use correct
subject-verb agreement and phrasing. Adjust the text in the ZKsync section so it
reads naturally, using the existing description sentence as the reference point.
- Line 10: The vendor description in the ZKsync card uses promotional
superlative phrasing, so rewrite the copy in vendors/zksync.md to be neutral and
factual. Replace the marketing language in the Prividium description with an
objective summary of its capabilities, while keeping the core references to
ZKsync, enterprise solutions, real-world asset tokenization, private capital
markets, institutional financial infrastructure, and selective disclosure.
---
Outside diff comments:
In `@approaches/approach-private-identity.md`:
- Around line 300-304: Update the wording in the “Technical perspective” section
to remove the uniqueness claim around Issuer-Independent OPRF; in the sentence
in the approach-private-identity discussion that currently says it is “the only
category designed to survive single-issuer failure,” rewrite it in neutral
factual terms or qualify it as one option rather than the sole one. Keep the
rest of the comparison intact and preserve the technical positioning of
Issuer-Independent OPRF, Registry Membership, Document ZK, TLS Transcript
Proofs, On-Chain Attestation, and POD2.
In `@approaches/approach-private-trade-settlement.md`:
- Around line 1-35: Update the frontmatter in approach-private-trade-settlement
so the use_case matches the document’s own topic; replace the current
private-bonds value with private-trade-settlement. Keep the rest of the metadata
unchanged, and verify the related_use_cases and other approach fields still
align with the Private Trade Settlement card.
In `@approaches/approach-white-label-deployment.md`:
- Around line 1-261: The approach card is over the 2000-word limit and needs to
be shortened without losing the core decision guidance. Trim repetitive detail
in the long narrative sections of approach-white-label-deployment.md, especially
the repeated trust/threat/implementation prose under Vendor-Managed Deployment,
Institution-Controlled Deployment, and the Legal & risk/Technical perspective
sections, while preserving the summary, comparison table, and recommendation.
Keep the unique identifying section headers intact so the card remains easy to
scan.
In `@vendors/_template.md`:
- Around line 42-43: The vendor card template is missing the required CROPS
profile section, so restore the `## CROPS profile` table in the template used
for new vendor cards. Update the markdown in the template so it includes the
full evaluation columns for Product, CR, OS, Privacy, Security, and Context,
matching the guidance referenced by the template and the contributing rules. If
CROPS is being removed intentionally, update the path instructions first;
otherwise keep the section in place for consistency with vendor card
requirements.
In `@vendors/fairblock.md`:
- Around line 1-88: The Fairblock vendor doc is missing the required CROPS
profile section at the end of the file. Add a new “## CROPS profile” section
after the Links content in vendors/fairblock.md, and include the required table
with the columns Product, CR, OS, Privacy, Security, and Context, using the
existing Fairblock/FairyRing details from the document.
In `@vendors/fhenix.md`:
- Around line 14-20: The internal pattern references in the Fhenix markdown use
hardcoded GitHub blob URLs, which should be changed to relative links. Update
all pattern links in this section to use relative paths to the corresponding
files under patterns so the references work in forks and local previews without
depending on a specific branch. Keep the link targets consistent across every
occurrence in this file and use the existing pattern filenames as the source of
truth.
- Around line 1-63: The Fhenix vendor card is missing the required CROPS profile
section. Add a "## CROPS profile" table in this document with rows for CR, OS,
Privacy, Security, and Context, matching the existing vendor template and
scoring format used by other vendor profiles. Use the current content in the
vendor card to populate the scores and short justifications, and place the new
section in the standard position alongside the other top-level vendor metadata
sections.
In `@vendors/fireblocks.md`:
- Around line 1-61: The Fireblocks vendor card is missing the required
product-level CROPS profile section from the vendor template. Add a new “##
CROPS profile” section in this document, using the same structure and fields as
vendors/_template.md, and place it in a sensible spot alongside the other
top-level sections such as “What it is” and “Fits with patterns.” Ensure the new
section is complete and consistent with the existing Fireblocks content.
In `@vendors/flashbots.md`:
- Around line 45-65: Add the missing required ## CROPS profile section to the
Flashbots vendor card, using the vendor template in vendors/README.md and the
existing Strengths/Risks structure as a guide; include a table for each product
with CR, OS, Privacy, Security, and Context, and ensure the card is not marked
ready until this section exists. While editing the same card, tone down the
promotional language in the Strengths bullets referenced by the Flashbots
section so terms like “significant adoption,” “strong relationship,” and
“next-generation infrastructure” are replaced with more neutral wording, keeping
the content aligned with the template.
In `@vendors/paladin.md`:
- Around line 1-112: The vendor page is missing the required dedicated Privacy
domains section. Add a new “## Privacy domains” section in paladin.md before “##
Enterprise demand and use cases,” and move or summarize the existing mentions of
Zeto, Noto, and Pente there so the document matches the required headings from
vendors/_template.md.
- Around line 1-112: The Paladin vendor card is missing the required CROPS
profile section, so add a new “## CROPS profile” section in the Paladin markdown
and include the evaluation table for CR, OS, Privacy, Security, and Context.
Place it alongside the existing sections in this vendor doc so the card can be
marked ready; use the current content in vendors/paladin.md to fill the row for
the Paladin entry.
In `@vendors/peer.md`:
- Around line 1-67: Add the missing required Privacy domains section in the Peer
vendor card, using the same style as the existing sections. Place the new ##
Privacy domains heading between the Architecture and Enterprise demand and use
cases sections in vendors/peer.md, and ensure it summarizes the relevant privacy
domains for Peer consistently with the rest of the document.
- Around line 1-67: Restore the missing CROPS profile section in the Peer vendor
card, since `vendors/_template.md` and the vendor path rules require it before
the file can stay ready. Add back the `## CROPS profile` heading and the CROPS
evaluation table in the `Peer` document, keeping the existing vendor summary
intact and making sure the section appears with the rest of the card content.
In `@vendors/soda-labs.md`:
- Line 41: The typo in the Soda Labs description should be corrected in the
Garbled Circuit + ZK phrase. Update the text in the affected markdown entry so
the term is spelled “Circuit” instead of “Cirtcuit,” keeping the rest of the
sentence unchanged.
- Line 32: Fix the typo in the Soda Labs documentation text by updating the
misspelled word in the sentence about Evaluators and garbled circuits;
specifically, correct the wording in the markdown content that contains
“posession” so it reads “possession” while keeping the rest of the paragraph
unchanged.
- Line 59: The wording in the Soda Labs description uses a promotional
superlative (“lowest latency”); update the affected sentence in the markdown
copy to neutral, factual phrasing such as “lower latency” or a clearly qualified
comparison, keeping the rest of the text unchanged.
In `@vendors/tx-shield.md`:
- Around line 6-136: The vendor card in tx-shield.md uses promotional wording
that should be replaced with neutral descriptions, especially in the
Architectural, Enterprise demand, and Strengths sections; update phrases like
“high performance,” “Ideal for,” “delivers institutional-grade,” and “enables
privacy-preserving” in the relevant TX-SHIELD, OpenTMP LLM, and Collab-Key
descriptions. Also verify that a ## CROPS profile section/table exists per the
vendor template, confirm the document stays within the word-count guidance, and
clarify the Ethereum/alignment claim by naming the specific chain(s) for the
on-chain settlement mention.
In `@vendors/zksync.md`:
- Around line 50-53: Revise the bullet list in the vendor description to use
factual, non-promotional wording: remove the superlative from the enterprise
features line, replace the vague “Efficient ZK Proving” phrasing with a neutral
concrete description or drop it, and correct the typo in the interoperability
bullet from “accross” to “across”; update the text where these bullets appear in
the markdown content.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4394ae21-8d62-4e97-8b82-9eb32afcbb8b
⛔ Files ignored due to path filters (2)
weekly-updates/2026-01-16.mdis excluded by!weekly-updates/**weekly-updates/README.mdis excluded by!weekly-updates/**
📒 Files selected for processing (147)
.coderabbit.yaml.github/workflows/audit-check.ymlCHANGELOG.mdCONTRIBUTING.mdQA-AUDIT.mdapproaches/approach-civic-participation.mdapproaches/approach-dvp-atomic-settlement.mdapproaches/approach-private-bonds.mdapproaches/approach-private-broadcasting.mdapproaches/approach-private-derivatives.mdapproaches/approach-private-identity.mdapproaches/approach-private-money-market-funds.mdapproaches/approach-private-payments.mdapproaches/approach-private-trade-settlement.mdapproaches/approach-white-label-deployment.mdjurisdictions/_template.mdjurisdictions/cn-crypto-ban.mdjurisdictions/de-eWpG.mdjurisdictions/eu-MiCA.mdjurisdictions/eu-data-protection.mdjurisdictions/hk-crypto-licensing.mdjurisdictions/int-banking-secrecy.mdjurisdictions/us-SEC.mdpatterns/pattern-blob-anchored-state-with-dispute.mdpatterns/pattern-co-snark.mdpatterns/pattern-commit-and-prove.mdpatterns/pattern-compliance-monitoring.mdpatterns/pattern-cross-chain-privacy-bridge.mdpatterns/pattern-crypto-registry-bridge-ewpg-eas.mdpatterns/pattern-dvp-erc7573.mdpatterns/pattern-eil.mdpatterns/pattern-erc3643-rwa.mdpatterns/pattern-focil-eip7805.mdpatterns/pattern-forced-withdrawal.mdpatterns/pattern-forward-secure-pseudorandom-tree.mdpatterns/pattern-forward-secure-signatures.mdpatterns/pattern-hybrid-public-private-modes.mdpatterns/pattern-icma-bdt-data-model.mdpatterns/pattern-immutable-guarantees.mdpatterns/pattern-l2-encrypted-offchain-audit.mdpatterns/pattern-l2-privacy-evaluation.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-mesh-store-forward-submission.mdpatterns/pattern-mixnet-anonymity.mdpatterns/pattern-modular-privacy-stack.mdpatterns/pattern-mpc-custody.mdpatterns/pattern-native-account-abstraction.mdpatterns/pattern-network-anonymity.mdpatterns/pattern-noir-private-contracts.mdpatterns/pattern-oif.mdpatterns/pattern-onion-routing.mdpatterns/pattern-origin-locked-confidential-ledger.mdpatterns/pattern-permissioned-ledger-interoperability.mdpatterns/pattern-permissionless-spend-auth.mdpatterns/pattern-plasma-stateless-privacy.mdpatterns/pattern-pretrade-privacy-encryption.mdpatterns/pattern-privacy-l2s.mdpatterns/pattern-private-information-retrieval.mdpatterns/pattern-private-iso20022.mdpatterns/pattern-private-mtp-auth.mdpatterns/pattern-private-pvp-stablecoins-erc7573.mdpatterns/pattern-private-set-intersection-circuit.mdpatterns/pattern-private-set-intersection-dh.mdpatterns/pattern-private-set-intersection-fhe.mdpatterns/pattern-private-set-intersection-oprf.mdpatterns/pattern-private-shared-state-cosnark.mdpatterns/pattern-private-shared-state-fhe.mdpatterns/pattern-private-shared-state-tee.mdpatterns/pattern-private-stablecoin-shielded-payments.mdpatterns/pattern-private-transaction-broadcasting.mdpatterns/pattern-private-vaults.mdpatterns/pattern-proof-of-innocence.mdpatterns/pattern-recipient-derived-receive-addresses.mdpatterns/pattern-regulatory-disclosure-keys-proofs.mdpatterns/pattern-relay-mediated-proving.mdpatterns/pattern-safe-proof-delegation.mdpatterns/pattern-shielding.mdpatterns/pattern-social-recovery.mdpatterns/pattern-stealth-addresses.mdpatterns/pattern-tee-based-privacy.mdpatterns/pattern-tee-key-manager.mdpatterns/pattern-tee-network-anonymity.mdpatterns/pattern-tee-zk-settlement.mdpatterns/pattern-threshold-encrypted-mempool.mdpatterns/pattern-tls-payment-bridge.mdpatterns/pattern-user-controlled-viewing-keys.mdpatterns/pattern-verifiable-attestation.mdpatterns/pattern-voprf-nullifiers.mdpatterns/pattern-zk-kyc-ml-id-erc734-735.mdpatterns/pattern-zk-promises.mdpatterns/pattern-zk-proof-systems.mdpatterns/pattern-zk-tls.mdpatterns/pattern-zk-wrappers.mdrfps/rfp-benchmark-dashboard.mdscripts/audit-sync.jsscripts/schemas/use-case.jsonscripts/schemas/vendor.jsonscripts/validate-patterns.jsscripts/weekly-summary.shuse-cases/_template.mduse-cases/private-bonds.mduse-cases/private-commodities.mduse-cases/private-corporate-bonds.mduse-cases/private-derivatives.mduse-cases/private-fx.mduse-cases/private-government-debt.mduse-cases/private-identity.mduse-cases/private-messaging.mduse-cases/private-money-market-funds.mduse-cases/private-oracles.mduse-cases/private-payments.mduse-cases/private-procurement.mduse-cases/private-read.mduse-cases/private-registry.mduse-cases/private-repo.mduse-cases/private-rwa-tokenization.mduse-cases/private-stablecoins.mduse-cases/private-stocks.mduse-cases/private-supply-chain.mduse-cases/private-treasuries.mduse-cases/resilient-civic-participation.mduse-cases/resilient-disbursement-rails.mduse-cases/resilient-identity-continuity.mdvendors/_template.mdvendors/aztec.mdvendors/chainlink-ace.mdvendors/curvy.mdvendors/ey.mdvendors/fairblock.mdvendors/fhenix.mdvendors/fireblocks.mdvendors/flashbots.mdvendors/hinkal.mdvendors/iexec.mdvendors/miden.mdvendors/paladin.mdvendors/peer.mdvendors/privacypools.mdvendors/railgun.mdvendors/renegade.mdvendors/shutter.mdvendors/soda-labs.mdvendors/space-and-time.mdvendors/taceo-merces.mdvendors/tx-shield.mdvendors/zama.mdvendors/zksync.md
💤 Files with no reviewable changes (4)
- patterns/pattern-l2-privacy-evaluation.md
- .coderabbit.yaml
- CONTRIBUTING.md
- scripts/weekly-summary.sh
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CodeRabbit review — triage & fixesPushed ✅ Fixed (62aeb95)
🔧 Config reconciled (62aeb95)
⏸️ Deferred — vendor cards (out of scope this round, tracked in
|
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 (2)
QA-AUDIT.md (1)
177-191: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUpdate the
approach-private-identity.mdtracker note
QA-AUDIT.md:186still says TACEO OPRF was corrected from13-node productiontopublic beta, but the current file sayslive in productionandmaturity: production. Align the row with the current wording.🤖 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 `@QA-AUDIT.md` around lines 177 - 191, Update the tracker note for approach-private-identity.md in QA-AUDIT so it matches the current wording in the source document. The row currently references the old TACEO OPRF phrasing; revise the notes to reflect “live in production” and “maturity: production” instead of “13-node production” to “public beta,” keeping the rest of the review status entry unchanged.scripts/schemas/use-case.json (1)
27-33: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winKeep
secondary_domainaligned with the published use-case template.This schema now permits
secondary_domain: nulland describes the field as optional, but the currentuse-cases/_template.mdcontract still listssecondary_domainas required. Becausescripts/validate-patterns.jscompiles this schema directly, CI will start accepting frontmatter that no longer matches the documented template.If optionality is intentional, update the template/readme in the same PR; otherwise keep this field non-nullable here.
Suggested fix
"secondary_domain": { "oneOf": [ { "type": "string" }, - { "type": "array", "items": { "type": "string" } }, - { "type": "null" } + { "type": "array", "items": { "type": "string" } } ], - "description": "Secondary business domain(s); optional" + "description": "Secondary business domain(s)" },🤖 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 `@scripts/schemas/use-case.json` around lines 27 - 33, The `secondary_domain` field in the `use-case.json` schema is now out of sync with the published template contract. Either make the schema match `use-cases/_template.md` by removing the `null`/optional allowance, or, if optionality is intended, update the template and any README/docs in the same change so `scripts/validate-patterns.js` and the documented frontmatter rules stay aligned. Use the `secondary_domain` schema block and the `use-cases/_template.md` contract as the source of truth when making the fix.Source: Path instructions
🤖 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 `@QA-AUDIT.md`:
- Around line 177-191: Update the tracker note for approach-private-identity.md
in QA-AUDIT so it matches the current wording in the source document. The row
currently references the old TACEO OPRF phrasing; revise the notes to reflect
“live in production” and “maturity: production” instead of “13-node production”
to “public beta,” keeping the rest of the review status entry unchanged.
In `@scripts/schemas/use-case.json`:
- Around line 27-33: The `secondary_domain` field in the `use-case.json` schema
is now out of sync with the published template contract. Either make the schema
match `use-cases/_template.md` by removing the `null`/optional allowance, or, if
optionality is intended, update the template and any README/docs in the same
change so `scripts/validate-patterns.js` and the documented frontmatter rules
stay aligned. Use the `secondary_domain` schema block and the
`use-cases/_template.md` contract as the source of truth when making the fix.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b013a35d-32ca-4d3b-a096-becd5d5c4332
📒 Files selected for processing (11)
.coderabbit.yamlQA-AUDIT.mdapproaches/approach-dvp-atomic-settlement.mdapproaches/approach-private-identity.mdjurisdictions/us-SEC.mdpatterns/pattern-cross-chain-privacy-bridge.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-recipient-derived-receive-addresses.mdscripts/schemas/use-case.jsonuse-cases/private-identity.mduse-cases/resilient-civic-participation.md
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: Validate Documentation Patterns
🧰 Additional context used
📓 Path-based instructions (4)
use-cases/**/*.md
⚙️ CodeRabbit configuration file
use-cases/**/*.md: This is a use case card.Structure & frontmatter: Validate against the template at
use-cases/_template.md.
Rules and scope are inuse-cases/README.md.Check that
primary_domainmatches one of the domains listed indomains/README.md.
Use cases should stay on a single page — flag if the content is excessively long or duplicates linked docs.Warn if section
## 2) Additional Business Contextcontains anything that looks like confidential
information (specific organization names, pilot scopes, committed volumes) — these belong incontext/files.
Files:
use-cases/resilient-civic-participation.mduse-cases/private-identity.md
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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.md
jurisdictions/**/*.md
⚙️ CodeRabbit configuration file
jurisdictions/**/*.md: This is a jurisdiction card.Structure & frontmatter: Validate against the template at
jurisdictions/_template.md.
All required subsections under## Actionable Best Practicesmust be present
(Payments, Trading, Funds & Assets, Custody, Identity & Compliance, Data & Oracles).
Files:
jurisdictions/us-SEC.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-identity.mdapproaches/approach-dvp-atomic-settlement.md
🧠 Learnings (18)
📚 Learning: 2026-04-14T08:10:15.334Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 145
File: use-cases/resilient-identity-continuity.md:26-26
Timestamp: 2026-04-14T08:10:15.334Z
Learning: In ethereum/iptf-map’s `use-cases/` markdown files, the `## 3) Actors` section may use a single-line inline `·`-separated actor list (e.g., `Actor A · Actor B · Actor C`) instead of a bulleted list. If the formatting matches `use-cases/_template.md`, do not flag it as non-compliant.
Applied to files:
use-cases/resilient-civic-participation.mduse-cases/private-identity.md
📚 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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.md
📚 Learning: 2026-05-14T23:07:51.781Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 166
File: patterns/pattern-immutable-guarantees.md:47-110
Timestamp: 2026-05-14T23:07:51.781Z
Learning: When reviewing ethereum/iptf-map “pattern card” Markdown documents, treat the word-count threshold of >800 words as advisory only. Do not raise it as a blocking issue unless the document exceeds the error threshold of >1500 words. In particular, word counts in the 800–1500 range should not be flagged for remediation of the body content.
Applied to files:
patterns/pattern-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.md
📚 Learning: 2026-05-15T20:51:34.203Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 168
File: patterns/pattern-private-information-retrieval.md:36-36
Timestamp: 2026-05-15T20:51:34.203Z
Learning: When reviewing pattern card Markdown files under `patterns/`, do not flag acronyms/abbreviations as “unexpanded” if they are defined in the project’s `Glossary` (e.g., `HNDL` = “Harvest Now, Decrypt Later”). Inline expansion is not required for terms covered by the Glossary.
Applied to files:
patterns/pattern-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.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-recipient-derived-receive-addresses.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-cross-chain-privacy-bridge.md
📚 Learning: 2026-05-06T13:50:53.704Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 160
File: approaches/approach-private-trade-settlement.md:42-62
Timestamp: 2026-05-06T13:50:53.704Z
Learning: For approach Markdown cards using the v2 schema in the ethereum/iptf-map repo, treat the use_case frontmatter slug as the canonical cross-reference to the addressed use case. Do not enforce an in-body markdown link to the use case on v2 approach cards. The in-body link requirement is a v1 convention and should not be applied to v2 cards; this distinction is tracked separately. This pattern applies to all approach Markdown files under approaches/ (e.g., approaches/**/*.md). For the file approaches/approach-private-trade-settlement.md specifically, ensure it adheres to the v2 rule by using the frontmatter use_case reference and omit enforcing in-body use-case links.
Applied to files:
approaches/approach-private-identity.mdapproaches/approach-dvp-atomic-settlement.md
📚 Learning: 2026-05-06T13:50:59.931Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 160
File: approaches/approach-private-money-market-funds.md:1-24
Timestamp: 2026-05-06T13:50:59.931Z
Learning: In iptf-map v2 approach cards, iptf_pocs is for IPTF-internal research prototypes tied to a specific sub-approach, while open_source_implementations is for third-party production-viability signals. Do not flag a missing iptf_pocs block unless an IPTF-internal prototype actually exists for that approach; a sub-approach with maturity: prototyped does not imply an IPTF PoC exists. Reviewers should: (1) verify whether an IPTF-internal prototype exists for the sub-approach in question; (2) if yes, ensure an iptf_pocs block is present and accurately describes it; (3) if no internal prototype exists, do not require an iptf_pocs block. This guideline applies to all approach markdown files under approaches/ in this repository (ethereum/iptf-map).
Applied to files:
approaches/approach-private-identity.mdapproaches/approach-dvp-atomic-settlement.md
📚 Learning: 2026-05-06T13:50:58.986Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 160
File: approaches/approach-private-broadcasting.md:1-26
Timestamp: 2026-05-06T13:50:58.986Z
Learning: Follow the v2 schema for approach cards in approaches/**/*.md. iptf_pocs is strictly for IPTF-internal research prototypes with a matching sub_approach entry; open_source_implementations covers third-party production-viability signals. Do not flag missing iptf_pocs when there is no IPTF-internal prototype for the approach card; the field is optional and must not be fabricated.
Applied to files:
approaches/approach-private-identity.mdapproaches/approach-dvp-atomic-settlement.md
🪛 GitHub Check: vale
patterns/pattern-cross-chain-privacy-bridge.md
[warning] 101-101: [vale] patterns/pattern-cross-chain-privacy-bridge.md#L101
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
QA-AUDIT.md
[warning] 60-60: [vale] QA-AUDIT.md#L60
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 62-62: [vale] QA-AUDIT.md#L62
[IPTF.Terminology] Use 'DvP' instead of 'dvp' for consistency with GLOSSARY.md.
[warning] 62-62: [vale] QA-AUDIT.md#L62
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 65-65: [vale] QA-AUDIT.md#L65
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
🔇 Additional comments (33)
QA-AUDIT.md (10)
1-41: LGTM!
44-55: LGTM!
58-73: LGTM!
74-148: LGTM!
149-176: LGTM!
192-204: LGTM!
205-216: LGTM!
217-247: LGTM!
248-263: LGTM!
264-277: LGTM!patterns/pattern-lean-ethereum.md (3)
3-7: LGTM!
52-52: LGTM!
61-61: LGTM! The previously flagged "eight independent client teams" claim has been replaced with appropriately vague "Multiple independent client teams" wording, avoiding the execution-vs-consensus client overcount issue.patterns/pattern-cross-chain-privacy-bridge.md (3)
3-7: LGTM!
101-101: LGTM! The previously flagged "maximum privacy" marketing language has been corrected to neutral phrasing. The vale warning for "first" is a false positive — it is used sequentially ("first…then"), not promotionally.
112-114: LGTM!patterns/pattern-recipient-derived-receive-addresses.md (2)
3-7: LGTM! The previously flagged missingtypefrontmatter field has been added withtype: standard.
56-63: LGTM!Also applies to: 80-83
use-cases/private-identity.md (2)
2-5: LGTM!
19-19: LGTM! The revised "18M+ verified humans" figure is more precise than the prior "25M+ registrations" claim, correctly distinguishing verified unique humans from raw registrations.use-cases/resilient-civic-participation.md (1)
2-5: LGTM! The previously flagged shortenedprimary_domainhas been corrected to the full canonicalCivic Coordination & Governance.approaches/approach-dvp-atomic-settlement.md (6)
47-47: LGTM! The standard-status wording is now accurate: ERC-6123 as Draft and ERC-3643 as Final.
59-90: LGTM! The HTLC section correctly inverts the timeout ordering to T2 > T1, explicitly calls out the free-option problem, and properly scopes HTLC to cross-chain use. CROPS metadata and narrative are consistent.
125-134: LGTM! Addingpattern-shieldingtouses_patternsaligns with the privacy recommendations in this approach. Verify it appears in the card'sprimary_patternsorsupporting_patternsfront-matter list.
167-181: LGTM! Comparison table aligns with revised HTLC CROPS and privacy/trust descriptions.
182-195: LGTM! Persona perspectives correctly restate single-network atomicity, scope HTLC to cross-chain, and accurately note that privacy requires shielded pools beyond the atomicity mechanism itself.
196-210: LGTM! The Default recommendation correctly shifts to Escrow with Dual Approval. Decision factors properly route Oracle to event-driven triggers and HTLC to cross-chain cases. The hybrid guidance correctly emphasizes shielded-pool privacy and timed unilateral refund fallback.approaches/approach-private-identity.md (5)
3-4: LGTM! Status correctly promoted toreadywith updatedlast_revieweddate.
244-280: LGTM! TACEO status correctly updated to "live in production." Sub-approach YAML block is complete with all required v2 fields. CROPS profile is plausible for issuer-independent threshold OPRF with social recovery exit paths.
300-300: LGTM! Formatting change removes bold emphasis from approach names while preserving factual tone.
314-320: LGTM! "on-chain" hyphenation is correctly applied.Note: Lines 318–320 have three successive sentences beginning with "If". Consider varying the structure for readability, though this is not blocking.
322-325: LGTM! Hybrid guidance appropriately layers approaches and correctly frames coercion-resistance as an open research item.scripts/schemas/use-case.json (1)
13-25: 🗄️ Data Integrity & IntegrationNo change needed The
primary_domainenum matches the list indomains/README.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@coderabbitai review |
✅ Action performedReview finished.
|
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
rymnc
left a comment
rymnc
left a comment
There was a problem hiding this comment.
generally looks good, can you get rid of emdashes please :)
|
Humanizer/style pass notes:
Otherwise LGTM to me. |
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
vendors/shutter.md (2)
7-60: 📐 Maintainability & Code Quality | 🟠 Major | 🏗️ Heavy liftAdd the required
## CROPS profiletable.This vendor card is missing the per-product CROPS evaluation required by the template, so CR / OS / Privacy / Security / Context cannot be audited here. Per the vendor template requirements in
vendors/_template.md.🤖 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/shutter.md` around lines 7 - 60, The Shutter Network vendor card is missing the required CROPS profile section, so add the per-product evaluation table in this document using the same structure as other vendor cards. Update the content around the existing Shutter overview sections to include a clear “## CROPS profile” heading with the CR, OS, Privacy, Security, and Context assessments so it matches the vendor template requirements in vendors/_template.md.Source: Path instructions
11-17: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winKeep
Fits with patternsnames-only and tone factual.
../approaches/approach-private-broadcasting.mdis an approach, not a pattern, and the section should not use markdown links. The rest of the card also reads promotional (prevents MEV extraction,Proven solution,Effective MEV prevention) and should be rewritten as neutral facts. Per the vendor template and house style invendors/_template.mdandvendors/README.md.Also applies to: 30-33, 41-46
🤖 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/shutter.md` around lines 11 - 17, The vendor card text in the Shutter entry is too promotional and the “Fits with patterns” section uses markdown links and includes an approach, not just pattern names. Rewrite the Shutter description in neutral, factual language, remove promotional phrasing, and change “Fits with patterns” to names-only entries that list only valid pattern names without links. Use the Shutter card content plus the vendor template and README guidance to align wording and section style, especially around the patterns list.Source: Path instructions
🤖 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.
Inline comments:
In `@QA-AUDIT.md`:
- Line 68: The vendor CROPS guidance is inconsistent between the audit note and
the repository rule, so future checks may treat a required vendor-card section
as optional. Update the repo instruction in .coderabbit.yaml or revise the
QA-AUDIT.md note so they match, and make sure the vendor-card guidance for CROPS
aligns with the current policy around the CROPS profile section and its table
requirement.
---
Outside diff comments:
In `@vendors/shutter.md`:
- Around line 7-60: The Shutter Network vendor card is missing the required
CROPS profile section, so add the per-product evaluation table in this document
using the same structure as other vendor cards. Update the content around the
existing Shutter overview sections to include a clear “## CROPS profile” heading
with the CR, OS, Privacy, Security, and Context assessments so it matches the
vendor template requirements in vendors/_template.md.
- Around line 11-17: The vendor card text in the Shutter entry is too
promotional and the “Fits with patterns” section uses markdown links and
includes an approach, not just pattern names. Rewrite the Shutter description in
neutral, factual language, remove promotional phrasing, and change “Fits with
patterns” to names-only entries that list only valid pattern names without
links. Use the Shutter card content plus the vendor template and README guidance
to align wording and section style, especially around the patterns list.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b2e820d4-f98c-40eb-8b26-aee7cd5e4ce9
📒 Files selected for processing (21)
QA-AUDIT.mdapproaches/approach-dvp-atomic-settlement.mdapproaches/approach-private-bonds.mdapproaches/approach-private-identity.mdapproaches/approach-private-payments.mdapproaches/approach-white-label-deployment.mdjurisdictions/_template.mdjurisdictions/cn-crypto-ban.mdjurisdictions/de-eWpG.mdjurisdictions/eu-MiCA.mdjurisdictions/eu-data-protection.mdjurisdictions/hk-crypto-licensing.mdjurisdictions/int-banking-secrecy.mdjurisdictions/us-SEC.mdpatterns/pattern-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.mduse-cases/private-rwa-tokenization.mduse-cases/resilient-disbursement-rails.mduse-cases/resilient-identity-continuity.mdvendors/flashbots.mdvendors/shutter.md
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: Validate Documentation Patterns
🧰 Additional context used
📓 Path-based instructions (5)
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.mdapproaches/approach-private-bonds.mdapproaches/approach-private-identity.mdapproaches/approach-white-label-deployment.mdapproaches/approach-dvp-atomic-settlement.md
jurisdictions/**/*.md
⚙️ CodeRabbit configuration file
jurisdictions/**/*.md: This is a jurisdiction card.Structure & frontmatter: Validate against the template at
jurisdictions/_template.md.
All required subsections under## Actionable Best Practicesmust be present
(Payments, Trading, Funds & Assets, Custody, Identity & Compliance, Data & Oracles).
Files:
jurisdictions/eu-MiCA.mdjurisdictions/_template.mdjurisdictions/cn-crypto-ban.mdjurisdictions/us-SEC.mdjurisdictions/de-eWpG.mdjurisdictions/int-banking-secrecy.mdjurisdictions/hk-crypto-licensing.mdjurisdictions/eu-data-protection.md
use-cases/**/*.md
⚙️ CodeRabbit configuration file
use-cases/**/*.md: This is a use case card.Structure & frontmatter: Validate against the template at
use-cases/_template.md.
Rules and scope are inuse-cases/README.md.Check that
primary_domainmatches one of the domains listed indomains/README.md.
Use cases should stay on a single page — flag if the content is excessively long or duplicates linked docs.Warn if section
## 2) Additional Business Contextcontains anything that looks like confidential
information (specific organization names, pilot scopes, committed volumes) — these belong incontext/files.
Files:
use-cases/private-rwa-tokenization.mduse-cases/resilient-identity-continuity.mduse-cases/resilient-disbursement-rails.md
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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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/flashbots.mdvendors/shutter.md
🧠 Learnings (21)
📚 Learning: 2026-05-06T13:50:53.704Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 160
File: approaches/approach-private-trade-settlement.md:42-62
Timestamp: 2026-05-06T13:50:53.704Z
Learning: For approach Markdown cards using the v2 schema in the ethereum/iptf-map repo, treat the use_case frontmatter slug as the canonical cross-reference to the addressed use case. Do not enforce an in-body markdown link to the use case on v2 approach cards. The in-body link requirement is a v1 convention and should not be applied to v2 cards; this distinction is tracked separately. This pattern applies to all approach Markdown files under approaches/ (e.g., approaches/**/*.md). For the file approaches/approach-private-trade-settlement.md specifically, ensure it adheres to the v2 rule by using the frontmatter use_case reference and omit enforcing in-body use-case links.
Applied to files:
approaches/approach-private-payments.mdapproaches/approach-private-bonds.mdapproaches/approach-private-identity.mdapproaches/approach-white-label-deployment.mdapproaches/approach-dvp-atomic-settlement.md
📚 Learning: 2026-05-06T13:50:59.931Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 160
File: approaches/approach-private-money-market-funds.md:1-24
Timestamp: 2026-05-06T13:50:59.931Z
Learning: In iptf-map v2 approach cards, iptf_pocs is for IPTF-internal research prototypes tied to a specific sub-approach, while open_source_implementations is for third-party production-viability signals. Do not flag a missing iptf_pocs block unless an IPTF-internal prototype actually exists for that approach; a sub-approach with maturity: prototyped does not imply an IPTF PoC exists. Reviewers should: (1) verify whether an IPTF-internal prototype exists for the sub-approach in question; (2) if yes, ensure an iptf_pocs block is present and accurately describes it; (3) if no internal prototype exists, do not require an iptf_pocs block. This guideline applies to all approach markdown files under approaches/ in this repository (ethereum/iptf-map).
Applied to files:
approaches/approach-private-payments.mdapproaches/approach-private-bonds.mdapproaches/approach-private-identity.mdapproaches/approach-white-label-deployment.mdapproaches/approach-dvp-atomic-settlement.md
📚 Learning: 2026-05-06T13:50:58.986Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 160
File: approaches/approach-private-broadcasting.md:1-26
Timestamp: 2026-05-06T13:50:58.986Z
Learning: Follow the v2 schema for approach cards in approaches/**/*.md. iptf_pocs is strictly for IPTF-internal research prototypes with a matching sub_approach entry; open_source_implementations covers third-party production-viability signals. Do not flag missing iptf_pocs when there is no IPTF-internal prototype for the approach card; the field is optional and must not be fabricated.
Applied to files:
approaches/approach-private-payments.mdapproaches/approach-private-bonds.mdapproaches/approach-private-identity.mdapproaches/approach-white-label-deployment.mdapproaches/approach-dvp-atomic-settlement.md
📚 Learning: 2026-06-29T17:36:52.262Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 130
File: jurisdictions/_template.md:12-27
Timestamp: 2026-06-29T17:36:52.262Z
Learning: In ethereum/iptf-map, jurisdiction card markdown files under `jurisdictions/**/*.md` should use the shorter developer-oriented template. They should include `## At a Glance` and may include `## What to Watch` plus `## See also`; do not require or enforce the legacy `## Actionable Best Practices` subsections that were removed in favor of `jurisdictions/_template.md`.
Applied to files:
jurisdictions/eu-MiCA.mdjurisdictions/_template.mdjurisdictions/cn-crypto-ban.mdjurisdictions/us-SEC.mdjurisdictions/de-eWpG.mdjurisdictions/int-banking-secrecy.mdjurisdictions/hk-crypto-licensing.mdjurisdictions/eu-data-protection.md
📚 Learning: 2026-06-29T17:37:02.314Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 130
File: jurisdictions/int-banking-secrecy.md:15-30
Timestamp: 2026-06-29T17:37:02.314Z
Learning: For markdown files under `jurisdictions/**/*.md`, use the required developer-oriented documentation structure: include the section `## At a Glance`. Also include `## What to Watch` and `## See also` (recommended). Do not require `## Actionable Best Practices` or its six subsections—these should be omitted unless already present for a specific reason.
Applied to files:
jurisdictions/eu-MiCA.mdjurisdictions/_template.mdjurisdictions/cn-crypto-ban.mdjurisdictions/us-SEC.mdjurisdictions/de-eWpG.mdjurisdictions/int-banking-secrecy.mdjurisdictions/hk-crypto-licensing.mdjurisdictions/eu-data-protection.md
📚 Learning: 2026-06-29T17:37:30.625Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 130
File: jurisdictions/us-SEC.md:0-0
Timestamp: 2026-06-29T17:37:30.625Z
Learning: In `ethereum/iptf-map`, jurisdiction card markdown files under `jurisdictions/**/*.md` must use the newer concise developer-oriented section format: require a `## At a Glance` section, strongly recommend including `## What to Watch` and `## See also`, and stop requiring/reminding the legacy `## Actionable Best Practices` section with its six subsections.
Applied to files:
jurisdictions/eu-MiCA.mdjurisdictions/_template.mdjurisdictions/cn-crypto-ban.mdjurisdictions/us-SEC.mdjurisdictions/de-eWpG.mdjurisdictions/int-banking-secrecy.mdjurisdictions/hk-crypto-licensing.mdjurisdictions/eu-data-protection.md
📚 Learning: 2026-04-14T08:10:15.334Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 145
File: use-cases/resilient-identity-continuity.md:26-26
Timestamp: 2026-04-14T08:10:15.334Z
Learning: In ethereum/iptf-map’s `use-cases/` markdown files, the `## 3) Actors` section may use a single-line inline `·`-separated actor list (e.g., `Actor A · Actor B · Actor C`) instead of a bulleted list. If the formatting matches `use-cases/_template.md`, do not flag it as non-compliant.
Applied to files:
use-cases/private-rwa-tokenization.mduse-cases/resilient-identity-continuity.mduse-cases/resilient-disbursement-rails.md
📚 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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.md
📚 Learning: 2026-05-14T23:07:51.781Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 166
File: patterns/pattern-immutable-guarantees.md:47-110
Timestamp: 2026-05-14T23:07:51.781Z
Learning: When reviewing ethereum/iptf-map “pattern card” Markdown documents, treat the word-count threshold of >800 words as advisory only. Do not raise it as a blocking issue unless the document exceeds the error threshold of >1500 words. In particular, word counts in the 800–1500 range should not be flagged for remediation of the body content.
Applied to files:
patterns/pattern-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.md
📚 Learning: 2026-05-15T20:51:34.203Z
Learnt from: Meyanis95
Repo: ethereum/iptf-map PR: 168
File: patterns/pattern-private-information-retrieval.md:36-36
Timestamp: 2026-05-15T20:51:34.203Z
Learning: When reviewing pattern card Markdown files under `patterns/`, do not flag acronyms/abbreviations as “unexpanded” if they are defined in the project’s `Glossary` (e.g., `HNDL` = “Harvest Now, Decrypt Later”). Inline expansion is not required for terms covered by the Glossary.
Applied to files:
patterns/pattern-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.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-cross-chain-privacy-bridge.mdpatterns/pattern-zk-wrappers.md
🪛 GitHub Check: vale
patterns/pattern-cross-chain-privacy-bridge.md
[warning] 101-101: [vale] patterns/pattern-cross-chain-privacy-bridge.md#L101
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
approaches/approach-private-identity.md
[warning] 310-310: [vale] approaches/approach-private-identity.md#L310
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
QA-AUDIT.md
[warning] 58-58: [vale] QA-AUDIT.md#L58
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 60-60: [vale] QA-AUDIT.md#L60
[IPTF.Terminology] Use 'DvP' instead of 'dvp' for consistency with GLOSSARY.md.
[warning] 60-60: [vale] QA-AUDIT.md#L60
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 63-63: [vale] QA-AUDIT.md#L63
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 83-83: [vale] QA-AUDIT.md#L83
[IPTF.Terminology] Use 'eWpG' instead of 'ewpg' for consistency with GLOSSARY.md.
[warning] 84-84: [vale] QA-AUDIT.md#L84
[IPTF.Terminology] Use 'DvP' instead of 'dvp' for consistency with GLOSSARY.md.
[warning] 84-84: [vale] QA-AUDIT.md#L84
[IPTF.Terminology] Use 'ERC-7573' instead of 'erc7573' for consistency with GLOSSARY.md.
[warning] 86-86: [vale] QA-AUDIT.md#L86
[IPTF.Terminology] Use 'ERC-3643' instead of 'erc3643' for consistency with GLOSSARY.md.
[warning] 115-115: [vale] QA-AUDIT.md#L115
[IPTF.Terminology] Use 'PvP' instead of 'pvp' for consistency with GLOSSARY.md.
[warning] 115-115: [vale] QA-AUDIT.md#L115
[IPTF.Terminology] Use 'ERC-7573' instead of 'erc7573' for consistency with GLOSSARY.md.
[warning] 145-145: [vale] QA-AUDIT.md#L145
[IPTF.Terminology] Use 'zero-knowledge proof' instead of 'zk-proof' for consistency with GLOSSARY.md.
[warning] 182-182: [vale] QA-AUDIT.md#L182
[IPTF.Terminology] Use 'DvP' instead of 'dvp' for consistency with GLOSSARY.md.
[warning] 254-254: [vale] QA-AUDIT.md#L254
[IPTF.Terminology] Use 'ERC-3643' instead of 'ERC3643' for consistency with GLOSSARY.md.
[warning] 259-259: [vale] QA-AUDIT.md#L259
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 276-276: [vale] QA-AUDIT.md#L276
[IPTF.Terminology] Use 'DvP' instead of 'dvp' for consistency with GLOSSARY.md.
[warning] 276-276: [vale] QA-AUDIT.md#L276
[IPTF.Terminology] Use 'DvP' instead of 'dvp' for consistency with GLOSSARY.md.
🪛 LanguageTool
jurisdictions/eu-data-protection.md
[grammar] ~19-~19: Ensure spelling is correct
Context: ...erasure rights and the anonymisation-vs-pseudonymisation line are being actively clarified by th...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
approaches/approach-white-label-deployment.md
[style] ~247-~247: ‘under stress’ might be wordy. Consider a shorter alternative.
Context: ...olution timelines the regulator expects under stress. ## Recommendation ### Default For i...
(EN_WORDINESS_PREMIUM_UNDER_STRESS)
QA-AUDIT.md
[grammar] ~182-~182: Ensure spelling is correct
Context: ...ved + 6123/3643 made optional; FINOS to chatch HTLC repo; added pattern-shielding (inc...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~270-~270: Ensure spelling is correct
Context: ...on` applied consistently? It sits on an offchain pattern with no mainnet usage (mesh) an...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~273-~273: Ensure spelling is correct
Context: ... use-cases but is a Vercel preview URL (linkrot risk). Repoint to a stable/canonical UR...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
approaches/approach-dvp-atomic-settlement.md
[grammar] ~204-~204: Ensure spelling is correct
Context: ...dit access to its evidence trail. HTLC, where used for a cross-chain leg, has a deter...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~204-~204: Use a hyphen to join words.
Context: ...precisely, but it publishes the trade on chain; whether that documentation and di...
(QB_NEW_EN_HYPHEN)
🔇 Additional comments (20)
approaches/approach-private-payments.md (1)
357-357: LGTM!jurisdictions/eu-MiCA.md (1)
15-20: LGTM!jurisdictions/_template.md (1)
12-19: LGTM!use-cases/private-rwa-tokenization.md (1)
17-18: LGTM!vendors/shutter.md (1)
11-11: Verify the Ethereum-aligned vendor scope.The card only documents a Gnosis Chain deployment, with Ethereum support still framed as planned. If this is meant to stay in
vendors/, add the Ethereum-mainnet / production-L2 deployment or the explicit Ethereum-ecosystem benefit that makes it eligible. Per the vendor scope rules invendors/README.md.Also applies to: 36-37
Source: Path instructions
approaches/approach-white-label-deployment.md (1)
243-247: LGTM!patterns/pattern-zk-wrappers.md (1)
37-37: LGTM!jurisdictions/cn-crypto-ban.md (1)
15-19: LGTM!use-cases/resilient-identity-continuity.md (1)
88-88: LGTM!jurisdictions/us-SEC.md (1)
17-27: 📐 Maintainability & Code QualityVerify the legal claims in this summary block.
The GENIUS Act, staking, and generic-listing statements are time-sensitive regulatory facts; please confirm them against current primary sources before merging.
use-cases/resilient-disbursement-rails.md (1)
91-91: LGTM!Also applies to: 107-107
jurisdictions/de-eWpG.md (1)
14-18: LGTM!approaches/approach-dvp-atomic-settlement.md (1)
40-52: LGTM!Also applies to: 57-89, 94-180, 186-232
jurisdictions/int-banking-secrecy.md (1)
15-20: LGTM!patterns/pattern-cross-chain-privacy-bridge.md (1)
101-101: LGTM!approaches/approach-private-bonds.md (1)
233-237: 🎯 Functional CorrectnessVerify the external support claims behind this default.
The recommendation leans on the Railgun volume figure, Paladin coverage, and PoC results across the IPTF implementations. Please confirm those facts still hold or add a source before keeping UTXO Shielded Notes as the default.
vendors/flashbots.md (1)
7-65: 📐 Maintainability & Code Quality | 🏗️ Heavy liftAdd the required
## CROPS profiletable.The vendor template requires product-level CROPS scores, and this rewrite does not include the table. Please add rows for Flashbots Auction and SUAVE before merging.
Source: Path instructions
jurisdictions/hk-crypto-licensing.md (1)
15-20: 📐 Maintainability & Code Quality | ⚡ Quick winUse neutral wording for the regime summary.
“progressive regime” and “APAC institutional crypto hub” read as promotional; describe the licensing path and scope factually instead.
Source: Path instructions
approaches/approach-private-identity.md (1)
308-312: LGTM!Also applies to: 318-324
jurisdictions/eu-data-protection.md (1)
15-26: LGTM!
3 participants
Opening this branch to follow the informal audit of the map, the goal is to make the map both sound and complete.
Audit needs to make sure that:
Process
Claim-and-reveal workflow on QA-AUDIT.md: claim a batch of
pendingfiles (commit + push), review on this branch, fix small issues inline, raise GitHub issues for big ones. See "How the audit works" in the doc.scripts/audit-sync.jskeeps the tracker in sync with the content list on master; CI checks it on every push to this branch.Before merge
scripts/audit-sync.jsand.github/workflows/audit-check.yml(audit scaffolding only)chore:CHANGELOG entry for the auditSummary by CodeRabbit
Documentation
Chores & Quality