All 50 configs I've deep-tested past the GPU screen so far share one entry family — range_bottom_reclaim — spread across four symbols: MEGAUSDT, BILLUSDT, LIGHTUSDT, ARIAUSDT. 72,872 trades combined. Most of them close the way the strategy intends: price reclaims a range low, the take-profit target fires, done. But not all of them. 2,129 trades (2.92%) got force-closed by final invalidation — the hard stop level where the trade thesis is just dead. Another 3,194 (4.38%) ran out the clock on a time stop before ever reaching target. Combined, 7.3% of every trade in this dataset never got to resolve on its own terms.
That 7.3% isn't evenly spread. It clusters hard around one variable: how long the trade was open.
Hold time vs forced-exit rate, config by config
I took avg_hold (minutes) and the combined rate of time_stop_rate + fi_rate for each of the 50 configs and ran the correlation. 0.88. That's a strong, close-to-linear relationship for backtest data — the kind of number I usually only see when one metric is mechanically driving the other, not just loosely associated with it.
| Symbol | Configs | Avg hold | Final-invalidation rate | Time-stop rate | Combined forced-exit |
|---|---|---|---|---|---|
| BILLUSDT | 9 | 11.3 min | 4.22% | 1.51% | 5.73% |
| MEGAUSDT | 30 | 12.4 min | 2.31% | 3.19% | 5.50% |
| LIGHTUSDT | 3 | 19.9 min | 1.98% | 6.54% | 8.52% |
| ARIAUSDT | 8 | 39.7 min | 4.84% | 9.69% | 14.53% |
50 deep-tested range_bottom_reclaim configs, 72,872 trades. avg_hold, fi_rate, and time_stop_rate averaged per symbol across each symbol's config set.
The two extremes
Zoom into single configs instead of symbol averages and the gap widens further. My fastest-closing config — a BILLUSDT setup averaging 6.0 minutes per trade — had a combined forced-exit rate of 3.3%. My slowest, an ARIAUSDT config averaging 41.6 minutes, had 14.8%. That's a 4.5x jump in forced-exit rate between the fastest and slowest config in the shortlist, driven by nothing but how long the trade stayed open.
It makes mechanical sense once I look at what a time stop actually is: a clock, not a price level. The longer a config's time_stop_min setting lets a trade run, the more opportunities it has to still be open when that clock runs out — and every extra minute open is also another minute for price to wander down into the final-invalidation level instead of back up to target. Hold time isn't just correlated with forced exits. It's most of the mechanism behind them.
Where this doesn't match win rate
I also checked avg_hold against headline win rate directly, expecting a cleaner story. It's weaker: -0.41. Negative, meaning longer holds do trend toward lower win rates, but nowhere near as tight as the 0.88 on forced exits specifically. That gap matters. Win rate blends every way a trade can close — including small wins salvaged by a DCA add — into one number, and I've written before about how easily DCA can prop win rate up regardless of what's actually happening underneath. Forced-exit rate skips that blending. It only asks one question: did the trade get to resolve on the strategy's own terms, or did a clock or a hard stop end it first? That's the number that tracked hold time almost one-to-one.
What I'm changing
Before this I sized every deep-tested config off win rate, profit factor, and MAE. Now avg_hold gets checked against forced-exit rate before anything else, because it's a cheap way to flag a config that's structurally more likely to get taken out of the market before its edge has a chance to show up. A 40-minute average hold isn't disqualifying by itself, but a config in that range needs slack in its time-stop setting and its position sizing needs to assume roughly 1 in 7 trades ends in a forced exit, not the 1 in 20 the fast configs get. Same entry logic, same family, four different failure rates — and the clock, not the symbol, is what set them.
Before you trust a backtest's hold-time numbers
- Pull avg_hold next to forced-exit rate, not just win rate. Correlation was 0.88 across 50 of my configs — hold time is close to a direct driver, not a side note.
- Separate time-stop exits from real stop-outs. 4.38% of my 72,872 trades ran out the clock; 2.92% hit a hard invalidation level. They're different failure modes with different fixes.
- Don't assume win rate already captures this. Hold time only correlated -0.41 with win rate — much weaker than the 0.88 on forced exits, because win rate blends in DCA saves.
- Size positions for the config's actual forced-exit rate, not a flat assumption. My slowest config forced out 1 in 7 trades; my fastest, 1 in 30.
→ Stop-loss hit probability calculator · → DCA survival calculator · → Risk of ruin calculator
FAQ
Does a longer hold time mean a backtest trade is more likely to lose?
Not directly to lose, but to get forced out instead of hitting a clean take-profit. Across 50 deep-tested range_bottom_reclaim configs I ran, avg hold time and the combined rate of time-stop plus final-invalidation exits correlate at 0.88. Configs where trades sat open around 42 minutes on average had a 14.8% forced-exit rate; configs where trades closed in about 6 minutes had 3.3%. A forced exit isn't always a loss, but it means the trade never reached the target price on its own terms.
What is a time stop in a backtest and why does it matter?
A time stop closes a trade once it's been open past a fixed duration, regardless of price, so a strategy doesn't hold dead capital indefinitely waiting for a target. In my 72,872-trade sample across 50 configs, 3,194 trades (4.38%) closed via time stop rather than hitting take-profit. That rate climbed sharply the longer a config's average hold time ran, from under 2% on the fastest configs to over 10% on the slowest.
What is final invalidation in a backtest strategy?
Final invalidation is the hard stop-loss level in my range_bottom_reclaim setup — the price point where the trade thesis is dead and the position closes for a real loss, separate from a time stop or a take-profit. Across the full 72,872-trade sample, 2,129 trades (2.92%) closed this way. It was the rarer of the two forced-exit types, but still correlated with hold time: the longest-held configs saw final-invalidation rates 2-3x the shortest-held ones.
Should I set a shorter time stop to avoid forced exits?
On this data, hold time and forced-exit rate move together, but that doesn't mean shortening the time stop fixes it — the underlying setups holding longer (ARIAUSDT range_bottom_reclaim configs in my sample) needed more room for the entry to resolve at all. Cutting the clock early on those just converts a would-be time-stop exit into an earlier, less-informed one. The fix is checking a strategy's average hold time against its forced-exit rate before sizing it, not shortening every clock by default.