BtcDeribitMonthlyLongOptionTrendConvexityCheapIV

Deribit BTC Monthly Single-Leg Long-Option Trend Convexity (Cheap-IV Gated, Directional Both Ways)

Express a BTC trend view through a SINGLE long option leg instead of a perp, converting the trend-following payoff into a convex, defined-risk structure. When BTC is in a confirmed up-regime AND implied vol is cheap, buy one ~5% OTM monthly CALL on Deribit; when in a confirmed down-regime AND IV is cheap, buy one ~5% OTM monthly PUT. No hedging leg, no shorting margin — max loss is the premium paid. This is the deliberate inverse of the short-vol cash-secured-put writes and the non-directional long straddle already in the pipeline: here we are LONG vega + LONG direction, harvesting the fat right/left tail of BTC returns that perp trend-followers cannot capture because fee drag and stop whipsaws bleed them out. Single leg keeps it clear of the multi-leg options execution path that has never cleared verification (L2). Deribit BTC is the most liquid crypto-options market, has greeks/IV in the catalog, and single-leg Deribit BTC structures have already cleared Layer-3 sandbox (long straddle, CSP write both reached backtest_review), so data availability and execution are de-risked. Fills the two most under-represented buckets at once: Options venue (~5% vs 15% target) and long_short direction (15% vs target), with a mid-to-long horizon and only 4 parameters.

Iteration 3 fix for the Layer-3 wall-clock timeout (>300s). All signal logic already passed Layers 1 and 2, so the fix is scoped strictly to the per-bar cost the feedback named. Root cause: _realized_vol_cheap() computed its rolling standard deviation with a Python for-loop over the full close history (`for i in range(n): rolls[i] = rets[i:i+w].std()`) — O(n·w) per call, executed as the cheap-IV fallback on every bar where DVOL history is thin (i.e. the whole early/gappy portion of the backtest), which is exactly the 'rebuilding a list inside on_bar on every bar' pattern the diagnostic describes. Fix: (1) replace that loop with a fully vectorized cumulative-sum rolling std (population std, ddof=0 — identical to np.std default), so the fallback is O(n) with no Python loop; (2) memoize the cheap-IV verdict per bar timestamp (_iv_cheap_ts/_iv_cheap_val) so repeat calls within a bar's period/leg scan are O(1); the DVOL path was already O(log n) via np.searchsorted and is untouched. No imports, class structure, regime logic, roll logic, or entry/exit gating changed — so Layers 1 and 2 cannot regress. As belt-and-suspenders against leg-bar volume (the same failure mode that hit the rolling-options siblings), the config pins the perp primary AND the rolling_options leg `timeframe` to 1-DAY (the expander defaults legs to 1-HOUR, a 6-24x leg-bar blow-up) and caps lookback_days at 365 (~12 monthly periods).

BTC Deribit MONTHLY single-leg long-option trend-convexity strategy, cheap-IV gated, directional both ways. The primary BTC-PERPETUAL.DERIBIT (1-DAY) drives the roll clock and supplies the daily close series; the tradeable legs are the resolved monthly ~5% OTM call and put contracts. When BTC is in a confirmed up-regime (price above a rising 50-day SMA) AND implied vol is cheap (DVOL percentile <= 0.40, realized-vol percentile fallback), it buys one OTM monthly CALL; in a confirmed down-regime AND cheap IV it buys one OTM monthly PUT. At most one long leg per monthly expiry, rolled out 5 DTE before expiry, with early exit on a regime flip against the leg or a -70% premium catastrophe stop. Long vega + long direction, max loss = premium paid, no shorting/hedging leg.

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).

Analyst: confirm total_trades over the full window; a doubly-gated monthly long-option program may produce too few trades for a reliable verdict. Consider extending lookback_days beyond 365 to accumulate more expiries.

Low trade count / statistical power. Monthly tenor (dte 30) over a 365-day option-chain lookback (~12 expiries), further filtered by BOTH a confirmed-trend regime gate AND a cheap-IV gate, so it realistically opens well under 10 long legs over the window (sandbox produced 9 total). That is far below the ~100-trade threshold for cleanly separating edge from noise, and the wide Sharpe CI ([-13.1, 11.1], PSR 0.77) confirms the estimate is low-confidence. Inherent to a double-gated monthly options program, so this is a caveat for the analyst rather than a code defect, but no Sharpe/PF from this strategy should be trusted without a much longer window.

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

Sandbox reports total_commission=0.0001 (~zero) across 9 option trades. Deribit option fees (0.03% of underlying per contract, capped at 12.5% of premium) are material for LONG options that pay premium and pay fees on both open and close. A near-zero commission result suggests option fees may not be modeled on the injected leg instruments, which would overstate net return on a premium-paying long-option book. Backtest-engine/fee concern, not a strategy-code defect.

Consider defaulting to False (skip entry) when neither DVOL nor RV is measurable, so every entry genuinely satisfies the cheap-IV conjunct; or confirm via logs that no entries were taken under the permissive fallback.

The cheap-IV gate is PERMISSIVE when neither vol measure is available: if DVOL history is thin (< min_iv_samples) AND the realized-vol fallback is not computable, _iv_cheap returns True, so an entry can be taken WITHOUT a confirmed cheap-IV condition. The hypothesis makes cheap IV a required conjunct ('confirmed regime AND IV is cheap'). For BTC Deribit DVOL this window fills quickly so the impact is limited to the early/gappy portion of the backtest, but any trades taken in that region are regime-only, not regime-AND-cheap-IV as specified.

Analyst: verify the per-trade premium outlay as a fraction of equity is sane (defined-risk long options should risk a small % per trade); if 1 contract is too large relative to equity, switch to a premium-budget (risk_frac) sizing.

avg_position_pct=93.6% in the sandbox. Sizing is a fixed 1 contract per entry via the inherited _leg_size (contracts=1.0). For a long option the true risk is the premium paid (defined-risk, and the -70% stop bounds it further), so a high reported position_pct likely reflects the engine valuing option NOTIONAL (contracts x underlying) rather than premium at risk. Worth confirming the fixed 1-contract size does not over-concentrate the book at low equity or produce an implausibly large premium outlay relative to equity on the full backtest.

Mechanism is sound and clears verification: single long-option leg = defined-risk convex expression of a trend view, no multi-leg execution path.

Fills two under-represented buckets (options venue + long_short direction).

Where it does trade, per-trade convexity looks favorable (PF 1.86, positive skew 1.55, max_dd only 9.8%).

Only 9 trades over the entire available option history; engine flags metrics_reliable=false.

Entire net return is one outlier month (2026-02 +14.3%); other 8 months roughly wash.

sharpe_ci_low = -13.1 — Sharpe CI straddles 0; deflated_sharpe uncomputable. Metrics are statistically meaningless.

Monthly Deribit BTC option chain in the catalog spans only ~12 expiries (2025-07 onward); lookback_days=365 already covers it — no developer change can add monthly periods.

This is the second pass with the identical 9-trade outcome; iterating again on the same data wall is thrashing.

Do NOT optimize on 9 trades (engine flagged metrics_reliable=false, and the entire +100% return is a single Feb-2026 outlier). The root cause is data coverage, not logic: rolling_options.lookback_days is 365, so the monthly chain expansion only found ~12 periods (2025-07 onward). The promoted CSP sibling used lookback_days=1100 and got a 36-period chain back to 2023. FIX: raise rolling_options.lookback_days to ~1100 so the monthly Deribit BTC chain covers 2023-2026, yielding ~36 entry opportunities (~3x the trades) and a statistically testable sample that spans both the 2024 bull and the 2025-26 drawdown. Re-backtest and confirm the edge survives across ~30+ trades (positive expectancy NOT dependent on one month, win_rate and profit_factor stable) before spending optimization compute. Keep everything else unchanged.

BtcDeribitMonthlyLongOptionTrendConvexityCheapIV was the deliberate long-vega, long-direction inverse of the pipeline's short-vol and non-directional option books, buying a single OTM call or put to convert a BTC trend view into a defined-risk convex payoff, and it cleanly cleared the multi-leg execution and Layer-3 hurdles that had blocked siblings. But the backtest could only produce 9 trades because the catalog's monthly Deribit BTC chain spans just ~12 expiries from mid-2025, and the engine flagged the metrics as unreliable — a headline Sharpe of 3.43 sat atop a confidence interval running from -13 to +11, with the whole net return coming from one February 2026 month. The reviewer ruled revise_hypothesis, noting this was the second identical 9-trade pass and that no code change could add monthly periods to a shallow chain. The convexity thesis was never disproven; it simply could not be tested on the available option history, and the strategy was abandoned rather than iterated into the same wall a third time.

A mechanically sound, verification-cleared options strategy is still unvalidatable if the catalog holds only ~12 monthly expiries — 9 trades with a Sharpe CI from -13 to +11 and all return from one month cannot support optimization, so option-chain depth must be confirmed before repeatedly iterating.

The backtest reviewer returned 'revise_hypothesis' at the pre-optimization gate: the mechanism was sound and cleared verification, but the catalog's monthly Deribit BTC option chain spans only ~12 expiries (2025-07 onward), so lookback_days=365 already covers it and no developer change can add periods — and this was the second pass with the identical 9-trade outcome, making further iteration thrashing on a data wall. The final stage is abandoned.

A single-leg long-option strategy on Deribit BTC monthly expiries that expressed a directional trend view convexly: in a confirmed up-regime with cheap IV it bought a ~5% OTM call, in a confirmed down-regime with cheap IV a ~5% OTM put, holding at most one defined-risk leg (max loss = premium) and rolling monthly.

The backtest traded only 9 times over the available option history (6 calls, 3 puts, avg entry IV 0.323, net entry vega +751, ~24 DTE) with metrics_reliable=false: nominal Sharpe 3.43 and profit factor 1.86 with positive skew and a 9.8% max drawdown, but sharpe_ci_low of -13.1 (CI straddling zero) and the entire net return carried by a single outlier month (2026-02, +14.3%). No optimization stage ran.