A backtest asks what a defined trading rule would have done on a particular set of historical observations under a particular execution model. The work starts before the first performance chart: write a rule that could fail, verify which prices were available at each decision, and keep the assumptions beside the results.
“Buy when the chart looks strong” cannot be reproduced. “After a completed hourly close moves above the previous 20-bar high, model an entry at the next available bar open” is specific enough to test. It still needs an exit, a market definition, costs and a benchmark, but another researcher can tell what evidence would change the conclusion.
1. Freeze the hypothesis and the rule
Write down the instrument and contract, venue or data provider, bar interval, timezone, entry event, exit and invalidation conditions, direction, quantity rule, maximum holding time and benchmark. Explain why the rule might work and what pattern would count against it. A breakout might fail if closes quickly return inside the old range; a mean-reversion rule might fail when price keeps moving away from its average.
Keep a dated version of each rule. If you test 20 combinations of lookback and exit, record all 20 and why they were selected. The best row from a large search is not evidence that the setting was chosen in advance. The Probability of Backtest Overfitting paper on its publisher’s page explains why repeatedly selecting the best candidate can make in-sample results look more persuasive than their later performance.
2. Audit what each candle actually tells you
Keep the provider, product, symbol, contract type, requested dates, retrieval time, candle interval, raw timestamps, volume units and any transformations with the dataset. Check for duplicate or missing intervals, malformed high/low values, abrupt symbol changes and a final bar that had not closed when retrieved. Preserve the original file or a stable fingerprint so you can reproduce the input.
For example, imagine a fictional hourly candle with open $100, high $108, low $97 and close $105. The rule enters when a completed close exceeds the previous 20-bar high of $104.50. The signal becomes knowable only at the candle’s close. A test that sees that close but fills at the same candle’s $100 open is using later information to choose an earlier price. A causal bar model could use the next bar’s fictional $105.20 open, while still labeling that open as a price proxy rather than a guaranteed fill. An intrabar stop or breakout needs data fine-grained enough to establish the event sequence.
Binance Spot’s current API reference identifies GET /api/v3/klines and defines open and close timestamps alongside OHLC and volume fields. Treat those fields as provider facts to preserve, then determine whether each candle was complete at your retrieval time. Data from one venue is not automatically a market-wide history, and a spot bar does not stand in for a perpetual contract. Binance Spot Kline documentation.
3. Put every material cost in the ledger
Model entry and exit fees, spread, adverse slippage, borrow or funding where relevant, and the venue’s quantity and price increments. State which account tier and order role the fee assumes. For a perpetual, join each position to the funding settlements that actually fall inside its holding window, using their timestamps and sign; a missing interval remains unknown, not a zero payment.
Also decide what happens when the same OHLC candle crosses both a stop and a target. Candle data cannot tell which happened first. Use a conservative convention, finer-grained data, or classify the result as ambiguous. Then repeat the test with higher costs and report when the apparent result no longer survives. A single unexplained “conservative fee” does not make an execution model realistic.
4. Separate rule selection from later evaluation
Use earlier observations to form and tune the rule. Keep a chronological period aside before tuning and use it once for the question it was meant to answer. If you inspect that period and change a parameter, mark it as used; a repeatedly consulted holdout is now part of the research process.
Repeated chronological windows can show how a fixed procedure behaves as more history becomes available. In a walk-forward test, define what gets refit at each boundary and which settings remain frozen. Scikit-learn’s current TimeSeriesSplit documentation provides expanding, time-ordered folds and an optional gap measured in samples. It also requires equally spaced samples for test folds to represent comparable durations; hourly crypto data with missing intervals therefore needs an explicit missing-time policy. The gap is a row count, so choose it to match the outcome horizon and overlap in your own labels rather than copying a default. TimeSeriesSplit documentation.
Track the number of trades as well as the number of candles. Report net result after costs, drawdown path, longest losing sequence, exposure time and the contribution of the largest few trades. If two events explain most of the gain, that concentration belongs in the conclusion. Compare with a benchmark using the same market, dates and capital convention.
5. Challenge the implementation before trusting the chart
Try a deliberately unfavorable check: increase costs, shift the evaluation window, perturb a parameter slightly, and examine individual trade records around missing or volatile periods. Verify that future observations cannot alter a signal that should already have been fixed. Keep the failed checks and negative findings with the run, not only the winning chart.
Save the exact strategy version, data snapshot, configuration, cost schedule, benchmark and result ledger together. A useful final question is “What would make me stop believing this result?” Write that answer before running another variation. When a later check changes your view, create a new version instead of rewriting the original record.
After historical testing, paper trading or prospective observation can check different questions, such as whether a rule can be followed and whether recorded data arrive on time. Those exercises still do not verify that an exchange would fill a live order at the modeled price.
SuperQuant’s bundled backtest histories are synthetic. Its hourly research workflow and ledger help inspect how the software applies a rule, but the engine’s simplified execution and margin assumptions do not reproduce every exchange’s order-book depth, partial fills or liquidation tiers. A repeatable run on synthetic candles is a software rehearsal, not a crypto-market result.
Use the backtest audit checklist, then read the guides to data quality, cost sensitivity and overfitting. This is a research method, not an investment recommendation or a claim of future profitability.