BtcCmLiquidationCascadeConvexityReversalLS

COIN-M Inverse-Perp Liquidation-Cascade Convexity Reversal, Long-Short (Single-Instrument BTCUSD_PERP.BINANCE_CM — Fade Forced-Deleveraging Overshoots That Are Structurally Amplified by Inverse-Contract Collateral Convexity, Liquidation-Feed Gated, 2-Parameter)

A LONG-SHORT, SINGLE-INSTRUMENT, SINGLE-VENUE mean-reversion strategy on the BTCUSD_PERP.BINANCE_CM inverse perpetual whose edge is COIN-M-SPECIFIC and not expressible on USD-M. On inverse (coin-margined) contracts, collateral IS the underlying coin, so a falling price hits long holders TWICE — the position loses AND the margin's USD value shrinks — a convex feedback that makes LONG-liquidation cascades on COIN-M mechanically more violent and more overshoot-prone than the same move on a USDT-margined perp. The signal is orthogonal to price (it is the exchange liquidation feed, already in the catalog/supplementary set), so this is NOT a price-only directional strategy: we act only when a genuine forced-deleveraging cluster is present. When a large long-liquidation cluster prints (forced selling) alongside a sharp intrabar drop, we FADE it (go LONG the bounce); symmetrically, a large short-liquidation cluster with a sharp up-spike triggers a SHORT. Single venue, single instrument — both the bars and the liquidation feed are jointly available in the Layer-3 sandbox, avoiding the cross-venue/multi-leg verification_loop deaths. Deliberately 2-parameter to resist overfitting.

Implements the hypothesis exactly: single-instrument, single-venue COIN-M, liquidation-feed gated (orthogonal to price), correctly-signed fade, two tunable knobs (liq_z, move_atr) with clamps mirrored in _param_bounds. I verified the data rather than assuming it: COIN-M liquidations ARE collected from Binance's dstream forceOrder feed into the liquidations table under symbol BTCUSD_PERP - 5,625 prints spanning 2026-05-15 to 2026-09-03, split 2,970 SELL / 2,655 BUY - and the loader resolves that exact symbol for a BINANCE_CM instrument, so the bars and the feed are jointly available in the sandbox. I then measured the full joint gate on the real 5-minute bars over that window: at the defaults it fires 85 times in 110 days (40 BUY / 45 SELL, near-symmetric), so a zero-trade sandbox is not a risk and the sample is genuinely two-sided. I chose 5-MINUTE deliberately: it is already in the catalog (no on-demand collection risk), it matches the minutes-scale overshoot the mechanism targets, and a ~20k-bar Layer-3 window lands almost entirely inside the liquidation feed's coverage. Thresholds are rolling z-scores rather than absolute USD because COIN-M print sizes span median $41k to $779M - a fixed constant would either never fire or fire constantly. calculate_signal returns the CONTINUOUS bar move in natural ATR units, signed in the direction we would fade, every bar; the cluster test is a cached z-score used in should_enter, and an empty feed produces no trades at all rather than a silent price-only fallback. The honest caveat: the feed only starts 2026-05-15, so the usable evaluation window is ~3.6 months regardless of how much bar history exists - the strategy will be judged on a short sample, and at ~0.10% COIN-M round-trip cost the 1.5x ATR target (roughly 0.3-0.6% on 5m BTC) leaves real but not generous headroom. Inverse sizing uses contracts_for_notional (whole $100-face contracts), never the linear equity/price formula; ~$40k notional is ~400 contracts, far above min notional. leverage stays 1.0 with notional capped at 0.4x equity and per-trade risk near 1%, so there is no compounding blow-up path. All per-bar work is O(1) (Wilder ATR, running-sum z-score, dict lookups) with the feed bucketed once at startup, so the 5-minute backtest stays inside the smoke budget.

Data-walled and negative-expectancy liquidation-fade — not worth 2 hours of optimization, and the limitation is data-side, not code. Despite the multi-year BTCUSD_PERP catalog, the liquidations supplementary feed only spans ~111 days (2026-05-15 → 2026-09-03) in a single regime (funding_events_available 4), the recurring forward-only liquidation-feed wall (L47/L58): a 3-window walk-forward plus 20% holdout cannot populate on 3.6 months. On that window it is negative and fee-dead: profit_factor 0.646, avg_trade_return_pct -0.086%, expectancy -$34.6/trade, total_return -7.0%, Sharpe -3.88 with bootstrap CI [-6.1, -2.6] (PSR 0.0002), and commission is 63.53% of gross — the 5-minute cadence bleeds the entire edge to fees (L18). Only 77 trades with exposure 2.02% (the extreme-cluster gate rarely fires), and all three vol sub-regimes are negative (Sharpe -5 to -8). This is the L55/L73 single-name liquidation-gated fade family, here both structurally unmeasurable and negative-expectancy. No parameter tuning conjures a positive edge, and the fix is a multi-year liquidation feed the catalog does not have; recommend factory-gate/manual review if that data becomes available. Failure pattern: data_unavailable + no_edge/fee_edge single-name liquidation fade (L47/L58/L18).

Long-short liquidation-cascade fade on the BTC COIN-M inverse perpetual (BTCUSD_PERP.BINANCE_CM, 5-minute bars, single instrument, single venue). The gating signal is the exchange liquidation feed, not price: every print is bucketed once into its bar and split by side (a SELL print is a long being liquidated, a BUY print is a short), and the bar's total liquidated USD is scored as a rolling z-score of log(1+usd) against the previous 200 bars that carried liquidations - scale-invariant, never a fixed dollar threshold, and computed before the current bar joins the statistics so there is no look-ahead. It enters only when an extreme cluster (z >= 1.5) coincides with a real price overshoot on the same bar (>= 0.8x ATR): long liquidations plus a sharp drop are faded LONG, short liquidations plus a sharp spike are faded SHORT. Exits are a 1.5x ATR take-profit, a 1.5x ATR stop, or a 24-bar (2-hour) cap. If the liquidation feed is empty the strategy stays flat - it never falls back to a price-only reversal. Sizing risks 1% of equity against the ATR stop, capped at 0.4x equity of gross notional, floored to WHOLE $100-face inverse contracts via contracts_for_notional (BTC-margined/settled).

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.

Use a resting reduce-only STOP_MARKET (or use_bracket_orders) to cap loss at the level intra-bar. Note this alone won't clear the fee floor at 5m.

Exit uses BAR-CLOSE TP/SL (close >= tp / close <= sl) rather than a venue-managed resting stop. For a strategy fading violent cascades that overshoot within a 5m bar, the bar-close stop is regularly blown through intra-bar, so realized loss exceeds the intended 1.5-ATR bound: sandbox avg_loss $213 vs avg_win $106 (~2x) despite symmetric levels. The hypothesis claims the tight stop bounds per-trade loss; the implementation does not during cascades, materially driving Sharpe -5.19.

Weigh optimized metrics against the ~110-day feed span; re-validate as the feed extends.

The BTCUSD_PERP liquidation feed begins 2026-05-15 (5,625 prints to 2026-09-03), so the usable window is ~3.6 months regardless of bar history. Sandbox ran 68 data_days / 68 trades — enough for a >=10-trade holdout but a short single-regime sample with tight walk-forward windows and low OOS confidence. Not disqualifying, but optimized results are provisional until more feed accrues.

Clean 2-parameter single-instrument construction; correct inverse-contract sizing; no liquidation of the account; genuine non-price (liquidation-feed) gate

COIN-M convexity thesis is coherent and the strategy correctly stays flat without the feed (no price-only fallback)

Structurally unmeasurable: liquidation feed spans only ~111 days (2026-05 → 2026-09) in a single regime — the L47/L58 forward-only liquidation-feed wall; walk-forward/holdout can't populate

Negative and fee-dead: PF 0.646, avg_trade_return_pct -0.086%, expectancy -$34.6/trade, Sharpe -3.88 (CI [-6.1, -2.6], PSR 0.0002), commission 63.53% of gross

Below measurability: 77 trades, exposure 2.02%; all three vol sub-regimes negative (Sharpe -5 to -8); kurtosis 39.6

Single-name liquidation-gated fade (L55/L73) — both data-walled and negative-expectancy

Verification failed (Layer 4 — QA review) [class=premise_falsified]: - The liquidation-cascade REVERSAL premise is refuted: fading forced-deleveraging overshoots significantly LOSES. Sandbox Sharpe -3.86 with CI [-6.59, -0.58] entirely below zero (PSR 0.003), profit_factor 0.561 (<1), avg_trade_return_pct -0.109% (negative), total_return -6.55%, IR -3.63, over 66 trades. Inverted payoff: win_rate 0.530 but avg_loss $211 ~= 2x avg_win $105 — the fade is systematically run over, i.e. 5m BTC liquidation clusters CONTINUE rather than revert. I explicitly checked the L17 liquidation-fade bug classes and found them CORRECT: side mapping (SELL=long liquidated), fade sign (long liq+drop->BUY), no look-ahead (cluster z vs prior liq bars before folding current; shared open-stamped bucket grid), inverse sizing. Metrics sit below L17's hard code-defect triggers (win_rate 0.53!=0, |Sharpe| 3.86 not >5, PF 0.561!=0), so this is a genuine premise inversion, not an undiscovered bug — corroborated by the family's repeated strongly-negative deaths (15m -7.39, 1m -12.80). Even normalizing for the stop weakness, a 0.53 hit rate with symmetric ATR TP/stop can't clear the ~0.10% CM round-trip on 0.3-0.6% moves. - Secondary risk-control weakness (not the failure cause; does not liquidate here): the stop is close-based in should_exit, so a continuing cascade blows through the intended 1.5-ATR stop intra-bar (part of why avg_loss is ~2x avg_win). Fixing it tightens losses but doesn't create edge given the coin-flip hit rate.