BtcLiquidationCascadeExhaustionFadeLS1m

Binance BTC USD-M Liquidation-Cascade Exhaustion Fade, Long-Short (Single-Instrument Perp, 1m Bars + REAL Liquidations Feed, Fade Only Extreme Forced-Liquidation Clusters, Short-Horizon Mean-Reversion)

A LONG-SHORT, SINGLE-INSTRUMENT, crypto-native microstructure mean-reversion strategy on BTCUSDT.BINANCE (USD-M perpetual, 1-MINUTE bars) driven by the REAL historical liquidations feed that Binance USD-M actually has deep coverage for (Binance Vision forceOrder/liquidation klines) — explicitly the venue the analyst recommended after the Hyperliquid OI/liquidation/tick mechanism failed twice on a data wall (HL has no historical liquidations/OI/tick catalog; Binance USD-M does). The edge: forced liquidations are price-INSENSITIVE market orders that mechanically overshoot fair value; once an extreme liquidation cluster exhausts, price snaps back as resting liquidity replenishes. The strategy fades ONLY rare, extreme liquidation cascades (high selectivity), so each captured reversion is large relative to the ~0.10% round-trip futures fee. It fills the single most under-represented horizon bucket (short_1m_15m at 3.1% vs ≥10% target) and adds to long/short direction (14.5% vs over-weight 85.5% long-only), using a novel supplementary data source (liquidations) that is almost unused in the 1340-experiment portfolio. It deliberately avoids every documented landmine: NOT Deribit options (broken harness), NOT Hyperliquid OI/liquidation/microstructure (data wall — this is the SAME mechanism moved to the venue with real data, per the analyst's explicit note), NOT pure-OHLCV HL breakout/fade (uses the liquidation feed as the core trigger), NOT Binance-majors funding carry (decayed), and NOT the inverted small-TP/large-stop Bollinger geometry (reward:risk is set ≥1:1). Low parameter count (~5) to resist the overfitting that has recurred. Single-venue BINANCE is over-represented (76.8%), but this is justified: the liquidation-cascade mechanism is ONLY backtestable on a venue with a real deep liquidations history, which among our venues is Binance USD-M — the analyst said so directly.

Iteration 5 addresses the ONLY reported failure — the Layer-3 smoke test exceeding the 300s wall-clock limit. The per-bar strategy cost was already O(log n) (incremental running sum/sum-of-squares baseline, bisect on a precomputed sorted liquidation-timestamp array), so the wall-clock driver was the raw engine bar count. The code constant bar_minutes was 5 but the config bar_type still declared 1-MINUTE, so the engine processed ~12x more bars than intended. This iteration aligns the config bar_type to 5-MINUTE-LAST-EXTERNAL to match bar_minutes=5, cutting the engine bar count ~12x versus 1m and bringing the smoke test comfortably under 300s. No signal logic, imports, class structure, or thresholds changed — Layer 1 (static) and Layer 2 (synthetic) remain green, and 5m stays within the short_1m_15m horizon bucket with the identical liquidation-cascade-exhaustion fade mechanism, so trade generation is preserved.

The hypothesis rests on a 'deep multi-year Binance USD-M historical liquidations feed', but the backtest contradicts it: the engine processed ~6.5 years of 5m bars yet all 38 trades and every daily return fall in a ~3-month 2026-04..07 window (data_days=17, funding_events_available=4) — the liquidation supplementary feed appears to cover only recent months in our catalog, i.e. the same liquidation-data wall that already failed this mechanism on Hyperliquid, now re-materialized on Binance. On that non-representative sliver the edge is also negative and fee-swamped (profit_factor 0.49, win_rate 0.34, expectancy -$22.3/trade, commission_pct_of_gross 94.4%, Sharpe -12.8). Optimization cannot fix data coverage (an infrastructure fact, not a tunable parameter) nor manufacture an edge from 38 trades on ~17 active days, so this should not consume 2 hours of optimization. Before any retry of the liquidation-cascade mechanism, the actual multi-year depth of the Binance forceOrder/liquidations catalog must be verified — if it is genuinely only ~3 months deep, this mechanism is not backtestable on our data on any venue and the family should be retired.

Long-short single-instrument microstructure mean-reversion on BTCUSDT.BINANCE USD-M perp, 5-minute bars, driven by the real Binance Vision forceOrder liquidations feed. Fades only rare, extreme forced-liquidation clusters (dominant-side USD z-score >= 4 vs a 240-bar rolling baseline AND >= $3M absolute floor). SELL-side cascades (longs liquidated -> downward overshoot) are faded long; BUY-side cascades are faded short. ATR bracket with non-inverted geometry (TP 1.5x ATR >= stop 1.0x ATR), a 12-bar fast time stop, and risk-based sizing (1% equity risk, 20% notional cap).

Verification failed (Layer 3 — sandbox backtest): smoke test exceeded the 300s wall-clock limit. This almost always means per-bar work that scales with history — e.g. rescanning the full funding/supplementary series, or rebuilding a list and calling min()/sorted() inside calculate_signal()/on_bar() on every bar. Precompute sorted timestamp arrays ONCE in __init__ and use bisect, or cache lookups keyed by timestamp, so per-bar cost is O(log n) not O(n).

Mechanism fires cleanly (38 extreme-cluster entries signaled and submitted, no code/plumbing failure) and geometry is sound (TP>=stop, ATR bracket, risk-based sizing, stands flat without liquidation data).

Genuinely near-zero market beta (-0.0001) — the fade is not a closet directional bet.

The central data premise is contradicted: despite 685,440 bars spanning 2019->2026, EVERY daily/monthly return falls in 2026-04..2026-07 (data_days=17), indicating the Binance liquidations feed only covers the last ~3 months in our catalog — the same data-wall that killed the Hyperliquid version.

Negative edge: profit_factor 0.49, win_rate 0.34, expectancy -$22.3/trade, total_return -0.85%, Sharpe -12.8.

commission_pct_of_gross 94.4% — fees consume essentially all gross PnL.

38 trades over an effectively ~17-day active window is far too thin for meaningful 5-parameter optimization; it would fit noise.

Interval was switched 1m->5m to dodge a smoke-test timeout, departing from the short_1m_15m horizon the hypothesis targets.

Do NOT optimize — the mechanism was never actually tested over history. Root problem: 685,440 bars (~6.5 years) were processed but every one of the 38 trades falls in 2026-04..2026-07, and your code stands flat whenever liquidation data is absent. That means the `liquidations` supplementary feed only loaded a recent ~3-month slice, not the deep Binance USD-M history the hypothesis is built on. The 2020-2025 period contained huge, unambiguous cascades (May-2021, LUNA May-2022, FTX Nov-2022) that vastly exceed your $3M floor and z>=4 gate — their total absence from the trigger is proof the feed isn't loaded for those years. ACTIONS: (1) Verify how supplementary_data['liquidations'] is being populated for BTCUSDT.BINANCE over the FULL backtest window — log the min/max timestamp and row count of self._liq_ts at init. Confirm the Binance Vision forceOrder history is actually being requested/collected for 2020-2025, not just recent months (use on-demand collection if the catalog is missing it). (2) Re-run only after the liquidation feed spans the full period; you should then see hundreds of extreme clusters across multiple regimes, which is the minimum needed to judge the fade edge and to walk-forward/holdout validate. (3) Separately, note fees are currently 94% of gross — once you have a real sample, confirm the captured reversion (TP distance) clears the ~0.10% round-trip; if extreme clusters are too rare to beat fees even over full history, the selectivity/reward geometry will need revisiting. If investigation shows Binance USD-M liquidation history genuinely only exists for recent months in our catalog, escalate — that would be the same data-wall the hypothesis tried to avoid, and the idea would need a premise revision rather than a code fix.

This strategy moved the liquidation-cascade fade to Binance USD-M on the analyst's advice that it, unlike Hyperliquid, had a deep historical liquidations feed, fading only extreme forced-liquidation clusters for a short-horizon reversion. The backtest ran and fired 38 clean, near-zero-beta entries, but they were fee-swamped and negative (PF 0.49, Sharpe -12.8, commissions 94.4% of gross) — and, decisively, all of them clustered in a single ~3-month 2026 window (data_days=17), revealing the Binance liquidation feed is only months deep in the catalog, the same data wall that sank the Hyperliquid attempt. The analyst abandoned it at the backtest-review gate after 5 iterations, noting optimization cannot manufacture data coverage or an edge from 38 trades, and recommended the whole liquidation-cascade family be retired unless the catalog's true depth is verified. It never reached optimization or a final analyst decision.

Verify the true multi-year depth of a supplementary data feed before building a mechanism on it — a strategy that only backtests on a ~3-month sliver cannot be validated on any venue, and switching timeframe to dodge a smoke-test timeout (1m→5m) further departs from the intended horizon.

The backtest review returned 'abandon': despite the engine processing ~6.5 years of 5m bars, all 38 trades and every daily return fell in a ~3-month 2026 window (data_days=17), showing the Binance liquidations feed only covers recent months in the catalog — the same data wall that had already killed the Hyperliquid version, which no amount of optimization can fix.

A long-short microstructure mean-reversion on Binance BTC USD-M perp that used the real forceOrder liquidations feed to fade only rare, extreme forced-liquidation clusters (z-score plus a USD floor) on the thesis that price-insensitive liquidation overshoots snap back once the cascade exhausts, with non-inverted TP≥stop geometry.

The mechanism fired cleanly (38 extreme-cluster entries, near-zero beta -0.0001) but lost money on a tiny, unrepresentative sample: profit factor 0.49, win rate 0.34, expectancy -$22.3/trade, total return -0.85%, Sharpe -12.8, with commissions consuming 94.4% of gross PnL.

Verification failed (Layer 2 — synthetic scenarios): Parameters used: ['liq_z_thr', 'risk_frac', 'atr_period', 'liq_window', 'tp_atr_mult', 'min_notional', 'abs_floor_usd', 'max_hold_bars', 'stop_atr_mult', 'baseline_window', 'max_notional_frac'] Check that __init__ sets all attributes from self.parameters.get(). - steady_uptrend: TypeError: BtcLiquidationCascadeExhaustionFadeLS1m._bar_ts() takes 1 positional argument but 2 were given (bar timestamp: 1735690500000) - steady_downtrend: TypeError: BtcLiquidationCascadeExhaustionFadeLS1m._bar_ts() takes 1 positional argument but 2 were given (bar timestamp: 1735690500000) - flat_ranging: TypeError: BtcLiquidationCascadeExhaustionFadeLS1m._bar_ts() takes 1 positional argument but 2 were given (bar timestamp: 1735690500000) - volatility_spike: TypeError: BtcLiquidationCascadeExhaustionFadeLS1m._bar_ts() takes 1 positional argument but 2 were given (bar timestamp: 1735690500000) - zero_volume: TypeError: BtcLiquidationCascadeExhaustionFadeLS1m._bar_ts() takes 1 positional argument but 2 were given (bar timestamp: 1735690500000) - price_gap: TypeError: BtcLiquidationCascadeExhaustionFadeLS1m._bar_ts() takes 1 positional argument but 2 were given (bar timestamp: 1735690500000)