The configs that need their DCA rescue most often also win most often. That's not what I expected.

Our screening pipeline logs a field called dca1_rate for every config it tests: the percentage of trades where the position moved against us enough to trigger the first average-down add before the trade closed. I went in assuming this would be a quiet red flag — a config that needs to rescue itself on most of its trades sounds like one with a bad entry rule, propped up by throwing more money at losing positions. I ran the numbers across 12,331 config rows (five strategy families, trades ≥ 20 for a fair sample) and sorted by how often DCA1 fires. The result is the opposite of what I expected.

Heavier DCA reliance → higher win rate, higher profit factor

That's a straight climb on every column. Configs where the DCA1 add almost never fires average a 54.21% win rate and barely-positive 0.0081 expectancy per trade. Configs where it fires on 60-80% of trades average a 75.88% win rate and 0.1088 expectancy — more than 13x higher. Checked the other way: among the rarely-DCA group (under 20% fire rate), 367 of 727 configs (50.5%) are outright net losers (profit factor below 1.0). Among the heavy-DCA group (60%+ fire rate), only 208 of 2,738 (7.6%) are. On this data, needing the rescue often is not the warning sign I assumed — it's associated with configs that survive.

But those 208 are exactly why you don't stop at win rate

The 208 heavy-DCA configs that still net-lose average a 67.17% win rate — well above the group that barely uses DCA at all. One concrete example from the table: a pullback_reclaim config on SENTUSDT wins 86.9% of its 1,200 logged trades, with DCA1 firing on 78.4% of them. Profit factor: 0.98. It loses money overall. Compare that to a pullback_reclaim config on MEGAUSDT with almost identical shape — 93.95% win rate, DCA1 firing 80.95% of the time, 2,000 trades — and a profit factor of 2.08, a strong net winner. Same strategy family, same DCA-heavy profile, same ballpark win rate. One prints money, one bleeds it, and the only way to tell them apart is to look past the win rate at the size of the wins versus the size of the losses.

The mechanism is simple once you see it: DCA1 converts some trades that would have stopped out small into trades that close as a win, which inflates win rate directly. But it also means every rescued trade is carrying more capital at a worse average price, so when the rescue doesn't save the trade, the loss on that one trade is bigger than a normal stop-out would have been. A config can rescue 78% of its bad entries into small wins and still bleed more on the 22% that get away from it than it earns on the rest — which is exactly what happened to the SENTUSDT row above.

What I actually do with this

I stopped treating dca1_rate as a screening red flag by itself — on this dataset it's closer to the opposite, correlating with the configs that made it to GOOD_FOR_DEEP_TEST most often. But I never let a win rate pass review without checking profit factor and expectancy next to it, because win rate and DCA reliance can both look great on the same row that's quietly losing money. If you're running your own DCA-style setup, the DCA survival calculator will tell you how far price can move against your averaging before you're out of capital to rescue with — which is the real constraint a backtest's clean dca1_rate number doesn't show you. And before trusting any win-rate headline, run it through the profit factor calculator first; it takes thirty seconds and it's the number that actually decides whether a strategy is worth running.

Method: 12,331 rows from our own backtest archive (same data that feeds backtest-reports.html), filtered to configs with at least 20 logged trades for a fair per-config average, covering five strategy families (micro_momentum, pullback_reclaim, range_bottom_reclaim, range_bounce, volume_reversal) across live-tracked symbols. dca1_rate, win rate, profit factor and expectancy are the backtester's own logged fields, not re-derived.