What is unreviewed
dpp-rules is 4,679 LOC across 40 files — the second-largest crate here — and holds the cross-field regulatory rules: thresholds, enumerated categories, effective dates, per-sector lint packs. It is no_std, zero-dependency, and shared between dpp-domain and the Wasm sector plugins, so a defect in it reaches both the host determination path and every plugin.
It has never had a dedicated review. A recent full audit of this repo covered the domain, disclosure, crypto, schema-validation, plugin-ABI and vocabulary surfaces, and sampled dpp-rules only indirectly through its callers.
The part with a specific problem
The bundle feature — the signed-ruleset format and its fail-closed verification — is enabled by no crate in this workspace.
just test and just lint pass --all-features, so it compiles and its own tests run. But nothing uses it: there is no consumer exercising the format end to end, no integration test that a tampered bundle is refused in situ, and no caller whose behaviour would change if the verification silently stopped failing closed. A feature that only its own unit tests touch is a feature whose integration is unproven.
Given what it is for — establishing that a determination was made under a specific, unmodified ruleset — that gap matters more than the line count suggests.
Suggested scope
- Constants and thresholds. Sample against primary OJ text. The standing rule is that a secondary-sourced claim may never become a constant, threshold or enum variant; check it holds.
- Effective dates. Whether a rule that is not yet in force can produce a binding determination, and whether the date gate is applied consistently across sectors.
- The
bundle feature end to end. Who is meant to consume it, whether the fail-closed path is reachable from a real caller, and what happens on a truncated or re-signed bundle.
- Test quality. Specifically: rules whose tests assert against our own fixture rather than a worked example from the instrument.
Why now
Nothing is deployed, so a change here costs a release note. Once a determination has been issued against a ruleset, its identity and version become part of what a receipt claims — and correcting a rule afterwards means the old receipts describe a ruleset that no longer means what it said.
What is unreviewed
dpp-rulesis 4,679 LOC across 40 files — the second-largest crate here — and holds the cross-field regulatory rules: thresholds, enumerated categories, effective dates, per-sector lint packs. It isno_std, zero-dependency, and shared betweendpp-domainand the Wasm sector plugins, so a defect in it reaches both the host determination path and every plugin.It has never had a dedicated review. A recent full audit of this repo covered the domain, disclosure, crypto, schema-validation, plugin-ABI and vocabulary surfaces, and sampled
dpp-rulesonly indirectly through its callers.The part with a specific problem
The
bundlefeature — the signed-ruleset format and its fail-closed verification — is enabled by no crate in this workspace.just testandjust lintpass--all-features, so it compiles and its own tests run. But nothing uses it: there is no consumer exercising the format end to end, no integration test that a tampered bundle is refused in situ, and no caller whose behaviour would change if the verification silently stopped failing closed. A feature that only its own unit tests touch is a feature whose integration is unproven.Given what it is for — establishing that a determination was made under a specific, unmodified ruleset — that gap matters more than the line count suggests.
Suggested scope
bundlefeature end to end. Who is meant to consume it, whether the fail-closed path is reachable from a real caller, and what happens on a truncated or re-signed bundle.Why now
Nothing is deployed, so a change here costs a release note. Once a determination has been issued against a ruleset, its identity and version become part of what a receipt claims — and correcting a rule afterwards means the old receipts describe a ruleset that no longer means what it said.