Strategia Deribit BTC di vendita settimanale di put OTM garantite da liquidità — raccolta del premio per il rischio di volatilità, con soglia IV>RV e filtro di trend

Una strategia sistematica PUT-WRITING a gamba singola e interamente garantita (con copertura in contanti), basata sulle opzioni settimanali BTC di Deribit, che raccoglie il premio per il rischio di volatilità delle criptovalute (VRP): la volatilità implicita delle opzioni BTC supera strutturalmente quella realizzata in seguito, perciò chi vende protezione incassa un vantaggio nel tempo. Questa è la strategia in opzioni FIRST della piattaforma e colma il maggiore deficit di quota (opzioni 0.1% rispetto all'obiettivo di >=15%), riducendo al contempo la sovrarappresentazione di 80% BINANCE. A ogni ciclo la strategia seleziona la scadenza settimanale Deribit BTC più vicina (5-9 giorni) e vende ONE put OTM con delta ~20, garantite FULLY in contanti (nessuna leva, nessun rischio di richiesta di margine: la perdita massima è limitata dal prezzo di esercizio, ossia equivale ad accettare di acquistare BTC a sconto). La posizione è subordinata a due filtri strutturali: (1) una soglia VRP: vendere solo quando la volatilità implicita ATM a 7 giorni (dal feed greche/IV di Deribit) supera di un margine la volatilità realizzata mobile a 10 giorni (IV/RV > ~1.15), così da vendere protezione solo quando è valutata generosamente; (2) una soglia di regime/trend: vendere solo quando il prezzo spot di BTC è sopra la sua SMA a 50 giorni, per evitare di vendere put durante una tendenza ribassista confermata o in una caduta libera (il principale rischio di coda della vendita di put). L'uso di un solo strumento per ciclo mantiene il backtest sul percorso pulito del motore ed evita l'artefatto di ottimizzazione multi-gamba/feed aggiuntivo. Lo sviluppatore rinnova le posizioni ogni settimana scegliendo tra gli strumenti put BTC quotati su Deribit (a ogni ciclo la strategia seleziona dal catalogo il prezzo di esercizio e la scadenza appropriati).

L’iterazione 3 modifica il valore di configurazione ONE; la logica della strategia è identica byte per byte a quella dell’iterazione 2 (viene aggiornata solo la docstring PERF per registrare la diagnosi). Ho profilato il timeout effettivo invece di fare un’altra supposizione: il sottoprocesso sandbox avviato 22:05:22 è stato terminato a 22:10:24 (302s) e il costo è il lavoro per barra NOT — tutto lo stato per barra era già O(1) dopo l’iterazione 2. Dipende dal numero di QUERIES nel catalogo. BacktestRunner chiama catalog.bars() una volta per tipo di barra e, con 35,765 directory di barre in data/catalog, ogni chiamata costa circa FIXED ~8.4s indipendentemente dal contenuto (misurato su questa macchina: BTC-PERPETUAL 1-DAY, 365 barre -> 8.31s; BTC-10APR26-63000-P, 19 barre -> 8.27s; BTC-17APR26-68000-P, 24 barre -> 8.77s). La catena settimanale di 365 giorni si espande in 52 leg (confermato nel log di esecuzione: 'Deribit chain discovered contracts=52'), quindi il solo caricamento dei dati costava 53 * 8.4s ~= 445s: ecco perché il passaggio dell’iterazione 2 da 1-HOUR a 1-DAY (24x barre in meno) non ha cambiato nulla. Correzione: lookback_days 365 -> 150, ottenendo circa 21 leg settimanali; il caricamento richiede quindi ~22 * 8.4s ~= 185s e l’intera esecuzione circa ~230s, con un buon margine rispetto al limite di 300s. Prima dell’invio ho anche eseguito a secco il gate composto FULL su dati reali nell’intervallo ridotto (seguendo la lezione sui gate composti): negli ultimi 150 giorni il gate VRP è aperto per 97/150 giorni, il gate di trend per 70/150, BOTH per 51 giorni distribuiti su 11 delle 23 settimane di calendario; la catena scriverà quindi circa 8-11 put, superando agevolmente il requisito di >=1 trade del Layer-3. Per recuperare una parte del campione perso con la catena più breve, ho ampliato entry_window_hours da 96 a 120 (sempre entro la finestra entry..expiry-24h della base), così una settimana in cui i gate si aprono a ciclo iniziato viene comunque inclusa. Da segnalare all’analista: il backtest effettivo ora copre circa 5 mesi / circa 10 trade invece di un anno — il campione è ridotto, ma il limite sandbox lo impone, dato il costo di circa 8.4s per leg delle query al catalogo; il calcolo è documentato nella docstring (il limite è ~30 query), quindi la finestra potrà essere ampliata di nuovo se il costo delle query al catalogo verrà corretto a monte.

Verifica non riuscita (Layer 4 — revisione QA) [class=not_measurable]: - [edge_concern] Le metriche impeccabili della sandbox (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) sono un BENIGN-WINDOW ARTIFACT: l’intero rischio della vendita di put garantite in contanti è la coda dei crolli e in questo intervallo di circa 5 mesi non se ne è verificato nessuno, quindi tutte le put hanno guadagnato. Qualsiasi vendita di put sembra priva di rischio finché non arriva un drawdown. avg_trade_return_pct 91.4% è relativo al premio (non al nozionale dello strike, né confrontabile con le soglie minime di spot/futures) e total_commission 0.0 su 16 operazioni con opzioni Deribit fa pensare che le commissioni sulle opzioni non siano applicate: entrambe le cose rendono ancora più lusinghiero un risultato non informativo. - Non misurabile con la configurazione attuale. rolling_options.lookback_days è fissato a 150 (la correzione dello sviluppatore per il timeout delle query al catalogo di circa 8.4s per leg), limitando la chain negoziabile a circa 5 mesi e producendo solo 16 vendite settimanali. Il limite è incorporato nella configurazione, quindi anche il backtest completo è limitato nello stesso modo (circa 16 trade, meno della soglia minima di 30 opzioni, L26). 16 vendite senza eventi di coda non possono valutare una vendita di put VRP, il cui vantaggio/rischio è definito dai drawdown durante i crolli: l’intervallo deve coprire anni per includere eventi reali di coda sinistra. Esistono i dati DVOL + della chain Deribit; l’ostacolo è il costo a monte delle query al catalogo per leg. Sospendere finché il costo non sarà corretto, così una chain pluriennale (>=2yr, ~50-100 vendite soggette ai gate durante diversi drawdown) rientrerà nel budget; non basta allungare lookback_days (il timeout si ripresenterebbe). - total_commission 0.0 su 16 operazioni con opzioni Deribit — Deribit applica commissioni sulle opzioni (minimo 0.03% del sottostante o 12.5% del premio, più il regolamento). Se il motore non applica le commissioni sulle opzioni, il PnL derivante dalla vendita del premio è sovrastimato. È un dubbio sull’applicazione delle commissioni del motore, da sottoporre all’analista o al backtest engineer, non un difetto del codice della strategia.

Verifica non riuscita (Layer 4 — revisione QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — cadenza di scadenza delle opzioni x filtri). La sandbox ha prodotto 12 trade su data_days=12, con la classica firma degenere non misurabile: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (un valore per trade impossibile per una vendita di put garantite in contanti — il calcolo del nozionale/rendimento delle opzioni non è affidabile). Non sono segnali di performance reali. Secondo L26 (intervallo/scadenza x superamento dei gate): lookback_days è stato ridotto da 365 a 150 per rientrare nel limite di 300s; il gate composto VRP+trend si apre solo in circa 11 delle 23 settimane -> circa 8-11 put. Circa 10 trade sono ben al di sotto della soglia di circa 30 trade e non permettono di distinguere un vantaggio VRP dal rumore. - INFRASTRUCTURE HARD-CAP rende il campione non misurabile con la parametrizzazione ANY. Come indicato nella docstring dello sviluppatore, ogni query catalog.bars() costa circa 8.4s fissi e l’esecuzione è limitata a circa 30 query (~250s) per il timeout di 300s; il backtest copre quindi AT MOST ~30 leg settimanali (~7 mesi) -> circa 15 trade dopo i filtri. lookback_days=150 era necessario per rispettare il timeout. Nessuna regolazione delle soglie supera il limite di circa 30 leg per le query al catalogo. - PUT-WRITE TAIL-RISK MASKING. Un campione di circa 10 trade win_rate 1.0 è l’esito MOST fuorviante per una put short: significa che nell’intervallo non c’è stata alcuna settimana di crollo, proprio quando una put garantita in contanti realizza la sua forte perdita di coda sinistra. Il risultato lusinghiero della sandbox (tutte operazioni vincenti, drawdown zero, Sharpe 31) riflette il decadimento theta nelle settimane tranquille e nasconde l’unico rischio che conta. - Il codice è CORRECT e implementa fedelmente l’ipotesi: direzione vendita put (P -> SELL), dimensionamento garantito in contanti e limitato dallo strike, gate VRP (atm_iv >= rv*vrp_ratio), gate di trend (spot > SMA), ricerca causale di DVOL (searchsorted right-1, senza look-ahead), leg chiusi 24h prima del regolamento europeo, fallback documentato senza gate quando manca IV (nessuna sostituzione silenziosa del vantaggio). Il controllo di correttezza delle opzioni (#12) è superato. Segnalato affinché lo sviluppatore non insegua un bug di codice inesistente.