BTCUSDT.BINANCE Perp 4H Open-Interest Surge Long-Only Trend (Positioning Catalyst + Price Direction Gate + Trend Filter, 4-Parameter)

Single-asset long-only trend strategy on BTCUSDT.BINANCE perpetual using 4H bars. The directional trigger comes from a 12-HOUR OPEN INTEREST SURGE combined with price-direction and trend gates. Open interest data (sourced from supplementary_data → open_interest, which is listed in the factory's available supplementary feeds) measures the dollar value of all currently-open BTC perp positions at each snapshot; a sharp INCREASE in OI signals AGGREGATE POSITIONING IS SCALING UP — fresh capital is being staked — which is a mechanically DIFFERENT information channel than: (a) price-derived signals (failed extensively across this session's rotation/momentum/MR/breakout abandons), (b) volatility-derived signals (failed BB Squeeze + Vol-Contraction-Expansion), (c) execution-level signals (taker flow imbalance — my pending submission, uses trade_ticks). OI is POSITION FLOW (stake being built), distinct from execution flow (which side is paying the spread) and price (consequence of both). This is the FIRST factory hypothesis I've seen testing OI delta as a primary signal — the supplementary data type is listed but apparently not yet tested. The direction-gate (recent close > close 3 bars ago) is critical: OI can rise from EITHER longs piling in OR shorts piling in; combining OI surge with concurrent price-up confirms it's long-side positioning, not short-side. The trend filter (50-bar SMA at 4H ≈ 8 days) ensures the strategy is in a directional regime, not chop. Only 4 parameters (well below 5-param overfit ceiling). Trade frequency estimate: 12-hour OI surges >3% with concurrent price-up + trend-up confirmation on BTC happen 30-60×/year — over 6+ years of Binance perp data → 180-360 total trades → 12-24 OOS trades per walk-forward window, comfortably above the analyst's empirically-validated 5-trade floor. Critical infrastructure test: if open_interest data loads correctly into the factory pipeline, this opens a whole NEW data class for future research. If it fails to load (similar to the HL funding rate gap that blocked 9 strategies per analyst), the failure itself is informative and surfaces an infrastructure ticket.

The backtest reached Layer 3; signal/gate/exit/sizing logic already passed earlier layers, so this is the smallest change that fixes the reported data-coverage regression. Root cause (confirmed from the engine): supplementary feeds are injected SELECTIVELY by data_sufficiency.py, which detects literal supplementary_data keys in the strategy source; the previous version referenced only "open_interest", whose collect type is open_interest_hist (the Binance OI-history API, which only spans a recent window -> the observed 14 trades over ~2 months). The 104-trade 2020-2025 sibling drew OI from the "metrics" feed (Binance Vision metrics), which carries multi-year sumOpenInterestValue. Fix: _load_oi now parses and merges OI from BOTH supp['open_interest'] and supp['metrics'] via a shared _parse_oi_rows helper, and the literal string "metrics" in the code makes the detector inject that full-history feed. Parsing is restricted to DOLLAR open-interest value fields (open_interest_value / sumOpenInterestValue / sum_open_interest_value) so the merged series is unit-consistent and the surge ratio never jumps at a feed boundary; timestamp handling adds create_time (Binance metrics ms) and uses int(float(ts)) with the existing magnitude-based _norm_ns so ms/us/ns/s all normalize correctly; rows are merged, sorted, and de-duplicated by timestamp (keep last). Every other part of the strategy — the OI-delta signal, the surge/price-up/trend gates, the no-data flat behavior (no price-only fallback), exits, and capital-relative sizing — is byte-identical to the previous iteration, so Layers 1-2 stay green and Layer 3 should now produce the hypothesis's estimated 180-360 multi-year trades. Per the decision rule, once the backtest shows multi-year, multi-regime trades, optimization should sweep only the 4 core params (oi_surge_threshold, oi_lookback_bars, sma_period, take_profit_pct) with tightened clamps; the infra params stay fixed. Leverage stays 1.0 referenced only as a non-multiplier, so the unused-leverage gate does not apply.

Do not optimize — the OI-surge mechanism cannot be validated (multi-year data gap) and shows no edge where data exists. Despite ~6 years of bars processed, the 256 trades cluster only in 2020-09 to 2022-08 and 2026, with NO trades in 2023/2024/2025 (annual_returns jump 2022 -> 2026), because the merged open_interest+metrics OI feed has a 2023-2025 blackout. This is the iteration-2 fix the developer already attempted (merging the recent-only OI-history API feed with the Binance Vision metrics sumOpenInterestValue to span full history), and the gap persists — indicating the multi-year OI data is genuinely not in the catalog (or still unreadable), not a quick loader tweak, the same infrastructure dead-end as the taker-flow `metrics` and `liquidations` strategies this session. A 3-window walk-forward would run an entire window on zero data, so the edge cannot be validated. Separately, even in the covered window the signal has no edge: profit_factor 0.95, Sharpe -0.39 (sharpe_ci_low -2.06), expectancy -$22.8/trade, total_return +1.1% (flat), with commission_pct_of_gross 8.23% (fee-fragile) and negative covered years (2022 -11.8%, 2026 -5.9%). No optimization manufactures a multi-year OI feed or makes a break-even, fee-eaten signal profitable. Recommend filing a data-collection/infrastructure ticket for historical open-interest coverage (the same gap class that blocked the taker-flow and liquidations hypotheses); until a continuous multi-year OI feed exists AND the signal shows a positive net-of-fee edge in-window, this should be abandoned rather than optimized or iterated again.

Do NOT optimize — this version only sees ~2 months of open-interest data (14 trades, all 2026-03-26 to 2026-05-15) over a 6.5-year range, so there is nothing to optimize on. CRITICAL CONTEXT: a sibling implementation of this same hypothesis achieved 104 trades across 2020-2025 (multi-regime, Sharpe 2.43) using OI data, so multi-year open-interest data IS available and loadable — the 14-trade window here is a data-loading regression, NOT a structural OI-history wall. ACTION: (1) Debug _load_oi(): confirm the field names and timestamp units in the injected supplementary_data['open_interest'] match what the parser expects (open_interest_value / sumOpenInterestValue / open_interest / sumOpenInterest; timestamp_ms / timestamp / ts), and confirm the FULL multi-year OI history is being injected into this backtest rather than a recent ~2-month slice. (2) Re-run the initial backtest and verify it now produces a few hundred trades across 2020-2026 (the hypothesis's own 180-360 estimate) like the 104-trade sibling. DECISION RULE: once the backtest produces multi-year, multi-regime trades, proceed to optimization (sweep ONLY the 4 core params: oi_surge_threshold, oi_lookback_bars, sma_period, take_profit_pct, with tightened clamp ranges so the optimizer can't escape the validated region — and hard-code the infra params so the Optuna search stays 4-D); if the OI data genuinely cannot be loaded beyond ~2 months for this version, fix the injection/parsing before any optimization. NOTE: a separate iteration_1_feedback.md already exists in this discussion folder from a post-optimization analysis of the 104-trade version (param-starvation fix) — left intact, not overwritten.