Validation methodology

On-chain anchoring proves that a decision was made at a stated time and not edited afterward: it proves a revealed record matches a prior commitment. It does not prove the whole track record is complete unless the decision stream is defined. It cannot, by itself, indicate whether performance was skill or luck. That is the harder question, and it is the one BLEEEP’s validation engine is built to answer. Before any strategy is trusted, it must survive a battery of statistical and adversarial tests designed to strip out the flattering coincidences that make a backtest look better than the strategy actually is.

What is fixed, what the user controls, what is exposed

The validation standard is a constitution, not a setting. A user controls their strategy; they do not control the bar it has to clear. If a user could move the passing threshold, validation would be self-grading and worthless. The engine is a neutral judge, fixed for everyone: it does not run its own strategies, and the standard is the same for every user strategy. For how a user’s strategy is built, see User strategies.

The rule in one line: a user owns their strategy’s parameters; BLEEEP publishes, versions, and anchors the bar; changes are public. The bar is frozen, published, and version-controlled, so a GO means the same thing for every user strategy. A user can keep their own logic private while still proving results: the engine seals the committed spec and publishes only the verdict and proofs.

Capture-first: no look-ahead by construction

Validation begins before a strategy is even scored. BLEEEP is designed around a capture-first discipline: raw market data is collected first and appended immutably, then a frozen strategy specification is replayed against data that arrives only afterward. Parameters are locked before evaluation, so there is no post-hoc tuning and no way to peek at the future. Look-ahead bias and curve-fitting are ruled out structurally, not by promise.

The six gates

A candidate must pass all six gates to earn a GO. Failing any one is a NO_GO. Each gate targets a specific way a backtest can flatter a strategy. The exact numeric cutoffs are being finalized against current data and will be fixed and anchored on-chain at launch; the decision rule for each gate is fixed now and stated here.

1. Deflated Sharpe. The Sharpe ratio has to stay positive after correcting for how many strategies were tried. Testing a hundred variants and keeping the lucky one does not survive this, because the more candidates are tried, the higher a raw Sharpe turns up by chance alone.
2. Walk-forward out-of-sample. Fit on a window, test on the window that follows, roll forward, and repeat across the whole history. The weekly directional win rate has to stay above 50% out of sample, over the full period, not just the stretch it was fit on.
3. Multi-regime durability. The result has to be positive in every market regime the data covers, not concentrated in one. A strategy that only made money in a single bull run or a single volatility spike is regime luck, and it fails here even if the whole-period number looks strong.
4. Monte Carlo / permutation. Shuffle or resample the returns thousands of times to build the distribution that would arise by chance, then require the real result to sit outside it at p < 0.05. If a random reordering reproduces the edge, there is no edge.
5. Cost realism. Re-run against the actual order book, with real bid and ask, real fills, fees, funding, and slippage. Approximating the opposite side of a Polymarket binary as 1 − p is not allowed; the true book ask is used, because the shortcut manufactures profit that does not exist. Many “wins” go negative the instant realistic costs apply.
6. Adversarial refutation. A dedicated run actively tries to break the strategy: stress its assumptions, attack its weak points, search for the regime or cost model that kills it. Only edges that survive a genuine attempt to disprove them pass.

A passing strategy is not the one that printed the largest return. It is the one that could not be broken by the tests aimed at it.

The numbers, and when they lock

The decision rule above is fixed. The exact numeric cutoffs, such as the deflated-Sharpe floor, the acceptable drawdown, and the minimum sample size, are being calibrated against current data and will be published, versioned, and anchored on-chain at launch. Version-controlling and anchoring the thresholds is deliberate: a change to the bar is itself a public, timestamped event, so no one can quietly loosen the standard after the fact.

The denominator is the product

Most candidates do not pass, and this is the point. When an edge fails, or when a previously trusted one decays, it is recorded as a NO-GO with its rejection reason, and sealed and anchored exactly like a live trade. Across all user strategies, most submissions end in NO-GO, and every rejection is published, not hidden. Trust here does not come from a showcased winner; it comes from the accumulating collective GO/NO-GO record and from a NO-GO archive where each rejected strategy openly demonstrates that it exposed no alpha.

Ask any bot vendor how many strategies they tested and killed to arrive at the ones on display. They will not say, because a gallery of five winners drawn from an unknown number of attempts is selected for luck. Showing the denominator is what makes the numerator mean something. Browse it in the NO-GO archive.

From verdict to live

A GO is necessary but not sufficient. A validated strategy is designed to first run in paper forward-testing (real prices, no real orders) and is promoted to live capital only after it holds up out of sample and a human approves the promotion. Live execution is planned to remain off by default. How that record is sealed is covered in Proof of Provenance.

A note on figures: parts of the track record are paper (simulated), and any cited numbers come from specific experiments. On-chain records prove the past is real; they do not guarantee future returns.

A GO expires: continuous re-verification

A GO is a verdict at a point in time, not a permanent seal of approval. Edges decay (a strategy that was durable can stop working as the regime shifts) so BLEEEP re-verifies every validated strategy continuously against the outcomes that keep arriving. Each new decision is sealed before its outcome and then scored against the settled result, and the strategy’s live forward record updates in place. When forward performance breaks down, the verdict slides (GO → DECAYING → STALE → NO_GO) and that downgrade is itself sealed and anchored, so a decayed strategy cannot keep trading, or be sold to subscribers, under a stale green badge.

This runs at scale by construction. Re-verification is incremental scoring on shared outcomes: an outcome (a settled candle, a resolved market) is ingested once and fanned out to every strategy that acted on it, so the marginal cost of one more strategy is a handful of operations per decision, not another backtest. Anchoring is Merkle-batched (one root, one transaction, whether the batch holds one record or a million) so proving tens of thousands of live track records costs the same on-chain as proving one. The only heavy computation is the one-time, six-gate evaluation when a strategy is first submitted, which is metered so a submitter pays for their own validation, and cached by result_key. The practical ceiling on any single strategy is therefore economic, not computational: as more subscribers crowd the same edge on a thin venue the edge itself decays, which a per-strategy capacity cap manages.

Next: see how each verdict is committed before its outcome and made tamper-proof in Merkle anchoring.