Deribit BTC MONTHLY vendita di put OTM garantita da liquidità — raccolta VRP a gamba singola, filtro IV>RV, chiusura anticipata con presa di profitto 50% (3 parametri)

Un programma di vendita di put SINGLE-LEG, interamente garantito da liquidità, sulle opzioni BTC MONTHLY di Deribit. Estende alla scadenza mensile l'unica famiglia di opzioni che abbia mai superato il Layer 3 e raggiunto il paper trading qui (vendita di put BTC WEEKLY garantita da liquidità su Deribit, Sharpe 12.2), con un profilo di rischio sostanzialmente diverso: periodo di detenzione di circa 4x, gamma molto più bassa in prossimità della scadenza, liquidità più profonda sullo strike OTM e theta incassato nell'arco di un mese intero invece che di una settimana. Rigorosamente ONE gamba alla volta — niente spread, ali o copertura (L2 conforme; il bull put mensile CREDIT SPREAD appena fallito era a più gambe, questo no). Colma la maggiore lacuna operativa della sede: le opzioni sono a 4.3% rispetto a una quota del 15% e, con Hyperliquid bloccato da L11, COIN-M bloccato da timeout nella raccolta dati, i segnali di funding bloccati da L13, i panieri trasversali bloccati da L12 e i flussi di liquidazioni da L3, le opzioni Deribit a gamba singola sono l'unico segmento sottoutilizzato con un percorso di esecuzione comprovato e dati IV/greche confermati. Sono stati ottimizzati solo 3 parametri (otm_pct, min_iv_rv_spread, iv_rank_floor).

L'iterazione 2 recepisce il verdetto della revisione del backtest: valore atteso negativo dovuto interamente a una coda sinistra senza limite (avg_loss ~6.2x avg_win), che i parametri economici 3 non possono correggere. In base all'indicazione dell'analista di aggiungere un'uscita a rischio definito BEFORE qualsiasi ottimizzazione dei parametri, ho aggiunto un limite di coda per posizione a _manage_exits e lasciato intatta la logica di segnale, filtro e pianificazione che aveva superato la verifica (così nessun livello di verifica precedente regredisce). Due protezioni: (1) uno stop basato su un multiplo del premio — usando l'esistente _put_pnl_pct (P&L della put corta come percentuale del premio incassato), chiusura quando pnl <= -stop_loss_premium_mult*100 (valore predefinito 2.0 => il prezzo di riferimento della put ha raggiunto 3x il prezzo d'ingresso, cioè perdita = 2x del premio), limitando direttamente la perdita massima della singola operazione a un piccolo multiplo del premio invece che a una perdita quasi totale della liquidità a garanzia; e (2) un'uscita in caso di superamento dello strike da parte del prezzo spot (chiusura quando spot <= strike*(1+strike_breach_buffer)) come protezione indipendente dal prezzo di mercato dell'opzione contro lo scenario di crollo che ha generato la coda. L'implementazione è stata minima e mirata: aggiunti tre parametri in __init__, memorizzato 'strike' nello stato per periodo all'ingresso, passato 'spot' a _manage_exits e aggiunti i due rami elif dopo il controllo di presa di profitto esistente; la contabilizzazione e la registrazione delle uscite conteggiano già motivazioni arbitrarie, quindi 'stop_loss'/'strike_breach' compaiono nel riepilogo. In base al riscontro, in questa fase ho deliberatamente NOT inasprito iv_rank_floor / min_iv_rv_spread — da riconsiderare solo dopo un nuovo backtest della versione con limite di coda, che mostri profit_factor > 1.1 con avg_trade_return_pct positivo. La configurazione mantiene il collaudato primario perpetuo 1-DAY e l'intervallo temporale della gamba mobile 1-DAY (evita l'esplosione del tempo di calcolo), con un lookback di 365 giorni per ~12 scadenze mensili.

Insufficienza strutturale dei dati, non un difetto del codice. La correzione del limite di coda dell'iterazione 1 ha funzionato (valore atteso positivo, DD 0.62%), ma la catena di opzioni mensili BTC di Deribit contiene solo 12 scadenze (2025-07 → 2026-06 — ~1 anni di storico delle opzioni mensili), e il doppio filtro di volatilità le ha ridotte a 5 operazioni effettive / 5 rendimenti giornalieri (rapporto: metrics_reliable=false, 'Inaffidabile: solo 5 rendimenti giornalieri'). Nessuna modifica dello sviluppatore può creare altre scadenze mensili storiche, e allentare i filtri arriva solo a ~12 operazioni — ancora troppo poche per la pipeline a 3 fasi (le finestre walk-forward contengono 1-2 operazioni; il periodo di verifica di 15 giorni contiene ~0 operazioni mensili), quindi l'ottimizzazione si adatterebbe al rumore. Il meccanismo di vendita di put VRP è valido ed è stato validato in paper trading ALREADY sulla scadenza WEEKLY (Sharpe 12.2), che estrae ~4x campioni dalla stessa finestra di dati sulle opzioni; l'analogo mensile semplicemente non è validabile con i dati disponibili. Si raccomanda al responsabile della ricerca di non riproporre programmi mensili su singoli nomi con opzioni Deribit finché non saranno raccolti >2 anni di storico delle opzioni mensili — la scadenza settimanale è l'espressione praticabile di questo vantaggio.

Scrittura mensile di put OTM a gamba singola, interamente garantita da liquidità, su Deribit BTC, per cogliere il premio per il rischio di volatilità. A ogni ciclo di scadenza mensile, IF quando entrambe le soglie di volatilità sono superate (DVOL iv_rank >= iv_rank_floor AND IV/RV >= 1 + min_iv_rv_spread), SELL una put mensile con scadenza tra ~10%-OTM BTC, dimensionata in modo che strike*contratti sia ~20% del capitale netto (con limite rigido di 25%). La posizione viene chiusa al verificarsi del primo tra: FIRST: acquisizione di profitti pari a 50% del premio, uno stop a rischio definito (perdita non realizzata >= stop_loss_premium_mult x premio incassato, predefinito 2x), il superamento dello strike da parte del prezzo spot (put ~ITM) oppure il margine di tempo prima della scadenza previsto per il rollover. Una sola put aperta alla volta, leva 1.0, nessuno spread, ala o copertura. Le gambe put di rollover vengono ricavate dalla vera catena mensile storica di Deribit BTC; se la catena non è disponibile, la strategia non effettua operazioni (nessuna alternativa basata sul sottostante).

Non inviare NOT ancora all'ottimizzazione: il valore atteso della strategia è negativo per via esclusiva di una coda sinistra senza limite (avg_loss $1678 contro avg_win $270, ~6.2x), e i parametri ottimizzabili 3 non possono correggere il rischio di coda. Aggiungere un'uscita a rischio definito BEFORE qualsiasi ottimizzazione dei parametri: (1) uno stop per posizione che chiude la put corta quando il suo prezzo sale a un multiplo del premio incassato (per esempio, perdita = 2x-2.5x del premio) o quando la perdita supera una percentuale fissa del budget di garanzia, così un singolo crollo mensile non può più causare una perdita quasi totale; valutare (2) di spostare lo strike verso il basso o chiudere in caso di superamento dello strike da parte del prezzo spot, anziché mantenere la posizione fino alla scadenza. Riconsiderare anche se il doppio filtro selezioni davvero IV sufficientemente remunerative con la scadenza mensile — con 84% vittorie che producono comunque una perdita netta, il premio incassato non compensava la varianza della coda realizzata, quindi inasprire iv_rank_floor / min_iv_rv_spread solo AFTER lo stop sia attivo. Eseguire nuovamente il backtest; procedere all'ottimizzazione solo se la versione con limite di coda mostra profit_factor > 1.1 e avg_trade_return_pct positivo con un numero di operazioni simile o superiore.