use case: programmable policy + vendor: predicate#98
use case: programmable policy + vendor: predicate#98heupdegrave wants to merge 6 commits intoethereum:masterfrom
Conversation
|
Hi @heupdegrave |
addressed CI Quality Gate comment re: "Avoid marketing language"
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. 💤 Files selected but had no reviewable changes (1)
⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughAdded a new markdown document defining a programmable policy use case for privacy protocol operators. The document outlines the problem of preventing malicious actors in privacy-enhanced protocols, identifies participating actors, specifies requirements and constraints, and recommends an implementation approach using smart contracts and policy platforms. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@use-cases/programmable-policy.md`:
- Around line 13-16: The "Additional Business Context" section is empty —
populate the “Additional Business Context” header with a concise summary of the
business goals, scope, stakeholders, constraints, and intended outcomes for the
programmable-policy use case, and append a single-line template guidance/TODO
that instructs authors to move any confidential or sensitive details into a
linked context/ document (e.g., "For confidential details, see
context/<doc-name>"). Update the section around the "Additional Business
Context" header so it contains both the brief business context and the explicit
redirect to context/ for sensitive information.
- Around line 45-47: Replace the placeholder "N/A" under the "## 6) Open
questions" section with one or more bullet-pointed open questions each linking
to a GitHub issue; if no issues exist yet, create a tracking issue (e.g., "track
programmable policy edge-cases" or similar) and insert its link as the first
bullet, then add any additional specific questions (e.g., "How should conflicts
between policy rules be resolved?") with their issue links so the section
follows the project's guideline for actionable, linked open questions.
- Line 53: The markdown link labeled "Private RWA Tokenization" currently points
to patterns/pattern-private-vaults.md; update the link in
use-cases/programmable-policy.md so the label and target match—either change the
target URL to the correct document for "Private RWA Tokenization" (e.g., the
appropriate patterns/pattern-... .md file) or rename the link label to "Private
Vaults" to reflect patterns/pattern-private-vaults.md; ensure the link text
"Private RWA Tokenization" and the target path
patterns/pattern-private-vaults.md are consistent.
- Around line 41-44: The paragraphs describing the step-by-step implementation
(the smart contract/bridge integration and the cryptographic attestation flow)
are too implementation-specific for the use-case card; remove or condense those
two detailed paragraphs in programmable-policy.md into a brief high-level
summary of the mechanism and acceptance criteria, and replace them with a link
to a new or existing approach/pattern doc that contains the full sequence (e.g.,
detailed steps for "integrate this policy into smart contracts and automatically
prevent restricted addresses" and the "policy platform returns a cryptographic
attestation" flow). Create the separate approach/pattern document to hold the
detailed integration sequence, include identifiers for the smart contract
integration and bridge/attestation steps, and ensure the use-case card stays one
page with problem, requirements, acceptance criteria, and a pointer to the
deep-dive doc.
🪄 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: 3466bebf-39b3-4010-a1e6-6d7c44276db0
📒 Files selected for processing (2)
use-cases/programmable-policy.mdvendors/predicate.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
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/programmable-policy.md
🧠 Learnings (2)
📓 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.
📚 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:
use-cases/programmable-policy.md
🪛 LanguageTool
use-cases/programmable-policy.md
[grammar] ~9-~9: Ensure spelling is correct
Context: ...ts, etc.) confidential when transacting onchain. But the same privacy mechanisms that p...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~25-~25: Ensure spelling is correct
Context: ...pattern-private-vaults.md)) to complete onchain investments, payments, and other financ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~43-~43: Consider shortening this phrase to just ‘whether’, unless you mean ‘regardless of whether’.
Context: ... a cryptographic attestation confirming whether or not the transaction adheres to the applicat...
(WHETHER)
| ## 2\) Additional Business Context | ||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
Fill Additional Business Context or add the template TODO guidance.
This section is currently empty. Add concise business context and explicitly note that confidential details belong in a linked context/ document.
As per coding guidelines, use cases must include the template’s “Additional Business Context” section with guidance to move business-sensitive details to context/.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@use-cases/programmable-policy.md` around lines 13 - 16, The "Additional
Business Context" section is empty — populate the “Additional Business Context”
header with a concise summary of the business goals, scope, stakeholders,
constraints, and intended outcomes for the programmable-policy use case, and
append a single-line template guidance/TODO that instructs authors to move any
confidential or sensitive details into a linked context/ document (e.g., "For
confidential details, see context/<doc-name>"). Update the section around the
"Additional Business Context" header so it contains both the brief business
context and the explicit redirect to context/ for sensitive information.
| If the project in question is a privacy-enhanced application on Ethereum mainnet, the application team can integrate this policy into its smart contracts and automatically prevent restricted addresses from depositing funds. This provides more consistent compliance enforcement than the common framework of front-end compliance checks, which can be bypassed via direct contract calls. If the project is a privacy L2, the operator can integrate their programmable policy with the bridge contract, and prevent restricted addresses from moving funds to the chain at all. | ||
|
|
||
| In both cases, the application calls the policy platform, which returns a cryptographic attestation confirming whether or not the transaction adheres to the application team’s policy. If it does adhere, the transaction proceeds with the attestation attached, which allows the deposit to be executed. If the transaction doesn’t adhere to the policy, the address is unable to deposit funds to the protocol, thereby significantly reducing commingling risk for institutions using the protocol compliantly. Compliant users deposit funds unimpeded, and face no degradation of privacy guarantees. | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Move implementation sequence details to an approach/pattern doc and keep this card higher-level.
This block is too implementation-specific for a use-case card. Keep the use case focused on problem, requirements, and acceptance criteria; link out for the step-by-step mechanism.
As per coding guidelines, use-case files should stay brief (single-page scope) and link to deeper approaches rather than duplicating detailed implementation.
🧰 Tools
🪛 LanguageTool
[style] ~43-~43: Consider shortening this phrase to just ‘whether’, unless you mean ‘regardless of whether’.
Context: ... a cryptographic attestation confirming whether or not the transaction adheres to the applicat...
(WHETHER)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@use-cases/programmable-policy.md` around lines 41 - 44, The paragraphs
describing the step-by-step implementation (the smart contract/bridge
integration and the cryptographic attestation flow) are too
implementation-specific for the use-case card; remove or condense those two
detailed paragraphs in programmable-policy.md into a brief high-level summary of
the mechanism and acceptance criteria, and replace them with a link to a new or
existing approach/pattern doc that contains the full sequence (e.g., detailed
steps for "integrate this policy into smart contracts and automatically prevent
restricted addresses" and the "policy platform returns a cryptographic
attestation" flow). Create the separate approach/pattern document to hold the
detailed integration sequence, include identifiers for the smart contract
integration and bridge/attestation steps, and ensure the use-case card stays one
page with problem, requirements, acceptance criteria, and a pointer to the
deep-dive doc.
| ## 6\) Open questions | ||
|
|
||
| - N/A |
There was a problem hiding this comment.
Replace N/A with actionable open questions linked to GitHub issues.
The template expects bullet-pointed open questions with issue links. If none exist yet, add at least one tracking issue and link it here.
As per coding guidelines, “Open Questions” should be bullet points with links to GH issues.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@use-cases/programmable-policy.md` around lines 45 - 47, Replace the
placeholder "N/A" under the "## 6) Open questions" section with one or more
bullet-pointed open questions each linking to a GitHub issue; if no issues exist
yet, create a tracking issue (e.g., "track programmable policy edge-cases" or
similar) and insert its link as the first bullet, then add any additional
specific questions (e.g., "How should conflicts between policy rules be
resolved?") with their issue links so the section follows the project's
guideline for actionable, linked open questions.
|
|
||
| - Relevant use cases where programmable policy can enhance compliance: | ||
| - [Private stablecoins](https://github.com/ethereum/iptf-map/blob/master/use-cases/private-stablecoins.md) | ||
| - [Private RWA Tokenization](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-vaults.md) |
There was a problem hiding this comment.
Fix the “Private RWA Tokenization” link target.
The label suggests a use-case/topic-specific document, but it points to patterns/pattern-private-vaults.md. Please update to the intended target (or rename the label) to avoid misleading navigation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@use-cases/programmable-policy.md` at line 53, The markdown link labeled
"Private RWA Tokenization" currently points to
patterns/pattern-private-vaults.md; update the link in
use-cases/programmable-policy.md so the label and target match—either change the
target URL to the correct document for "Private RWA Tokenization" (e.g., the
appropriate patterns/pattern-... .md file) or rename the link label to "Private
Vaults" to reflect patterns/pattern-private-vaults.md; ensure the link text
"Private RWA Tokenization" and the target path
patterns/pattern-private-vaults.md are consistent.
Addressed comments
|
Just pushed updates addressing comments, let me know if I missed any. Thanks. |
|
Thanks @heupdegrave!
Let me know if I can help with anything. |
2 participants
What are you adding?
Description
We're adding a use case entry for programmable policy as it relates to privacy and a vendor entry for Predicate.
Checklist
Summary by CodeRabbit