Crypto buyer research · 12 October 2026

Crypto Signal Backtests, Paper Results and Live Evidence

Keep historical rules, prospective simulated events and actual account operations in separate evidence populations.

Fictional examples, declared assumptions, no connected accounts.

Declare which experiment produced the result

A historical replay uses data and modelling assumptions. A paper run observes a configured procedure with simulated account responses. A live account record describes authorised operations and actual capital. These labels should remain attached to records, tables and exports. A platform's ability to provide all three modes does not make their outputs one interchangeable performance series.

TradingView's repainting documentation explains differences between historical and realtime calculations. The relevant review question is whether the declared input and rule version would have produced the same observable event at the decision point. This is not an accusation about every chart script. Save the exact configuration and information boundary instead of treating a polished historical marker as a prospectively received call.

Finish a fictional historical-versus-forward case

In an invented replay, rule R-01 marks five attractive historical entries after completed bars are available. A separately frozen prospective simulation observes three alert events. The two populations have different boundaries. The reviewer retains the historical data window, input settings, bar-completion rule and the forward receipt log. The difference does not itself prove a programming failure or profitable forward performance.

The completed classroom conclusion says five historical markers and three simulated forward notifications were supplied, with unresolved event equivalence. It does not credit all five as delivered forward instructions. If a rule uses later data or changes its condition after the bar, the reconstruction needs to disclose that. If the forward log is incomplete, preserve that limitation rather than treating every absent event as a failed signal.

Freeze identity before evaluating an outcome

Keep rule version, instrument specification, data source, interval, entry convention and the declared exit policy with an experiment. Testing many variations and retaining the attractive one answers a different question from observing a predeclared rule on later independent data. A later parameter change should create a new identity or explicitly labelled change, not quietly rewrite the earlier result.

For a fictional change, the indicator input moves from setting X to setting Y midway through the sample. The record now has two configurations. Combining their most favourable outputs without retaining the change history would conceal a selection decision. This publication supplies an observation procedure, not a privately validated model factory, verified strategy or claim that one configuration is suitable for a real account.

Keep software tests outside the strategy sample

A test proving that a parser rejects an unknown symbol or that a calculator returns the intended arithmetic is useful software evidence. It is not an independent profitability observation. Likewise, replaying an invented fixture can verify lifecycle accounting while supplying no actual market returns. State which acceptance criterion was tested so technical correctness does not turn into strategy effectiveness by implication.

The simulated record can include a rejected entry, duplicate alert and missing close. Each reveals a workflow question, not a live loss or gain unless real supporting operations are supplied. Actual liquidity, fees, funding, account availability and counterparty risk remain outside a simple simulation. A correct receipt or successful webhook test does not erase those missing layers.

Request the appropriate original packet

For a backtest, obtain frozen rules, source data, assumptions and full outcomes. For a prospective simulation, obtain original events, settings and simulation policy. For a live claim, obtain the relevant account population, operations, cashflows, costs and remaining exposure. Do not substitute one artifact because the other is inconvenient or private. A source may be useful but insufficient for the advertised conclusion.

The finished classroom packet preserves the two observed populations, configuration history and missing equivalence evidence. It can support a carefully scoped learning or debugging conclusion without asserting that a provider has been audited. Any broader performance claim needs independent appropriate records and validation. This guide creates no account connection or deployment and does not offer an investment model, expected return or guarantee that historical examples repeat.

Completed fictional teaching record
ObjectSupplied teaching recordBounded conclusion
Historical replay5 invented markersNot 5 prospectively delivered calls
Forward simulation3 invented notificationsSimulated, not account fills
Configuration changeX to Y during sampleRetain separate identities
Software checkParser and arithmetic correctnessNot strategy validation
Live claimActual authorised account artifacts neededNot supplied by this classroom case

Source scope

Original sources support product descriptions or mechanisms, not the fictional results in this chapter. Source checks for this edition: 12 October 2026. No paid service or exchange account was connected.

Continue the research