docs: classify contract-readable anchor state as a hard requirement#45
Merged
Conversation
…not graded) Second Codex pass on the v0.3 draft caught a genuine inconsistency: the DLT_EVALUATION methodology listed 'programmable escrow ... and contract-readable anchor state' under *graded* criteria, but SPEC §13.1 makes programmable smart contracts (req 3) and contract-readable dispute/enforcement state (req 6) MUST-level requirements — and the file's own Hedera row already uses 'HCS not smart-contract-readable' as an outright disqualifier, not a low score. Split the methodology note: programmable contracts, programmatic wallets, contract-readable dispute/enforcement state, and anchor discoverability are now stated as SPEC §13.1 MUSTs (pass/fail, non-discriminating because the shortlist all clears them), with contract-readable state called out as the one that disqualifies HCS-style anchoring. Native randomness (conditional on VRF use), sponsored tx, stablecoins, maturity, and quantum resistance remain genuinely graded. No change to any chain's verdict.
5 tasks
iret77
added a commit
that referenced
this pull request
Jun 13, 2026
Third Codex pass: the README 'Hard selection criteria' summary listed 5 of SPEC §13.1's 7 MUST requirements, omitting req 6 (contract-readable dispute/enforcement state) and req 7 (anchor discoverability) — the very requirements PR #45 just clarified are hard, not graded. Added both, and noted contract-readable state as the one that rules out event-log-only anchoring (Hedera HCS). Summary now matches §13.1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Second-pass review fix. After the consistency PR (#44) merged, a fresh grounded Codex pass over the v0.3 draft surfaced one remaining inconsistency in the companion evaluation doc:
DLT_EVALUATION.mdlisted "programmable escrow with time-window logic and contract-readable anchor state" under graded criteria — but SPEC §13.1 makes programmable smart contracts (req 3) and contract-readable dispute/enforcement state (req 6) MUST-level requirements. The doc's own Hedera row already treats "HCS not smart-contract-readable" as an outright disqualifier (it "independently breaks the §6.2.1 uncontested path"), not a low score — so the "graded" classification contradicted both SPEC §13.1 and the file's own verdict logic.Fix: split the methodology note into
No chain's verdict changes — this aligns the methodology text with how the table already scores.
Affected spec section(s)
DLT_EVALUATION.md"Method and hard filters"; cross-references SPEC §13.1 (req 3/4/6/7), §6.2.1, §13.4 (Hedera).Trust impact
None. Documentation-only; classifies existing requirements correctly. No normative SPEC change, no trust root moves.
Checklist
docs-checkpasses