SolLiquidationCascadeExhaustionFadeLS

SOL Liquidation-Cascade Exhaustion Fade, Long-Short (Binance USD-M, 15m Bars + Real Liquidation Feed, Fade Forced-Order Overshoot After Confirmed Exhaustion — Deep-History Venue, Favorable Reward:Risk Geometry)

A LONG-SHORT, single-instrument crypto-native MICROSTRUCTURE reversal strategy on SOLUSDT.BINANCE USD-M perpetual using 15-MINUTE bars CONFIRMED BY THE REAL BINANCE LIQUIDATION FEED (forced-order/forceOrder data, which Binance USD-M has with multi-year depth). It deliberately targets four under-represented portfolio buckets at once: SHORT-horizon (1m–15m, only 4.0% of portfolio vs ≥10% target), LONG-SHORT direction (only 13.5% vs the ≤55% long-only cap), the crypto-native microstructure family (almost entirely absent), and it does so WITHOUT touching the Binance trend/momentum graveyard (it is a fade, not a breakout/continuation). Forced liquidations are price-insensitive market orders dumped by the exchange's liquidation engine; in a cascade they mechanically overshoot fair value by ~0.5–2% on SOL before passive liquidity refills. Pure-OHLCV strategies cannot distinguish a forced cascade from organic momentum — the liquidation feed is what makes this edge observable. CRITICAL DESIGN CHOICES driven by prior factory failures: (1) it runs on BINANCE USD-M, NOT Hyperliquid — the two prior liquidation/OI-fade attempts died on HL's data wall (no historical liquidation/OI feed); the meta-notes explicitly prescribe 'target a venue with real historical OI/liquidation data (e.g. Binance USD-M)'. (2) It fades ONLY confirmed exhaustion (reversal candle + decaying liquidation spike), never mid-cascade, to avoid knife-catching. (3) The exit geometry is REWARD-FAVORABLE (TP distance > SL distance), the exact opposite of the COIN-M Bollinger fade that died on small-TP/large-SL inverted payoff. (4) SOL is chosen over BTC because its cascades are larger-amplitude, keeping the per-trade reversion comfortably above the ~0.15% futures fee threshold. It is intentionally low-parameter and single-instrument (simpler beats diverse, per the equal-weight-basket edge-dilution failure).

Iteration 2 fixes the degenerate run (0/29 wins, avg_position_pct 249%) with the smallest changes off previous_code, preserving the already-passing Layer 1-3 scaffolding and the verified-correct side->fade mapping (data_spec line 106: side='SELL' => long liquidated => forced selling => price down => fade BUY; no inversion needed). (1) Win rate: the 0-win, ~1-bar-hold pattern is bar-1 stop-outs from knife-catching a resuming cascade; widened ATR room (SL 1.0->1.5, TP 2.0->2.5, still reward-favorable TP>SL) lets the reversion survive a one-bar continuation. (2) Sizing: added an explicit notional ceiling notional <= equity*leverage*max_notional_frac (0.5) plus integer-SOL rounding (step size 1), so avg_position_pct sits ~50%, well inside the leverage cap, instead of relying on a clamp that wasn't binding. Leverage set explicitly to 1.0. (3) Data coverage: added [LIQ-FEED] startup logging of event count and min/max timestamp, and [FADE-SETUP] per-entry logging of cascade side, side_sign, fade direction and SL/TP distances, so the analyst can verify the fade direction and confirm whether the Binance liquidation feed is data-walled to a recent window (data_spec line 107 warns it is live-stream only with no historical feed) before optimizing.

Data-wall + no edge. The liquidation feed only covers a ~2-month recent window (all 50 trades cluster in 2026-04..2026-06) despite 5.8 years of bars processed, so the 'deep-history Binance USD-M liquidation feed' premise fails in the available backtest data exactly as the prior Hyperliquid liquidation/OI-fade attempts did. Within the only tradeable window the fade is decisively negative (Sharpe -16.7, PF 0.23, win_rate 0.36, expectancy -$96/trade, all months negative) with avg_loss 2.4x avg_win despite reward-favorable TP>SL geometry — classic knife-catching that 'confirmed exhaustion' did not prevent. 50 trades over ~11 active days is too small to optimize (would fit noise), and the binding constraint is liquidation-data availability, which the developer cannot fix by tuning. Matches the known liquidation-fade data-wall failure pattern; abandon rather than spend 2 hours optimizing.

Long-short 15m liquidation-cascade exhaustion fade on SOLUSDT.BINANCE USD-M perp. Buckets the real Binance liquidation (forceOrder) feed to 15m, detects a top-percentile cascade over a short lookback, and fades the overshoot ONLY after confirmed exhaustion (peak is a prior bar, liquidation spike decayed below decay_frac*peak, and a reversal candle prints in the fade direction). Long-liquidation cascades (forced selling, price down) trigger a BUY snap-back; short-liquidation cascades trigger a SELL fade. Reward-favorable ATR exits (TP 2.5 ATR > SL 1.5 ATR) with a fast 8-bar time stop. Notional-capped, integer-contract sizing.

Well-engineered code with explicit data-coverage diagnostics and reward-favorable (TP>SL) geometry

Correctly targets under-represented buckets (short-horizon, long-short, microstructure) and avoids the trend/breakout graveyard

Liquidation feed only covers a ~2-month recent window (all 50 trades fall in 2026-04..2026-06) despite 5.8 years / 202,628 bars processed — the 'deep-history Binance USD-M liquidation feed' premise is false in the available data; this is the same data-wall that killed prior liquidation-fade attempts

Decisively negative within that window: Sharpe -16.7, profit_factor 0.23, win_rate 0.36, expectancy -$96/trade, every month negative

avg_loss is 2.4x avg_win even with TP>SL geometry — fades are being run over (knife-catching), so 'confirmed exhaustion' gating is not producing an edge

Only 50 trades over ~11 active days — far too small a sample to optimize 14 parameters without fitting noise

Do NOT optimize — the run is degenerate (metrics_reliable=false, 0/29 win rate). Fix and re-run the initial backtest first: 1) ZERO WINS (0/29) is the priority. A reward-favorable fade that never wins, with ~1-bar holding (avg_holding_period 16m), means entries stop out on the very next bar. Add diagnostic logging at each entry: the cascade side (peak long vs short), side_sign, the fade direction submitted, and the price move over the following 4-8 bars. Verify the fade is going the RIGHT way: a long-liquidation cascade (side='SELL', forced selling, price down) must trigger a BUY snap-back. Confirm side_sign mapping and the bullish_rev/bearish_rev candle logic actually align with the cascade direction — a sign inversion here would produce exactly this 0-win result. Also check that you are not entering while the cascade is still going (peak_is_current guard) — confirm the 1-ATR SL isn't being hit because price keeps falling after entry. 2) POSITION SIZING: avg_position_pct is 249% — the max_qty leverage clamp is not binding. With qty=(equity*risk_frac)/sl_dist, a small ATR produces a huge qty; verify sl_dist (=sl_atr*ATR) is in PRICE units consistent with `price`, that leverage is explicitly set (it defaults to 1.0 → cap should be ~100% notional), and that the clamp actually caps notional. Target avg_position_pct at/under the intended ceiling. 3) DATA COVERAGE (critical): all 29 trades fall in 2026-04 to 2026-06 despite a 2020-2026 span and 199K bars. Print the min/max timestamp and event count of supplementary_data['liquidations'] at startup. If the liquidation feed only covers recent months, the 'deep-history Binance USD-M' premise fails and there is no walk-forward sample — confirm the full-history Binance forceOrder feed is being injected before proceeding. If it genuinely only exists for a short recent window, this hypothesis is data-walled on Binance too and should be reconsidered. Acceptance gate before optimization: win_rate plausibly > 0 with some winners, avg_position_pct within the leverage cap, trades spread across the full backtest period (not just 2 months), and metrics_reliable=true.

This strategy was a carefully engineered second attempt at a crypto-native edge: fading the mechanical overshoot of liquidation cascades on SOL, deliberately moved to Binance USD-M (rather than Hyperliquid) and given reward-favorable TP>SL geometry specifically to avoid the failure modes of prior attempts. In the backtest, however, the same data-wall reappeared — the liquidation feed spanned only a ~2-month window, so despite 5.8 years of bars only 50 trades over ~11 days were generated, and they were sharply unprofitable (Sharpe -16.68, profit factor 0.23, expectancy -$96/trade) with losses running over the 'confirmed exhaustion' fades. The analyst abandoned it at the backtest-review gate rather than spend hours optimizing 14 parameters on a tiny, noise-dominated sample whose core constraint — historical liquidation data — could not be fixed by tuning. After 2 iterations it never advanced past backtest review to optimization or risk analysis.

Verify the actual historical depth of a supplementary data feed (liquidations/OI) before building on it — the binding constraint here was data availability the developer could not tune away, repeating the prior liquidation/OI-fade data-wall failure.

It was abandoned at the pre-optimization backtest-review gate (verdict: abandon); the liquidation feed only covered a ~2-month recent window — all 50 trades clustered in ~11 active days despite 202,628 bars / 5.8 years processed — so the 'deep-history Binance USD-M liquidation feed' premise failed, and within that window the fade showed no edge. Optimization, analyst, and risk-review stages were never reached.

A long-short, single-instrument 15m microstructure reversal on SOLUSDT.BINANCE USD-M perp that used the real Binance liquidation feed to fade the price overshoot of forced-liquidation cascades only after confirmed exhaustion (decayed liquidation spike plus reversal candle), with reward-favorable TP>SL geometry.

Decisively negative over the only tradeable window: total return -4.82%, Sharpe -16.68, profit factor 0.23, win rate 0.36, and expectancy -$96.40 per trade across 50 trades (28 long, 22 short). Despite the TP>SL design, avg loss (~$196) ran ~2.4x avg win (~$81), and every month was negative.