BtcWeeklyDirectionalDebitSpreadCheapIv

BTC Weekly Directional Debit Spread on BINANCE_OPTIONS — Convexity-Wrapped Trend, Long Calls-Spread in Uptrend / Long Puts-Spread in Downtrend, Cheap-IV-Gated, Weekly Roll (Defined-Risk, Long-Premium, 3-Parameter)

A DEFINED-RISK, LONG-PREMIUM, single-venue DIRECTIONAL options strategy on BINANCE_OPTIONS BTC weekly contracts. This deliberately fills the empty options bucket (BINANCE_OPTIONS = 0.0% of 2997 experiments; quota target >=15% combined options) while routing around every prior options death: it is NOT short vol (so it cannot draw the Deribit short-straddle/strangle risk_reject/no_edge deaths), it is NOT a slow monthly single-leg roll (the ETH Deribit ~30-delta monthly/biweekly long-convexity died data_wall on only 12 trades), and it trades the option legs directly on a weekly cadence (the ETH covered call died with 0 option trades). Each Monday (or first available weekly expiry ~7 DTE), read the primary BTC trend: sign of a slow momentum measure on the underlying (e.g. price vs a ~8-week EMA, or 8-week return sign). If UP, BUY a call debit spread (long ~25-delta call, short ~12-delta call, same weekly expiry); if DOWN, BUY a put debit spread (long ~25-delta put, short ~12-delta put). The short wing finances part of the long leg, cutting theta bleed roughly in half versus a naked long option and capping the premium at risk — which is exactly why the naked monthly convexity trade bled out and had too few trades. Enter ONLY when option IV rank is LOW (short-dated ATM IV in the bottom ~40% of its trailing 8-week range) so convexity is bought cheap and the positive-VRP headwind (crypto IV usually > RV) is smallest. Hold to expiry or exit early on a defined profit/stop, then roll into the next weekly. This produces a POSITIVELY-SKEWED payoff (small capped losses when the trend chops, large capped wins on the fat-tailed weekly BTC trend legs) that can survive where the LINEAR 4H/daily momentum re-skins (L91) and the short-vol harvests (L87) cannot, because the loss side is bounded and the win side rides the fat right tail of BTC weekly returns.

Layer-1.5 fix, minimal in scope: iteration 1 implemented the identical mechanism on the DERIBIT rolling weekly chain and failed hypothesis/config consistency because the hypothesis declares BINANCE_OPTIONS contracts. This version trades exactly those four declared legs on BINANCE_OPTIONS. The rolling-options base could not be reused: expand_rolling_options resolves chains through discover_deribit_chain only (Deribit-exclusive), so a Binance-Options program must name its contracts, which is what the hypothesis does — hence a plain FactoryStrategy with the four legs as primary + extras. The reported timeframe note is also fixed: the trend clock is now a 1-WEEK BTCUSDT bar (the hypothesis's '8-week EMA', weekly cadence) with the option legs on 1-DAY premium bars; hypothesis_config_check now returns no problems and no warnings. Signal, cheap-IV gate, defined-risk sizing and exit rules are carried over unchanged from the code that already passed Layer 1 (static analysis re-run: passed; Layer-2 synthetic re-run: passed). HONEST DATA CAVEAT (why the recommendation is abandon): the declared contracts cannot be backtested. Binance's option API serves klines for CURRENTLY-LISTED contracts only — I queried eapi/v1/klines for BTC-260116-120000-C while coding and it returns -1121 'symbol does not exist' (same for a recently expired contract, BTC-260829-74000-C), and data.binance.vision hosts only BVOLIndex/EOHSummary for options, no per-contract klines. The catalog holds zero BINANCE_OPTIONS bar directories for the same reason. So this config will reach Layer 3 and abandon data_unavailable, and no code change can create the data. More fundamentally, a HISTORICAL weekly-roll program is impossible on Binance Options: weeklies are listed only days before expiry (the live BTC expiry set today is 260908..270625), so only the long-dated quarterlies carry ~8 months of history. The mechanism itself is backtestable on DERIBIT, which does serve expired-contract candles and is what the rolling-chain expander supports. Recommended revision for the Research Lead: re-declare this hypothesis on the Deribit BTC weekly chain (identical structure: long 25-delta / short 12-delta vertical, cheap-IV gated, weekly roll) — iteration 1's code implements exactly that and would run.

data_unavailable: backtest data for BTC-260116-120000-C.BINANCE_OPTIONS could not be collected after 5 retries: data collection for BTC-260116-120000-C.BINANCE_OPTIONS exceeded the 600s per-cycle budget; resuming next cycle The data layer (not the strategy) is the blocker — re-evaluate this hypothesis once collection is fixed / the symbol is backfilled.

Defined-risk, long-premium DIRECTIONAL debit spread on the BINANCE_OPTIONS BTC chain declared by the hypothesis (BTC-260116 120000/125000 calls and 100000/95000 puts). A slow 8-WEEK EMA distance on BTCUSDT weekly spot bars sets the view: trend up -> buy the CALL debit spread (long 120000C / short 125000C), trend down -> buy the PUT debit spread (long 100000P / short 95000P). Entries fire only on the calendar-anchored entry weekday (Monday, derived from the bar timestamp), only while days-to-expiry sits in [min_dte_days, max_dte_days], and only when the vol level ranks in the bottom 40% of its trailing window (Deribit DVOL implied-vol index preferred, the underlying's realized vol used for the same cheap-vol question when DVOL has no history). The short wing finances part of the long leg, halving theta bleed and capping max loss at the net debit; size is set so that debit is at most 2% of equity. Exits: +60% of debit take-profit, -50% stop, trend flip against the structure, or 1 day before expiry. The underlying is the trend source only and is never traded — every order goes to an option leg.

BtcWeeklyDirectionalDebitSpreadCheap-857442b835

This strategy reached iteration 2, having already fixed a Layer-1.5 venue-consistency issue by re-routing its debit-spread mechanism onto the four declared BINANCE_OPTIONS BTC weekly legs. Its thesis was to buy cheap convexity in the direction of an ~8-week trend, using a short wing to finance the long leg and cap losses at the net debit. However, the pipeline never got to test it: backtest data for BTC-260116-120000-C.BINANCE_OPTIONS could not be collected after 5 retries, exceeding the 600s per-cycle budget. The run was abandoned for data_unavailable reasons — a data-layer blocker rather than a strategy flaw — with the note to re-evaluate the hypothesis once collection is fixed or the symbol is backfilled.

Before committing an options hypothesis to named BINANCE_OPTIONS contracts, confirm that the data layer can actually collect those specific legs within the per-cycle budget; a sound mechanism cannot be tested if the underlying market data is unavailable.

It was abandoned at the data-availability stage — backtest data for the declared contract BTC-260116-120000-C.BINANCE_OPTIONS could not be collected after 5 retries (collection exceeded the 600s per-cycle budget), so no backtest, backtest-review, optimization, or analyst stage was ever reached.

A defined-risk, long-premium directional options strategy on BINANCE_OPTIONS BTC weekly contracts that buys a call debit spread in an uptrend and a put debit spread in a downtrend, gated to enter only when short-dated IV is cheap, aiming for a positively-skewed payoff with capped losses.

No performance metrics exist: the backtest report is empty and no optimization report was produced, so the strategy was never actually evaluated for return, Sharpe, or trade count.

Verification failed (Layer 1.5 — hypothesis/config consistency) [class=hypothesis_mismatch]: - config.instrument_id is BTC-PERPETUAL.DERIBIT but the hypothesis declares BTC-260116-120000-C.BINANCE_OPTIONS, BTC-260116-125000-C.BINANCE_OPTIONS, BTC-260116-100000-P.BINANCE_OPTIONS, BTC-260116-95000-P.BINANCE_OPTIONS — a different asset. Implement the hypothesis as written (or the Research Lead must revise it). Also note: - hypothesis states Weekly bars but config.bar_type is BTC-PERPETUAL.DERIBIT-4-HOUR-LAST-EXTERNAL (4-HOUR) — QA rejects a timeframe that contradicts the hypothesis; align bar_type or revise the text.