ETH Spread settimanale put-credit Deribit — cattura del premio per il rischio di volatilità + skew al ribasso (opzioni a rischio definito, con filtro skew, 3 parametri)

Una strategia di opzioni DEFINED-RISK su un'unica venue, con scadenze settimanali DERIBIT ETH, che vende il lato ribassista persistentemente sovrapprezzato della superficie di volatilità crypto. Una volta per ciclo settimanale (scadenza più vicina ~5-7 DTE), e ONLY quando la protezione dal ribasso è chiaramente costosa (put 25-delta IV più cara di ATM IV, con un margine di skew AND ATM IV sopra la volatilità realizzata passata), apre uno PUT CREDIT SPREAD: SELL una put a ~25-delta e BUY una put a ~10-delta con la stessa scadenza. La perdita massima è limitata a (ampiezza degli strike − credito netto), quindi un movimento estremo non può liquidare il conto: questo affronta direttamente la principale preoccupazione emersa nella revisione del rischio sulle strategie short vol. Colma deliberatamente la più grande lacuna del portafoglio della fabbrica: le opzioni sono 4.7% del portafoglio, contro una quota ≥15%, con una copertura precedente pressoché nulla. Si distingue intenzionalmente da uno short strangle semplice: sottostante diverso (ETH), struttura diversa (verticale a rischio definito, non scoperta su entrambi i lati) e segnale diverso (premio dello skew delle put SKEW + VRP, non IV/RV grezzo). Solo 3 parametri regolabili, per resistere all'overfitting che ha fatto fallire 259 ipotesi precedenti. NOT carry da funding (L33), NOT una variante basata sulla convergenza dei segnali momentum/trend (esaurita), NOT un'inversione o un rientro del prezzo: la fonte del P&L è un premio assicurativo strutturale più il premio dello skew delle put crypto, non una previsione direzionale del prezzo.

Il livello-3 «Nessuna operazione generata / 0 barre valutate» aveva due cause concrete, e nessuna delle due era la soglia di ingresso (il feedback dice correttamente di non allentare le soglie). Primo, la riga «0 barre valutate» è un falso indizio per questa famiglia: RollingOptionsStrategy.on_bar sovrascrive completamente FactoryStrategy.on_bar e non raggiunge mai _process_primary, quindi bars_seen è 0 per ogni strategia rolling-options, comprese quelle che operano normalmente — l’ho confermato leggendo rolling_options_template.py e base_template.py, invece di aggiungere una chiamata super().on_bar() che avrebbe instradato le barre primarie verso la barriera di allineamento tra gambe della classe base, dove le gambe delle opzioni intermittenti (stesso intervallo temporale 1-DAY della primaria) avrebbero bloccato per sempre l’elaborazione. Secondo, i veri impedimenti: (a) ANNUALIZATION MISMATCH — le impostazioni ereditate della volatilità realizzata erano orarie (rv_window=168, bars_per_year=8760), mentre l’esecuzione usa barre 1-DAY, perciò i rendimenti logaritmici giornalieri venivano annualizzati con sqrt(8760) invece di sqrt(365), gonfiando RV di 4.90x (una serie normale da 3%/giorno ETH mostra 281% invece di 57%); il filtro VRP iv >= rv*(1+margin) confrontava quindi ~60% IV con ~281% RV e risultava False a ogni ciclo. Corretto derivando bars_per_year dal tipo di barra configurato ed esprimendo la finestra RV in giorni di calendario, così che l’errore non possa ripetersi con alcun intervallo (verificato: 1-DAY -> 365, 1-HOUR -> 8760, 4-HOUR -> 2190, e ora il filtro si attiva con una serie normale). (b) ROLE MAPPING — l’impalcatura ereditata identificava le gambe in base al tipo di opzione e ne richiedeva una call e una put (uno strangle), quindi le due gambe P di uno spread put si scontravano sulla stessa chiave, la seconda veniva rifiutata come duplicato, il controllo di prontezza richiedeva una gamba call inesistente e ogni gamba veniva inviata SELL (due put short scoperte, non un verticale a rischio definito). Ora le gambe vengono associate in base allo strike come short/long; la short viene venduta e la long acquistata usando lo stesso numero di contratti memorizzato in cache, atomicamente. Ho anche rimosso lo stop ereditato basato su un multiplo del premio: l’ala long limita già la perdita, quindi uno stop su una struttura con perdita massima definita realizza soltanto in anticipo una perdita limitata e aggiunge commissioni. L’aritmetica del dimensionamento è stata verificata dall’inizio alla fine (spread largo 150, credito di $22, perdita massima di $128 -> 15 contratti = 1.9% del capitale a rischio). Ho mantenuto intatto tutto ciò che aveva superato i livelli 1-2: importazioni pulite, la funzione libera _bar_ts a livello di modulo che risolve il TypeError di riassegnazione dello staticmethod del livello-2, il parser DVOL, l’inversione Black-Scholes di IV e il calculate_signal continuo. lookback_days è 49 (7 cicli, 14 gambe di opzioni) perché il caricatore del catalogo per tipo di barra impiega ~10s per gamba e una catena più ampia rischia di superare il tempo limite del livello-3; ciò limita il campione iniziale ed è una caratteristica del caricatore, non un’ipotesi.

verification_loop: Verifica non superata (Livello 4 — revisione QA) [classe=code_defect]: - [edge_concern] La sandbox avg_trade_return_pct è -45.45% su 2 operazioni con metrics_reliable=false e data_days=1 — questo non è un verdetto sulla performance (il rendimento per nozionale non è significativo per le gambe delle opzioni, dove il nozionale del premio << il nozionale dell'ala, e la sandbox è un test preliminare di 1 giorni). Viene riportato solo come contesto: se il problema del caricatore/lookback qui sotto viene risolto e si accumula un campione reale di opzioni settimanali, l'analista dovrebbe verificare di nuovo se il credito netto incassato supera il costo round-trip di Deribit di 0.03%/lato su 4 gambe (apertura+chiusura x short+long), oltre a eventuali slittamenti da assegnazione, poiché il vantaggio per nozionale di uno spread put credit è strutturalmente esiguo. - [critico] rolling_options.lookback_days=49 limita la catena di opzioni risolvibile di ENTIRE del backtest ANY a circa 49 giorni che terminano «ora» = circa 7 cicli settimanali / circa 14 gambe di opzioni, indipendentemente dalla storia delle opzioni di Deribit di 6.5 anni ETH. La strategia resta inattiva per il resto della finestra e opera solo nella parte finale. La sandbox lo conferma empiricamente: bars_processed=2400 (circa 6.5 anni), ma data_days=1 e total_trades=2 (trades_count=4). Un vantaggio basato sul premio per il rischio di varianza e sullo skew non si può distinguere dal rumore su circa 7 cicli / circa 14 gambe — molto meno delle circa 30-100 operazioni necessarie per un campione di opzioni misurabile. È proprio questo il problema tra costo del caricatore e dimensione del campione-22 che ha causato l'abbandono, giorni fa, di BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp, quasi identico (stessa sede, stesso lookback_days=49), al Livello 4. La motivazione dello sviluppatore riconosce il limite («lookback_days è 49 (7 cicli, 14 gambe di opzioni) perché il caricatore del catalogo per tipo di barra costa circa 10s per gamba e una catena più ampia rischia di superare il tempo massimo del Livello-3»). Con questa configurazione, la strategia non può mai produrre un backtest completo misurabile. — correzione: non procedere con circa 7 cicli. Risolvi il problema tra costo del caricatore e dimensione del campione-22 prima di inviare di nuovo: raggruppa e parallelizza, oppure memorizza nella cache i caricamenti di catalog.bars() per gamba tra le barre, in modo che lookback_days possa coprire molti anni di cicli settimanali (circa 200-300 cicli) senza superare il tempo massimo della sandbox; poi imposta lookback_days per coprire l'intera finestra di test. Se il caricatore non riesce davvero a risolvere una storia di opzioni settimanali misurabile entro il limite di tempo, questa famiglia non è testabile nell'infrastruttura attuale con cadenza settimanale e va riprogettata (per esempio, usando meno cicli mensili con scadenze più lunghe nell'intero periodo) invece di proseguire.

Spread put credit settimanale a rischio definito su Deribit ETH. A ogni ciclo di scadenza settimanale (circa 7 DTE), il framework di opzioni rolling risolve due gambe put (circa 5% e circa 10% OTM); la strategia le associa in base allo strike a una gamba short (strike più alto, delta circa 25) e una long (strike più basso, delta circa 10), SELLS la short e BUYS la long con un identico numero di contratti 1:1, e mantiene la posizione fino al buffer di rollover prima del regolamento in contanti europeo. L'ingresso è subordinato a due test di ricchezza misurati nella finestra d'ingresso del ciclo: skew al ribasso (short-put IV >= DVOL Deribit ATM IV x (1 + skew_margin)) e premio per il rischio di varianza (ATM IV >= volatilità realizzata dei precedenti 14 giorni x (1 + vrp_margin)). Le IV delle gambe sono ricavate dalla barra del premio USD di ciascuna gamba con Black-Scholes. La perdita massima per spread è (ampiezza dello strike - credito netto), fissata all'ingresso, e il dimensionamento rischia esattamente tale importo: contratti = floor(equity x risk_frac / max_loss), con limite affinché l'ampiezza lorda dello spread resti entro 50% dell'equity e minimo pari al requisito di 1 contratti ETH di Deribit. Parametri regolabili 3 (skew_margin, vrp_margin, risk_frac); leva 1.0; nessun percorso di trading perp/sottostante.

Verifica non riuscita (revisione Layer 4 — QA) [class=code_defect]: - [edge_concern] La sandbox avg_trade_return_pct è -45.45% su 2 operazioni con metrics_reliable=false e data_days=1 — questo non è un giudizio sulle prestazioni (il rendimento per nozionale non è significativo per le gambe di opzioni, dove il nozionale del premio è << il nozionale dell’ala, e la sandbox è un test preliminare di 1 giorni). Si mantiene solo come contesto: se il problema del loader/lookback qui sotto viene risolto e si accumula un campione reale di opzioni settimanali, l’analista dovrebbe verificare nuovamente se il credito netto incassato supera il costo round-trip di Deribit, pari a 0.03%/lato, per 4 gambe (apertura+chiusura x short+long), oltre a qualsiasi slippage da assegnazione, poiché il vantaggio per nozionale dei put credit spread è strutturalmente esiguo. - [critical] rolling_options.lookback_days=49 limita la catena di opzioni risolvibile di ENTIRE del backtest ANY ai circa 49 giorni che terminano «ora» = circa 7 cicli settimanali / circa 14 gambe di opzioni, indipendentemente dalla cronologia delle opzioni di Deribit di 6.5 anni ETH. La strategia resta inattiva per il resto della finestra e opera solo nella parte finale. La sandbox lo conferma empiricamente: bars_processed=2400 (circa 6.5 anni), eppure data_days=1 e total_trades=2 (trades_count=4). Un vantaggio basato sul premio per il rischio di varianza e sull’inclinazione non può essere distinto dal rumore su circa 7 cicli / circa 14 gambe — ben al di sotto delle circa 30-100 operazioni necessarie per un campione di opzioni misurabile. È proprio questo problema di costi del loader rispetto alla dimensione del campione-22 che ha portato, 4 giorni fa, all’abbandono della strategia quasi identica BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (stessa piattaforma, stesso lookback_days=49). La motivazione dello sviluppatore riconosce il limite («lookback_days è 49 (7 cicli, 14 gambe di opzioni) perché il loader del catalogo per tipo di barra costa circa 10s per gamba e una catena più ampia rischia di superare il tempo massimo di esecuzione Layer-3»). Con la configurazione attuale, la strategia non potrà mai produrre un backtest completo misurabile. — Correzione: non procedere con circa 7 cicli. Risolvere il problema dei costi del loader rispetto alla dimensione del campione-22 prima di inviare nuovamente: raggruppare/elaborare in parallelo o memorizzare nella cache i caricamenti di catalog.bars() per singola gamba tra le barre, così che lookback_days possa coprire molti anni di cicli settimanali (circa 200-300 cicli) senza superare il tempo massimo della sandbox, quindi impostare lookback_days in modo da coprire l’intera finestra di test. Se il loader non può effettivamente risolvere una cronologia misurabile di opzioni settimanali entro il limite di tempo, questa famiglia non è verificabile nell’harness attuale con cadenza settimanale e dovrebbe essere riprogettata (ad esempio, con meno cicli mensili a scadenza più lunga distribuiti sull’intero intervallo) anziché

Verifica non riuscita (Layer 2 — scenari sintetici): Parametri utilizzati: ['contracts', 'leg_sides', 'risk_frac', 'rv_window', 'atm_offset', 'skew_margin', 'iv_rv_margin', 'bars_per_year', 'min_contracts', 'iv_stale_hours', 'rv_slow_window', 'long_put_offset', 'rolling_options', 'short_put_offset', 'max_notional_frac', 'min_bars_required', 'roll_buffer_hours', 'entry_window_hours'] Verifica che __init__ imposti tutti gli attributi usando self.parameters.get(). - steady_uptrend: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000)

Verifica non riuscita (Layer 2 — scenari sintetici): Parametri utilizzati: ['contracts', 'leg_sides', 'risk_frac', 'rv_window', 'stop_mult', 'put_offset', 'call_offset', 'iv_rv_margin', 'bars_per_year', 'min_contracts', 'iv_stale_hours', 'rv_slow_window', 'max_delta_ratio', 'rolling_options', 'max_notional_frac', 'min_bars_required', 'roll_buffer_hours', 'entry_window_hours'] Verifica che __init__ imposti tutti gli attributi usando self.parameters.get(). - steady_uptrend: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() accetta 1 argomenti posizionali, ma ne sono stati forniti 2 (timestamp della barra: 1735691040000)

Verifica non superata (Livello 4 — revisione QA) [classe=hypothesis_mismatch]: - [edge_concern] Non è alla base del verdetto — il problema è la fedeltà, non la performance. (Per completezza, anche la sandbox è negativa: -2.9%, PF 0.13, percentuale di vittorie 0.125, coda a -$2,149 su un portafoglio che si presumeva chiuso — ma è il risultato della strategia sbagliata.) - WHOLE-STRATEGY SWAP / MISLINK. L'ipotesi è uno ETH Deribit settimanale PUT CREDIT SPREAD (vendere una put a circa 25g, BUY una put a circa 10g — verticale a rischio definito). Il codice è lo BTC Deribit settimanale delta-neutrale SHORT STRANGLE (il nome della classe, la docstring, la motivazione iter-3 e ogni meccanismo corrispondono allo strangle). Sia lo strumento sia il meccanismo AND differiscono → artefatto generato/collegato in modo errato, non questa ipotesi. Rigenerare/ricollegare il corretto put credit spread ETH. - Strumento errato: l'ipotesi è ETH, ma instrument_id e bar_type sono BTC-PERPETUAL.DERIBIT e rolling_options.underlying è 'BTC'. Nessun ETH in alcun punto. - Struttura errata / rischio non definito: l'ipotesi limita la perdita massima con un'ala put PURCHASED a circa 10g. Il codice invia TWO SELL gambe senza ala acquistata NO; la coda è limitata solo da uno stop morbido sul premio della barra successiva (sandbox largest_loss -$2,149 contro avg_win circa $214 mostra che non limita la coda) — esattamente il profilo senza limite che l'ipotesi evita. - Vantaggio fondamentale assente: il segnale dell'ipotesi è la ricchezza dello skew al ribasso (SKEW put a 25g IV contro ATM IV) più IV>RV. Il codice non calcola lo skew — solo IV/RV dello strangle medio VRP. La raccolta dello skew delle put, che distingue questa ipotesi, non è implementata.

verification_loop: Verifica non superata (Livello 4 — revisione QA) [classe=code_defect]: - [edge_concern] La sandbox avg_trade_return_pct è -45.45% su 2 operazioni con metrics_reliable=false e data_days=1 — questo non è un verdetto sulla performance (il rendimento per nozionale non è significativo per le gambe delle opzioni, dove il nozionale del premio << il nozionale dell'ala, e la sandbox è un test preliminare di 1 giorni). Viene riportato solo come contesto: se il problema del caricatore/lookback qui sotto viene risolto e si accumula un campione reale di opzioni settimanali, l'analista dovrebbe verificare di nuovo se il credito netto incassato supera il costo round-trip di Deribit di 0.03%/lato su 4 gambe (apertura+chiusura x short+long), oltre a eventuali slittamenti da assegnazione, poiché il vantaggio per nozionale di uno spread put credit è strutturalmente esiguo. - [critico] rolling_options.lookback_days=49 limita la catena di opzioni risolvibile di ENTIRE del backtest ANY a circa 49 giorni che terminano «ora» = circa 7 cicli settimanali / circa 14 gambe di opzioni, indipendentemente dalla storia delle opzioni di Deribit di 6.5 anni ETH. La strategia resta inattiva per il resto della finestra e opera solo nella parte finale. La sandbox lo conferma empiricamente: bars_processed=2400 (circa 6.5 anni), ma data_days=1 e total_trades=2 (trades_count=4). Un vantaggio basato sul premio per il rischio di varianza e sullo skew non si può distinguere dal rumore su circa 7 cicli / circa 14 gambe — molto meno delle circa 30-100 operazioni necessarie per un campione di opzioni misurabile. È proprio questo il problema tra costo del caricatore e dimensione del campione-22 che ha causato l'abbandono, giorni fa, di BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp, quasi identico (stessa sede, stesso lookback_days=49), al Livello 4. La motivazione dello sviluppatore riconosce il limite («lookback_days è 49 (7 cicli, 14 gambe di opzioni) perché il caricatore del catalogo per tipo di barra costa circa 10s per gamba e una catena più ampia rischia di superare il tempo massimo del Livello-3»). Con questa configurazione, la strategia non può mai produrre un backtest completo misurabile. — correzione: non procedere con circa 7 cicli. Risolvi il problema tra costo del caricatore e dimensione del campione-22 prima di inviare di nuovo: raggruppa e parallelizza, oppure memorizza nella cache i caricamenti di catalog.bars() per gamba tra le barre, in modo che lookback_days possa coprire molti anni di cicli settimanali (circa 200-300 cicli) senza superare il tempo massimo della sandbox; poi imposta lookback_days per coprire l'intera finestra di test. Se il caricatore non riesce davvero a risolvere una storia di opzioni settimanali misurabile entro il limite di tempo, questa famiglia non è testabile nell'infrastruttura attuale con cadenza settimanale e va riprogettata (per esempio, usando meno cicli mensili con scadenze più lunghe nell'intero periodo) invece di proseguire.