BtcDeribitWeeklyCashSecuredPutWriteVrpTrendGated

Deribit BTC Weekly Cash-Secured OTM Put-Write — Volatility-Risk-Premium Harvest, IV>RV Gated, Trend-Filtered

A single-leg, fully-collateralized (cash-secured) systematic PUT-WRITING strategy on Deribit BTC weekly options that harvests the crypto volatility risk premium (VRP): implied vol on BTC options structurally exceeds subsequently-realized vol, so the seller of insurance is paid an edge over time. This is the factory's FIRST options strategy and fills the largest quota gap (options 0.1% vs >=15% target) while simultaneously relieving the 80% BINANCE over-representation. Each cycle the strategy selects the nearest weekly Deribit BTC expiry (5-9 days out) and writes ONE ~20-delta OTM put, FULLY collateralized in cash (no leverage, no margin call risk — max loss is bounded by the strike, i.e. equivalent to agreeing to buy BTC at a discount). The position is gated by two structural filters: (1) a VRP gate — only write when 7-day ATM implied vol (from Deribit greeks/IV feed) exceeds trailing 10-day realized vol by a margin (IV/RV > ~1.15), so we only sell insurance when it is richly priced; (2) a regime/trend gate — only write when BTC spot is above its 50-day SMA, to avoid selling puts into a confirmed downtrend / falling knife (the dominant tail risk of put-writing). Single-instrument-per-cycle keeps the backtest on the clean engine path and avoids the multi-leg/extra-leg-feed optimization artifact. The developer rolls weekly across listed Deribit BTC put instruments (the strategy picks the appropriate strike/expiry from the catalog each cycle).

Iteration 3 changes ONE config value; the strategy logic is byte-identical to iteration 2 (only the PERF docstring is updated to record the diagnosis). I profiled the actual timeout instead of guessing again: the sandbox subprocess launched 22:05:22 and was killed at 22:10:24 (302s), and the cost is NOT per-bar work — all per-bar state was already O(1) after iteration 2. It is the number of catalog QUERIES. BacktestRunner issues one catalog.bars() call per bar type, and with 35,765 bar directories in data/catalog each call costs a FIXED ~8.4s regardless of payload (measured on this box: BTC-PERPETUAL 1-DAY, 365 bars -> 8.31s; BTC-10APR26-63000-P, 19 bars -> 8.27s; BTC-17APR26-68000-P, 24 bars -> 8.77s). The 365-day weekly chain expands to 52 legs (confirmed in the run log: 'Deribit chain discovered contracts=52'), so data loading alone was 53 * 8.4s ~= 445s — which is exactly why iteration 2's 1-HOUR -> 1-DAY switch (24x fewer bars) changed nothing. Fix: lookback_days 365 -> 150, giving ~21 weekly legs, so loading is ~22 * 8.4s ~= 185s and the whole run lands around ~230s with real headroom under the 300s cap. I also dry-ran the FULL compound gate on real data over the shortened window before submitting (per the compound-gate lesson): in the last 150 days the VRP gate is open on 97/150 days, the trend gate on 70/150, BOTH on 51 days spanning 11 of 23 calendar weeks — so the chain will write roughly 8-11 puts, comfortably clearing the >=1-trade Layer-3 gate. To recover a little of the sample lost to the shorter chain I widened entry_window_hours 96 -> 120 (still inside the base's entry..expiry-24h window), so a week whose gates open mid-cycle still gets written. Tradeoff to flag for the analyst: the real backtest now covers ~5 months / ~10 trades rather than a year — that is thin, but it is forced by the sandbox cap given the ~8.4s-per-leg catalog cost, and the arithmetic is documented in the docstring (~30 queries is the ceiling) so the window can be re-widened if the catalog query cost is ever fixed upstream.

verifying_stuck_3_timeouts

Weekly cash-secured OTM put-write on Deribit BTC options (single leg, ~6% OTM, ~7 DTE), rolled weekly and closed 24h before expiry. Writes the put only when both structural gates are open: a VRP gate (Deribit DVOL implied vol >= 1.15x trailing 10-day realized vol) and a trend gate (spot above its 50-day SMA). Sizing is cash-secured/equity-relative (0.85 of equity divided by spot, floored at 0.1 contract), leverage 1.0, so max loss is bounded by the strike. The Deribit perp is the primary instrument purely as the weekly roll clock; the underlying is never traded.

Verification failed (Layer 4 — QA review) [class=not_measurable]: - [edge_concern] The sandbox's flawless metrics (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) are a BENIGN-WINDOW ARTIFACT — the entire risk of cash-secured put-writing is the crash tail, and this ~5-month window sampled none, so every put won. Any put-write looks free until a drawdown hits. avg_trade_return_pct 91.4% is premium-relative (not strike-notional, not comparable to spot/futures floors), and total_commission 0.0 on 16 Deribit option trades suggests option fees aren't applied — both further flatter a non-informative result. - Not measurable as configured. rolling_options.lookback_days is pinned at 150 (the developer's fix for the ~8.4s-per-leg catalog-query timeout), capping the tradeable chain to ~5 months and yielding only 16 weekly writes. That cap is baked into the config, so the full backtest is capped identically (~16 trades, below the ~30 options floor, L26). 16 tail-free writes cannot evaluate a VRP put-write whose edge/risk is defined by crash drawdowns — the window must span years to sample real left-tail events. DVOL + Deribit chain data exist; the blocker is the upstream per-leg catalog-query cost. Park until that cost is fixed so a multi-year chain (>=2yr, ~50-100 gated writes across several drawdowns) runs in budget; do not just lengthen lookback_days (reintroduces the timeout). - total_commission 0.0 across 16 Deribit option trades — Deribit charges option fees (min 0.03% underlying or 12.5% premium, plus settlement). If the engine isn't applying option commissions the premium-harvest PnL is overstated. Engine fee-application concern for the analyst/backtest engineer, not a strategy-code fault.

Verification failed (Layer 3 — sandbox backtest): smoke test exceeded the 300s wall-clock limit. 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).

Verification failed (Layer 4 — QA review): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — options expiry cadence x gating). The sandbox produced 12 trades over data_days=12 with the classic unmeasurable-degenerate signature: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (an impossible per-trade figure for a cash-secured put-write — the options notional/return computation is untrustworthy). These are not real performance signals. Per L26 (window/expiry x gate-pass): lookback_days was cut 365->150 to fit the 300s cap, and the compound VRP+trend gate opens in only ~11 of 23 weeks -> ~8-11 puts. ~10 trades is far below the ~30-trade floor and cannot distinguish VRP edge from noise. - INFRASTRUCTURE HARD-CAP makes the sample non-measurable at ANY parameterization. Per the developer's own docstring, each catalog.bars() query costs a fixed ~8.4s and the run is capped at ~30 queries (~250s) under the 300s timeout, so the backtest covers AT MOST ~30 weekly legs (~7 months) -> ~15 trades after gating. lookback_days=150 was forced to survive the timeout. No threshold tuning escapes the ~30-leg catalog-query ceiling. - PUT-WRITE TAIL-RISK MASKING. A ~10-trade win_rate 1.0 sample is the MOST misleading outcome for a short put: it means the window contained no crash week, exactly when a cash-secured put realizes its fat left-tail loss. The flattering sandbox (all wins, zero drawdown, Sharpe 31) is theta decay in benign weeks and hides the only risk that matters. - The code is CORRECT and faithfully implements the hypothesis: put-write polarity (P -> SELL), cash-secured strike-bounded sizing, VRP gate (atm_iv >= rv*vrp_ratio), trend gate (spot > SMA), causal DVOL lookup (searchsorted right-1, no look-ahead), legs closed 24h before European settlement, documented ungated fall-through when IV missing (no silent edge swap). Options-correctness (#12) passes. Noted so the developer does not chase a phantom coding bug.