BtcCmOpenInterestConfirmedSwingLS

Open-Interest-Confirmed Positioning-Shift Swing (BINANCE_CM Inverse Perp BTCUSD_PERP — Take a Directional Swing ONLY When a Price Move Is Backed by RISING Open Interest = New Conviction Money; Stand Aside on Deleveraging Moves Where OI Is Falling; Exit When OI Rolls Over, 3-Parameter)

A LONG-SHORT, SINGLE-INSTRUMENT, SINGLE-VENUE swing strategy on BTCUSD_PERP.BINANCE_CM (COIN-M inverse perpetual, BTC-margined, ~0.06% RT taker). The signal is driven PRIMARILY by open interest (a sandbox-available, orthogonal-to-price positioning feed), not by price alone. The core insight — which is NOT a re-derivation of trend — is that a directional price move means very different things depending on whether open interest is EXPANDING or CONTRACTING. Rising-OI moves are new money taking conviction positions and tend to persist; falling-OI moves are deleveraging / short-covering / stop-runs with no fresh conviction and tend to chop and reverse. The strategy therefore only takes a swing in the two 'rising-OI' quadrants and stays FLAT in the deleveraging quadrants, which is exactly where price-only trend systems whipsaw. It deliberately fills three under-represented buckets: BINANCE_CM venue (3.2% vs >=5% target), long_short direction (13.2% vs push target), and it keeps a single-venue single-instrument structure to avoid the cross-venue/multi-leg verification_loop trap (L44) and the options/IV sandbox trap (L43). It uses OI as the orthogonal dependency demanded by L42 rather than dressing a price-only trend signal in a new indicator name.

verification_loop: Verification failed (Layer 1 — config): config.instrument_id and config.bar_type are REQUIRED (got instrument_id=None, bar_type=None). Set both to the hypothesis's instrument, e.g. instrument_id='BTCUSDT.BINANCE', bar_type='BTCUSDT.BINANCE-4-HOUR-LAST-EXTERNAL'.

Verification failed (Layer 1 — config): config.instrument_id and config.bar_type are REQUIRED (got instrument_id=None, bar_type=None). Set both to the hypothesis's instrument, e.g. instrument_id='BTCUSDT.BINANCE', bar_type='BTCUSDT.BINANCE-4-HOUR-LAST-EXTERNAL'.

BtcCmOpenInterestConfirmedSwingLS aimed to use open interest — an orthogonal positioning feed — to distinguish conviction-backed moves (rising OI, tradeable) from deleveraging whipsaws (falling OI, stand aside) on the under-represented BTC COIN-M venue. Across three iterations it fought the OI data layer: a prior run took zero entries over 17,442 bars because the OI series was never built or matched, prompting broad parser and staleness fixes. The final iteration then failed even more basically at Layer 1 config validation — instrument_id and bar_type were both None — so the strategy could not be instantiated. It was abandoned in the verification loop without ever producing a backtest, verification pass, optimization, or analysis.

Basic configuration correctness is a gating prerequisite — an OI-driven edge (or any edge) is never evaluated if config.instrument_id/bar_type are unset and Layer 1 rejects the strategy; and repeated OI-feed plumbing failures across iterations signal a data-availability wall that should be confirmed before further threshold tuning.

It was abandoned in a verification loop: the final iteration failed Layer 1 (config) because the required config.instrument_id and config.bar_type were both None, so the strategy could not even be instantiated — let alone reach synthetic tests, the sandbox backtest, QA, or any downstream stage. Combined with the prior zero-entry OI-data problems across three iterations, the run never generated a valid backtest.

A long-short, single-instrument, single-venue swing strategy on the BTC COIN-M inverse perp (BTCUSD_PERP.BINANCE_CM, 1H) that gated entries on open interest as an orthogonal positioning feed — taking a directional swing only when a price move was backed by rising OI (new conviction money), standing flat during falling-OI deleveraging moves, and exiting when OI rolled over from its peak, with an ATR stop and time cap.

No performance data exists — the strategy never produced a backtest. Earlier iterations struggled at the OI-plumbing level (iteration 3 was fixing a 'should_enter returned a side 0 times over 17,442 bars' failure caused by the OI series never being built/matched), and the final run failed even earlier at Layer 1 config validation.

Verification failed (Layer 2 — synthetic scenarios): Parameters used: ['move_atr', 'risk_pct', 'atr_period', 'oi_lookback', '_param_bounds', 'atr_stop_mult', 'max_hold_bars', 'min_stop_frac', 'oi_change_pct', 'max_gross_frac', 'oi_rollover_pct'] Check that __init__ sets all attributes from self.parameters.get(). - steady_uptrend: TypeError: BtcCmOpenInterestConfirmedSwingLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691280000) - steady_downtrend: TypeError: BtcCmOpenInterestConfirmedSwingLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691280000) - flat_ranging: TypeError: BtcCmOpenInterestConfirmedSwingLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691280000) - volatility_spike: TypeError: BtcCmOpenInterestConfirmedSwingLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691280000) - zero_volume: TypeError: BtcCmOpenInterestConfirmedSwingLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691280000) - price_gap: TypeError: BtcCmOpenInterestConfirmedSwingLS._to_ns() takes 1 positional argument but 2 were given (bar timestamp: 1735691280000)

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