Same 808 Trades, Same Net Profit, a 50-Point Win-Rate Gap

My deep-candidate report has 50 rows left after GPU screening and CPU verification. I was grouping them by symbol to see how many distinct parameter sets survived per pair, and BILLUSDT has nine. All nine run the identical 808 trades -- same symbol, same range_bottom_reclaim family, same underlying signal set, just nine different exit-parameter tweaks layered on top. I expected nine configs clustered somewhere near each other. Instead the win rate falls into exactly two groups, and nothing lands between them.

The split

Five rows land at 91.58-96.78% win rate. Four rows land at 44.43-49.88%. Nothing sits between 50% and 92% across all nine. And the column that separates them cleanly is tp_after_dca1_pct -- the profit target the trade needs to hit once it's already added to the position on the first DCA leg. Every row at 0.141% or above wins. Every row at 0.128% or below loses more than it wins. The cutoff sits right in the gap between 0.128% and 0.141%, and I didn't go looking for this split -- it fell out the moment I sorted the nine rows by win rate.

The part I didn't expect: net profit ignores the split completely

If a smaller recovery target were simply easier to hit, I'd expect the low-target rows to win more often, not less -- a 0.109% bounce off the DCA entry should print well before a 0.169% one does. It's backwards from that, and the money backs up the backwards-ness: the four losing-majority rows average $212.49 net. The five winning-majority rows average $182.06. The cluster that's wrong more than half the time made more money on this symbol than the cluster that's right nineteen times out of twenty. Profit factor stays in a tight 1.69-2.12 band on both sides of the gap, so it's not that one cluster is quietly worse on risk -- both sides have roughly comparable PF, they just get there by completely different win/loss arithmetic. A few big wins carrying a majority of losses (low-wr side) nets out close to a lot of small wins carrying a few small losses (high-wr side), on the same 808 trades, on the same coin.

One more thing worth flagging honestly: my own PARAMETER_SPACE.md documents the intended search range for tp_after_dca1_pct as 0.15% to 0.65%. The entire losing-majority cluster -- 0.109%, 0.109%, 0.117%, 0.128% -- sits below that documented floor. These are parameter-mutation artifacts from the search drifting outside the range I meant to sample, not points I'd have picked on purpose. They still cleared GPU screening and CPU verification and made the top-50 deep-candidate list with real money-equivalent net profit. I don't have a full explanation yet for why a tighter target produces fewer wins instead of more -- it's not obvious from the parameters alone, and I'm not going to pretend I traced it through the exit-priority logic for this post. What I do know, because I can just read the dollar column, is that "win rate" told me nothing about which of these nine configs to prefer.

What I'm doing with this

I'm flagging tp_after_dca1_pct values outside the 0.15-0.65 documented range for a manual review pass before anything from this symbol goes near live testing -- not because the backtest numbers are fake, but because I don't trust a parameter that produces a result I can't explain, even when the net profit looks fine. If you're staring at your own backtest and trying to decide between two configs with wildly different win rates, don't let the win-rate column break the tie by itself -- run both through a breakeven win-rate calculator against their actual average win/loss size first. On this data, the "safer-looking" 95% win rate and the "scarier-looking" 45% win rate were worth almost exactly the same amount of money.