{"entry":266,"judgment_execution":{"settled_at":1790725303,"settled_outcome_ref":"https://github.com/ogasurfproject-jpg/horizon-shield/issues/25#issuecomment-5900842832"},"ledger":"invinoveritas verdict ledger","proof":{"artifact_sha256_in_event":true,"event_id":"6eaa12737b174c30d6e52b95f29614c5dbc96a799920cb7da56d8cebf5dff46f","how_to_verify":"POST /verify-proof with this Nostr event, or run NIP-01; the artifact_hash binds it to the exact artifact reviewed.","pubkey":"6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7"},"title":"Forward verdict: MUSUBI settle accepts a batch listing by raw byte search (resolves by 2026-10-31)","ts":1790706391,"type":"pre_action_verdict","verdict":{"confidence":0.99,"issues":[{"category":"correctness","description":"The proposed raw search accepts a digest solely because the exact byte sequence occurs once, even when the digest is not an accepted record. A stamped batch containing the digest under rejected, supersedes, or an unrelated kind will therefore satisfy the settlement predicate despite contradicting the batch's stated acceptance definition.","severity":"blocker","suggested_fix":"Parse the batch as its defined format and return true only if an entry in records[] has the exact digest and required accepted record kind/status."},{"category":"security","description":"The OTS/Bitcoin leg authenticates immutable batch bytes, not the interpretation of fields within those bytes. An adversary or faulty intake that includes a claimant digest in a stamped non-accepted field can obtain a cryptographically anchored but semantically false settlement eligibility result.","severity":"blocker","suggested_fix":"Bind settlement verification to a canonical structural extraction of accepted records, and reject malformed batches and records with ambiguous or unsupported schemas."},{"category":"correctness","description":"The 'exactly once anywhere' condition is neither equivalent to accepted membership nor robust serialization handling: valid accepted data can be rejected if the digest is repeated in metadata, while accepted records serialized with different whitespace, key ordering, or escaping can be missed.","severity":"high","suggested_fix":"Compare the parsed digest value against normalized records[] entries rather than matching a serialized JSON byte fragment."},{"category":"intent_mismatch","description":"The proposed resolution criterion is unsound: maintainer documentation that raw-byte acceptance is intended does not prove that it is safe for a verdict whose stated semantic requirement is accepted membership. It could label an acknowledged semantic mismatch as 'PROVEN WRONG' without resolving the settlement-risk question.","severity":"high","suggested_fix":"Define the outcome by protocol semantics and adversarial test vectors: raw acceptance is only valid if the batch specification explicitly makes every occurrence of the digest an accepted listing, which conflicts with the described records[] definition."}],"summary":"Raw-byte occurrence is not a sound acceptance predicate when settlement semantics require that a digest was accepted in records[]. It deterministically converts appearances in rejected, supersedes, wrong-kind, or malformed payload contexts into a false within_grant verdict, while the Bitcoin/OTS anchor only proves the bytes were stamped—not their semantic meaning.","verdict":"reject"},"what":"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."}