BtcDeribitWeeklyDeltaNeutralShortStrangleVrp

BTC Deribit Weekly Delta-Neutral Short-Strangle Volatility-Risk-Premium Harvest (Options, IV>RV Gated, Defined-Risk Stops, 3-Parameter)

A SHORT-VOLATILITY, delta-neutral options strategy on DERIBIT BTC weekly expiries that harvests the crypto Volatility Risk Premium (VRP) — the persistent structural gap where option-implied vol systematically exceeds subsequently-realized vol. Once per weekly cycle (front expiry ~5-7 DTE), and ONLY when implied vol is richer than trailing realized vol by a set margin, the strategy sells an out-of-the-money strangle: short one ~20-delta call and one ~20-delta put, opened delta-neutral. It collects premium and lets theta/vega decay work over the week. This is deliberately chosen to fill the single largest portfolio gap — options are 4.7% of the book vs a ≥15% quota, and BINANCE_OPTIONS+DERIBIT have essentially zero prior coverage (1 experiment). It is also market-neutral at entry, helping the direction quota (86% long-only). Only 3 tunable parameters to resist the overfitting that killed 258 prior hypotheses. NOT a funding-carry idea (L33), NOT a momentum/trend-confluence port (exhausted family), NOT a single-name price reversal/fade (inverted-RR graveyard) — the edge is a documented, mechanically-driven insurance premium, not a price-prediction bet.

Iteration 3 makes the smallest changes that address the three Layer-4 findings, leaving the Layer-1/2/3-passing structure untouched (same imports, same class hierarchy, same continuous IV-RV signal, same 91-day chain window that passed Layer 3). Finding 3 (stacked degrade-open) is fixed: the ~20-delta band check no longer degrades open when DVOL is missing — it falls back to trailing realized vol as the strike-distance yardstick (used only to sanity-check moneyness, never to time the trade, so no edge substitution) and now BLOCKS when neither IV nor RV, spot, or time-to-expiry is measurable; strikes are parsed from the Deribit symbol when the chain payload omits them, which closes the silent no-op path where a missing 'strike' field made the band check pass unconditionally; and on_stop now reports gated_entries vs ungated_entries plus the vol source used for each band check, so the reviewer can directly count how much of the traded sample was genuinely IV>RV-gated. Finding 1 (untrustworthy P&L / all-wins, zero-drawdown signature) is attacked at the only mechanism reachable from strategy code: an unbooked adverse leg. A new idempotent sweep force-closes any leg still holding an open position past expiry-minus-roll-buffer (guarded on an actual open position and latched per leg, so no duplicate closes), the defined-risk stop now accrues premium over ALL open legs of a period instead of skipping legs without a fresh bar (previously it could fire against partial premium), and on_stop emits a per-leg booking audit — entry price, exit price, realized PnL, win/loss/flat counts, realized total, and legs still open at stop — so the next review can verify booking from the log rather than inferring a defect from aggregate metrics. Finding 2 I cannot fix in strategy code and I say so plainly: two legs per weekly structure is irreducible (one leg is a naked directional short, a different hypothesis) and each catalog.bars() query costs a fixed ~8.9s of fsspec directory-walk, so ~13-16 cycles is the hard ceiling under the 300s Layer-3 cap; 30+ cycles needs ~545s and would SIGKILL, which would regress a passing layer. lookback_days can go to 365+ with zero strategy change once BacktestRunner caches the globbed file list, and until then the ~13-cycle metrics (and avg_trade_return_pct, which is meaningless against option-premium notional) should be read as a smoke test, not as edge — if the reviewer holds the ~30-cycle line, abandon-pending-that-platform-fix remains the honest verdict.

Structurally unmeasurable smoke test, not an edge — the developer pre-registers this and the engine confirms it. metrics_reliable=false, sharpe_note 'Unreliable: only 3 days moved the equity curve (span 78d)', effective_daily_obs 3, data_days 78: just 6 trades (3 strangles) over ~2.5 months in one calm BTC regime. The 100% win rate with max_drawdown 0.0 and zero losses is the textbook short-vol suspected artifact — the crash tail the strategy is short is entirely un-sampled (return_skew 5.6, kurtosis 34 on 3 points). The docstring documents the hard ~13-16-cycle infrastructure ceiling (one ~8.9s catalog query per bar type against the 300s cap) and states the metrics are a smoke test and avg_trade_return_pct is meaningless for option-premium notional; reaching the 30+ cycles a short strangle's tail needs requires a PLATFORM fix (cache the globbed file list), not a strategy-code change. The 3-phase walk-forward/holdout cannot populate on 3 cycles. This is the L67/L23 Deribit short-vol options family. Failure pattern: structurally unmeasurable single-regime option history (infra query ceiling) + short-vol under-sampled crash tail, metrics_reliable=false (L67/L23).

Weekly delta-neutral short strangle on BTC Deribit options that harvests the volatility risk premium: when the DVOL implied-vol index exceeds trailing realized vol by vrp_ratio, it sells one ~6%-OTM call and one ~6%-OTM put on the front weekly expiry (symmetric offsets -> delta-neutral at inception, delta verified inside a [0.10, 0.40] band per cycle), holds through the week for theta/vega decay, and closes 24h before European cash settlement. A defined-risk stop closes the whole structure when combined open loss reaches stop_loss_mult x premium collected, and an idempotent sweep force-closes any leg still open past the roll buffer so every leg's PnL is realized and booked. Three tunables: vrp_ratio, rv_window, stop_loss_mult.

Verification failed (Layer 4 — QA review) [class=not_measurable]: - [edge_concern] Sandbox is non-informative: 6 trades over 78 days, win_rate 1.0, max_drawdown 0.0, PF 0.0, Sharpe 3.56 but metrics_reliable=FALSE. For a SHORT STRANGLE the entire risk is in the tail (unbounded adverse wing move, capped only by a 2x-premium stop), so 6 winning calm-window weeks with zero drawdown say nothing about the loss tail that defines the strategy. avg_trade_return_pct 93.9% is meaningless (premium notional « underlying). The all-wins/zero-DD/PF-0 signature is also the fingerprint of unbooked adverse legs; the iter-3 forced-close + booking audit are the right fix but can't be confirmed at 6 trades — the eventual backtest must read the on_stop per-leg booking audit (legs_open_at_stop=0, some losing legs) to verify. - Structurally unmeasurable sample. Weekly Deribit expiries gated by IV>RV yield single-digit entries, and the backtest is HARD-CAPPED by infrastructure: per the developer's own diagnosis each catalog.bars() query costs ~8.9s, so a two-leg weekly structure fits only ~13-16 cycles under the 300s cap and 30+ SIGKILLs. Sandbox realized 6 trades (metrics_reliable=false). A tail-risk-dominated short-vol strategy cannot be characterized on <~30 cycles of all-winning calm trades (L26). Not fixable in-strategy — needs the engine's globbed-file-list caching so a 365-day+/30+-cycle history can run. Park pending that platform fix; developer concurs this is the honest verdict. - Booking note (not the blocking reason): metrics still show the all-wins/zero-DD/PF-0 signature the iter-3 fixes targeted. Plausibly just a calm 6-trade window rather than a defect, and the forced-close sweep + booking audit are correctly coded, but unconfirmable at this sample size. When the measurable backtest runs, verify from the on_stop audit that legs_open_at_stop=0 and some legs booked losses in high-move weeks; if adverse legs still show unbooked, that's a separate code_defect.

Careful booking-audit / forced-close / delta-band hardening; genuinely delta-neutral (net_entry_delta 0.04) and the DVOL gate is real

Explicitly unmeasurable: metrics_reliable=false, sharpe_note 'Unreliable: only 3 days moved the equity curve (span 78d)', effective_daily_obs 3, data_days 78 — just 6 trades (3 strangles) over ~2.5 months in one calm BTC regime

Win rate 1.0 with max_drawdown 0.0 / largest_loss 0.0 is the textbook short-vol suspected artifact — the crash tail the whole strategy is exposed to is entirely un-sampled (return_skew 5.6, kurtosis 34 on 3 points)

The developer documents the ~13-cycle infrastructure ceiling (300s/8.9s per query) and states these metrics 'are a smoke test, not edge,' with 30+ cycles requiring a PLATFORM fix

L67/L23 Deribit short-vol options family — thin single-regime option history

Verification failed (Layer 4 — QA review): - STRUCTURALLY UNMEASURABLE SAMPLE. The strategy is a weekly options roll hard-capped at 10 cycles by design: lookback_days=70 / 7-DTE = 10 weekly strangles = 20 legs, and after the VRP gate (IV>=RV*1.15) only ~5-7 of those cycles actually fire. The author's own docstring/rationale states this is an 'INFRASTRUCTURE ceiling, not a design choice' and that widening to a 365-day chain (~105 catalog queries ~= 1050s) would be SIGKILLed at the 300s cap -- i.e. the REAL backtest cannot widen the sample either without a catalog-query-cost fix. The sandbox already shows the consequence: total_trades=20 legs (10 structures), data_days=10, sharpe_ci_low=-0.1692 / sharpe_ci_high=86.7223 -- a confidence interval so wide the result carries zero information. A short-vol VRP harvester is exactly the strategy family that CANNOT be evaluated on a handful of cycles: its entire risk is the rare tail (avg_loss $735 vs avg_win $149, a single tail event dominates), and 5-10 cycles cannot sample that tail. Per accumulated learning L26, options strategies whose expiry cadence + IV gating imply < ~30 trades over the backtest span must be rejected at Layer 4 before they burn backtest/optimization/timeout iterations discovering they are unmeasurable (this exact fate befell the Deribit monthly/weekly put-write siblings at 1/4/5 trades). This one is worse than those precedents because it is architecturally incapable of ever producing a larger sample. - STRIKE SELECTION APPROXIMATES BUT DOES NOT MATCH THE STATED '~20-delta' SPEC. The hypothesis calls for short ~20-delta OTM call and put; the code/config use fixed symmetric +/-5% moneyness offsets (rolling_options.legs offset +0.05 / -0.05). A fixed 5% strike is not a 20-delta strike and does not adapt to the vol regime -- in a high-IV week (precisely when the VRP gate opens) 5% OTM is far closer to ATM (higher delta / more tail exposure) than 20-delta, and in a calm week it is much further OTM. The essential structural property the hypothesis needs (symmetric offsets => delta cancels at entry => delta-neutral inception) IS preserved, so this is not a whole-strategy swap, but the moneyness does not track the '20-delta' the edge is described around. - SANDBOX METRICS ARE NOT TRUSTWORTHY AND MUST NOT BE READ AS EDGE. avg_trade_return_pct=44.2% is a nonsense magnitude for an options short-premium leg (premium notional is tiny relative to the underlying, so % of notional inflates wildly) and cannot be compared to the 0.10-0.15% fee floor. Sharpe 10.4 / profit_factor 3.85 / win_rate 0.95 are small-sample artifacts of 10 cycles with theta bleed-in and a single un-sampled tail (return_skew -2.24). None of these numbers survive the sharpe CI [-0.17, 86.7]. This is not the L17 code-defect signature (win_rate is 0.95 not 0.0, PF is 3.85 not 0.0), just statistically empty output -- which reinforces the critical measurability fail above.

Verification failed (Layer 4 — QA review): - SANDBOX OUTPUT CARRIES A CODE-DEFECT SIGNATURE -- the option-leg P&L accounting is not being booked correctly, so the metrics are not trustworthy. Results: win_rate=1.0, profit_factor=0.0, avg_loss=0.0, largest_loss=0.0, max_drawdown=0.0, sortino=0.0, Sharpe=42.7 (CI [34.2, 86.6]), across 24 legs (12 strangles). This is impossible for a real short strangle: over 12 weekly cycles BTC will breach a ~20-delta wing or move enough to produce at least one losing week and non-zero intra-week mark-to-market drawdown -- yet the run books 24 wins, ZERO losses, and ZERO drawdown. Per learning L17, |Sharpe|>5 AND profit_factor=0.0 are explicit code-defect signals (not edge and not a fee/analyst matter). The likely mechanism: only the premium-collected (winning) side of each leg is realized on close while the adverse leg's loss / the mark-to-market path is not marked -- consistent with benchmark_type='primary_leg_only' and benchmark_meaningful=false, i.e. the P&L engine is measuring the never-traded perp rather than the option structure. avg_trade_return_pct=87% is likewise meaningless (premium notional is a tiny fraction of the underlying), which the author acknowledges. No metric from this run -- return, Sharpe, win rate, drawdown -- can be trusted to reflect the strategy's real payoff. - UNMEASURABLE SAMPLE AT A HARD INFRASTRUCTURE CEILING -- conceded by the author. lookback_days=91 resolves ~13 weekly cycles / 26 legs, and the docstring/rationale state plainly that ~13-16 cycles is the ABSOLUTE maximum for any two-leg weekly options structure under the 300s Layer-3 cap (each catalog.bars() query costs ~8.9s of fsspec directory-walk regardless of payload), that '30+ cycles needs ~545s -> SIGKILLed', that reaching a measurable tail sample requires a BacktestRunner platform fix (cache/reuse the globbed file list), and that 'the 13-cycle metrics must not be read as edge'. A short-strangle's risk is dominated by the rare tail; 12-13 cycles cannot sample it, so even correctly-booked metrics would be statistically empty (per L26, options strategies implying < ~30 measurable cycles must be rejected at Layer 4). The author's own recommended verdict when the reviewer holds the ~30-cycle line is 'abandon-pending-that-platform-fix rather than another code iteration' -- which is the correct call here. - The VRP gate degrades OPEN when DVOL is missing (no_iv -> ungated fall-through) AND the ~20-delta band check also degrades OPEN when IV/spot/strike/tte are unavailable. Both are defensible individually as 'no edge substitution' policies, but stacked they mean that on any timestamp where DVOL has no sample the strategy writes the strangle with NEITHER the timing gate NOR the delta-band protection active -- i.e. it can sell a near-ATM strangle in exactly the data-gap conditions the checks were added to prevent. Given DVOL coverage starts 2021-03 and is hourly, verify how many of the ~13 entered cycles actually had a live DVOL sample vs fell through ungated; if a meaningful fraction are ungated, the 'IV>RV-gated, ~20-delta' characterization does not hold for the traded sample.

Verification failed (Layer 4 — QA review): - SAMPLE COLLAPSED TO 2 TRADES -- a REGRESSION from the prior iteration and now fully unmeasurable. This run produced total_trades=2, data_days=1, metrics_reliable=FALSE (sharpe_note: 'Unreliable: only 1 daily returns'), where the immediately-prior iteration of this same strategy produced 24 legs / 12 cycles. Only ONE strangle (2 legs) entered over the entire 91-day window. The iteration-3 entry tightening is the likely cause: _delta_in_band now BLOCKS (instead of degrading open) whenever neither DVOL IV nor trailing RV is measurable, and the stricter band + strike-parse path can reject far more cycles -- so a change intended to make the traded sample 'genuinely ~20-delta' instead starved the sample to near-zero. Whatever the exact cause, 2 trades / 1 data day cannot support ANY inference; this is below even the ~13-cycle ceiling the developer already conceded is unmeasurable for a tail-dominated short strangle (L26). This is strictly worse than the prior iteration, not an improvement. - THE L17 ALL-WINS / ZERO-DRAWDOWN METRIC SIGNATURE PERSISTS despite the iteration-3 booking fixes. Metrics: win_rate=1.0, profit_factor=0.0, avg_loss=0.0, largest_loss=0.0, max_drawdown=0.0, sortino=0.0, and benchmark_type still 'primary_leg_only' / benchmark_meaningful=false. The developer added an idempotent forced-close sweep, all-legs premium accrual, and an on_stop per-leg booking audit -- all reasonable STRATEGY-code changes -- but the aggregate P&L metrics the pipeline reports STILL show the same one-sided signature: the engine appears to be measuring the never-traded perp (primary_leg_only), not the option legs' realized P&L. At only 2 legs (1 winning strangle) this could be a genuine single win rather than unbooked losses, but that is exactly the problem: the booking-audit LOG that would disambiguate is not in the verification payload I can see, and the numeric metrics remain profit_factor 0.0 / max_drawdown 0.0 / avg_loss 0.0 -- indistinguishable from the loss-not-booked defect. The fix targeted the strategy, but the metric computation that produced the defect signature is engine-level and is unchanged here.