DeribitBtcMonthlyCashSecuredPutWriteVrpDoubleGated

Deribit BTC MONTHLY Cash-Secured OTM Put-Write — Single-Leg VRP Harvest, IV>RV Gated, 50%-Profit Early Close (3-Parameter)

A SINGLE-LEG, fully cash-collateralized put-writing program on Deribit BTC MONTHLY options. It extends the only options family that has ever cleared Layer 3 and reached paper here (Deribit BTC WEEKLY cash-secured put-write, Sharpe 12.2) to the monthly tenor, which is a materially different risk profile: ~4x the holding period, far lower gamma near expiry, deeper OTM strike liquidity, and theta harvested over a full month instead of a week. Strictly ONE leg at a time — no spreads, no wings, no hedge (L2 compliant; the monthly bull-put CREDIT SPREAD that just died was multi-leg, this is not). It fills the largest actionable venue gap: options sit at 4.3% versus a 15% quota, and with Hyperliquid blocked by L11, COIN-M blocked by data-collection timeouts, funding signals blocked by L13, cross-sectional baskets by L12, and liquidation feeds by L3, single-leg Deribit options are the one under-filled bucket with a proven execution path and confirmed IV/greeks data. Only 3 tuned parameters (otm_pct, min_iv_rv_spread, iv_rank_floor).

Iteration 2 addresses the backtest-review verdict: negative expectancy driven entirely by an uncapped left tail (avg_loss ~6.2x avg_win), which the 3 economic parameters cannot fix. Per the analyst's instruction to add a defined-risk exit BEFORE any parameter sweep, I added a per-position tail cap to _manage_exits and left the passing signal/gate/scheduling logic untouched (so no earlier verification layer regresses). Two backstops: (1) a premium-multiple stop — using the existing _put_pnl_pct (short-put P&L as % of premium collected), close when pnl <= -stop_loss_premium_mult*100 (default 2.0 => put mark reached 3x entry, i.e. loss = 2x premium), directly bounding the worst single-trade loss to a small multiple of premium instead of near-full cash-secured loss; and (2) a spot-through-strike breach exit (close when spot <= strike*(1+strike_breach_buffer)) as an option-mark-independent safeguard for the crash scenario that generated the tail. Implementation was minimal and surgical: added three parameters in __init__, stored 'strike' in the per-period state at entry, threaded 'spot' into _manage_exits, and added the two elif branches after the existing take-profit check; exit accounting/logging already tallies arbitrary reasons so 'stop_loss'/'strike_breach' surface in the summary. Per the feedback I deliberately did NOT tighten iv_rank_floor / min_iv_rv_spread in this pass — those are to be revisited only after the tail-capped version is re-backtested and shows profit_factor > 1.1 with positive avg_trade_return_pct. Config keeps the proven 1-DAY perp primary and 1-DAY rolling leg timeframe (avoids the wall-clock blow-up) with a 365-day lookback for ~12 monthly expiries.

Structural data insufficiency, not a code defect. The tail-cap fix from iteration 1 worked (positive expectancy, DD 0.62%), but the monthly Deribit BTC option chain resolves only 12 expiries (2025-07 → 2026-06 — ~1yr of monthly option history), and the double vol gate cut that to 5 actual trades / 5 daily returns (report: metrics_reliable=false, 'Unreliable: only 5 daily returns'). No developer change can create more historical monthly expiries, and loosening the gates only reaches ~12 trades — still far too few for the 3-phase pipeline (walk-forward windows hold 1-2 trades; the 15-day holdout holds ~0 monthly trades), so optimization would fit noise. The VRP put-write mechanism is sound and ALREADY validated in paper on the WEEKLY tenor (Sharpe 12.2), which extracts ~4x the samples from the same option-data window; the monthly analog is simply not validatable with available data. Recommend the Research Lead not re-propose monthly-tenor single-name Deribit option programs until >2yr of monthly option history is collected — the weekly tenor is the viable expression of this edge.

Single-leg, fully cash-secured monthly OTM put-write on Deribit BTC harvesting the volatility risk premium. Each monthly expiry cycle, IF both vol gates clear (DVOL iv_rank >= iv_rank_floor AND IV/RV >= 1 + min_iv_rv_spread), SELL one ~10%-OTM BTC monthly put sized so strike*contracts is ~20% of equity (hard-capped 25%). The position is closed on the FIRST of: 50%-of-premium profit capture, a defined-risk stop (unrealized loss >= stop_loss_premium_mult x premium collected, default 2x), a spot-through-strike breach (put ~ITM), or the pre-expiry roll buffer. One put open at a time, leverage 1.0, no spreads/wings/hedge. Rolling put legs are resolved from the real historical Deribit BTC monthly chain; if the chain is unavailable the strategy trades nothing (no underlying fallback).

Analyst: confirm total_trades over the full window; consider extending the 365-day lookback to accumulate more expiries.

Very low trade count / statistical power. Monthly tenor (dte 30) over a 365-day chain lookback (~12 expiries), further filtered by the double vol gate, so likely <10 puts over the window — far below the ~100-trade threshold. Inherent to a monthly cash-secured program (lowest-frequency member of the family); a caveat for the analyst, not a code defect.

Note the tail is daily-bar-bounded; optionally finer leg resolution or an intraday stop. Not required for viability given cash-secured sizing.

Daily-bar gap risk. Both tail exits (2x-premium stop, spot-through-strike breach) are evaluated only on the daily bar close. In a monthly crash that gaps through the 10%-OTM strike within a day, realized loss on close can exceed the intended ~2x-premium cap before the exit fires. Much better than iteration 1 (avg_loss ~6.2x avg_win -> ~2.3x with the cap) but not a hard intraday stop; the 62% sandbox max_dd reflects a single large loss still being possible. Acceptable given cash-secured sizing (25% cap, no leverage).

Verify BacktestRunner._apply_fees covers DERIBIT option leg instruments; confirm non-zero commissions on the full backtest.

Sandbox total_commission=0.0 across 5 option trades. Deribit option fees may not be modeled on the injected legs, overstating net premium capture. Engine/fee concern, not a strategy-code defect.

Iteration-1 feedback addressed: defined-risk tail cap (stop_loss_premium_mult + strike-breach backstop) works — max_drawdown 0.62%, avg_loss now $630 vs avg_win $273, expectancy positive (+$92/trade), win rate 80%

avg_trade_return_pct 7.6% and profit_factor 1.73 are above fee floors — the per-trade edge is real where it trades

Code is clean, single-leg L2-compliant, O(log n) per bar

Only 5 trades / 5 daily returns — report self-flags metrics_reliable:false, sharpe unreliable, sharpe_ratio 0.0

Structural data limit: the resolved monthly option chain contains only 12 expiries (JUL-2025→JUN-2026); Deribit monthly historical option data spans ~1yr, so at most ~12 writable puts exist regardless of gate settings

3-phase optimization is infeasible: walk-forward windows would hold 1-2 trades each and the 15-day holdout would contain ~0 monthly trades — parameters would fit noise

Do NOT send to optimization yet — the strategy has negative expectancy driven entirely by an uncapped left tail (avg_loss $1678 vs avg_win $270, ~6.2x), and the 3 tunable params cannot fix tail risk. Add a defined-risk exit BEFORE any parameter sweep: (1) a per-position stop that closes the short put when its price rises to a multiple of premium collected (e.g. loss = 2x-2.5x premium) or when the loss exceeds a fixed % of the collateral budget, so a single monthly crash can no longer run to near-full loss; consider (2) rolling the strike down / closing on a spot-through-strike breach rather than holding into expiry. Also reconsider whether the double gate is actually selecting rich-enough IV at the monthly tenor — with 84% wins still netting a loss, the harvested premium wasn't compensating for realized tail variance, so tighten iv_rank_floor / min_iv_rv_spread only AFTER the stop is in. Re-backtest; only proceed to optimization if the tail-capped version shows profit_factor > 1.1 and positive avg_trade_return_pct on a similar or larger trade count.

DeribitBtcMonthlyCashSecuredPutWriteVrpDoubleGated took the factory's one paper-validated options family — the weekly Deribit BTC cash-secured put-write — and extended it to the monthly tenor for a materially different, lower-gamma risk profile, kept strictly single-leg to respect the zero-clear-rate on multi-leg structures. The iteration-1 feedback was genuinely addressed: a defined-risk tail cap turned the uncapped left tail into a 0.62% max drawdown with positive expectancy, an 80% win rate and a 7.6% per-trade return. But the mechanism could not be tested: the monthly chain resolves only 12 expiries over ~1 year, and the double vol gate reduced that to 5 trades with metrics flagged unreliable, making 3-phase optimization infeasible. The reviewer abandoned it as a structural data limit rather than a code defect, explicitly recommending the weekly tenor as the viable expression of the edge until more than two years of monthly option history exists.

The monthly tenor is not validatable on ~1 year of Deribit monthly option history, whereas the same VRP put-write edge already reached paper on the weekly tenor because weeklies extract ~4x the samples from the same data window — tenor choice should follow available sample depth, not just risk-profile preference.

The backtest reviewer returned 'abandon' at the pre-optimization gate on grounds of structural data insufficiency: the resolved monthly Deribit BTC chain holds only 12 expiries (Jul-2025 to Jun-2026, ~1 year of history), which the double vol gate cut to 5 actual trades — far too few for the 3-phase pipeline, where walk-forward windows would hold 1-2 trades and the 15-day holdout ~0.

A single-leg, fully cash-secured OTM put-write on Deribit BTC monthly options that harvested the volatility risk premium — selling a ~10% OTM monthly put only when a double vol gate qualified (IV rank elevated AND implied vol exceeding realized), closing early at 50% of premium and capping the tail with a defined-risk stop — extending the promoted weekly put-write mechanism to the monthly tenor.

The backtest produced only 5 trades (5 daily return points), so metrics_reliable=false and Sharpe read 0.0: where it did trade the per-trade edge was real (80% win rate, avg_trade_return_pct 7.6%, profit factor 1.73, positive expectancy +$92/trade) and the iteration-1 tail-cap fix worked (max drawdown 0.62%, avg_loss $630 vs avg_win $273, net entry vega -61, theta +69, ~23 DTE). No optimization stage ran.