Conversation
WalkthroughAdded two new pattern documentation pages (Proof of Innocence; zk-promises) and corresponding entries in Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CHANGELOG.md`:
- Around line 9-10: Update the two changelog entries that currently link to
issue `#123` so they reference the PR number that closes the issue instead;
specifically edit the lines for "feat(pattern):
[zk-promises](patterns/pattern-zk-promises.md)" and "feat(pattern): [Proof of
Innocence](patterns/pattern-proof-of-innocence.md)" to replace "(`#123`)" with the
correct PR reference "(`#NNN`)" pointing to the PR that closes the issue.
🪄 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: ea8df784-8699-40b6-9416-4b0df53aa46f
📒 Files selected for processing (3)
CHANGELOG.mdpatterns/pattern-proof-of-innocence.mdpatterns/pattern-zk-promises.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (2)
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: Entries must go under[Unreleased], include a markdown link to the changed file,
reference the PR number(#NNN), and use a semantic prefix (feat(pattern):,feat(vendor):,fix:,docs:, etc.).
Files:
CHANGELOG.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-proof-of-innocence.mdpatterns/pattern-zk-promises.md
🧠 Learnings (6)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:19-23
Timestamp: 2026-03-20T05:29:10.507Z
Learning: In ethereum/iptf-map pattern reviews, distinguish between **censorship** (operator blocks user inputs from being processed — affects CR score) and **liveness** (operator withholds output after protocol participation — does not directly affect CR score). For garbled-circuit PSI patterns, the garbler withholding the output decoding table is a liveness concern, not censorship; do not flag it as a CR justification gap.
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:51.310Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
📚 Learning: 2026-03-18T09:22:00.023Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
CHANGELOG.md
📚 Learning: 2026-03-19T10:42:51.310Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:51.310Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
Applied to files:
CHANGELOG.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-proof-of-innocence.mdpatterns/pattern-zk-promises.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-proof-of-innocence.mdpatterns/pattern-zk-promises.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-proof-of-innocence.mdpatterns/pattern-zk-promises.md
🪛 GitHub Check: vale
patterns/pattern-proof-of-innocence.md
[warning] 40-40: [vale] patterns/pattern-proof-of-innocence.md#L40
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 41-41: [vale] patterns/pattern-proof-of-innocence.md#L41
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 60-60: [vale] patterns/pattern-proof-of-innocence.md#L60
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
patterns/pattern-zk-promises.md
[warning] 38-38: [vale] patterns/pattern-zk-promises.md#L38
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 44-44: [vale] patterns/pattern-zk-promises.md#L44
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 52-52: [vale] patterns/pattern-zk-promises.md#L52
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 54-54: [vale] patterns/pattern-zk-promises.md#L54
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 63-63: [vale] patterns/pattern-zk-promises.md#L63
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 68-68: [vale] patterns/pattern-zk-promises.md#L68
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
🪛 LanguageTool
patterns/pattern-proof-of-innocence.md
[style] ~40-~40: To form a complete sentence, be sure to include a subject.
Context: ...: flexible, jurisdiction-specific sets. Can be inclusion-based ("only low-risk depo...
(MISSING_IT_THERE)
🔇 Additional comments (8)
patterns/pattern-zk-promises.md (4)
1-27: LGTM: Frontmatter structure.All required fields present, schema-compliant enums, and CROPS profile complete. Filename follows kebab-case pattern naming convention and title is vendor-neutral.
22-26: LGTM: CROPS scores are well-justified.The CROPS profile is plausible:
cr: mediumaccounts for provider's inability to selectively target users,privacy: fullis supported by obliviousness guarantees,os: partialacknowledges production deployment realities, andsecurity: mediumcorrectly notes bulletin board trust assumptions. The I2U context clarification (CR drops if provider controls the only bulletin board) is valuable.Also applies to: 63-63
29-80: LGTM: Structure and content.Pattern follows the template structure (Intent → Ingredients → Protocol → Guarantees → Trade-offs → Example → See also). Protocol section is appropriately high-level (6 steps) without granular implementation details. Post-quantum exposure note at line 64 aligns with CROPS best practices.
Based on learnings: pattern documentation should keep the Protocol section high-level and concise, avoiding granular implementation steps.
1-80: Word count is acceptable (784 words, within the 800-word guideline).patterns/pattern-proof-of-innocence.md (4)
1-27: LGTM: Frontmatter structure.All required fields present and schema-compliant. Pattern name "Proof of Innocence (Association Set Proofs)" is vendor-neutral despite referencing Privacy Pools and Railgun implementations in the body.
22-26: LGTM: CROPS scores appropriately reflect structured disclosure.
privacy: partialis correctly justified because the pattern reveals a compliance signal (clean vs not-proven-clean), not full privacy.cr: mediumappropriately acknowledges that set providers can effectively exclude users. The I2U context note (CR drops if institution mandates single provider) is valuable.Also applies to: 78-78
29-98: LGTM: Structure and dual-variant documentation.Pattern follows the template structure. Documenting both Privacy Pools (withdrawal-time) and Railgun PPOI (deposit-time) variants within a single pattern is appropriate since they share the same cryptographic primitive but differ in timing and proof propagation. Protocol steps remain high-level as expected.
Based on learnings: pattern documentation should keep the Protocol section high-level and concise.
1-98: Word count is compliant. Pattern contains 787 words (excluding frontmatter), which is under the 800-word warning threshold and well within acceptable limits.
- Add zk-promises pattern: stateful anonymous credentials with async callbacks - Add Proof of Innocence pattern: association set membership/exclusion proofs - Address @oskarth review: clarify Privacy Pools and Railgun as separate implementations - Update CHANGELOG Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Meyanis95
force-pushed
the
feat/minimal-disclosure
branch
from
b3faa5e to
1d16c33
Compare
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CHANGELOG.md`:
- Line 12: Update the CHANGELOG entry so the retired document filename uses a
Markdown file link instead of inline code and include the PR reference; replace
`PRD-IPTF-PUBLIC-Q1-2026.md` with a markdown link
[PRD-IPTF-PUBLIC-Q1-2026.md](PRD-IPTF-PUBLIC-Q1-2026.md) and ensure the entry
mentions the PR number (e.g., include
"([`#144`](https://github.com/ethereum/iptf-map/pull/144))") alongside the issue
reference.
In `@patterns/pattern-proof-of-innocence.md`:
- Around line 81-84: Convert the prose paragraph under the Example section into
a 3–5 step bullet flow describing the sequence of actions: (1) user withdraws
from a shielded pool to an institutional exchange, (2) exchange requires proof
of non-association with OFAC-sanctioned addresses, (3) user generates a ZK
exclusion proof against the relevant set, (4) user submits the proof with the
withdrawal, and (5) exchange verifies the proof and accepts the deposit without
learning which deposit or timing details; replace the existing paragraph in the
Example section with these concise bullets.
In `@patterns/pattern-zk-promises.md`:
- Around line 66-69: Replace the current prose Example paragraph in the Example
section with a concise 3–5 bullet step flow that mirrors the template structure:
1) user holds zk-object with compliance state (KYC flag, reputation score), 2)
on transfer the user proves "KYC = valid AND reputation > threshold AND scanned
within 24h", 3) if AML review flags a transaction the compliance team posts a
callback docking reputation, and 4) user ingests the callback before the next
transfer and re-proves the updated state; ensure the bullets mention the key
actions and state transitions (zk-object, proof, callback/docking,
ingestion/re-proof) so the example aligns with the pattern card template.
🪄 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: 8519db47-74a1-4a2c-9a96-add1cfd3afb9
📒 Files selected for processing (3)
CHANGELOG.mdpatterns/pattern-proof-of-innocence.mdpatterns/pattern-zk-promises.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Validate Documentation Patterns
🧰 Additional context used
📓 Path-based instructions (2)
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: Entries must go under[Unreleased], include a markdown link to the changed file,
reference the PR number(#NNN), and use a semantic prefix (feat(pattern):,feat(vendor):,fix:,docs:, etc.).
Files:
CHANGELOG.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-zk-promises.mdpatterns/pattern-proof-of-innocence.md
🧠 Learnings (7)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:19-23
Timestamp: 2026-03-20T05:29:10.507Z
Learning: In ethereum/iptf-map pattern reviews, distinguish between **censorship** (operator blocks user inputs from being processed — affects CR score) and **liveness** (operator withholds output after protocol participation — does not directly affect CR score). For garbled-circuit PSI patterns, the garbler withholding the output decoding table is a liveness concern, not censorship; do not flag it as a CR justification gap.
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:51.310Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
📚 Learning: 2026-03-18T09:22:00.023Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:22:00.023Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
CHANGELOG.md
📚 Learning: 2026-03-19T10:42:51.310Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:51.310Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
Applied to files:
CHANGELOG.md
📚 Learning: 2026-03-20T05:29:10.507Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:19-23
Timestamp: 2026-03-20T05:29:10.507Z
Learning: In ethereum/iptf-map pattern reviews, distinguish between **censorship** (operator blocks user inputs from being processed — affects CR score) and **liveness** (operator withholds output after protocol participation — does not directly affect CR score). For garbled-circuit PSI patterns, the garbler withholding the output decoding table is a liveness concern, not censorship; do not flag it as a CR justification gap.
Applied to files:
CHANGELOG.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-zk-promises.mdpatterns/pattern-proof-of-innocence.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-zk-promises.mdpatterns/pattern-proof-of-innocence.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-zk-promises.mdpatterns/pattern-proof-of-innocence.md
🪛 GitHub Check: vale
patterns/pattern-zk-promises.md
[warning] 7-7: [vale] patterns/pattern-zk-promises.md#L7
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 38-38: [vale] patterns/pattern-zk-promises.md#L38
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 63-63: [vale] patterns/pattern-zk-promises.md#L63
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
🔇 Additional comments (3)
CHANGELOG.md (1)
7-8: Compliant changelog entries.These two entries correctly use
feat(pattern):, link the changed files, and reference PR#132.patterns/pattern-proof-of-innocence.md (1)
1-27: Frontmatter and CROPS block look valid.Required fields are present, naming is compliant, and the CROPS profile is plausible for this trust model.
patterns/pattern-zk-promises.md (1)
1-27: Pattern metadata and CROPS profile are well-formed.Required fields are present, and the CROPS claims are consistent with the documented trust assumptions.
| ### Removed | ||
|
|
||
| - chore: Retire `PRD-IPTF-PUBLIC-Q1-2026.md` — Q1 closed; remaining unfinished items tracked in [#143](https://github.com/ethereum/iptf-map/issues/143) ([#144](https://github.com/ethereum/iptf-map/pull/144)) | ||
| - chore: Retire `PRD-IPTF-PUBLIC-Q1-2026.md` -- Q1 closed; remaining unfinished items tracked in [#143](https://github.com/ethereum/iptf-map/issues/143) ([#144](https://github.com/ethereum/iptf-map/pull/144)) |
There was a problem hiding this comment.
Use a markdown file link for the retired document.
This entry uses inline code for the filename; changelog entries should link changed files with markdown links.
Suggested fix
-- chore: Retire `PRD-IPTF-PUBLIC-Q1-2026.md` -- Q1 closed; remaining unfinished items tracked in [`#143`](https://github.com/ethereum/iptf-map/issues/143) ([`#144`](https://github.com/ethereum/iptf-map/pull/144))
+- chore: Retire [PRD-IPTF-PUBLIC-Q1-2026.md](PRD-IPTF-PUBLIC-Q1-2026.md) -- Q1 closed; remaining unfinished items tracked in [`#143`](https://github.com/ethereum/iptf-map/issues/143) ([`#144`](https://github.com/ethereum/iptf-map/pull/144))As per coding guidelines, CHANGELOG entries must include a markdown link to the changed file and reference the PR number.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - chore: Retire `PRD-IPTF-PUBLIC-Q1-2026.md` -- Q1 closed; remaining unfinished items tracked in [#143](https://github.com/ethereum/iptf-map/issues/143) ([#144](https://github.com/ethereum/iptf-map/pull/144)) | |
| - chore: Retire [PRD-IPTF-PUBLIC-Q1-2026.md](PRD-IPTF-PUBLIC-Q1-2026.md) -- Q1 closed; remaining unfinished items tracked in [`#143`](https://github.com/ethereum/iptf-map/issues/143) ([`#144`](https://github.com/ethereum/iptf-map/pull/144)) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CHANGELOG.md` at line 12, Update the CHANGELOG entry so the retired document
filename uses a Markdown file link instead of inline code and include the PR
reference; replace `PRD-IPTF-PUBLIC-Q1-2026.md` with a markdown link
[PRD-IPTF-PUBLIC-Q1-2026.md](PRD-IPTF-PUBLIC-Q1-2026.md) and ensure the entry
mentions the PR number (e.g., include
"([`#144`](https://github.com/ethereum/iptf-map/pull/144))") alongside the issue
reference.
| ## Example | ||
|
|
||
| A user withdraws from a shielded pool to an institutional exchange. The exchange requires proof of non-association with OFAC-sanctioned addresses. The user generates a ZK exclusion proof against the relevant set and submits it with the withdrawal. The exchange verifies the proof, accepts the deposit, and never learns which deposit the user made or when. | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Convert Example into a 3–5 bullet flow.
The template expects an explicit bullet flow for the example section; this is currently a prose paragraph.
Suggested structure
## Example
-A user withdraws from a shielded pool to an institutional exchange. The exchange requires proof of non-association with OFAC-sanctioned addresses. The user generates a ZK exclusion proof against the relevant set and submits it with the withdrawal. The exchange verifies the proof, accepts the deposit, and never learns which deposit the user made or when.
+- User withdraws from a shielded pool to an institutional exchange.
+- The exchange requests proof of non-association with sanctioned addresses.
+- The user generates a ZK exclusion proof against the selected association set.
+- The exchange verifies the proof and accepts the deposit without learning deposit linkage.As per coding guidelines, pattern cards should include a 3–5 bullet Example flow in the template structure.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@patterns/pattern-proof-of-innocence.md` around lines 81 - 84, Convert the
prose paragraph under the Example section into a 3–5 step bullet flow describing
the sequence of actions: (1) user withdraws from a shielded pool to an
institutional exchange, (2) exchange requires proof of non-association with
OFAC-sanctioned addresses, (3) user generates a ZK exclusion proof against the
relevant set, (4) user submits the proof with the withdrawal, and (5) exchange
verifies the proof and accepts the deposit without learning which deposit or
timing details; replace the existing paragraph in the Example section with these
concise bullets.
| ## Example | ||
|
|
||
| An institutional stablecoin platform allows anonymous transfers. Users hold zk-objects with compliance state (KYC-valid flag, AML reputation score). On each transfer, the user proves: "KYC flag = valid AND reputation > threshold AND scanned within 24h." If a post-hoc AML review flags a transaction, the compliance team posts a callback docking the user's reputation. The user ingests the callback before the next transfer. The platform never learns which user was flagged; it verifies solely that the user's updated state still passes the predicates. | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Use bullet steps for the Example section.
Template alignment is missing here; convert the prose example into a 3–5 bullet sequence.
Suggested structure
## Example
-An institutional stablecoin platform allows anonymous transfers. Users hold zk-objects with compliance state (KYC-valid flag, AML reputation score). On each transfer, the user proves: "KYC flag = valid AND reputation > threshold AND scanned within 24h." If a post-hoc AML review flags a transaction, the compliance team posts a callback docking the user's reputation. The user ingests the callback before the next transfer. The platform never learns which user was flagged; it verifies solely that the user's updated state still passes the predicates.
+- User maintains a local zk-object with compliance state (e.g., KYC-valid, AML score).
+- Before each transfer, user proves required predicates over current state.
+- If post-hoc review detects risk, compliance posts an encrypted callback ticket.
+- User ingests the callback locally and updates commitment before next interaction.
+- Platform verifies predicate satisfaction without learning user identity or raw state.As per coding guidelines, pattern cards should include a 3–5 bullet Example flow in the template structure.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@patterns/pattern-zk-promises.md` around lines 66 - 69, Replace the current
prose Example paragraph in the Example section with a concise 3–5 bullet step
flow that mirrors the template structure: 1) user holds zk-object with
compliance state (KYC flag, reputation score), 2) on transfer the user proves
"KYC = valid AND reputation > threshold AND scanned within 24h", 3) if AML
review flags a transaction the compliance team posts a callback docking
reputation, and 4) user ingests the callback before the next transfer and
re-proves the updated state; ensure the bullets mention the key actions and
state transitions (zk-object, proof, callback/docking, ingestion/re-proof) so
the example aligns with the pattern card template.
2 participants
Summary
issue #123 was rescoped. The two supporting patterns are the deliverables; minimum-necessary-disclosure is deferred to approach-level work.
Test plan
npm run validatepasses (no new errors)npm run check-termsclean for new filesCloses #123
Summary by CodeRabbit