Merkle anchoring and the sealed record

Every record admitted to a formally registered BLEEEP proof stream follows a proof-class-specific schema, is hashed, and receives its required sequence and anchor status. An eligible record is included in a Merkle root when batching succeeds. The root and batch-manifest commitment are then submitted under the registered anchoring rules; failed, missed, or late anchoring remains visible rather than being described as finalized.

A batch used for a pre-outcome decision claim must finalize before the relevant predefined outcome deadline. An event-record batch may finalize later but cannot be labeled as a pre-outcome cryptographic commitment for that event. This page focuses on the pre-outcome decision envelope; event-evidence and computation-provenance records use separate schemas while sharing the batching layer.

What a sealed record contains

A sealed decision record identifies the schema version, decision time, strategy and market, decision type, direction, horizon, and applicable sizing or risk rule. The reasoning may be represented by a digest rather than disclosed in full. Orders, paper fills, and live fills use a different event-evidence record because a later commitment cannot by itself prove when an external execution occurred or convert a simulated fill into a real one.

The decision commitment is the salted hash defined under commit–reveal. The ordered Merkle leaf combines that commitment with the manifest-defined ordering fields. When disclosure is required, a verifier derives the commitment from the disclosed original record and salt and compares it with the earlier commitment. This establishes that the disclosed record matches what was committed; it does not establish that the reasoning was sound or that an unsupported local timestamp was accurate.

From commitments to one anchored root

Publishing every commitment onchain would be expensive and unnecessary. BLEEEP therefore groups ordered commitments into a Merkle tree and anchors the resulting root:

leaf_i = keccak256(LEAF_DOMAIN ‖ canonical_encode(ordering_fields_i, commit_i))
root   = MerkleTree([leaf_0 ... leaf_n]).root

A Merkle path lets a verifier prove that one disclosed cryptographic commitment belongs to the anchored batch without placing every record onchain. The committed manifest identifies its ruleset, evidence scope, ordering rules, expected record count, prior-root reference, and reveal obligations. Where a batch contains several streams or record types, the manifest also commits the applicable stream identifiers, sequence ranges, and expected counts.

Admission receipts and published reveal-status records can expose certain missing, late, invalid, or unrevealed entries inside the declared stream. The Merkle root alone cannot prove that BLEEEP admitted every required event; the registered-stream completeness controls defined in Proof of Provenance remain necessary.

The phrase “sealed before outcome” is valid only when the applicable outcome and commitment deadline were defined in advance and the accepted external anchor became final before that deadline. A missed or late anchor cannot be backdated or presented as a valid pre-outcome proof.

Where the root goes

BLEEEP anchors the root and batch-manifest commitment on Robinhood Chain. The public verifier applies the complete end-to-end check described under Independent verification, including the reveal-after-outcome sequence and proof-class-specific timing rule.

Next: the NO-GO Archive applies this to rejections and decisions not to trade.