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>
48 lines
2.7 KiB
Markdown
48 lines
2.7 KiB
Markdown
# 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).
|