Backtest traps – ROI

There is no need to be concerned if you use a single ROI value or a ROI table with intervals that correspond to the timeframe you are using. However, if you use a ROI table with an unusual interval that doesn’t correspond to your timeframe, you potentially fall victim to the trap. Consider the following case

# This is okay
minimal_roi = {
    "0": 0.09

# This is okay, assuming you are on 5m interval
minimal_roi = {
    "0": 0.15,
    "55": 0.1,
    "110": 0.05,
    "150": 0

# This is not okay, assuming you are on 5m interval
minimal_roi = {
    "0": 0.15,
    "53": 0.1,
    "117": 0.05,
    "151": 0

In a backtest, every exit analysis, including ROI, is performed at candle opening. This means that the duration of a trade is based on the duration of the trade at the open of each candle when deciding which ROI value to be used. As previously said, provided your ROI table is correctly constructed to match the change of ROI to coincide with candle opening, then it is OK. But let’s imagine we have such a trade and look at the third code snippet from above.

Let’s move forward to 00.50 UTC since you have a trade open at 00.00 UTC. The ROI utilized to check for exit is 15% because it is checked at the candle’s opening. At 00.55 UTC, it will perform a 10% ROI check. The problem arises when the candle at 00.50 UTC would indeed reach 10% but would never reach 15%. Depending on intra-candle movement and when it actually reaches the 10% profit in dry/live, it may or may not exit at 10%. However, in a backtest, the bot in this scenario would never exit. If this candle is a green candle, the bot would close the trade on backtest at 00.55 UTC, which would result in an insignificant difference from dry/live trading. However, what would happen if the candle at 00.50 UTC was red? The trade would thus likely be open for a longer period of time than dry/live and exit at a substantially different profit.

Therefore, using time intervals that correspond to your timeframe will help you avoid falling into the ROI trap. Without knowledge of intra-candle movement, there is no problem in terms of profit percentage because the simplified ROI assumption is sufficient to simulate dry/live as long as the above-discussed odd time interval is avoided.


  1. Thank you for the explanation. Would this still count if we use detailed backtesting? Say we use 1m to catch those odd ROI timings

    • Well, if you use 1m timeframe-detail, then there is no more backtest trap, but you might have memory issue. Honestly, having odd roi timings has no real benefit imo.

Leave a Reply

Your email address will not be published. Required fields are marked *