How to read KLINEO backtests and their limitations

A backtest applies rules to historical data under a specified execution model. It can help examine a strategy and find failures; it does not establish live returns, native exchange execution parity or future profitability. Read the data source, exact period, costs, budget, drawdown and data-quality notes together. A “verified” preset label describes the recorded validation scope, not an investment guarantee or external audit.

Before you start

  • Know which result you are reading: an illustration, a preset’s stored historical simulation, your own replay, or an observed product run.
  • Retain the actual configuration and result details if you want a reproducible comparison.

Identify the kind of evidence first

Results that answer different questions
EvidenceUseful forDoes not establish
IllustrationExplaining ladder arithmetic or a hypothetical price path.Historical returns or actual fills.
Stored historical simulationInspecting a recorded configuration and historical data window.A freshly rerun test or a deployed live result.
Your own replayChecking your selected settings against that replay’s data and model.Future behavior or the fidelity of another engine.
Observed Live order recordWhat was recorded for that order, account and time.A general future-return claim or performance of other accounts.

Read the published DCA preset method

The current stored DCA preset dataset covers 11 July 2022 to 11 July 2026. Its primary source is Coinbase Exchange spot data, with separate secondary-venue results where present. Preset labels using familiar pair symbols do not turn the primary dataset into Binance production execution evidence.

The recorded method uses 260 in-window warmup candles and 260 completed candles per signal. Its fee model is 0.10% per side. Market entries and modeled exits include 0.05% adverse slippage; resting safety limits are modeled at their limit without an additional buy-slippage charge. The ladder is anchored to the modeled base fill.

The published research companion exposes the source results, modeled cost sensitivities and candle-quality rows. It does not claim a new historical replay, independent audit or comparison of paid competitor accounts.

Record enough context to interpret a run

  • Exchange data source, spot or futures, exact symbols and timeframe.
  • Start and end timestamps, timezone, warmup and actual candle range returned.
  • Every strategy parameter, risk setting, order-size unit, planned ladder and effective budget.
  • Fee and slippage assumptions, fill rules and any explicit funding or liquidation model. If a cost is absent, treat it as absent.
  • Return denominator: deployed cash, starting quote balance, notional or margin. Do not compare percentages with different denominators.
  • Maximum drawdown, losing periods, stops, cycle counts and open exposure at the end.
  • The saved strategy or workflow version and the engine used. Results from one engine do not automatically validate another.

Inspect missing candles and intrabar assumptions

OHLC candles contain open, high, low and close, not a complete sequence of every market event. If both a stop and target are touched in one candle, the modeled ordering affects the result. A candle-based fill is not an exchange queue, partial fill or latency simulation.

Check actual versus expected candles, coverage, gap counts and the longest missing gap. A checksum helps identify a dataset; it does not prove that the data is complete or unbiased. Some source series have missing candles. A result that has not rerun with gap sensitivity should not be described as having passed it.

Test whether a result depends on favorable choices

  1. Separate parameter development from evaluation. Record which dates influenced the selected settings; do not silently label a fitted historical period as an untouched holdout.
  2. Examine losing folds and the final fold as well as cumulative return. A positive total can conceal long or deep losses.
  3. Compare modeled base costs with higher-cost scenarios and inspect secondary-venue results only where their source and period are present.
  4. Try materially different periods, plausible execution assumptions and parameter neighborhoods when those tests are available.
  5. Keep missing checks explicit. Without a fresh replay, gap-removal sensitivity or live matched execution test, those questions remain unanswered.

Use the result to improve a testable rule

Treat a backtest as a way to discover where a strategy can fail: capital exhaustion, unfavorable trends, costs, data gaps and unrealistic fills. A positive result is a reason to investigate those assumptions, not a promise to trade profitably.

For a practical next step, retain a small explicit test case, inspect its order lifecycle in an available simulated mode and compare expected and recorded behavior. Do not substitute a historical result for current exchange permissions, product eligibility or the decision to take Live risk.