The Overfitting Trap
If you give a machine learning model enough parameters, it will find patterns in random noise. The same thing happens with trading strategy development, just less obviously. A strategy with 12 adjustable parameters, entry threshold, exit threshold, lookback period, volume filter, time-of-day filter, and so on, has enough degrees of freedom to fit the historical data almost perfectly. The problem is that those fitted parameters captured noise specific to the historical period, not a durable market relationship.
You can test this directly. Take any strategy that looks great in a backtest and shift the parameters by 10-20%. If the performance collapses, the strategy is overfit. A robust strategy should degrade gradually with parameter changes, not fall off a cliff. The cliff shape tells you the strategy found a narrow pocket of historical data that happened to work, not a broad structural edge.
Survivorship Bias in Data
Most crypto backtesting is done on assets that currently exist and are actively traded. But a huge number of tokens have been created, traded for some period, and then effectively died, losing 99%+ of their value or getting delisted. When you backtest a strategy on "the top 50 tokens by market cap," you are selecting tokens that survived. Your strategy never encounters the ones that went to zero.
This matters because many momentum strategies look excellent in backtests. Buy things going up, sell things going down. But in a survivorship-biased dataset, the things that went up include future survivors, and the things that went down and eventually went to zero are excluded from the dataset. The strategy's alpha is partially or entirely an artifact of the data selection.
The fix is survivorship-bias-free data, which includes delisted assets and dead tokens. This data is harder to obtain and more expensive, but it gives you dramatically more realistic backtest results.
Slippage and Market Impact
Backtests typically assume you can execute at the price visible at the time of the signal. In practice, the act of trading moves the price. If your strategy generates a buy signal at $100, by the time your order reaches the exchange and gets filled, you might pay $100.15. On a single trade, that is trivial. Over thousands of trades, it is the difference between a profitable strategy and a losing one.
The slippage problem is worse for strategies that trade during volatile periods (when you want to trade is exactly when liquidity thins out) and for strategies that trade less liquid assets. A strategy that looks great backtested on DOGE/USD with assumed zero slippage might be physically impossible to execute at those prices because the order book cannot absorb the position size without moving the price significantly.
Realistic slippage modeling requires actual order book data, not just OHLCV candles. If you are backtesting with candle data and assuming execution at the close price, you are being optimistic by a margin that often exceeds the strategy's entire edge.
Regime Changes
Markets change. Volatility regimes shift, correlations break down, new participants enter, regulations change, and the macroeconomic backdrop evolves. A strategy calibrated to the 2020-2021 bull market, with its low interest rates and massive retail inflows, will behave differently in a higher-rate environment with different participant composition.
The subtlety is that regime changes are only obvious in hindsight. You cannot know in advance when the market structure that your strategy depends on will shift. What you can do is test your strategy across multiple regimes if the data is available, and you can monitor the strategy's real-time performance against its expected performance to detect when something has changed.
Look-Ahead Bias
This is the most insidious bug in backtesting code. Look-ahead bias occurs when your strategy inadvertently uses information that would not have been available at the time of the trade. Common examples: using the daily close price to make a decision at market open, using an indicator that gets revised after initial publication, or using data that arrives with a delay (like exchange reserve data that might have a 1-hour reporting lag).
In code, look-ahead bias often appears as an off-by-one error in indexing. If your signal at time t uses data from index t instead of t-1, you are looking ahead. This is easy to introduce and hard to catch by inspection. The best defense is to run your backtest engine in strict event-driven mode, where the strategy only ever sees data that has already been "published" according to realistic timestamps.
What Survives the Translation to Live
Strategies that tend to work in live trading share certain properties. They have few parameters. They are based on a clear economic rationale, not just a pattern in the data. They degrade gracefully with parameter changes. They have been tested across multiple time periods and market conditions. And they account for realistic execution costs.
None of this guarantees success, but it shifts the odds. The default outcome, that a backtested strategy fails in live trading, is the base rate you are trying to beat. Understanding exactly why strategies fail gives you a systematic way to stress-test your work before you put real capital at risk.