BtcLiquidationCascadeContinuationLS

BTC Liquidation Cascade Continuation Momentum Long-Short (BINANCE 1H Bars, Liquidation-Spike-Triggered, 6-12H Hold)

Single-asset long-short momentum strategy on BTCUSDT.BINANCE triggered by extreme liquidation cascade events. Core thesis: large liquidation events are mechanical, non-discretionary forced order flow. When >3x the 24h rolling average of liquidation volume hits in a single hour AND price has already moved >0.8% in the direction of the liquidations (i.e., longs being liquidated coincides with price DOWN, shorts with price UP), the cascade has KINETIC momentum that empirically continues for 6-12 hours before mean-reversion kicks in. This contradicts the textbook liquidation-cascade-REVERSAL play (which captures the multi-day reversal but requires >24h holds and significant drawdown tolerance). The continuation play captures the 'second wave' of cascades — the forced flow from cross-margined positions that get liquidated AFTER the first wave triggers their maintenance margin. Strategy enters in the SAME direction as the liquidations (short on long-liquidation cascade; long on short-liquidation cascade) and holds for a fixed 6-12 hour window. Uses 1-HOUR bars on BINANCE BTCUSDT (1h bars are well-supported in the data infrastructure and explicitly avoid the 8-HOUR refill bug that has caused 10+ recent failures). Fills the long_short under-represented bucket (9.2% vs <=55% long_only target) and uses the liquidations supplementary data source which is under-explored in the portfolio. Fundamentally different signal class from my prior funding-rate proposals.

Iteration 2 fixes the Layer-2 (synthetic) failure 'BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given'. Root cause: _to_ns was a @staticmethod but is invoked as self._to_ns(...); the Layer-2 verification proxy rebinds strategy helpers as instance methods and passes self, so the 1-arg staticmethod received 2 args. The minimal fix converts _to_ns from a staticmethod to an instance method (drop @staticmethod, add self); its single call site in _build_liq already uses the self. form, so no other change is needed, and the other helpers (_liq_window, _position) are already instance methods so none reproduce the trap. Every other line -- the liquidation series build, causal per-side windowing, 24h baseline spike detection, continuation entry/exit gates, and sizing -- is byte-identical to the previous iteration, preserving all Layer-1 checks and the passing signal logic. This is the same recurring synthetic-proxy gotcha where @staticmethod helpers invoked through self break only under verification.

BTC liquidation-cascade continuation fired exactly 1 trade in 113,088 1H bars, on the very last day (2026-06-25), with the engine flagging metrics_reliable=false and 'Unreliable: only 1 daily returns' — untestable. Root cause is the same supplementary-data-coverage gap that already sank four positioning-data strategies this session: the spike signal needs a 24h liquidation baseline plus a >=3x spike, and only ONE valid entry occurred across six years (on the final day), meaning the liquidations feed has no usable historical coverage and _liq_window() returns ~0 for nearly every historical bar, so no spike ever registers. The hypothesis's 'under-explored liquidations data source' premise is contradicted by the result, exactly as the OI and L/S-ratio premises were. The metrics are non-existent on n=1 (Sharpe 0.0 flagged unreliable, no CI/skew/vol, win_rate 1.0 from one trade). Not optimize: a 3-phase optimization (walk-forward 3 windows + 15-day holdout) is impossible on 1 trade. Not iterate: the implementation is correct (causal windowed liquidation lookup, side-aware parsing, no price-only fallback) and the blocker is structural historical coverage of the Binance liquidations feed — a data-engineering backfill task no parameter or code change can fix. FAILURE PATTERN: ALL Binance derivatives-state supplementary feeds (open_interest, top/global account L/S ratios, AND liquidations) currently lack multi-year history (only a recent ~2-month-to-single-day window is populated), so ANY strategy gating on them fires once or a handful of times in 2026 and zero before — the identical recent-only signature now confirmed across FIVE strategies this session (OI-surge, OI-spike, OI-percentile, L/S-divergence, liquidation-cascade). These mechanism classes must be shelved until the data engineer backfills historical OI, L/S-ratio, and liquidation data; the analyst's reliable-data-path guidance should explicitly exclude open_interest, account-ratio, AND liquidations feeds for historical strategies, and the Research Lead should stop proposing derivatives-state-data-primary hypotheses until multi-year coverage is confirmed — five consecutive identical data-gap abandons is a clear systemic signal, not a per-strategy issue.

Single-asset long/short liquidation-cascade CONTINUATION momentum on BTCUSDT.BINANCE 1H bars. Each hour it sums liquidation USD per side over the last hour from the liquidations supplementary data and compares it to the 24h rolling hourly average; on a spike (>= liq_spike_mult x average) accompanied by a same-direction price move >= price_move_thr_pct, it enters WITH the cascade (short when longs are being liquidated and price is down, long when shorts are liquidated and price is up), holding a fixed 6-12 bar window or exiting on a stop_pct loss. Pure liquidation-triggered signal, no price-only fallback. Four tunable parameters; leverage 1.0.

Verification failed (Layer 2 — synthetic scenarios): Parameters used: ['stop_pct', 'hold_bars', 'min_notional', 'liq_spike_mult', 'price_move_thr_pct'] Check that __init__ sets all attributes from self.parameters.get(). - steady_uptrend: TypeError: BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691040000) - steady_downtrend: TypeError: BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691040000) - flat_ranging: TypeError: BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691040000) - volatility_spike: TypeError: BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691040000) - zero_volume: TypeError: BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691040000) - price_gap: TypeError: BtcLiquidationCascadeContinuationLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691040000)

Clean, correct implementation: causal windowed liquidation aggregation, side-aware (SELL=long liquidated), no price-only fallback, simple 4-parameter design

Sound thesis (cascade continuation / second-wave forced flow) and a genuinely under-used signal class

DECISIVE: only 1 trade in 113,088 bars, on the final day 2026-06-25; metrics_reliable=false — the liquidations feed has no historical coverage, so the 24h-baseline spike never registers pre-2026

Metrics non-existent on n=1: Sharpe 0.0 (flagged unreliable), no CI/skew/vol, win_rate 1.0 from a single trade; cannot support walk-forward + holdout optimization

FIFTH Binance derivatives-state supplementary-data strategy this session blocked by the identical recent-only coverage gap (OI-surge, OI-spike, OI-percentile, L/S-divergence all abandoned)

BtcLiquidationCascadeContinuationLS proposed a genuinely under-used, economically grounded mechanism — riding the kinetic continuation of liquidation cascades rather than fading them — with a clean, side-aware, causal implementation and no price-only fallback. But it fired exactly one trade in six years, on the very last day, because the liquidations feed has no usable historical coverage, leaving the metrics non-existent on n=1. This was the fifth Binance derivatives-state-data strategy of the session blocked by the identical recent-only coverage gap after the three OI hypotheses and the L/S-divergence one, confirming a systemic blocker rather than a per-strategy issue. The analyst abandoned it on its second iteration as a data-engineering backfill task no code change can fix, recommending the Research Lead stop proposing derivatives-state-data-primary hypotheses until the data engineer confirms multi-year coverage of OI, account-ratio, and liquidation feeds.

All Binance derivatives-state supplementary feeds — open interest, top/global account L/S ratios, and liquidations — currently lack multi-year history, so any strategy gating on them fires once or a handful of times in 2026 and never before; five consecutive identical data-gap abandons this session is a systemic signal, and these mechanism classes must be shelved until the feeds are backfilled.

The analyst abandoned it at the backtest-review gate before optimization because of the same supplementary-data-coverage gap that had already sunk four positioning-data strategies this session: the spike signal needs a 24h liquidation baseline, but the liquidations feed has no usable historical coverage, so the window aggregation returned ~0 for nearly every historical bar and no spike ever registered before 2026 — a structural data-engineering blocker, not a strategy flaw.

A long/short, single-instrument BTCUSDT 1H momentum strategy triggered by extreme liquidation cascades — when a single hour's liquidation volume hit ≥3x its 24h rolling average and price had already moved ≥0.8% in the implied direction, entering in the SAME direction as the cascade (short on long-liquidations + price down, long on short-liquidations + price up) to capture the 'second wave' of forced cross-margin flow, holding 6-12 hours or until a stop, with 4 parameters and no price-only fallback.

It was effectively untestable: the signal fired exactly 1 trade across 113,088 1-hour bars (on the final day, 2026-06-25), with the engine flagging metrics_reliable=FALSE and 'Unreliable: only 1 daily returns' — Sharpe 0.0, no CI/skew/volatility, win rate 1.0 from a single trade, total return 0.11%.