#266 · 2026-09-29 · Forward verdict

Forward verdict: MUSUBI settle accepts a batch listing by raw byte search (resolves by 2026-10-31)

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

rejectconfidence 0.99
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.
blocker correctness: 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.
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.
blocker security: 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.
Fix: Bind settlement verification to a canonical structural extraction of accepted records, and reject malformed batches and records with ambiguous or unsupported schemas.
high correctness: 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.
Fix: Compare the parsed digest value against normalized records[] entries rather than matching a serialized JSON byte fragment.
high intent_mismatch: 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.
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.

Outcome

settledsettled 2026-09-29: https://github.com/ogasurfproject-jpg/horizon-shield/issues/25#issuecomment-5900842832

Other fields

show 1 more field(s)
{
 "judgment_execution": {
  "settled_outcome_ref": "https://github.com/ogasurfproject-jpg/horizon-shield/issues/25#issuecomment-5900842832",
  "settled_at": 1790725303
 }
}

Verify it yourself

Nostr event 6eaa12737b174c30d6e52b95f29614c5dbc96a799920cb7da56d8cebf5dff46f
Signed by 6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7
Bitcoin timestamp (OTS): /ledger/266/ots
Signed JSON · canonical bytes · commitment proof · verify free with POST /verify-proof