Merkle anchoring & the sealed record

Every decision BLEEEP makes is turned into a structured record, hashed, chained to the record before it, and rolled up with its neighbors into a single Merkle root that gets anchored on-chain. This page describes the shape of a sealed record and the two hashing steps that make a batch of them tamper-evident. The internal logic that produces a decision stays private; what is described here is only the envelope around it: the part designed to be public and independently checkable.

What a sealed record contains

A decision record is a small, fixed-schema object. It captures what was decided and when, not why the engine decided it. Conceptually, each record holds:

• A version tag: so the schema can evolve without breaking old proofs.
• A timestamp: the seal moment, fixed before the outcome is known.
• A kind: one of TRADE, NO_GO, PREDICTION, or SIGNAL. A NO_GO is a deliberately-not-taken trade, sealed the same way as any action.
• The subject: which strategy and market the decision concerns, and a direction (a NO_GO carries NONE).
• A horizon and sizing rule: the intended holding window and the risk rule, by reference rather than raw parameters.
• An inputs / rationale digest: the reasoning is committed as a hash only (rationale_hash), so the record proves a specific rationale existed without exposing engine logic.
• A salt: a secret value used in the commitment and disclosed only at reveal.

Because the rationale enters as a digest and the record is salted, the sealed commitment does not expose the strategy logic at commit time. Repeated reveals may still expose behavioral patterns over time. It only pins down, irreversibly, that a particular decision was made at a particular time.

From record to tamper-evident chain

Each record is first committed, then linked to its predecessor:

commit_i = keccak256( serialize(record_i) || salt_i )
leaf_i   = keccak256( batch_id || index_i || prev_leaf_i || commit_i )
root     = MerkleTree([leaf_0 ... leaf_n]).root

The commit_i step hides the record behind a one-way hash. The leaf_i step folds in the previous leaf’s hash, so the log becomes an append-only chain: no one can insert, delete, or reorder a record without breaking every hash that follows it. Any tampering is detectable by re-walking the chain.

From chain to a single anchored root

Publishing every commit on-chain would be expensive and unnecessary. Instead, a batch of commits (for example one hour or one day of activity) is arranged as the leaves of a Merkle tree, and only the tree’s root is anchored:

root = MerkleTree([leaf_0 ... leaf_n]).root

This is why one transaction covers a whole batch, whether it holds one decision or a thousand: cost is independent of batch size. Yet no fidelity is lost: any single leaf can still be proven to belong to that root by supplying its Merkle path (the sibling hashes from leaf to root). A verifier recomputes the root from the leaf and its path; if it matches the anchored root, that decision was provably part of the sealed batch. At reveal time, disclosing the record and its salt lets anyone recompute the commit, check the Merkle path against the anchored root, and confirm the batch was sealed before the outcome.

Where the root goes

The root is anchored on Robinhood Chain. A second anchor chain for resilience is planned to be added later, so no single chain becomes a point of failure. Under the planned dual-chain design, the same root is written to a second chain in parallel, so a proof survives even if one chain does not. Fitting the pieces together into an end-to-end check is covered on the verify page, and the reveal-after-outcome sequence is part of proof-of-provenance. For the records that make BLEEEP distinctive, the trades it refused, see the NO-GO archive.

Next: Dual-chain anchoring: the planned design for a second resilience chain, planned for later.