BtcDeribitFrontWeekIvInversionAtmCallCalendar

BTC Deribit ATM Call CALENDAR Spread on Front-Week IV Term-Structure INVERSION — Defined-Risk Long-Vega / Long-Theta Harvest of Panic-Priced Front-End Vol (sell the 3-8 DTE ATM call, buy the SAME strike 21-38 DTE ATM call, exit when the inversion resolves; 3-parameter)

A DEFINED-RISK, two-leg OPTIONS TERM-STRUCTURE strategy on Deribit BTC options — a mechanism this factory has never run (every prior Deribit hypothesis traded the vol LEVEL or direction: naked/hedged short straddle-strangle, cash-secured put write, debit vertical, directional long-premium roll; none traded the SHAPE of the curve). Crypto short-dated IV is event-driven and spikes far more violently at the front than at the 1-month point: a liquidation cascade, ETF headline or macro print can take 7-day ATM IV 10-25 vol points above 30-day ATM IV within hours, inverting the term structure. That inversion is mechanically transient — the event resolves and front vol is crushed, or it does not happen and the front simply decays; the 30-day point barely moves either way. The trade: SELL the expensive front-week ATM call, BUY the SAME-STRIKE ~1-month ATM call — a long calendar, a NET DEBIT structure whose maximum loss is bounded by the debit. That bounded-loss property is the direct answer to how this factory's short-vol attempts died: the ETH delta-hedged strangle ran -139.8% / 196% drawdown because realized gamma ran ~2.1x the vol sold, and the BTC delta-hedged short straddle showed no edge once the perp hedge was paid for. A calendar keeps the short front gamma COVERED at the identical strike, needs NO perp delta hedge (ATM calendar is ~0.03-0.08 net delta at inception), and cannot lose more than what was paid. Signal needs no greeks feed: ATM IV per expiry is recovered model-free from the ATM call mark via C_atm ≈ 0.3989·S·σ·√T, inverted from the option's own bar close and the BTCUSDT.BINANCE reference price.

Iteration 2 — two targeted changes, mechanism untouched (the trade records already showed 36 legs = 18 same-strike short-front/long-back calendars entering on genuine inversion, so signal, sizing, greeks caps and roll logic are left byte-for-byte as they were). (1) TEST WINDOW: rolling_options.lookback_days 540 -> 1650, so the calendar expansion covers mid-2022 onward and the strategy finally sees the FTX-aftermath, 2023 and 2024 front-vol panics the hypothesis is about, instead of one 519-day regime with 18 events and a holdout that could not physically reach the 10-trade floor. timeframe (1-DAY), roll (weekly) and the 7/28 DTE legs are unchanged as instructed; per-bar cost is O(1) and independent of the window, so the only extra wall-clock is one-off chain discovery/leg collection (~236 weekly opens x 2 legs). If that ever binds, the fix is a wider roll cadence, not less history. (2) DEEPER INVERSIONS OVER SHALLOW ONES: entry_slope default 0.02 -> 0.03 and its clamp/_param_bounds floor 0.01 -> 0.02 (ceiling 0.08 -> 0.09). This is the opposite of loosening — it raises the bar so that neither the default nor any optimizer trial can select the shallow, fee-negative calendars flagged in review: realistic Deribit cost is ~$110-130 per round trip (0.0003 BTC/contract/leg, capped at 12.5% of premium) against ~$490 average gross, so a marginal +$154-gross calendar is a loser in reality even though the engine books it at ~$0 commission. Entries observed at 0.108-0.332 slope are far above the new floor, and 4.5x more history more than offsets the higher threshold on sample size. No other parameter, gate or code path changed; Layers 1-3 all passed on this structure and nothing they exercise was touched.

Defined-risk ATM CALL CALENDAR on Deribit BTC traded off the IV TERM-STRUCTURE SHAPE. Every daily bar the strategy inverts each leg's own option candle premium (coin premium converted to USD against the Deribit BTC perp close) to Black-Scholes implied vol and computes slope = IV(front ~7 DTE ATM call) - IV(back ~28 DTE ATM call) in vol points. When the front week is bid above the month (slope >= entry_slope, i.e. the curve is INVERTED by an event, cascade or headline) it SELLS the front-week ATM call and BUYS the SAME-STRIKE ~1-month ATM call in equal contracts — a net-debit long calendar whose maximum loss is the debit paid, with the short front gamma fully covered at the identical strike and ~0.03-0.08 net delta (measured with Black-Scholes and capped, so no perp hedge is needed). It unwinds when the inversion resolves (slope <= exit_slope) or at a forced roll 24h before the front expiry, so front gamma/pin risk is never carried into settlement. Legs are REAL Deribit contracts resolved per weekly open by the rolling_options 'calendar' expander over a 1650-day window (mid-2022 -> now, covering the 2022 aftermath, 2023, the 2024 ETF/unwind episodes and 2025-26); the BTC-PERPETUAL primary supplies spot and the roll clock only and is never traded. Sizing is capital-relative: contracts = equity * risk_frac / net debit per contract, capped by gross notional, floored at the 0.1-contract Deribit lot.

Submit the long back-month leg FIRST and confirm it was accepted before submitting the short front leg, or have _enter_calendar check order/position state on the next bar and immediately flatten any orphan leg. At minimum, only set self._active when both submissions returned orders.

Leg atomicity is not verified. _enter_calendar checks only that each contract object is loaded (_contract_ready), then fires two independent market orders and unconditionally sets self._active = cyc. _submit_entry_instrument can silently drop an order (_in_warmup, _no_entries_before_ns freeze, _market_ready False, or an entry already in flight). In backtest _market_ready always returns True so both legs went through (43 long + 43 short in the sandbox, balanced), but in paper/live (_live_mode True) the back-month BUY is the leg most likely to be dropped because the longer-dated contract's tick feed is thinner — leaving a NAKED SHORT front-week ATM call while the strategy believes it holds a defined-risk calendar. That directly breaks the hypothesis's central risk claim (max loss = debit paid).

Gate _active on an actual position appearing for both leg instrument_ids (checked on the following bar via cache.positions_open), and fall back to _candidate if neither leg filled.

Phantom-active state: if both submissions are dropped (same paths as above), self._active is still set and self._candidate cleared, so the cycle is blocked from re-entry until close_ns and the strategy sits idle for up to 6 days with no position. _exit_calendar will then also clear _active with nothing to close, so the condition is invisible in logs beyond the OPEN/CLOSE pair.

Keep the cycle in a 'closing' state and re-issue _submit_exit_position on each subsequent bar until cache.positions_open() is empty for both legs; only then clear _active.

Exit is single-shot and unverified. _exit_calendar submits exits for whatever positions are open, then unconditionally sets self._active = None and advances the cursor. If an exit order is rejected or only one leg closes, the residual position is never retried on a later bar and will drift to the contract's last bar (the short front call would then sit past expiry with no settlement path in this engine, since Deribit options are modelled as linear-USD CurrencyPair and are not auto-exercised). The sandbox shows no residual (end_unrealized_pct null, 43/43 balanced), so this is latent rather than observed.

Drop roll_buffer_hours from _param_bounds (keep it a fixed 24.0 hygiene constant) so the optimized space matches the pre-registered 3 tunables.

The hypothesis pre-registers a 3-parameter strategy (entry_slope, exit_slope, risk_frac) and the docstring repeats that, but parameters['_param_bounds'] declares FOUR searchable ranges — it also exposes roll_buffer_hours [24.0, 72.0]. The optimizer will therefore search a 4-dimensional space, widening the overfit surface beyond what was pre-registered, and roll_buffer_hours materially changes the holding horizon (exit 1 vs 3 bars before front expiry) rather than being pure hygiene.

Pass risk_free_rate=0.0 explicitly to implied_volatility and black_scholes_delta for both legs (crypto options are quoted off the forward, and a zero rate makes the two tenors directly comparable), or invert both legs against the Deribit forward.

IV inversion and delta both use the helper's default risk_free_rate = 0.05, applied to legs with different tenors (7d vs 28d). Because the discounting bias scales with T, it does not cancel in the front-minus-back slope: at r=5% the back leg's implied vol is biased slightly more than the front's, adding a small (order 0.1-0.3 vol point at these tenors) positive tilt to the measured inversion. Immaterial against a 3-vol-point threshold, but it is a systematic, one-signed offset in the decision variable.

Fee realism, not code: the engine's DERIBIT config charges 0.03% of the traded PRICE, and Deribit option bars here are COIN premium (~0.02-0.03 BTC), so the sandbox booked $0.005 total commission on 172 fills — effectively zero. Real Deribit options fees are 0.0003 BTC PER CONTRACT per leg (capped at 12.5% of premium; the cap does not bind on a ~1.1-contract ATM calendar), i.e. ~$18-30 per leg and ~$80-130 per calendar round trip (4 legs). The sandbox's 43 calendars earned $147 net each ($73.4 x 2 legs) under a near-zero fee model, so a realistic cost deck removes roughly half to nearly all of the gross: PF would fall from 1.134 toward ~1.00-1.05 and the +6.3% total return toward ~+1.5-3%. The developer already responded to this in iteration 2 by raising entry_slope (default 0.02 -> 0.03, floor 0.01 -> 0.02), which is the right direction, but the headline backtest metrics on this venue will still overstate net edge and should be re-deflated by ~0.12% of underlying notional per calendar before any promotion decision. Secondary: sample size. The sandbox resolved 43 calendars in 888 days (~0.048/day); at that rate the 1650-day window yields roughly 80-90 calendars and a last-20% holdout of ~16 — above the 10-trade holdout floor and the ~30-trade options floor, but thin for a 3-parameter optimization, so treat walk-forward Sharpe with wide error bars. Also note the reported long/short split (long leg win rate 0.163, short leg 0.837) is the expected signature of a debit calendar booked as two independent positions, NOT a polarity bug, and avg_trade_return_pct (+11.33%) is sign-consistent with total_return (+6.32%) and reconciles exactly ($73.4 x 86 = $6,315 on $100k) — no accounting defect.

Mechanism verified against the hypothesis on the actual trade records, not assumed: every one of the 43 cycles is SELL ~7DTE ATM call + BUY the SAME-STRIKE ~28DTE call, equal quantity, net debit, avg moneyness 0.997, avg DTE at entry 15.3 (7/28 blend). Direction, strike-matching and 1:1 sizing all implement the stated defined-risk calendar. No underlying leg was ever traded.

Per-CALENDAR economics are far better than the reported leg-level profit_factor of 1.134 suggests. Grouping the 86 legs into their 43 calendars: gross PF 3.09, 29/43 winners, +$6,315 total. The 1.134 is the arithmetic signature of booking a debit spread as two independent positions (QA already identified this as expected, not a polarity bug) and should not be read as a promotion-stage PF.

QA's fee concern is real but NOT fatal, which is the key finding. Reconstructing the true Deribit deck on each fill (0.0003 BTC/contract/leg, capped at 12.5% of premium, spot backed out from strike/moneyness) gives $3,450 of commission — vs the $0.005 the engine actually booked. Net of that realistic deck the strategy still makes +$2,865 with calendar-level PF 1.71 and 27/43 winners. QA projected PF collapsing to ~1.00-1.05; measured on the trade file it lands at 1.71.

Risk profile is what a defined-risk calendar should look like: max drawdown 5.17%, recovery factor 1.22, Sharpe 1.74 with bootstrap CI low 0.69 (> 0), no liquidation, 20% exposure. Max loss per cycle is the debit and sizing is capital-relative (risk_frac 0.02), so the 65.9% avg_position_pct is underlying notional, not capital at risk.

Sample is adequate for the gate arithmetic: 940 days (> the 24-month daily-bar span floor), 86 trades (> the 30-trade daily floor), and a last-20% holdout of ~188 days / ~17 legs (> the 10-trade holdout floor). A novel mechanism family for this factory — no prior failure pattern covers BTC term-structure calendars.

THE OPTIMIZER'S OBJECTIVE IS FEE-BLIND. The engine charged $0.005 of commission on 172 fills because the DERIBIT config applies a percentage to a COIN-denominated premium; the true cost is ~$80 per calendar, i.e. ~55% of gross PnL. Walk-forward maximizes Sharpe computed on that near-zero-cost series, so the search is structurally biased toward shallower entry_slope and MORE cycles — exactly the wrong direction. Treat any optimizer move that lowers entry_slope or raises trade count as a red flag, not an improvement.

Absolute return is thin: +6.32% over 2.4 years (CAGR 2.55%) before the real fee deck, roughly 1.2%/yr after it. Even scaling risk_frac to its 0.05 clamp puts this around 3%/yr.

Concentration: the top 5 of 43 calendars supply 55% of gross PnL. 2022 is negative gross (-$232) and net (-$1,134); only 2023 and 2024 carry the result.

Bid-ask is not modeled at all — four option legs fill at bar close with zero slippage. Average premium traded per calendar is $6,728 against $147 of gross edge, so the result is spread-fragile: charging 1% of premium per side per leg flips the net from +$2,865 to -$2,921. This is a sensitivity, not a measurement, but it bounds how much of the edge can survive execution.

The requested window was not delivered. rolling_options.lookback_days is 1650 but the run covers 2022-02-09 to 2024-09-05 (940 days, ~57%), and the last ~2 years are simply absent. This is not a data wall: BTC-PERPETUAL.DERIBIT 1-DAY bars in the catalog run to 2026-09, and the 2025/2026 option legs the schedule names (e.g. BTC-24JAN25-94000-C, BTC-13FEB26-68000-C) have parquet files on disk yet never appear in data_spans. Symptom reported; the mechanism is engine-side and I have not verified it, so I am not asserting a cause. Consequence: the 2025-2026 vol regime is untested and the effective sample is 43 events, not the ~90 the lookback implies.

Keep the mechanism — the trades implement the hypothesis correctly and the risk profile is what a defined-risk calendar should look like. The defect is the test window: raise rolling_options.lookback_days from 540 to ~1500-1800 so the expansion covers mid-2022 onward (weekly BTC call day-bars for 2021-2024 are already in the catalog), keep timeframe/roll/DTE legs unchanged, report calendars resolved per year and wall-clock, widen the roll cadence rather than shortening history if runtime binds, and do not lower entry_slope to manufacture trades. Also favour deeper inversions over frequent shallow ones: real Deribit fees are ~$110-130 per calendar round trip against ~$490 average gross. Full notes in workspace/discussions/9baab48f-ee42-454a-91ec-0acaeea751cb/iteration_1_feedback.md