Published
My 50-config deep-test shortlist covers four symbols: MEGAUSDT (30 configs), BILLUSDT (9), ARIAUSDT (8), LIGHTUSDT (3). Each config logs max_mae, the average worst unrealized loss its trades sank into before closing. I went looking at how much that number moves when I change a config's stop placement. For two of those four symbols, the answer is: not at all. Not "barely" -- identical, out past the 10th decimal place, across every parameter combination I tested.
Same symbol, same family, one number
All 30 MEGAUSDT configs are range_bottom_reclaim variants with final-invalidation levels spread from -3.5605% to -3.9999%, a 0.44 percentage-point range, and five different time-stop settings (45, 60, 75, 90, 120 minutes). Every single one of those 30 configs reports max_mae of -14.236890103748815%. Not close. The exact same float. LIGHTUSDT does it too, at a smaller scale: 3 configs, final-invalidation spread across 0.07 points, two time-stop settings, and all three land on -10.17849995667211%.
That's 33 of my 50 shortlisted configs -- two-thirds of the list -- where changing the stop, the time limit, or the take-profit target never once touched the worst-case drawdown number.
| Symbol | Configs | Final-invalidation spread | Time-stop settings | max_mae range |
|---|---|---|---|---|
| MEGAUSDT | 30 | 0.44pp | 5 | 0 (identical) |
| LIGHTUSDT | 3 | 0.07pp | 2 | 0 (identical) |
| BILLUSDT | 9 | 0.26pp | 4 | 1.29x |
| ARIAUSDT | 8 | 0.41pp | 2 | 2.65x |
pp = percentage points of final-invalidation spread across that symbol's configs. max_mae range = ratio of worst to best max_mae value among that symbol's configs.
Read that table against intuition and it runs backwards. MEGAUSDT has the widest final-invalidation spread of any symbol on the list, more time-stop variety than any of them, and zero drawdown movement. ARIAUSDT has a narrower parameter spread and the biggest drawdown swing I've found anywhere in this shortlist -- 2.65x, which I wrote about in September when I thought the story was purely "small stop changes, big drawdown changes." It's not purely that. It's true for half my symbols and flatly false for the other half, and the half where it's false aren't the ones with less room to move.
Two explanations, and I can't fully rule either out
One: a single historical candle for MEGAUSDT and LIGHTUSDT is so far past every final-invalidation level I tested that every config's worst trade gets caught by the same move regardless of where the stop sits. If the real worst wick blew through -14.24% and my tightest tested stop was -3.56%, the stop should have fired well before that -- so this explanation requires the exit to not actually be capping the loss the way I assume, which is its own problem.
Two: something upstream in my logging computes max_mae once per symbol -- off one representative run, or a pre-scan stage -- and copies it into every per-config row for that symbol, rather than recalculating it from each individual backtest. BILLUSDT and ARIAUSDT would then be the two symbols where that shortcut, if it exists, didn't get taken.
I don't have a clean way to tell these apart from the exported table alone, and I'd rather say that directly than pick the more flattering one. What I do know: I was treating max_mae as a number that reflects the specific stop and time-limit I chose for that specific config. For 33 of 50 rows in my own shortlist, it doesn't reflect that at all -- it reflects something about the symbol, full stop, and I don't yet know what.
What I'm doing about it
Before sizing a MEGAUSDT or LIGHTUSDT position off max_mae, I'm now checking whether that symbol's configs show any variation at all. If they don't, the number isn't telling me "this stop produces this drawdown" -- it's telling me a floor or a ceiling exists somewhere in the data that none of my tested parameters reached. That's a different kind of information, and sizing off it the way I'd size off a parameter-sensitive number would be a mistake. Next step on my list is re-running the MEGAUSDT max_mae calculation from raw trade logs instead of the exported table, specifically to rule explanation two in or out -- I'll write up whichever it turns out to be.
Method: 50 deep-tested configs from our own backtest shortlist (the same pipeline behind backtest-reports.html), 72,872 trades combined, one strategy family (range_bottom_reclaim), four symbols. final_invalidation_pct, time_stop_min, base_tp_pct and max_mae are the pipeline's own logged per-config fields.