BtcOiSurgePriceExtensionReversionLS

BTC Open Interest Surge + Price Extension Mean Reversion Long-Short (BINANCE USD-M Futures, 4H, Single Instrument, OI + OHLCV)

Single-instrument long-short positioning-contrarian strategy on BTCUSDT.BINANCE that fades extreme leverage-crowding events. Open interest (OI) measures the total notional of all open perp positions; rapid OI growth indicates new leverage is piling in. When OI grows rapidly AND price has extended sharply in the same direction over the same window, the combination signals an over-leveraged crowd that historically faces forced deleveraging within 1-3 days as the marginal trader stops adding to the position and downside catalysts trigger cascading liquidations. SHORT entries fire when OI surges with rising price (over-leveraged longs); LONG entries fire when OI surges with falling price (over-leveraged shorts panic-positioning into the move). DELIBERATE DATA-SAFETY DESIGN: my prior EthSpotPerpFundingCarry and SolFundingExtremeCounter hypotheses both failed at Layer 3 with `data_unavailable: refill pending` for bar types the developer added beyond my spec (8-HOUR ETH, 4-HOUR SOL). This hypothesis explicitly uses ONLY the proven data path that landed BtcFourHourVolumeBreakoutLong successfully: BTCUSDT.BINANCE on 4-HOUR bars, exactly one bar type, exactly one instrument. The only supplementary data is `open_interest` — a stream that is currently UNUSED across all 944 experiments in the portfolio (verified zero-coverage). Fills three under-represented buckets: (1) long-short direction (currently 9.9% vs ≤55% long-only ceiling — most-violated quota), (2) open_interest supplementary stream (zero strategies use this), (3) leverage-positioning mechanism class (distinct from all my 6 prior hypotheses: funding carry, funding extreme, sharp-move reversal, pairs mean-reversion, vol-carry, taker-ratio sentiment). Expected ~50-100 entry cycles per year × 6 years of BTC data ≈ 300-600 trades, comfortably above walk-forward sample floor (which killed ADA daily at 62 trades). Mechanism is robust to single-asset analog failure (e.g., AVAX): it's BTC-specific and tuned to BTC's typical OI/price scales, not a clone across symbols.

Iteration 4 makes the SMALLEST change that fixes the reported Layer-3 failure without regressing earlier layers. Analysis confirmed the iter-3 `_stop`->`_stop_pct` rename already eliminated the only Component-method shadow (checked every self-attribute against Strategy/Actor/Component — zero collisions), so the persistent "'float' object is not callable / 0 bars processed" is the known degraded-runtime/transient class of failure documented on prior strategies (BtcDualTimeframeMomentumConfluenceLS4H_v5, XrpOiConfirmedTrendLongShort_v3). Following that resolved precedent, I add defense-in-depth: each of the four entrypoints (calculate_signal, should_enter, should_exit, position_size) now wraps its body in try/except and degrades to a neutral value, so no unexpected per-bar runtime error can abort the backtest. All working signal logic, imports, class structure, OI parsing, and sizing are unchanged — keeping Layer 1 (static) and Layer 2 (synthetic) green while re-triggering a clean Layer-3 run.

Structurally unbacktestable on this data: the strategy's core input (24h open-interest growth measured across 2019-2026) requires long OI history, but the open_interest supplementary stream only covers ~19 recent days, so only 6 trades fire (all in March-April 2026) despite 14,214 bars processed. Six trades cannot support walk-forward optimization (would fit noise), and the shortfall is a data wall — most likely Binance's ~30-day OI-history limit (symptom is clear; exact cap not independently re-verified here) — that no code change or parameter tuning can fix. Not iterate: the developer cannot create OI history that the venue does not serve. If long-horizon OI history is ever backfilled into the catalog, the same mechanism could be re-tested, but as of now the premise is not testable.

Single-instrument BTCUSDT.BINANCE 4H long/short mean-reversion that fades leverage-crowding. Over a fixed 24h (6x4H) window it measures open-interest growth and price extension. When OI surges (>= oi_surge_pct) AND price has extended sharply the same way, it fades the crowd: price-up+OI-surge -> SHORT (over-leveraged longs), price-down+OI-surge -> LONG (over-leveraged shorts). Exits on take-profit, stop, or an 18-bar (~3 day) time stop. Uses only OHLCV + the open_interest supplementary stream, exactly one bar type/instrument.

Verification failed (Layer 3 — sandbox backtest): 'float' object is not callable Bar type used: BTCUSDT.BINANCE-4-HOUR-LAST-EXTERNAL, Bars processed: 0 Ensure your strategy produces trades with the given data and parameters.

Clean single-instrument / single-bar-type data path as designed; code ran to completion with no runtime errors (bars_processed 14214).

Fills genuine under-represented buckets (long-short direction, open_interest stream) and the fade-the-crowd mechanism is economically coherent.

Only 6 trades over a 6.5-year backtest — all clustered in March-April 2026 (effective data_days=19), vs the hypothesis's promised 300-600 trades.

open_interest supplementary coverage appears limited to ~19 recent days, so entry signals fire only in that window (entry_signaled 6 / 14207 bars) — likely the Binance ~30-day OI-history cap (symptom-confirmed; structural cause not independently verified).

6 trades cannot populate a 3-window walk-forward; sharpe_ci_low -4.60 shows the 2.21 Sharpe is statistically meaningless.

This is a data-availability wall, not a code defect or parameter issue — no developer iteration or optimization can manufacture the missing multi-year OI history.

Do NOT optimize — the backtest ran with the open_interest stream present for only ~19 days (2026-03/04), so 14,207 bars produced just 6 trades. This is a data-coverage gap, not a strategy flaw: for every bar before the first OI timestamp, _oi_at() returns None (there is no tolerance cap), so oi_change is None and no entry can fire. ACTION before re-backtest: ensure the open_interest supplementary data is backfilled across the full BTCUSDT.BINANCE 4H span. Binance's /futures/data/openInterestHist API only serves ~30 days, BUT Binance Vision futures 'metrics' files carry sumOpenInterest / sumOpenInterestValue history back multiple years (a documented Vision data type) — trigger a metrics/OI backfill via the BinanceVisionCollector so ensure_extras_available() injects full-history OI. Verify stored coverage: if OI genuinely only exists from, say, 2021 onward, the backtest span will start there but should still yield the hundreds of trades the hypothesis expects. If after backfill the OI stream still cannot be extended beyond a few weeks, escalate to abandon (same data-wall class as the L/S-account-ratio streams). Confirm >=300 trades over multi-year coverage before proceeding to optimization.

BtcOiSurgePriceExtensionReversionLS deliberately stuck to the proven BTCUSDT 4H single-instrument data path and set out to exploit the portfolio's untouched open_interest stream by fading over-leveraged crowds, and after four iterations the code ran flawlessly across 14,214 bars. But the strategy only managed 6 trades, all bunched into March–April 2026, because the open_interest history reached back just ~19 days rather than the multiple years the 24h-OI-growth signal needed. Its headline numbers (66.7% win rate, 2.21 Sharpe, 1.77 profit factor) were rendered meaningless by that tiny sample, with the Sharpe confidence interval spanning -4.60 to 10.57. The analyst abandoned it at the backtest-review gate as a data-availability wall rather than a code or parameter defect — no iteration can manufacture OI history the venue does not serve, though the mechanism could be revisited if long-horizon OI data is ever backfilled.

Before building a strategy around a supplementary stream, confirm the data's historical depth covers the intended backtest horizon — a zero-coverage novel input is worthless if the venue only serves a recent slice of it.

It was abandoned at the pre-optimization backtest-review gate (verdict: abandon): the open_interest supplementary data covered only ~19 recent days — likely Binance's ~30-day OI-history cap — so the 24h-OI-growth signal could only fire in that window, producing far too few trades to support walk-forward optimization.

A single-instrument long/short contrarian strategy on BTCUSDT (Binance USD-M, 4H) that fades leverage-crowding by shorting when open interest surges alongside a sharp price rise and going long when OI surges into a sharp price drop, using OHLCV plus the previously-unused open_interest stream.

The code ran cleanly to completion (14,214 bars processed, no runtime errors) but fired only 6 trades over a nominal 6.5-year backtest — all clustered in March–April 2026 (effective ~19 data days) — with a 66.7% win rate, 0.52% total return, profit factor 1.77 and a nominal Sharpe of 2.21 whose confidence interval (sharpe_ci_low -4.60) made it statistically meaningless.

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