Proof of Provenance

Every trading agent shows off its wins. BLEEEP is built to prove something no bragging bot can fake: that its record is complete within the committed decision stream, with gaps and unrevealed entries visible. Proof of Provenance is the layer that makes this possible. Instead of asking the reader to trust a screenshot or a backtest, it seals each decision as a cryptographic hash the moment it is made, batches those seals into a single on-chain fingerprint, and lets anyone check the math afterward. The trust comes from cryptography anyone can check, not from claims that must be accepted.

Why transparency is the moat

The market is drowning in profit claims. A flashy “+400%” backtest is everywhere, but nothing lets anyone check whether it was real, or whether it was skill or luck. In one public experiment, only about 3% of 47 AI trading bots survived a real drawdown. Anyone can inflate their wins by quietly deleting the losses.

BLEEEP’s differentiator is the opposite instinct: it is designed to seal and publish even the trades it did not take and the strategies it rejected. In a market that only advertises success, a verifiable archive of what was deliberately avoided is a moat that compounds over time, because faking it would require faking the on-chain history itself.

The three parts

Proof of Provenance is made of three cooperating mechanisms:

1. Commit–reveal: seal a hash of each decision before the outcome, disclose the original afterward, and let anyone match the two. Explained in depth below.
2. Merkle anchoring: batch many seals into one root and stamp it on-chain, so the record cannot be deleted, altered, or reordered. See Merkle anchoring.
3. NO-GO archive: the same sealing applied to rejected strategies and trades never entered. See the NO-GO archive.

Commit–reveal in depth

The core idea is simple: commit to a decision while its outcome is still unknown, then prove later that it was never changed.

Each decision (a trade, a signal, a prediction, or a NO-GO) is serialized into a record and hashed together with a secret salt:

commit_i = keccak256( serialize(record_i) ‖ salt_i )

At commit time only commit_i is published. The record’s contents and the salt stay hidden, so the seal reveals nothing about the strategy logic, only that a commitment existed by the time its batch was anchored. The salt is what prevents anyone from guessing the record by brute force.

The lifecycle has four steps:

Verification succeeds only when three independent checks all pass:

• keccak256(record ‖ salt) equals the committed commit_i, so the record is unaltered;
• a Merkle proof places commit_i inside an anchored root, so it was really in the batch;
• the batch timestamp precedes the outcome time, so the call was genuinely pre-committed.

If any check fails, the record is not verified. Because the seal is on-chain and public, no one, not even the operator, can quietly swap a losing prediction for a winning one after the fact.

What is public, and what is not

Reveals disclose the committed decision record, not necessarily the full strategy logic. Over time, repeated reveals may expose behavioral patterns, so private strategies must define carefully what fields are revealed. The strategy logic never leaves the operator’s core; only results, verdicts, and proofs flow outward. See the architecture for that boundary and validation for how GO/NO-GO verdicts are formed.

One important limitation: on-chain venues like Polymarket are fully verifiable because the trade lives on-chain, while a centralized-exchange fill is tamper-evident self-attestation rather than trustless proof absent an exchange-signed receipt. And all of this proves the past is real. It does not guarantee future returns.

Next: see where these seals actually land in Merkle anchoring.