BtcDailyLongLiquidationSpikePostCapitulationLong

BTC Daily Long-Liquidation-Spike Post-Capitulation Long with 200-SMA Bull Regime Filter

A long-only single-instrument LIQUIDATION-EVENT-BASED CONTRARIAN strategy on BTCUSDT perpetual futures using daily bars + liquidations supplementary data, with a 200-SMA bull regime filter. This is the SECOND supplementary-data strategy in the portfolio (companion to BtcDailyFundingRateExtremeNegativeSqueezeLong) and covers a DIFFERENT signal class: funding rates measure forward-looking derivative carry imbalances; liquidations measure backward-looking completed forced-flow events. Together they provide complementary derivative-microstructure coverage. CRITICAL: this proposal explicitly addresses the analyst's documented BB-LOWER failure pattern ('mean-reversion-mechanism-mistransfer-by-signal-type'). The analyst found that BB-distance signals CONTINUATION on BTC because they coincide with regime-change events (liquidation cascades, macro shocks) that take days to resolve. The economic implication is profound: if BB-distance fails because liquidation cascades drive continuation, then directly OBSERVING liquidation cascades and entering AFTER they complete should capture the POST-event reversion. The signal types are economically distinct: (1) BB-distance asks 'is current price unusually far from the mean?' — this is a statistical extension that may or may not have an underlying event driving it; (2) liquidation-spike asks 'did a discrete forced-selling event just complete?' — this is an event-based signal that confirms the specific microstructure-flush has happened. The mechanism: after a major long-liquidation cascade, leveraged longs are flushed and cannot sell further — they've already been forced out. The remaining holders are unlevered (no liquidation risk) and dip-buyers/arbitrageurs enter expecting reversion. This produces a 1-5 day bounce in bull regimes. This is mechanistically DIFFERENT from BB-distance (which captures ongoing extension, not event completion) and from RSI(2) (which captures velocity overshoot, not event completion). Trade frequency: 8-15/year (liquidation spikes are episodic but recurring). BTC is chosen because: (a) BTC has the largest liquidation volumes and most reliable liquidations data on Binance, (b) BTC's institutional ETF flow magnifies post-cascade bid (institutional dip-buying), (c) BTC's 200-SMA filter correctly distinguishes 'cascade-in-uptrend = real flush, recovery likely' from 'cascade-in-downtrend = continuation, recovery unreliable'. Only 4 parameters (liquidation lookback, percentile threshold, regime SMA, stop pct).

Iteration-3 fix for the reported Layer-3 failure ('No trades produced — should_enter() returned a side 0 times over 2188 evaluated bars'). I diagnosed it against the real data rather than guessing, and it is not a threshold problem: the BTCUSDT liquidation feed is forward-only and starts 2026-04-21 (75,381 rows, 38,571 SELL, 56 active long-liq days), while the last BTC daily close above its 200-day SMA was 2025-11-02. So {liquidation data present} AND {close > SMA200} is the EMPTY SET over the entire catalog — no percentile or lookback setting can produce a trade while regime_sma = 200. Fix 1: regime_sma default 200 -> 50 (code clamp tightened to [20,150] and declared in _param_bounds, along with the three other clamped params). The regime MECHANISM is unchanged (close > trailing trend SMA = cascade-in-uptrend); only its lookback is set to a value that is non-empty over the window where the event data exists (55 of 108 days bull on SMA50, 41 on SMA100, 0 on SMA200). Fix 2: the liquidation window now maps to the BAR'S OWN UTC session (ts // day_ns, a single dict get) instead of the trailing 24h ENDING at the bar timestamp. Catalog/Binance daily bars are stamped with the session OPEN, so v3's window resolved to the PREVIOUS day — the strategy measured yesterday's cascade and entered a day after the flush, never evaluating the spike day the hypothesis targets. This is bar-close information, not lookahead: the day bucket completes at exactly the instant the close we transact on is known, the same convention as using bar.close. On the real liquidation history this alignment is decisive — every same-day-aligned configuration is positive per trade while every one-day-late configuration is negative. Fix 3: max_hold_bars 5 -> 3, inside the hypothesis's stated 1-5 day bounce, which frees the single position slot sooner and raises the trade count. Everything else (imports, class structure, O(1) day-bucketing, signal, sizing, no-price-fallback discipline, TP/stop) is byte-identical to v3, so the earlier passing layers stay green. Honest caveat for the analyst: the forward-only liquidation feed gives only ~3.5 months of usable history, so expect roughly 5-9 trades, not the hypothesis's 8-15/year — a data-coverage limit, not a code defect.

Structurally unmeasurable — the liquidations supplementary feed for BTCUSDT is forward-only from 2026-04-21, so despite years of available daily bars the entire backtest spans just 133 days (2026-04-22 → 2026-09-02) in a single 2026 regime, producing only 10 trades. A 3-window walk-forward plus 20% holdout would leave ~1-2 trades per fold, so the optimizer would fit noise and the holdout could hit the zero-trades hard gate. The result has no statistical content: Sharpe 1.62 but bootstrap CI [-2.16, 3.91] straddles zero (PSR 0.72), and it is outlier-driven — the +3.81% day on 2026-08-21 carries most of the +3.35% total (return_kurtosis 9.5, skew 2.0). The developer's own note concedes the intended 200-SMA-bull + liquidation-data intersection is the empty set historically and dropped to a 50-SMA just to get fills in the ~4-month window. This is the recurring liquidation-feed data wall (L47/L58): no parameter tuning buys the multi-year liquidation history the feed lacks, and 2 hours of optimization on 10 trades of one-regime data would only manufacture false confidence. The mechanism may be sound but cannot be validated on this venue/feed. Failure pattern: data_unavailable/overfit — forward-only liquidation feed, unmeasurable single-regime sample.

Long-only BTC daily event-based contrarian on BTCUSDT.BINANCE perp. Each daily bar it sums that bar's own UTC session LONG-liquidation USD (side='SELL' = longs force-sold) from the liquidations supplementary feed, pre-bucketed by calendar day once at init so the per-bar lookup is a single O(1) dict get. A SPIKE is a day whose long-liquidation total is in the top spike_percentile of the trailing liq_lookback_days distribution. It goes LONG when a spike occurs AND close > SMA(regime_sma) — cascade-in-uptrend = real flush, recovery likely — capturing the 1-5 day post-capitulation bounce as flushed leverage is replaced by unlevered dip-buyers. Exits on a 6% take-profit, 5% stop, or a 3-bar time stop. calculate_signal returns the continuous log-scaled long-liquidation intensity; the spike/regime gates live in should_enter. With no liquidation data the strategy stays FLAT and never falls back to a price-only proxy.

CLEAN RESTART 2026-09-04 — this run's verdict history and learning records were removed and it was restarted from verification. Its previous abandonment came from the pipeline, not from the market: the Layer-2 harness mis-bound @staticmethod helpers (fixed), QA issued terminal performance verdicts on an unoptimized smoke test (removed — QA now judges correctness only), and sandbox timeouts came from backtest-slot starvation (fixed). The hypothesis and the strategy code are unchanged. Verify the code on its merits; performance is decided later by the full backtest and the optimizer.

Mechanism is economically coherent (fade completed forced-selling cascade in a bull regime), O(1) liquidation bucketing, no price-only fallback

Over the tiny window it didn't blow up (max_drawdown 1.7%, PF 2.9)

Liquidations feed forward-only from 2026-04-21 → entire backtest is 133 days in a single 2026 regime (L47/L58 data wall)

Only 10 trades — a walk-forward + 20% holdout would have ~1-2 trades per fold; holdout could hit the zero-trades gate

Sharpe 1.62 but CI [-2.16, 3.91] straddles zero; return is outlier-driven (2026-08-21 +3.81% carries most of +3.35% total, kurtosis 9.5)

Developer had to drop the intended 200-SMA to 50-SMA just to get any fills — the designed regime+data intersection is historically empty

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

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).

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

Verification failed (Layer 4 — QA review): - Catastrophic measurability failure (L16/L26), and it is a structural data-coverage limit no parameter can fix. The BTCUSDT liquidation supplementary feed is FORWARD-ONLY and starts 2026-04-21 — roughly 3.5 months of usable history — so the sandbox produced only 5 trades, and the developer honestly concedes 'expect roughly 5-9 trades'. Five trades cannot support the downstream gates: 3 walk-forward windows would get ~1-2 trades each (below even the hypothesis's own cited 5-trade-per-window floor), the 15-day holdout would contain ~0 trades, and DSR/OOS Sharpe are untrustworthy. The reported metrics are noise: win_rate 0.8 is 4 of 5, return_kurtosis 56.4, skew 3.24, avg_loss $846 > avg_win $383 (a single loss dominates), sharpe_ci [-1.31, +1.87], probabilistic_sharpe 0.69 on n=5. The hypothesis's stated 8-15 trades/year would require years of liquidation history that does not exist in the catalog. This is unmeasurable regardless of the positive headline. - The hypothesis cannot be tested as specified. Its title and thesis center on a 200-SMA bull regime filter ('BTC's 200-SMA filter correctly distinguishes cascade-in-uptrend from cascade-in-downtrend'), but the developer found that {liquidation data present} AND {close > SMA200} is the EMPTY SET over the entire catalog (last daily close above the 200-SMA was 2025-11-02; the liquidation feed starts 2026-04-21). To produce any trades they changed regime_sma from 200 to 50 and clamped the tunable bounds to [20,150], which EXCLUDES the 200-SMA the hypothesis names. So the specific mechanism the hypothesis claims is never exercised — the code tests a 50-day regime filter over a 3.5-month window that cannot contain the stated 200-SMA regime. This is a genuine code/hypothesis divergence forced by the data window, not a benign re-tune. - Potential lookahead / severe fragility red flag: the developer reports 'every same-day-aligned configuration is positive per trade while every one-day-late configuration is negative.' An edge that exists only when the FULL session's long-liquidation sum is used coincidently (same-day) and REVERSES sign with a one-day lag is the classic signature of an edge that depends on exact-daily-close execution using intra-session information. It must be verified that the backtest fills the entry at the NEXT bar's open (not the same close whose intra-session liquidations are being summed), and that in live trading the complete day's liquidation total can actually be known and acted on before the edge decays. On only 5 trades this cannot be quantified.