Independent Verification

BLEEEP is built so every claim can be checked, not trusted. Each revealed decision can be recomputed from its record and salt, matched against its Merkle proof, and verified against an on-chain root anchored before the outcome was known. This page walks through that process for trades, NO-GO records, and, once live, a Verification API for automated agent and service-level checks.

The anchor transaction on the Robinhood Chain explorer carries a timestamp that is earlier than the outcome it commits to. Verify →

What a proof contains

When BLEEEP reveals a decision, it discloses three things: the original decision record, the secret salt that was sealed with it, and a Merkle path linking that record to a batch root. That root is anchored on Robinhood Chain. Verifying is a matter of recomputing hashes and comparing timestamps, with no trust in BLEEEP required. See Merkle anchoring for how batches are built, and dual-chain anchoring for a second resilience chain, planned for later.

Verify a revealed signal

The reveal payload provides record and salt. The steps mirror the protocol’s VERIFY stage:

Recompute the leaf. Serialize the decision record exactly as specified and hash it with the salt: commit = keccak256(serialize(record) ‖ salt). This must equal the commit value published in the batch.
Walk the Merkle path. Fold the leaf with each sibling hash in the supplied proof, up to the batch’s merkle_root. If the folded value equals the anchored root, the record was genuinely part of that batch.
Read the anchored root on-chain. Look up the batch on the anchor contract, for example the anchor transaction on the Robinhood Chain explorer. Confirm the root it stored matches the root just computed. Once a second resilience chain is added later, the same root can be read from it as well, so no single chain becomes a point of failure.
Check the timing. Confirm the on-chain block.timestamp of the anchor is earlier than the outcome time. A root sealed before the result cannot have been tuned to fit it.

If all four hold, the decision is real, unaltered, and pre-committed. The record itself carries the direction, market, and a rationale_hash: the reasoning is committed as a hash, so the private logic stays private while the decision stays provable.

keccak256(record ‖ salt) == commit
  AND  merkle_proof(leaf) -> anchored_root   (Robinhood Chain root; second resilience chain planned for later)
  AND  anchor.block_ts     <  outcome_time
  =>  real · unaltered · pre-committed

Verify a NO-GO the same way

A NO-GO, a trade deliberately not taken or a rejected strategy, is sealed and anchored with the identical mechanism. Its record simply carries kind: "NO_GO" and direction: "NONE". The verifier recomputes the leaf, walks the path to the anchored root, and checks that the seal predates the market move it declined to trade. This is what lets BLEEEP prove restraint, not just wins. The NO-GO archive collects these rejections and their reasons.

Programmatic verification (planned)

Manual checking is the ground truth, but BLEEEP is designed to expose a Verification API so third parties and other agents can verify proofs without hand-rolling the steps. A call is planned to look like:

POST /v1/verify
  body: { track_record | strategy_claim | wallet }
  -> { verdict, regime_luck, deflation_pass, report_uri, proof }
  proof.anchors: [ {chain:"robinhood", batchId, txHash} ]
  // a second {chain, ...} resilience entry is added once the second anchor chain ships later

The response returns the on-chain anchor reference, so the caller can independently re-check the root. Once a second resilience chain is added later, both chains’ references are returned. Payment is planned via x402 (per-call stablecoin) or a Virtuals ACP Evaluator job, letting autonomous agents ask “can I trust this record?” and get a verifiable answer. This is part of the broader agent economy described in the ecosystem overview.

Next: see how batches are hashed and anchored in Merkle anchoring.

Dual-chain anchoring Trading via Robinhood