COIN-M BTC Negative-Funding Carry, Long-Only Single-Leg (BINANCE_CM Inverse Perp BTCUSD_PERP, Collect Funding Paid-To-Longs During Backwardation Episodes, Multi-Day Hold, BTC-Denominated Returns, 3-Parameter)

A LONG-ONLY, single-leg CARRY strategy on the deepest coin-margined inverse perpetual, BTCUSD_PERP.BINANCE_CM. Mechanism is identical in spirit to the deployed survivor '5-Asset Negative-Funding Carry Basket' (Sharpe 1.97) and 'Cross-Venue BTC Funding Carry' (Sharpe 8.58) — collect a real, mechanically-paid cashflow — but expressed on a genuinely under-represented venue (BINANCE_CM is only 3.0% of the portfolio vs a >=5% quota target) and denominated in BTC, which is the reason the COIN-M venue exists. On an inverse perp, when 8h funding is NEGATIVE, shorts pay longs; a long position is PAID to hold. During risk-off / backwardation episodes on BTC, funding on the coin-margined contract goes persistently negative for 1-3 day stretches. We hold a single long BTCUSD_PERP position through those episodes to harvest the funding, with an ATR stop to bound the directional exposure that comes with being long a single name. Funding is used strictly as CARRY (a cashflow to collect), NOT as a direction predictor — this deliberately avoids the exhausted 'funding-as-signal-on-majors' class (L13). BTC CM is the single deepest inverse perp, so its funding history IS catalogued (avoids L20, which only bites thin multi-asset CM baskets). Deliberately 3 parameters and low-turnover to resist the overfitting that killed 229 prior hypotheses.

Iteration 2 fixes the reported Layer-3 zero-trade failure with two small, targeted changes and touches nothing else. ROOT CAUSE: _build_funding filtered keys with 'if not isinstance(k, int): continue'. The funding dict carries dual int/str keys only IN-PROCESS - the supplementary blob is JSON round-tripped into the backtest subprocess, after which only the STRING keys survive (documented in data_specification and confirmed in supp_collector's json.loads(json.dumps(...)) normalisation step). So the series parsed empty, _fund_ready stayed False, _data_ok was never True, and should_enter returned None on all 6,365 evaluated bars - exactly the diagnostic reported. The fix coerces BOTH key types with int(k) inside a try, deduping by timestamp, which is correct under either shape. SECOND, per the 'loosen the entry threshold' instruction, I measured the real BTCUSD_PERP COIN-M funding series (1,034 settlements): a 3-print mean pays longs at least 0.5 bps/8h in only 24 distinct episodes, versus 42 episodes at 0.25 bps, so the default entry_rate_bps drops 0.5 -> 0.25 while still requiring genuine backwardation (strictly above zero, and the exit stays at zero for hysteresis). Nothing else changed: imports, class structure, the continuous per-bar carry score, the no-price-proxy no-data policy, the exits and the inverse contract sizing are as they were when Layers 1, 1.5 and 2 passed, so no earlier check can regress. Honest note for the analyst: COIN-M funding history begins 2025-05-25, so only the recent ~1 year of the 8H window can generate trades - roughly 40 carry episodes - and the earlier bars are legitimately signal-free rather than broken.