The NO-GO archive

Every trading system on the market advertises its wins. Almost none can show the trades it declined: the setups it looked at, judged, and deliberately walked away from. BLEEEP treats those refusals as first-class evidence. A NO_GO record is sealed, batched, and anchored on-chain exactly like a live trade, so the decision not to act becomes as verifiable as the decision to act.

Why “what wasn’t done” is the hard part

Proving a win is easy: the fill is on-chain or on an exchange statement, and it flatters the operator, so there is every incentive to publish it. Proving a non-action is the opposite problem. There is no fill, no position, no artifact. Anyone can claim after the fact that they “would have skipped that one,” and no one can check. That asymmetry is exactly why unprofitable calls quietly disappear from most track records.

BLEEEP’s validation engine produces far more rejections than approvals: most strategies fail the gate and never reach live capital. Recording only the survivors would paint a distorted picture. The archive exists to close that gap. Since every strategy evaluation, signal candidate, and execution decision that enters the engine must produce either GO, NO_GO, or INSUFFICIENT, the refusals are the verifiable denominator behind every published win.

How a NO-GO is sealed

A NO_GO uses the same decision-record schema as any other call, with direction set to NONE. It is committed before the outcome is known, so it cannot be back-dated to look prescient:

{
  "kind": "NO_GO",
  "strategy_id": "…",
  "market": "BTC-USDT-PERP",
  "direction": "NONE",
  "rationale_hash": "0x…",   // reasoning hashed, not exposed
  "salt": "0x…"              // secret until reveal
}

The record’s rationale_hash binds the reason for skipping without revealing the private engine logic. From there the record follows the identical path as a live trade:

1. Commit: the sealed record joins a batch; its Merkle root is anchored on Robinhood Chain (a second resilience chain is planned for later).
2. Reveal: after the window closes, the full record and its salt are disclosed.
3. Verify: anyone recomputes the hash and checks the Merkle proof against the anchored root.

Because records are chained append-only and batched into a single root, the archive is resistant to insertion, deletion, and reordering. See Merkle anchoring and commit–reveal for the mechanics.

What “verified” means, and does not

Verification is a precise claim, and it is worth being candid about its edges.

What a valid proof establishes:

• A commitment to the record existed by the anchor time.
• It was committed before the outcome was known.
• It has not been altered since.

What it does not establish:

• That the decision was correct, or that skipping was the profitable choice.
• That any strategy is or will be suitable for a user’s goals.
• Anything about future returns: a proof describes the past only.

There is also a venue distinction. On-chain venues (Polymarket, DEXes) settle publicly, so those actions are fully verifiable. For a centralized exchange, commit–reveal proves the call was sealed on time and unaltered, but the fill itself stays tamper-evident self-attestation rather than trustless, absent an exchange-signed receipt. The planned second resilience chain and these boundaries are covered in dual-chain anchoring.

A record that says “we skipped this” carries the same cryptographic weight as one that says “we entered.” That is the point: transparency is not a slogan here, it is an anchored root anyone can check for themselves.

Next: walk through checking a proof end-to-end on /verify.