BtcLiquidationCascadeCounterTradeLS1H

BTC Liquidation Cascade Counter-Trade Long-Short: Fade Overshoots on BTCUSDT.BINANCE 1H Bars When Liquidation Volume Spikes Z > 3 with Concurrent 2% Price Move

A long-short mean-reversion strategy on BTCUSDT.BINANCE USD-M perpetual futures that trades counter to forced-liquidation cascades. Uses BINANCE USD-M perp bars (proven clean data) + liquidations supplementary data (PostgreSQL — distinct stream from any prior pipeline experiment). The hypothesis: when hourly liquidation volume on BTCUSDT spikes >3 standard deviations above its 30-day baseline AND price has moved ≥2% in the same direction over the prior 4 hours, the market is in a FORCED-FLOW OVERSHOOT — the marginal seller (in a long-liquidation cascade) or marginal buyer (in a short-squeeze) is mechanical, not natural. Once forced flow exhausts (typically within 4-12 hours), natural participants step in at the dislocated price and the move partially reverses. The strategy goes LONG when long-side liquidations cascade (price overshoots DOWN) and SHORT when short-side liquidations cascade (price overshoots UP). This fills FIVE under-represented buckets: long-short direction (14.2% → toward 45%), liquidations-driven mechanism (zero strategies in 459 experiments have used this data stream), crypto-specific microstructure (a TradFi-impossible edge), mid-term hold (4-12h cycles), and supplementary-data-driven (which has been clean in our catalog unlike BINANCE_SPOT bars). The mechanism is documented in crypto microstructure research (Kaiko 2022, Coin Metrics 2023) — liquidation cascades systematically produce 1.5-3% price overshoots that partially revert within 6-18 hours as the forced-flow component of order flow dissipates. Uses ONLY BINANCE USD-M perp bars + Postgres-stored liquidations data — no BINANCE_SPOT bars (which have repeatedly failed Layer 3 verification in this session). Position sizing: 15% of equity per direction. Risk per trade: 1.5% of equity capped by stop-loss.

Iteration-2 minimal fix for the Layer-3 'No trades produced' failure, with no regression of earlier layers. Root cause: the entry required a >=3-sigma liquidation spike measured in a single 1-hour bucket to coincide with directional dominance AND a >=2% same-direction 4h price move; with sparse liquidation rows the 1h bucket is frequently empty even during a real cascade, so `total` was often 0 and the triple conjunction essentially never fired. The fix keeps the mechanism 100% liquidation-driven (explicitly no price-only fallback): (1) liquidations are now summed over `liq_window_bars` hours (default 4h, the same window as the price move) so the cascade is actually captured and `total` is non-zero far more often, aligning the two halves of the signal; (2) the two numeric thresholds are relaxed (liq_z 3.0->2.0, price_move_pct 2.0->1.0) and min_events lowered 50->30 so the z-baseline is usable sooner. Imports are unchanged (Layer 1 stays green) and the z-score/trigger/exit/sizing scaffolding that passed Layer 2 is structurally identical — only one window bound and three parameter defaults changed. Venue remains BINANCE USD-M futures (long-short needs margin), leverage 1.0 (not used for amplification, so the leverage_set_but_unused gate does not trigger). If the sandbox genuinely has no liquidation rows the strategy still correctly stays flat rather than faking trades via a price proxy.

Structurally unbacktestable on the available liquidation history: the engine processed 56,208 1H bars (~6.5 years) but produced only 8 trades, ALL clustered in a single ~2-month window (2026-04-21 to 2026-06-24), with metrics_reliable=FALSE. The signal requires supplementary_data['liquidations'] rows, which the hypothesis and code both describe as sparse/live-stream-only; the trade clustering is consistent with the liquidations store holding only a recent ~2-month window, so the cascade signal can never fire across 6.4 of the 6.5 backtest years (symptom observed, not an independent audit of the Postgres table). This is a data-availability wall, not a code or parameter problem: the strategy is implemented correctly and trades faithfully when liquidation rows are present, so there is nothing for the developer to fix and no parameter to tune — 8 trades in one 2-month window cannot support walk-forward (3 windows) or a holdout, so optimization would fit pure noise. The mechanism is neither confirmed nor refuted; it simply cannot be validated. Not optimize, not iterate. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: liquidation-cascade hypotheses remain blocked until the liquidations data stream is backfilled with multi-year history (e.g. via Binance Vision liquidation snapshots) rather than live-stream-only; do not re-attempt liquidation-driven strategies until that history exists. FAILURE PATTERN: liquidations-driven strategies on BTCUSDT produce a near-empty backtest (8 trades confined to a recent ~2-month window) because the liquidations supplementary stream is live-stream-only with ~2 months of history — the mechanism cannot be validated out-of-sample and the strategy is structurally unbacktestable until the data is backfilled, the same supplementary-data-history wall seen across the OI/liquidation family.

Long-short liquidation-cascade counter-trade on BTCUSDT.BINANCE USD-M futures, 1H bars, using liquidations supplementary data. When liquidation USD volume aggregated over the prior 4h spikes >= 2 standard deviations above its ~30-day baseline AND price has moved >= 1% in the same direction over the prior 4h, it fades the forced-flow overshoot: long-side liquidations (downside cascade) -> LONG, short-side liquidations (upside squeeze) -> SHORT. Exits on a 4% take-profit, 10% hard stop, or 12-bar time stop. The signal is the signed liquidation z-score (natural units); should_enter thresholds the cached liq/price components. leverage 1.0.

Verification failed (Layer 3 — sandbox backtest): No trades produced Bar type used: BTCUSDT.BINANCE-1-HOUR-LAST-EXTERNAL, Bars processed: 56064 Diagnostics: should_enter() returned a side 0 times over 56059 evaluated bars -> your ENTRY CONDITION never triggered. Loosen the entry logic / thresholds. Ensure your strategy produces trades with the given data and parameters.

Code is correct and mechanism-faithful: when liquidation rows are present it fires as designed (8 entries, 0 dropped, long/short by cascade side); ITER-2 windowing fix works

Novel mechanism and direction bucket (first liquidations-driven long-short) — worth revisiting IF historical liquidation data becomes available

Structurally unbacktestable on available data: 56,208 bars processed but only 8 trades, ALL clustered in 2026-04-21 to 2026-06-24 (~2 months); annual_returns has only 2026

Engine flags metrics_reliable=FALSE; Sharpe -0.68 with CI -10.4 to +23.5 (meaningless on 8 trades), total_return -0.03%, profit_factor 0.92, commission 23% of gross

Liquidations supplementary stream is live-stream-only with ~2 months of history, so the cascade signal cannot fire across 6.4 of the 6.5 backtest years — no sample to optimize or validate

8 trades cannot support walk-forward (3 windows) or a holdout — optimization would fit pure noise

This strategy targeted a genuinely novel crypto-native edge — fading forced-liquidation cascades on BTC 1H, the first liquidations-driven long-short in 459 experiments — and the iter-2 windowing fix made it fire faithfully when liquidation rows existed. But across ~6.5 years it produced only 8 trades, all confined to a recent ~2-month window, with the engine marking metrics unreliable, because the liquidations supplementary stream is live-stream-only with roughly two months of history. The analyst abandoned it at the backtest-review gate on its second iteration as structurally unbacktestable — a data wall, not a code or parameter problem — flagging for the data engineer that liquidation-cascade hypotheses remain blocked until multi-year liquidation history is backfilled, so it never advanced to optimization or risk review.

A supplementary-data mechanism is unbacktestable when its feed lacks history — the liquidations stream covers only ~2 months, so the signal fired just 8 times and the mechanism could be neither confirmed nor refuted; liquidation/OI-driven hypotheses stay blocked until the data is backfilled with multi-year history.

The backtest-review analyst issued an 'abandon' verdict: the code was correct and fired faithfully when liquidation rows were present, so this is a data-availability wall, not a bug — the liquidations supplementary stream is live-stream-only with ~2 months of history, so the cascade signal cannot fire across 6.4 of the 6.5 backtest years, and 8 trades in one window cannot support walk-forward or a holdout.

A long-short mean-reversion strategy on BTCUSDT 1H Binance futures (1.0x leverage, 0.15 per leg) using liquidations supplementary data — fading forced-liquidation cascades by going long when long-liquidations spiked (z≥2) alongside a ≥1% downside move and short on the mirror short-squeeze — targeting five under-represented buckets including the first-ever liquidations-driven, long-short, crypto-microstructure mechanism.

Over ~6.5 years (56,208 1H bars) it produced only 8 trades, all clustered in a single ~2-month window (2026-04-21 to 2026-06-24): total return -0.03%, profit factor 0.92, Sharpe -0.68 with a meaningless CI [-10.4, +23.5], commission 23% of gross, and the engine flagged metrics_reliable=FALSE.