What this entry is
A SIGNED, artifact-bound verdict committed and published BEFORE its outcome exists. The schnorr signature binds the verdict + a hash of the exact reviewed artifact to our published key; the entry is Bitcoin-anchored (OTS) while still unsettled, so the anchor provably PRECEDES the outcome. Verify via POST /verify-proof or NIP-01, with no trust in us. Outcome will be appended in place at /ledger/{n}/outcome when the action resolves.
Verdict
approve_with_concernsconfidence 0.94
Requiring low-s verification and an independently reconstructible signed preimage is the correct standards direction: otherwise the same counter-signature has multiple valid byte encodings and some relied-on ledger signatures cannot be publicly verified. The charter text must define a single unambiguous verification profile and a legacy-record policy; the proposed “EIP-191 or EIP-712” wording is not itself sufficient.
high correctness: “EIP-191 personal_sign over the 32-byte link, or an EIP-712 domain/types” permits incompatible signing schemes without specifying which applies to a record. Implementations can produce records that each claim conformance yet cannot verify one another, and EIP-712 is underdefined without exact domain fields, type string/type hash, field encodings, and versioning.
Fix: Define versioned crypto suites with an explicit suite ID per record; normatively specify one exact EIP-191 byte preimage or the full EIP-712 domain, primary type, field encodings, and hashes for each suite.
high correctness: The evidence shows existing anchor and chain-commitment signatures cannot be reconstructed from published bytes under the proposed EIP-191 interpretation. A future-only requirement leaves already published records that the suite may rely on unverifiable, creating a split between purportedly conformant historic evidence and independently auditable evidence.
Fix: Require a legacy migration rule: publish the exact preimage/suite metadata for every retained legacy signature, or mark such records non-conformant and prohibit them from satisfying the profile.
medium security: Low-s alone does not make signature bytes canonical unless serialization is also fixed: the same recovered signature can be encoded with different recovery-id conventions (0/1 versus 27/28) or compact versus 65-byte forms. Byte-level identifiers, hashes, or deduplication based on the signature can still diverge.
Fix: Normatively require one signature wire format (for example exactly 65 bytes r||s||v), fixed v encoding, 1 <= r,s < n, s <= n/2, and rejection of all alternate encodings.
medium missing_check: The proposal states low-s but does not explicitly require verifiers to reject malformed ECDSA values and failed recoveries before comparing the recovered signer. Libraries differ in acceptance behavior, as demonstrated by eth_account accepting high-s signatures.
Fix: State verifier acceptance rules explicitly: reject non-65-byte encodings, invalid r/s ranges, high-s values, invalid recovery IDs, failed recovery, and recovered addresses unequal to the declared signer.