Crypto Bot Backtests: Audit Timing, Costs and Overfitting
A profitable crypto trading-bot backtest is a description of a simulation, not evidence that the strategy will produce the same result live. Before comparing returns, establish what the simulator knew, when it knew it, and which execution costs it charged.
Start with the timestamp, not the equity curve
Suppose a strategy uses a candle's closing value to generate an entry. If the simulation also fills at that exact close without a realistic decision and execution delay, it may grant the bot a price it could not obtain after observing the completed candle. Record the signal timestamp separately from the first eligible execution timestamp.
The same issue appears when a dataset contains revisions or indicators joined to an earlier timestamp. A valid historical value must have been available to the strategy at that point in time. Today's cleaned dataset is not automatically a faithful record of yesterday's information set.
Repeated tuning changes what a good result means
Choosing the best parameter set from hundreds of attempts creates a selection problem. A combination may fit noise in the development period. Keep a record of unsuccessful trials, not only the winning chart.
QuantConnect's research guide discusses overfitting and research safeguards. A useful practical extension is to freeze the strategy before evaluating a later, untouched time period. If that evaluation leads to more tuning, it has become development data; reserve a new final test.
Make costs visible
The following is a hypothetical accounting example, not an observed strategy:
| Item | Amount in USDT |
|---|---|
| Gross simulated trading profit | 300 |
| Entry and exit fees combined | -120 |
| Estimated execution slippage | -100 |
| Funding paid, net of receipts | -90 |
| Net simulated result | -10 |
The arithmetic is 300 - 120 - 100 - 90 = -10 USDT. Costs can reverse the sign of a result. Avoid counting spread twice if it is already included in simulated fill prices. Funding should follow the actual position, rate and settlement timing in the test rather than a convenient fixed annual rate.
Ask whether the fills were possible
A touched limit price does not establish that the whole order would have filled. Queue position, competing orders, available depth and partial execution matter. A large market order should not automatically receive the best displayed price for its entire size.
Test changes in latency, fees and slippage. A strategy that works only with one optimistic execution assumption is fragile. Test missing data, rejected orders and connection loss as separate operational scenarios; historical candles alone cannot model these well.
Compare across conditions
Report the test dates, instruments, position limits, trade count, turnover, drawdown and capital assumptions alongside return. A rising-market result may mostly reflect asset exposure. Compare with a suitable passive benchmark over the same dates and use consistent treatment of costs and cash.
An untouched holdout period and a small paper-trading observation can reveal implementation errors, but neither guarantees future profit. Do not increase capital simply because a short demonstration is positive.
A reviewable result
A useful bot report provides reproducible settings, data provenance, timestamp rules, all material costs and a clear separation between development and evaluation. Consult the current OrangeX fee schedule before using platform-specific assumptions. This article evaluates simulations and does not claim OrangeX offers a particular bot or backtesting product.
The decision is whether the evidence survives realistic assumptions, not which chart looks smoothest. All numerical results above are illustrative.
