fix(ci): stabilize markdown link checks#163
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughCI markdown-link-check config expanded (ignorePatterns + HTTP 202) and workflows pinned/updated to v6 with NODE_OPTIONS. Pattern and cross-document references canonicalized or corrected: ERC-7573 → ercs.ethereum.org, Noir links generalized, "L1 ZK Commitment Pool" replaced with "Shielding", Fireblocks link fixes, Miden link removed, and CHANGELOG updated. ChangesLink-Check and Documentation Maintenance
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRsSuggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
vendors/paladin.md (1)
1-112:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftAdd missing CROPS profile section.
Vendor cards must include a
## CROPS profilesection with a table evaluating each product against the rubrics inCONTRIBUTING.md § CROPS Evaluation. The table should include columns: Product | CR | OS | Privacy | Security | Context.Paladin references three products (Zeto, Noto, Pente) that require individual CROPS evaluation. The Security column should assess audit status, upgrade key controls, admin key scope, incident history, and bug bounty program.
🤖 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, Add a new "## CROPS profile" section to the Paladin vendor card that contains a CROPS evaluation table with columns "Product | CR | OS | Privacy | Security | Context" and one row for each referenced product: Zeto, Noto, and Pente; fill CR (completeness/resilience), OS (open-source status/license), Privacy (data confidentiality/anonymity model and threat surface), Context (intended deployment/use-cases and assumptions), and a detailed Security cell assessing audit status, upgrade key controls, admin key scope, incident history, and whether a bug bounty program exists for each product (Zeto, Noto, Pente). Ensure the new header is exactly "## CROPS profile" and that product names match the existing mentions (Zeto, Noto, Pente) so reviewers can cross-reference the rest of the document.vendors/ey.md (1)
1-135:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftAdd missing
## CROPS profilesection (CRITICAL).Vendor cards must include a
## CROPS profilesection with a table evaluating each product. The table format is:| Product | CR | OS | Privacy | Security | Context | |---------|----|----|---------|----------|---------| | [Product name] | high\|medium\|low\|negative | yes\|partial\|no | high\|medium\|low | high\|medium\|low | i2i\|i2u\|both |This card describes two products (Nightfall v4 and Starlight). Each requires its own CROPS evaluation row, validated against the rubrics in
CONTRIBUTING.md § CROPS Evaluation. For Starlight in particular, the Security score should account for the absence of a security audit and experimental/prototype status.🤖 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/ey.md` around lines 1 - 135, Add a new "## CROPS profile" section containing the required markdown table and one row per product (Nightfall v4 and Starlight). For Nightfall v4, assess CR/OS/Privacy/Security/Context per CONTRIBUTING.md (suggest CR=high, OS=partial, Privacy=high, Security=medium, Context=both); for Starlight set Security=low (explicitly note experimental/no audit), and pick CR/OS/Privacy/Context consistent with the doc (suggest CR=medium, OS=partial, Privacy=medium, Context=both). Ensure table headings exactly match the specified format and values follow the allowed enums so the table validates against the CROPS rubrics.
🤖 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/ci.yml:
- Around line 16-19: Replace floating action tags with their immutable commit
SHAs for all uses: directives referenced (e.g., actions/checkout@v6,
actions/setup-node@v6, and other floating uses like actions/setup-python@v4 or
community actions seen in ci.yml and link-check-full.yml); find each occurrence
of a "uses: <owner>/<repo>@<tag>" and update the tag to the corresponding full
commit SHA (obtain the exact SHA from the action repo release or git history)
and commit the change, and add a short comment or reference in the workflow
noting the original tag (for automated tooling) so future Dependabot/renovate
can update SHAs centrally.
In `@CHANGELOG.md`:
- Line 66: Don't modify the existing 0.3.0 release entry; instead add a new line
under the [Unreleased] section that logs PR `#163` using a semantic prefix (docs:
or fix:) and a proper markdown link to the changed file (e.g.
[approach-privacy-standards-survey.md](path/to/approach-privacy-standards-survey.md));
ensure the entry follows the pattern "docs(<scope>): <description>
([`#163`](...))" or "fix: ..." and includes the PR number and markdown link to the
file, leaving the released entry exactly as-is.
In `@domains/funds-assets.md`:
- Around line 18-19: The "Shortest-path patterns" list contains a duplicate link
to ../patterns/pattern-shielding.md shown as "Confidential ERC-20 on privacy L2
(FHE) + ERC-7573" and "Shielding"; remove one of these duplicate lines (or if
they are intended to be different, update the display text so each link uniquely
describes a different target) by editing the two entries in
domains/funds-assets.md that reference ../patterns/pattern-shielding.md.
In `@patterns/pattern-private-pvp-stablecoins-erc7573.md`:
- Around line 42-45: Update the open_source_implementations entry for ERC-7573:
replace the current description string ("ERC-7573 reference escrow contracts for
atomic asset transfer") with the corrected text "ERC-7573 specification for
conditional-upon-transfer-decryption asset escrow"; ensure the entry still
references the same url and retain language: Solidity, and keep mention of
ERC-7573 and related interface names (ILockingContract, IDecryptionContract) if
used elsewhere for clarity.
In `@vendors/fireblocks.md`:
- Line 15: Replace the visible label "DvP ERC7573" in vendors/fireblocks.md with
the normalized term "DvP ERC-7573" so the markdown link text uses the
repository's standard naming; update the string "DvP ERC7573" to "DvP ERC-7573"
while leaving the link target unchanged.
---
Outside diff comments:
In `@vendors/ey.md`:
- Around line 1-135: Add a new "## CROPS profile" section containing the
required markdown table and one row per product (Nightfall v4 and Starlight).
For Nightfall v4, assess CR/OS/Privacy/Security/Context per CONTRIBUTING.md
(suggest CR=high, OS=partial, Privacy=high, Security=medium, Context=both); for
Starlight set Security=low (explicitly note experimental/no audit), and pick
CR/OS/Privacy/Context consistent with the doc (suggest CR=medium, OS=partial,
Privacy=medium, Context=both). Ensure table headings exactly match the specified
format and values follow the allowed enums so the table validates against the
CROPS rubrics.
In `@vendors/paladin.md`:
- Around line 1-112: Add a new "## CROPS profile" section to the Paladin vendor
card that contains a CROPS evaluation table with columns "Product | CR | OS |
Privacy | Security | Context" and one row for each referenced product: Zeto,
Noto, and Pente; fill CR (completeness/resilience), OS (open-source
status/license), Privacy (data confidentiality/anonymity model and threat
surface), Context (intended deployment/use-cases and assumptions), and a
detailed Security cell assessing audit status, upgrade key controls, admin key
scope, incident history, and whether a bug bounty program exists for each
product (Zeto, Noto, Pente). Ensure the new header is exactly "## CROPS profile"
and that product names match the existing mentions (Zeto, Noto, Pente) so
reviewers can cross-reference the rest of the document.
🪄 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: 9c1cfc66-8b20-4ba5-8da0-40e833c60acb
📒 Files selected for processing (13)
.github/markdown-link-check-config.json.github/workflows/ci.yml.github/workflows/link-check-full.ymlCHANGELOG.mddomains/funds-assets.mdpatterns/pattern-private-pvp-stablecoins-erc7573.mdpatterns/pattern-relay-mediated-proving.mdrfps/rfp-privacy-pools.mdrfps/rfp-zk-spv-dvp.mdvendors/ey.mdvendors/fireblocks.mdvendors/miden.mdvendors/paladin.md
💤 Files with no reviewable changes (1)
- vendors/miden.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 (3)
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/fireblocks.mdvendors/ey.mdvendors/paladin.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.md
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
🧠 Learnings (12)
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation should keep the Protocol section high-level and concise. Do not include granular implementation steps (e.g., explicit point-validation sub-steps). If such concerns must be mentioned, use lightweight callouts in a separate Security Notes or Caveats section. Apply this guideline to all pattern docs under the patterns directory.
Applied to files:
patterns/pattern-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.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-relay-mediated-proving.mdpatterns/pattern-private-pvp-stablecoins-erc7573.md
🪛 GitHub Check: vale
vendors/fireblocks.md
[warning] 15-15: [vale] vendors/fireblocks.md#L15
[IPTF.Terminology] Use 'ERC-7573' instead of 'ERC7573' for consistency with GLOSSARY.md.
🔇 Additional comments (9)
rfps/rfp-zk-spv-dvp.md (1)
73-73: Link update in “See Also” looks correct.This is a clean internal-reference replacement and matches the document’s neutral style.
vendors/fireblocks.md (1)
15-16: Internal pattern link targets are correctedGood fix on Line 15 and Line 16—these links now point to valid internal pattern files and should remove link-check noise.
rfps/rfp-privacy-pools.md (1)
68-69: Pattern file references are valid. Bothpattern-shielding.mdandpattern-regulatory-disclosure-keys-proofs.mdexist at the referenced paths in the patterns directory.vendors/paladin.md (1)
21-24: All pattern file references are valid.Verification confirms that all four pattern files exist and the relative paths are correct. No action needed.
.github/workflows/ci.yml (2)
207-207: No additional concern on this control-flow close line.
52-57: The markdown-link-check noise suppression is well scoped.Applying
NODE_OPTIONS: --no-deprecationonly on the link-check step is an appropriate containment..github/markdown-link-check-config.json (1)
24-121: Config update looks consistent with link-check stabilization goals.The new ignore patterns and
202alive status handling are coherent and correctly represented in JSON.Also applies to: 136-137
.github/workflows/link-check-full.yml (1)
19-23: Step-scoped deprecation suppression is cleanly applied.
NODE_OPTIONSis scoped to the link-check step, which keeps noise down without affecting unrelated steps.patterns/pattern-relay-mediated-proving.md (1)
47-49: Link target update is consistent across sections.The Noir docs reference is aligned between
open_source_implementationsandSee also, with structure kept intact.Also applies to: 101-101
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
oskarth
dismissed
coderabbitai[bot]’s stale review
Addressed in f932ce7; CodeRabbit check now passes.
| - **Limited Solidity coverage:** not all Solidity syntax transpiles; complex conditionals, loops, and certain patterns are unsupported (see [STATUS.md](https://github.com/EYBlockchain/starlight/blob/master/doc/STATUS.md)) | ||
| - **No native regulatory disclosure:** no built-in viewing keys, selective disclosure, or compliance screening hooks; institutions must build or source these separately | ||
|
|
||
| ## CROPS profile |
There was a problem hiding this comment.
From the latest discussion, we decided not to add crops analysis directly into vendors card. Should we go back on that?
There was a problem hiding this comment.
Oops, this is just CI fixes. I got tired of the failing CI notifications.
There was a problem hiding this comment.
Addressed in f2506ea: removed the vendor-level CROPS profile section to keep this PR scoped to CI/link-check fixes.
| - Multiple privacy models under one surface (ZK UTXO, notary-backed UTXO, group-private EVM). | ||
| - Enterprise operations alignment: HSM/SSM integration, registry/addressing, predictable governance boundaries. | ||
|
|
||
| ## CROPS profile |
There was a problem hiding this comment.
Same here about crops at the vendor level.
There was a problem hiding this comment.
Addressed in f2506ea: removed the vendor-level CROPS profile section to keep this PR scoped to CI/link-check fixes.
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 (1)
vendors/fireblocks.md (1)
26-26:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFix terminology casing to unblock CI.
Line 26 should use
multi-party computation(lowercase), matching the terminology checker.Suggested edit
-Fireblocks’ core system is based on an MPC (Multi-Party Computation) wallet engine. +Fireblocks’ core system is based on an MPC (multi-party computation) wallet engine.🤖 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` at line 26, Summary: Replace the capitalized term "MPC (Multi-Party Computation)" with the lowercase phrase required by the terminology checker. Locate the sentence beginning "Fireblocks’ core system is based on an MPC (Multi-Party Computation) wallet engine" and change "MPC (Multi-Party Computation)" to "multi-party computation (MPC)" so the spelled-out term is lowercase while keeping the acronym for clarity.
🤖 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 `@vendors/fireblocks.md`:
- Around line 12-17: The "## Fits with patterns" bullet list currently uses
markdown links; replace each linked item with names-only bullets (no markdown
links) so the section reads as plain pattern names. Specifically update the
bullets referencing "MPC Custody", "DvP ERC-7573", "ISO-20022", and "TEE ZK
Settlement" under the "## Fits with patterns" header to be simple list items
(ensure the names exactly match the existing pattern titles).
---
Outside diff comments:
In `@vendors/fireblocks.md`:
- Line 26: Summary: Replace the capitalized term "MPC (Multi-Party Computation)"
with the lowercase phrase required by the terminology checker. Locate the
sentence beginning "Fireblocks’ core system is based on an MPC (Multi-Party
Computation) wallet engine" and change "MPC (Multi-Party Computation)" to
"multi-party computation (MPC)" so the spelled-out term is lowercase while
keeping the acronym for clarity.
🪄 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: 563b3f56-815d-416a-a6d3-c2627fcc6c51
📒 Files selected for processing (7)
.github/markdown-link-check-config.json.github/workflows/ci.yml.github/workflows/link-check-full.ymlCHANGELOG.mddomains/funds-assets.mdpatterns/pattern-private-pvp-stablecoins-erc7573.mdvendors/fireblocks.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
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/fireblocks.md
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-private-pvp-stablecoins-erc7573.md
🪛 GitHub Actions: CI Quality Gates / 1_Validate Documentation Patterns.txt
vendors/fireblocks.md
[error] 26-26: Terminology inconsistency: "Multi-Party Computation" should be "multi-party computation".
🪛 GitHub Actions: CI Quality Gates / Validate Documentation Patterns
vendors/fireblocks.md
[error] 26-26: Terminology inconsistency (check-terminology.js): "Multi-Party Computation" → "multi-party computation"
🪛 LanguageTool
CHANGELOG.md
[uncategorized] ~7-~7: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...Unreleased] - fix(ci): stabilize [full markdown link checks](.github/workflows/link-che...
(MARKDOWN_NNP)
[uncategorized] ~7-~7: The official name of this software platform is spelled with a capital “H”.
Context: ...i): stabilize full markdown link checks by ignor...
(GITHUB)
🔇 Additional comments (6)
domains/funds-assets.md (1)
25-25: LGTM!patterns/pattern-private-pvp-stablecoins-erc7573.md (1)
43-44: LGTM!CHANGELOG.md (1)
7-7: LGTM!.github/workflows/link-check-full.yml (1)
15-15: LGTM!Also applies to: 18-20
.github/markdown-link-check-config.json (1)
23-131: LGTM!Also applies to: 145-146
.github/workflows/ci.yml (1)
16-16: LGTM!Also applies to: 19-19, 44-44, 51-53, 61-61, 87-87, 147-147, 150-150, 171-171, 207-207
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
oskarth
dismissed
coderabbitai[bot]’s stale review
Stale CodeRabbit review; addressed in ae9b578 and CodeRabbit confirmed the Fireblocks thread.
|
btw is this related to #67? |
3 participants
What are you adding?
Description
Stabilizes CI link checking by ignoring bot-blocked or transient external references, fixing stale internal links, and pinning GitHub Actions to immutable SHAs. Also addresses CodeRabbit review feedback by restoring the released changelog entry format, adding this PR under [Unreleased], removing a duplicate Funds & Assets pattern link, normalizing ERC-7573 terminology, correcting the ERC-7573 implementation description, and adding CROPS profiles for the changed EY and Paladin vendor cards.
Checklist
Test plan
ERROR:lines.npm run validateexits 0 after installingscripts/dependencies; existing content warnings remain.@v*tags.Summary by CodeRabbit
Chores
Bug Fixes
Documentation