feat(patterns): migrate batch 2 (29 cards) to schema v2

[Meyanis95]

Third of 3 PRs for #150. Ports the remaining 29 pattern cards to the v2 shape introduced in #152. Stacked on #154.

Scope

This PR ports 29 pattern cards to the v2 template.

Pattern cards in scope (final state):
private-mtp-auth, private-pvp-stablecoins-erc7573, private-set-intersection-circuit, private-set-intersection-dh, private-set-intersection-fhe, private-set-intersection-oprf, private-shared-state-cosnark, private-shared-state-fhe, private-shared-state-tee, private-stablecoin-shielded-payments, private-transaction-broadcasting, private-vaults, proof-of-innocence, regulatory-disclosure-keys-proofs, safe-proof-delegation, stealth-addresses, tee-based-privacy, tee-key-manager, tee-network-anonymity, tee-zk-settlement, threshold-encrypted-mempool, tls-payment-bridge, user-controlled-viewing-keys, verifiable-attestation, voprf-nullifiers, zk-kyc-ml-id-erc734-735, zk-promises, zk-proof-systems, zk-tls.

Review categories in scope:

• v2 schema/frontmatter conformity (maturity enum, CROPS field rename, context_differentiation, no ad-hoc keys)
• v2 structural rules (Components/Protocol/Guarantees, See also vs related_patterns, vendor-neutral titles, Protocol step granularity)
• File-naming and CHANGELOG hygiene

Out of scope (handled in audit PR #130):

• CROPS score plausibility
• Prose/tone lint (promotional wording, sentence-level fragments)
• Content correctness (threat-model, recovery-path, governance)
• Non-pattern files

CodeRabbit: please limit findings on this PR to the listed pattern files and the in-scope categories above.

Summary by CodeRabbit

• New Features

  • Added L2 Privacy Evaluation Framework for comparing privacy layer capabilities and performance metrics

• Documentation

  • Renamed "Private Contract DSL" pattern to "Noir Private Contracts" for clarity
  • Standardized pattern documentation structure for improved consistency and readability
  • Enhanced pattern guidance with clearer intent, components, and threat model descriptions
  • Updated pattern maturity levels and risk assessments across the portfolio

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)

• master

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2f5d85f4-3d74-4503-a0aa-47e3363151ff

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/pattern-v2-migration-batch2

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Meyanis95]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 21

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

patterns/pattern-co-snark.md (1)

24-33: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Verify privacy score accounts for metadata leakage.

The pattern claims p: full while explicitly noting that "metadata about who requested a proof, when, and against which circuit can still leak." If metadata about requester identity and timing is observable by the operator, confirm that "full" privacy is the intended CROPS score rather than partial.

The CROPS rubric in CONTRIBUTING.md defines Privacy (P) as matching "who sees what"—if the operator observes request metadata (even without seeing witness content), this typically warrants partial rather than full in patterns where metadata protection matters.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@patterns/pattern-co-snark.md` around lines 24 - 33, The privacy score
currently set as "p: full" in the crops_context block is inconsistent with the
text noting metadata leakage; update the CROPS privacy value to "p: partial" (or
add an inline justification comment) and adjust the explanatory sentence under
crops_context (the line mentioning "Metadata about who requested a proof, when,
and against which circuit can still leak.") to clearly state that
operator-observable request metadata reduces privacy to partial per the CROPS
rubric (see CONTRIBUTING.md) so the pattern's declared privacy score matches the
documented leakage.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@patterns/pattern-dvp-erc7573.md`:
- Line 119: The internal repository link "[Private Trade Settlement
approach](../approaches/approach-private-trade-settlement.md)" should not live
under the "## See also" section (reserved for external refs); remove that line
from the "## See also" block and instead add the internal cross-reference using
the v2 structured/internal cross-link field used by this template (e.g., the
pattern's related/implements/see_also_v2 front-matter or dedicated "Related
patterns/approaches" field), keeping "## See also" external-only.

In `@patterns/pattern-eil.md`:
- Line 8: The frontmatter in patterns/pattern-eil.md contains a non-standard key
"rollout-plan"; remove this key from the YAML frontmatter so the file conforms
to the v2 pattern schema (per patterns/_template.md and
scripts/schemas/pattern.json). Locate the frontmatter block in
patterns/pattern-eil.md, delete the "rollout-plan: ready to be integrated in
wallets" line, and ensure no other ad-hoc keys remain so the file validates
against the v2 schema.

In `@patterns/pattern-focil-eip7805.md`:
- Line 8: Remove the ad-hoc frontmatter key "rollout-plan" from the YAML
frontmatter block in patterns/pattern-focil-eip7805.md (the top-of-file
frontmatter where keys like title, status, tags live) and relocate its content
into the document body — e.g., add a short paragraph under an existing section
such as "Trade-offs/Notes" or use an existing schema field instead; ensure the
frontmatter matches the template keys in patterns/_template.md and that no
non-template keys remain.

In `@patterns/pattern-icma-bdt-data-model.md`:
- Around line 20-27: The CROPS privacy score in the header (the token "p: full")
is inconsistent with the pattern's description; change the header privacy score
to "p: none" and update the crops_context.p text to clearly state that this
pattern is structural (schema-only), does not provide data privacy protections,
and relies on off-chain controls and hash anchoring rather than exposing
participant data protection—ensure the symbol "p: full" is replaced with "p:
none" and that the existing crops_context.p sentence reflects this downgrade so
the header and crops_context.p are aligned.

In `@patterns/pattern-l2-privacy-evaluation.md`:
- Around line 152-154: The "## See also" section in
pattern-l2-privacy-evaluation.md contains internal cross-doc links
(../rfps/rfp-benchmark-dashboard.md and ../domains/post-quantum.md); remove
those internal links from the "## See also" list and instead add them to the
document's related_patterns/frontmatter or a dedicated "Related patterns"
section, leaving only external references like L2Beat in "## See also"; update
the frontmatter key related_patterns (or create a short internal links list) to
include rfp-benchmark-dashboard and post-quantum so internal cross-links are
preserved outside the external-only See also block.

In `@patterns/pattern-native-account-abstraction.md`:
- Line 98: The "See also" section in
patterns/pattern-native-account-abstraction.md contains an internal repo link
"../domains/post-quantum.md" which violates the rule that "See also" must only
include external references; remove that internal link from the "## See also"
block and instead add it under the pattern's related_patterns (or
related_patterns field) as an internal cross-reference; update the section
containing "## See also" and the related_patterns list accordingly so internal
docs are no longer present in "See also".
- Around line 64-67: The Protocol section only has 4 numbered steps but must
have 5–8; split one of the existing steps into smaller lifecycle actions so
there are 5–8 steps and keep actor prefixes in brackets. For example, split step
2 into (a) a validation phase where `[contract]` executes `VERIFY` frames as
static calls and records each frame's `APPROVE` scope, and (b) an approval check
phase where `[contract]` ensures at least one frame approved payment (reject if
none). Alternatively add an explicit signature/nonce/replay-protection or
post-validation execution step between validation and charging to meet the
required granularity; keep references to `VERIFY`, `APPROVE`, `SENDER`-mode, and
`DEFAULT`-mode frames and ensure each new step has an actor prefix.

In `@patterns/pattern-network-anonymity.md`:
- Around line 103-104: The "## See also" section currently contains internal
cross-pattern links (pattern-modular-privacy-stack.md and
../rfps/rfp-private-reads.md); move those two links out of the "## See also"
section and add them to the pattern's related_patterns block instead, ensuring
related_patterns includes entries referencing pattern-modular-privacy-stack.md
and ../rfps/rfp-private-reads.md and that "## See also" contains only external
references going forward.

In `@patterns/pattern-onion-routing.md`:
- Line 111: The "See also" section contains an internal pattern link to
pattern-network-anonymity.md which is a duplicate of the existing
related_patterns frontmatter entry; remove the internal pattern-to-pattern link
line from the "## See also" section in patterns/pattern-onion-routing.md so only
external references remain, and rely on the related_patterns frontmatter (see
the related_patterns/see_also entries) for internal cross-references.

In `@patterns/pattern-private-mtp-auth.md`:
- Around line 22-33: The CROPS scores are inconsistent: update the crops_profile
'o' value from yes to no (or a more accurate value) and adjust crops_context:o
to state that institutional registries and KYC backends are proprietary and
therefore the pattern is not fully forkable; alternatively, if you can provide
open-source reference implementations, keep 'o: yes' but revise crops_context:o
to cite those implementations and add them to the open_source_implementations
list and ensure the "Off-chain KYC process" required component is labeled as
proprietary or linked to the OSS reference implementation accordingly.

In `@patterns/pattern-private-shared-state-cosnark.md`:
- Around line 26-33: The privacy score claims "p: full" in crops_context while
the text acknowledges metadata leakage; change the CROPS privacy grading for
this pattern (pattern-private-shared-state-cosnark / crops_context) to
explicitly reflect metadata exposure—either set p: partial (or p: medium) or add
an explicit caveat field stating "metadata visibility excluded from 'full'
rating" and update any CROPS scoring logic/docs that compute privacy from p to
treat metadata as a separate metric (mirror the approach used for
pattern-co-snark) so the score accurately reflects operator-observable metadata
leakage.

In `@patterns/pattern-private-shared-state-fhe.md`:
- Around line 26-33: The privacy score claim (`p: full`) in the crops_context
block conflicts with the noted on-chain metadata leakage; update either the
repository's CROPS Privacy definition to explicitly scope privacy to transaction
payloads only or change the pattern's privacy field from `p: full` to `p:
partial` (or an appropriate level) and add a short clarification sentence in the
crops_context `p:` entry explaining that plaintext remains hidden but on-chain
metadata (callers, timing) is exposed; edit the crops_context block and the
CROPS Privacy definition doc/section accordingly so the terminology and score
align.

In `@patterns/pattern-private-stablecoin-shielded-payments.md`:
- Around line 38-43: Remove the ad-hoc top-level frontmatter key "visibility"
from the v2 pattern card and relocate its contents into the document body (for
example under the "Guarantees" or "Trade-offs" section) or delete them; ensure
the card only uses standardized metadata per patterns/_template.md and update
any references to the "visibility" key so they instead point to the new prose
location.

In `@patterns/pattern-private-transaction-broadcasting.md`:
- Line 70: Remove the inline link to pattern-threshold-encrypted-mempool.md from
the Protocol narrative sentence and replace it with plain text (e.g., "the
threshold-encrypted variant is documented separately in
pattern-threshold-encrypted-mempool"), leaving cross-references only in the
related_patterns section (already present in the related_patterns entries
referenced around Lines 42-45); ensure the sentence in the Protocol narrative
contains no markdown link markup and that related_patterns remains the sole
place for pattern-to-pattern linking.

In `@patterns/pattern-proof-of-innocence.md`:
- Around line 123-124: In the "## See also" section of the
pattern-proof-of-innocence.md file remove the vendor links shown as "- [Privacy
Pools](../vendors/privacypools.md)" and "- [Railgun](../vendors/railgun.md) so
that "See also" contains only external references; locate the "## See also"
header and delete those two list items (or replace them with appropriate
external paper/blog/spec links) ensuring vendor references remain only in vendor
notes or vendor-to-pattern pages.

In `@patterns/pattern-safe-proof-delegation.md`:
- Around line 93-94: The sentence in the "Liveness depends on the prover" bullet
conflicts with the pattern's "works-best-when" premise that clients cannot
generate ZK proofs locally; remove the suggestion "move to client-side proving"
or replace it with a conditional note that client-side proving is only a
fallback if device constraints change or a capable client is available; update
the "Liveness depends on the prover" bullet (and any mention of "client-side
proving") so it aligns with the "works-best-when" constraint and explicitly
references the conditional nature when applicable.
- Around line 41-45: The YAML frontmatter lists "pattern-co-snark" in both
composes_with and alternative_to causing a semantic conflict; edit the
related_patterns block in the file to remove "pattern-co-snark" from the
composes_with array and keep it only in alternative_to (i.e., update the
composes_with value that currently includes pattern-co-snark so that it only
contains [pattern-permissionless-spend-auth, pattern-tee-based-privacy]),
leaving requires and see_also unchanged.

In `@patterns/pattern-stealth-addresses.md`:
- Around line 101-103: The "See also" section in
patterns/pattern-stealth-addresses.md currently contains an internal repo link
"../vendors/curvy.md" which violates the guideline that "## See also" must
contain external references only; remove that internal link (or replace it with
a publicly accessible external URL for Curvy if one exists) so the list only
contains external links like the EIP-5564 and Vitalik references, and ensure
formatting/punctuation remains consistent in the updated "See also" block.

In `@patterns/pattern-tee-based-privacy.md`:
- Line 126: Update the sentence that reads "Lifecycle: hardware security erodes
as attacks improve, so migration paths must be planned in advance." by removing
the redundant "in advance" and changing it to "migration paths must be planned"
(i.e., "Lifecycle: hardware security erodes as attacks improve, so migration
paths must be planned.") to simplify wording while preserving meaning.

In `@patterns/pattern-zk-kyc-ml-id-erc734-735.md`:
- Line 2: The title uses vendor-specific branding "ONCHAINID"; update the
pattern title string to a vendor-neutral term (e.g., replace "ONCHAINID" with
"on-chain identity" or "On-Chain Identity (ERC-734/735)") so it reads something
like "Pattern: zk-KYC/ML + On-Chain Identity (ERC-734/735) — modify the title
literal in the file where the current title value "Pattern: zk-KYC/ML +
ONCHAINID (ERC-734/735)" appears.

In `@patterns/pattern-zk-promises.md`:
- Around line 23-34: The CROPS privacy score entry 'p: full' conflicts with the
statement "A temporary linkability window exists while a callback ticket is
active."; update the document so the privacy score matches reality by either
lowering 'p' to 'high' or 'medium' depending on severity and frequency of the
temporary linkability, or alternatively reword the sentence about the callback
ticket to clearly state it is a metadata/timing issue outside cryptographic
guarantees; make the change near the 'p: full' line and the exact sentence "A
temporary linkability window exists while a callback ticket is active." to keep
the document consistent.

---

Outside diff comments:
In `@patterns/pattern-co-snark.md`:
- Around line 24-33: The privacy score currently set as "p: full" in the
crops_context block is inconsistent with the text noting metadata leakage;
update the CROPS privacy value to "p: partial" (or add an inline justification
comment) and adjust the explanatory sentence under crops_context (the line
mentioning "Metadata about who requested a proof, when, and against which
circuit can still leak.") to clearly state that operator-observable request
metadata reduces privacy to partial per the CROPS rubric (see CONTRIBUTING.md)
so the pattern's declared privacy score matches the documented leakage.

🪄 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: c3e840a6-ff51-4a34-89e1-e7f8af261fe9

📥 Commits

Reviewing files that changed from the base of the PR and between 93991ae and 5912876.

📒 Files selected for processing (58)

• CHANGELOG.md
• approaches/approach-private-identity.md
• domains/post-quantum.md
• patterns/pattern-co-snark.md
• patterns/pattern-compliance-monitoring.md
• patterns/pattern-cross-chain-privacy-bridge.md
• patterns/pattern-dvp-erc7573.md
• patterns/pattern-eil.md
• patterns/pattern-focil-eip7805.md
• patterns/pattern-forced-withdrawal.md
• patterns/pattern-hybrid-public-private-modes.md
• patterns/pattern-icma-bdt-data-model.md
• patterns/pattern-l2-encrypted-offchain-audit.md
• patterns/pattern-l2-privacy-evaluation.md
• patterns/pattern-lean-ethereum.md
• patterns/pattern-mixnet-anonymity.md
• patterns/pattern-modular-privacy-stack.md
• patterns/pattern-mpc-custody.md
• patterns/pattern-native-account-abstraction.md
• patterns/pattern-network-anonymity.md
• patterns/pattern-noir-private-contracts.md
• patterns/pattern-oif.md
• patterns/pattern-onion-routing.md
• patterns/pattern-permissioned-ledger-interoperability.md
• patterns/pattern-permissionless-spend-auth.md
• patterns/pattern-plasma-stateless-privacy.md
• patterns/pattern-privacy-l2s.md
• patterns/pattern-private-mtp-auth.md
• patterns/pattern-private-pvp-stablecoins-erc7573.md
• patterns/pattern-private-set-intersection-circuit.md
• patterns/pattern-private-set-intersection-dh.md
• patterns/pattern-private-set-intersection-fhe.md
• patterns/pattern-private-set-intersection-oprf.md
• patterns/pattern-private-shared-state-cosnark.md
• patterns/pattern-private-shared-state-fhe.md
• patterns/pattern-private-shared-state-tee.md
• patterns/pattern-private-stablecoin-shielded-payments.md
• patterns/pattern-private-transaction-broadcasting.md
• patterns/pattern-private-vaults.md
• patterns/pattern-proof-of-innocence.md
• patterns/pattern-regulatory-disclosure-keys-proofs.md
• patterns/pattern-safe-proof-delegation.md
• patterns/pattern-stealth-addresses.md
• patterns/pattern-tee-based-privacy.md
• patterns/pattern-tee-key-manager.md
• patterns/pattern-tee-network-anonymity.md
• patterns/pattern-tee-zk-settlement.md
• patterns/pattern-threshold-encrypted-mempool.md
• patterns/pattern-tls-payment-bridge.md
• patterns/pattern-user-controlled-viewing-keys.md
• patterns/pattern-verifiable-attestation.md
• patterns/pattern-voprf-nullifiers.md
• patterns/pattern-zk-kyc-ml-id-erc734-735.md
• patterns/pattern-zk-promises.md
• patterns/pattern-zk-proof-systems.md
• patterns/pattern-zk-tls.md
• rfps/rfp-benchmark-dashboard.md
• vendors/aztec.md

[oskarth]

A lot to review but generally LGTM, direction makes sense