BtcDeribitWeeklyDebitVerticalDailyTrend

BTC Deribit Weekly Directional DEBIT VERTICAL Spread, Daily-Trend Gated (Long-Short via Call/Put Verticals, Cross-Venue Signal, Defined-Risk, 2-Parameter)

A CROSS-VENUE, LONG-SHORT, DEFINED-RISK directional options overlay on Deribit BTC weekly options. This deliberately fills the two biggest structural gaps in the corpus at once: OPTIONS venue (BINANCE_OPTIONS+DERIBIT combined ~6% vs >=15% target, essentially zero survivors) and CROSS-VENUE (6.9% vs >=15%). It is NOT a short-volatility VRP structure (those repeatedly die risk_reject/no_edge: BTC/ETH delta-hedged straddles, short strangles, cash-secured put writes), and it is NOT an outright long-premium straddle/OTM buy (those bleed theta and die no_trades/no_edge). Instead it expresses the ONE mechanism that actually survives in this factory -- daily-timeframe directional trend on BTC (see the paper-stage BTC/ETH/ADA dual-timeframe momentum survivors) -- but packages it as a DEBIT VERTICAL SPREAD so the short leg finances the long leg's theta and the max loss is capped at the net debit. Signal is generated from BTCUSDT.BINANCE USD-M perp daily bars (the deep, clean price series the survivors use); execution is on DERIBIT BTC weekly options (the most liquid crypto option chain -- BTC specifically is required here because only the BTC weekly chain has strikes tight enough that BOTH legs of a vertical fill without the spread cost eating the edge; ETH weekly verticals are materially wider off-ATM). No continuous delta-hedging (that is what timed out the covered-call and straddle attempts) -- the position is opened once per weekly cycle and held to expiry, so per-bar work is O(1). Two parameters only (trend lookback, spread width in ATR units), chosen to keep walk-forward/holdout from fitting noise.

Iteration 3 changes ONLY what the reported Layer-3 sandbox_timeout requires: the SIZE OF THE RESOLVED OPTION CHAIN. Layers 1, 1.5 and 2 stay green because the Python body is byte-identical to iteration 2 apart from the module docstring - no imports, signal, sizing, entry, roll or guard logic was touched. Diagnosis, measured on this host under the load the sandbox actually runs at (load avg ~55): 40 Deribit BTC daily option legs cost 81.7s in catalog.instruments() plus 93.2s in the batched catalog.bars() call (~175s), and the probe burned only 31s of CPU in 9 minutes of wall clock - it is leg-count I/O, not per-bar strategy work (which is a few float ops on bounded deques). Corroborating corpus evidence from today on the same box: a sibling Deribit weekly run timed out at 208 daily legs and passed at 154; iteration 2 asked for 312-318. So legs = (lookback_days/7) x rungs_per_cycle is the only lever, and iteration 3 cuts it from both sides: the ladder drops from 3 rungs per side to 2 (ATM + ~3.5% OTM) and lookback_days goes 365 -> 182, i.e. 26 weekly cycles x 4 rungs = ~104 legs (a third of iteration 2, and a third below the 154-leg configuration known to clear the cap here). 26 structures = ~52 leg positions, above the 30-trade daily-strategy sample floor though below the hypothesis's pre-registered 80 - the alternative (more cycles) is a run that produces no number at all, which is what the last two iterations produced. HONEST CONSEQUENCE, flagged deliberately: with one OTM rung per side there is exactly one listed vertical per direction per week, so width_atr computes its target width but no longer chooses between candidate short strikes - a sensitivity sweep of width_atr will read flat and the binding width is the ladder's 3.5% moneyness (~1.8 daily ATRs at typical BTC weekly vol, i.e. the parameter's default). The selection code is unchanged and generalizes to any rung count >= 2, so a third rung can be restored the moment the wall-clock budget allows it. _param_bounds still mirrors every clamp in the code.

verification_loop: sandbox_timeout: Verification failed (Layer 3 — sandbox backtest): smoke test exceeded the 600s wall-clock limit on a ~20000-bar window (2400 days of BTCUSDT.BINANCE-1-DAY-LAST-EXTERNAL). This almost always means per-bar work that scales with history — e.g. rescanning the full funding/supplementary series, or rebuilding a list and calling min()/sorted() inside calculate_signal()/on_bar() on every bar. Precompute sorted timestamp arrays ONCE in __init__ and use bisect, or cache lookups keyed by timestamp, so per-bar cost is O(log n) not O(n).

Cross-venue, long-short, defined-risk weekly options overlay on BTC. A vol-normalised 30-day momentum t-stat on BTCUSDT.BINANCE 1-DAY closes picks the direction; the view is expressed once per weekly Deribit BTC cycle as a vertical DEBIT spread - bullish: buy the ~ATM call / sell the ~3.5% OTM call; bearish: buy the ~ATM put / sell the ~3.5% OTM put. Both legs are submitted on the same bar (never a naked short option) at the cycle's entry (expiry - 7d) and held to expiry, closed 24h before settlement by the roll schedule. The short leg finances the long leg's theta and caps max loss at the net debit, which is exactly what the sizer risks (contracts = equity * risk_frac / net_debit). Two economic parameters: trend_lookback_days (momentum horizon) and width_atr (target strike width in daily-ATR units). No delta hedging, no early exits; per-bar work is O(1). The historical Deribit weekly BTC chain is resolved before the run from parameters['rolling_options'] and injected as option legs + a roll schedule; if the chain is unavailable the run fails loud - there is no underlying fallback.

sandbox_timeout: Verification failed (Layer 3 — sandbox backtest): smoke test exceeded the 600s wall-clock limit on a ~20000-bar window (2400 days of BTCUSDT.BINANCE-1-DAY-LAST-EXTERNAL). This almost always means per-bar work that scales with history — e.g. rescanning the full funding/supplementary series, or rebuilding a list and calling min()/sorted() inside calculate_signal()/on_bar() on every bar. Precompute sorted timestamp arrays ONCE in __init__ and use bisect, or cache lookups keyed by timestamp, so per-bar cost is O(log n) not O(n).

BtcDeribitWeeklyDebitVerticalDailyTr-d62a4d17a2

BtcDeribitWeeklyDebitVerticalDailyTrend aimed to fill the corpus's options and cross-venue gaps by taking the one mechanism that has survived in this factory — daily BTC trend — and packaging it as a defined-risk Deribit weekly debit vertical, with the short leg financing the long leg's theta and max loss capped at the net debit. Across three iterations the author repeatedly cut the leg count (365 days x 6 rungs = 312 legs, then 182 days x 4 rungs = 104 legs) to fit the sandbox budget, even documenting that the trimmed 2-rung ladder would leave the width_atr parameter effectively inert. It still exceeded the 600s Layer-3 wall clock and was abandoned in the verification loop, so no backtest, optimization or analyst verdict was ever produced. The run is a record of an infrastructure ceiling on options-chain backtests rather than a judgement on the trading thesis.

For multi-leg options strategies the sandbox cost is dominated by per-leg catalog I/O (instrument and bar loading), not per-bar Python, so the leg budget — cycles x rungs — must be sized to clear the wall-clock cap before any edge can be measured.

It was abandoned in the verification loop after iteration 3 with a Layer-3 sandbox timeout — the smoke backtest exceeded the 600s wall-clock limit on the ~20,000-bar (2400-day) BTCUSDT.BINANCE 1-DAY window; backtest review, optimization, analyst and risk review were never reached.

A cross-venue, defined-risk directional options overlay that generated a daily vol-normalised momentum signal on BTCUSDT.BINANCE perp bars and expressed it as a BTC weekly call or put debit vertical spread on DERIBIT, held to expiry with only two economic parameters (trend lookback and spread width in ATR units).

No performance numbers exist: the backtest report is empty and no optimization report was produced, because the strategy never cleared verification.