Adriano Dal Pastro
8c3868cb31
Angolo term-structure DVOL / calendar-vol. Scan di fattibilita' PRIMA del backtest:
la storia per-scadenza NON e' pubblica su Deribit (DVOL solo 30g; trade-history IV
solo per strumenti vivi; il front rotola/espira -> serie continua front-vs-back
irricostruibile). Per la metodologia (niente edge senza OOS su dati certi) -> STOP,
niente backtest su uno snapshot.
Unica via legittima: costruire il dato IN AVANTI. Aggiunto logger forward idempotente
che interpola l'ATM IV a tenor fissi {7,30,60,90,180}g e accumula data/raw/vol_term_*.
Seminati i primi snapshot (oggi: contango lieve su BTC/ETH). Non auto-cablato in cron.
- scripts/research/probe_vol_termstructure.py (scan fattibilita')
- scripts/research/log_vol_termstructure.py (forward dataset builder)
- tests/test_vol_termstructure.py (interpolazione offline)
- docs/diary/2026-06-26-vol-termstructure-feasibility.md
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.7 KiB
2026-06-26 — Calendar-vol / term-structure DVOL: il DATO STORICO NON ESISTE (data-first gate)
Goal utente: "continua" — angolo scelto: scaricare e certificare la term-structure DVOL per
testare un calendar-vol (front IV vs back IV). Esito: bloccato a monte dal gate "il dato prima
della strategia" (lezione v2.0.0). Branch research/gamma-scalp-options.
Script: scripts/research/probe_vol_termstructure.py (scan) + log_vol_termstructure.py (forward).
Scan di fattibilità (prima di costruire qualunque backtest)
Cosa l'API pubblica Deribit espone davvero per la vol per-scadenza:
| dato | disponibile? |
|---|---|
| Snapshot CORRENTE della term-structure ATM (mark_iv per scadenza) | SÌ (book_summary_by_currency, tokenless) |
| DVOL storico | solo 30g fisso — nessun indice 7g/60g/90g pubblico |
| Trade-history IV per strumento | solo per strumenti VIVI (gli scaduti spariscono) |
| Serie storica continua front-vs-back IV | NO — il front-month rotola/espira → irricostruibile |
Snapshot oggi (2026-06-26), per riferimento:
- BTC spot $59.9k: 7g 45.6% · 30g 43.2% · 60g 42.7% · 90g 42.9% · 180g 44.5% — contango lieve.
- ETH spot $1.58k: 7g 57.6% · 30g 56.4% · 90g 57.5% · 180g 59.2% — contango (+1.6pp slope).
- (I valori sono interpolati a tenor fissi: il front a 1-giorno grezzo, 38%/54%, è rumore escluso.)
Verdetto
Un calendar-vol NON è backtestabile ora su dati certificati. La storia per-scadenza non è pubblica su Deribit (la nostra fonte di verità), e — coerentemente con la metodologia — nessun edge va creduto senza backtest OOS su dati certificati. Costruire un calendar-vol su uno snapshot singolo o su una storia ricostruita-a-pezzi sarebbe esattamente il tipo di scorciatoia che ha prodotto la libreria fasulla v2.0.0. Quindi: stop, niente backtest.
L'unica via legittima: costruire il dato in avanti
scripts/research/log_vol_termstructure.py — logger forward idempotente: ogni run prende lo snapshot
ATM, lo interpola ai tenor fissi {7,30,60,90,180}g e appende una riga/asset a
data/raw/vol_term_<asset>.parquet. Seminate le prime righe BTC/ETH oggi. Test offline
tests/test_vol_termstructure.py (interpolazione pura).
Non auto-cablato in cron (è ricerca forward, e non tocco il cron live senza ok). Per accumulare: aggiungere una riga giornaliera al crontab. Dopo ~6-12 mesi → certificare (monotonia, spike, cross-venue) e SOLO ALLORA testare front-vs-back. Prima, nulla.
Lezione
Il data-first gate ha funzionato: ha fermato un backtest su un dato che non esiste, invece di produrre un numero non falsificabile. La term-structure è in contango oggi (regime calmo) — osservazione da forward-monitor, non un edge. Nessun impatto sul book live (branch separato).