Designing a trading strategy that faithfully mirrors real-world performance is far from a simple task. The process is fraught with challenges, technical limitations, and potential pitfalls. Many strategy creators employ questionable methods or “optimizations” that produce visually impressive but ultimately unrealistic results. In addition, there are inherent constraints within the backtesting process that every trader should understand before relying on historical simulations.
Below are some of the most significant considerations when attempting to bridge the gap between backtests and live trading results.
1. The risk of repainting – calc_on_order_fills = true
When the parameter calc_on_order_fills = true is enabled within a strategy, TradingView’s Backtesting Engine performs an additional calculation inside the same bar after the order has been executed. This allows the strategy to access complete bar data — including its high and low — after the candle has closed.
Some developers exploit this by retroactively placing entry and exit orders at the most favorable points on a closed candle, creating an appearance of precision that would be impossible in live trading. This practice is known as repainting. We never use this parameter in our strategies, as it compromises the integrity of any performance data.
2. Real-Time Fluctuations vs. Closed-Bar Data
Consider a buy signal based on the price crossing an exponential moving average (EMA). In real time, the EMA value changes dynamically as each bar evolves, meaning the actual trigger point can occur at a different time than what appears once the bar has closed. This phenomenon affects nearly all technical indicators.
For consistency between backtests and live trading, our strategies only use offset data — indicator values from the previous fully closed bar. This ensures that decisions are based on fixed, non-fluctuating data, removing the discrepancies between historical testing and live execution.
3. Data Availability Limitations
On TradingView, even with a Premium subscription, backtests (outside of deep backtesting feature) are limited to a maximum of 20,000 bars of data. On a 15-minute chart, this equates to roughly seven months of historical data — and less if using lower plans.
Many strategies appear profitable over a short, favorable period but fail when market conditions change. We began developing our strategies years ago, refining parameters through multiple market cycles. Our testing spans back to early 2018 — a period that included extreme volatility, ranging markets, and prolonged trends. The result is a system that has not only remained profitable but has also adapted to changing market dynamics.
4. Market Liquidity and Execution Lag
When trades are automated, the process from signal generation to execution involves multiple steps:
The TradingView script sends a signal to a trading bot (e.g., 3Commas).
The bot receives the signal and processes the trade instructions.
The bot sends the order to the exchange, executing a market entry and placing safety orders.
We use market orders for initial entries to ensure rapid execution, but this can introduce minor slippage — the larger the order size and the lower the asset’s liquidity, the greater the potential impact. Additionally, even though the signal-to-execution process happens in milliseconds, small delays can result in price differences between the intended and actual execution point.
Based on our real-capital testing, these deviations are minimal, and the backtest results are closely reflected in live trading outcomes — even when accounting for slippage and latency.
Backtests are a powerful tool, but only when built with realistic assumptions and without exploiting parameters that can artificially inflate results. We design our systems to operate with integrity, ensuring that what you see in testing is what you can expect in the real market.
