What is BLEEEP?

BLEEEP is a verifiable crypto trading agent built on Virtuals Protocol. Its thesis is one sentence: prove what was done, and what was deliberately not done. Most trading agents ask the reader to trust a self-reported number. BLEEEP removes the need to trust self-reported performance. Every decision, prediction, and declined trade is sealed before the outcome is known. Results are revealed later against the original commitment, batched into a Merkle root, and anchored on-chain, so anyone can check the record without trusting the agent that wrote it.

The problem: forced trust in the bot

Ordinary trading bots fail the same four ways, and none of them are things a user can independently check:

• Performance inflation: look-ahead bias and curve-fit backtests manufacture a “+400%” that collapses the moment real capital is at risk.
• Survivorship: only winners stay on display. Dead strategies are quietly deleted, leaving a gallery selected for luck.
• No verification: self-reported figures on editable records. A “just trust me” black box with nothing to check against.
• Mortality: In one public test of 47 AI trading bots, only a small minority survived a real drawdown. The exact result matters less than the pattern: most bot records do not show what failed, what was abandoned, or what was never traded. When a bot dies, so does the capital inside it.

The common thread: the record is written by the same party that profits from it, after the fact.

The BLEEEP approach: seal, anchor, verify

BLEEEP moves the record out of the agent’s control and into cryptography. Transparency becomes a property of the record itself, not a claim taken on faith.

1. Seal: each decision and prediction is hashed and committed before the outcome is known (commit–reveal). Post-hoc editing and cherry-picking become impossible.
2. Anchor: seals are bundled into one Merkle root and stamped on-chain, cheaply and regardless of trade count, in a form that cannot be deleted, altered, or reordered. Roots are 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.
3. Verify: after the outcome settles, revealing the original proves both when the call was made and whether it was accurate. Anyone can run the check.

What makes this different is what also gets sealed: the trades BLEEEP did not take and the strategies it rejected as NO-GO. In a market that only publishes its wins, an auditable archive of documented rejections is the harder (and rarer) form of proof.

All strategies here are built by users. BLEEEP does not run its own book against them. The engine is a neutral judge, not a competitor. Every strategy is submitted to one fixed, public engine that returns the same verdict (GO / NO_GO / INSUFFICIENT) for everyone. Because that engine applies a fixed, versioned public methodology, verdicts can be checked against the same published standard. A user can keep their own logic private while still proving results, through the same commit–reveal seal. The accumulating record of passes and rejections, shared and verifiable, is collective intelligence: no single track record to trust, but a growing archive of verdicts anyone can check. Once a strategy’s forward record holds, its creator can list it in the strategy marketplace for others to subscribe to, non-custodially. See User strategies for the full model. What is always public is the methodology (capture-first, deflated Sharpe, walk-forward out-of-sample, multi-regime durability, adversarial refutation) and the sealed record of every verdict. Part of the record is paper (simulated) and is labeled as such; on-chain proof establishes that a record is real, not that future returns are guaranteed.

How to read these docs

• Using BLEEEP: what users actually do: build a strategy in chat, test it, and go from paper to live.
• User strategies: how user-built strategies are judged by the neutral engine, and what “private” really means.
• Strategy marketplace: how forward-verified user strategies are listed and subscribed to, non-custodially.
• Proof of Provenance: the commit–reveal proof layer and the NO-GO archive, the core of the trust model.
• Architecture: how the validation methodology and execution gates fit together.
• Verify: check a sealed record independently, step by step.
• Token: provisional supply and allocation information. Token utility is TBA while the design is being revised.

BLEEEP’s ethos is simple: Don’t trust. Verify.

Next: start with Proof of Provenance to see how a decision is sealed before its outcome.