ETH Deribit ugentlig put-credit-spread — høst af volatilitetsrisikopræmie + downside-skævhed (optioner med defineret risiko, skævhedsbetinget, 3-parameter)

En DEFINED-RISK, single-venue optionsstrategi på DERIBIT ETH ugentlige udløb, der sælger den vedvarende overprissatte downside på krypto-vol-overfladen. Én gang pr. ugentlig cyklus (front-udløb ~5-7 DTE), og ONLY når downside-forsikring er påviseligt dyr (25-delta put IV rigere end ATM IV med en skew-margin AND ATM IV over efterfølgende realiseret vol), åbner den en PUT CREDIT SPREAD: SELL én ~25-delta put og BUY én ~10-delta put med samme udløb. Maksimalt tab er cappet ved (strike-bredde − nettokredit), så kontoen ikke kan likvideres af et halehop — hvilket direkte adresserer den største risk-review-bekymring ved short-vol-strategier. Dette udfylder bevidst fabrikkens største porteføljegab: optioner er 4.7% af bogen vs. en ≥15%-kvote, med stort set nul tidligere dækning. Den er bevidst adskilt fra en almindelig short strangle — forskelligt underliggende (ETH), forskellig struktur (defined-risk vertical, ikke nøgen tosidet), og et andet signal (put-SKEW-richness + VRP, ikke rå IV/RV). Kun 3 tunbare parametre for at modstå den overfitting, der dræbte 259 tidligere hypoteser. NOT funding-carry (L33), NOT en momentum/trend-confluence-port (udtømt), NOT en prisreversal/fade — P&L-kilden er en strukturel forsikringspræmie plus krypto-put-skew-præmien, ikke en retningsbestemt prisprognose.

Lag-3 'No trades produced / 0 evaluated bars' havde to konkrete årsager, og ingen af dem var indgangstærsklen (feedbacken siger korrekt, at tærsklerne ikke skal lempes). Først er linjen '0 evaluated bars' en rød sild for denne familie: RollingOptionsStrategy.on_bar tilsidesætter fuldt ud FactoryStrategy.on_bar og når aldrig _process_primary, så bars_seen er 0 for enhver rolling-options-strategi, inklusive dem, der handler normalt — jeg bekræftede dette ved at læse rolling_options_template.py og base_template.py i stedet for at tilføje et super().on_bar()-kald, som ville have dirigeret primære barer ind i basens cross-leg-justeringsbarriere, hvor de intermitterende optionsben (samme 1-DAY-tidsramme som den primære) ville have blokeret behandlingen for altid. For det andet de faktiske blokeringer: (a) ANNUALIZATION MISMATCH — de nedarvede realized-vol-indstillinger var timebaserede (rv_window=168, bars_per_year=8760), mens kørslen er på 1-DAY-barer, så daglige log-afkast blev annualiseret med sqrt(8760) i stedet for sqrt(365), hvilket oppustede RV med 4.90x (et normalt 3%/dag ETH-tape aflæses som 281% i stedet for 57%); VRP-gaten iv >= rv*(1+margin) sammenlignede derefter ~60% IV med ~281% RV og var False i hver cyklus. Rettet ved at udlede bars_per_year fra den konfigurerede bartype og udtrykke RV-vinduet i kalenderdage, så driften ikke kan gentages på noget interval (verificeret: 1-DAY -> 365, 1-HOUR -> 8760, 4-HOUR -> 2190, og gaten består nu på et normalt tape). (b) ROLE MAPPING — den nedarvede scaffolding nøglede ben efter optionstype og krævede ét call plus ét put (en strangle), så et put-spreads to P-ben kolliderede på én nøgle, det andet blev afvist som duplikat, parathedstjekket krævede et ikke-eksisterende call-ben, og hvert ben blev indsendt SELL (to nøgne short puts, ikke en defined-risk vertical). Benene mappes nu efter strike til short/long, shorten sælges og longen købes med samme cachede kontraktantal, atomisk. Jeg fjernede også det nedarvede premium-multiple-stop: det lange wing begrænser allerede tabet, så et stop på en cappet struktur realiserer kun et begrænset tab tidligt og tilføjer gebyrer. Størrelsesberegningen er verificeret ende-til-ende (150-wide spread, $22 credit, $128 max loss -> 15 contracts = 1.9% of equity risked). Jeg beholdte alt, der bestod lag 1-2, intakt: rene imports, den modulære _bar_ts-frie funktion, der fikser lag-2-staticmethod-rebinding-TypeError, DVOL-parseren, Black-Scholes-IV-inversionen og den kontinuerlige calculate_signal. lookback_days er 49 (7 cycles, 14 option legs) fordi den per-bartype katalogloader koster ~10s per ben, og en større kæde risikerer lag-3-wall-clock; det begrænser den indledende stikprøve og er en loader-egenskab, ikke en hypotese-egenskab.

verification_loop: Verifikation mislykkedes (Lag 4 — QA-gennemgang) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct er -45.45% på 2 handler med metrics_reliable=false og data_days=1 — dette er ikke en performance-dom (afkast pr. notionel er ikke meningsfuldt for optionsben, hvor præmienotionel << wing-notionel, og sandboxen er en 1-dages smoke-test). Det videreføres kun som kontekst: hvis loader/lookback-problemet nedenfor løses, og en reel weekly-options-stikprøve opbygges, bør analytikeren genkontrollere, om den indsamlede nettokredit dækker Deribits 0.03%/side round-trip på tværs af 4 ben (åbn+luk x short+long) plus eventuel assignment-slippage, da put-credit-spread-kanten pr. notionel er strukturelt tynd. - [critical] rolling_options.lookback_days=49 begrænser den ENTIRE opløselige optionskæde for ANY-backtesten til de ~49 dage, der slutter 'nu' = ~7 ugentlige cykler / ~14 optionsben, uanset Deribits 6.5-årige ETH-optionshistorik. Strategien ligger fladt i resten af vinduet og handler kun i halen. Sandboxen bekræfter dette empirisk: bars_processed=2400 (~6.5 år), men data_days=1 og total_trades=2 (trades_count=4). En variance-risk-premium + skew-edge kan ikke skelnes fra støj på ~7 cykler / ~14 ben — langt under de ~30-100 handler, der kræves for en målbar optionsstikprøve. Dette er præcis den loader-cost-vs-sample-size-fælde-22, der gjorde, at den næsten identiske BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (samme venue, samme lookback_days=49) blev opgivet i lag 4 for dage siden. Udviklerens egen begrundelse anerkender loftet ('lookback_days er 49 (7 cycles, 14 option legs) fordi den per-bartype katalogloader koster ~10s per ben, og en større kæde risikerer lag-3-wall-clock'). Som konfigureret kan strategien aldrig producere en målbar fuld backtest. — fix: Bestå ikke på ~7 cykler. Løs loader-cost vs sample-size-fælden-22 før genindsendelse: batch/parallelisér eller cache de per-ben catalog.bars()-indlæsninger på tværs af barer, så lookback_days kan nå mange års ugentlige cykler (~200-300 cykler) uden at bryde sandboxens wall-clock, og sæt derefter lookback_days til at dække hele testvinduet. Hvis loaderen reelt ikke kan opløse en målbar weekly-options-historik inden for tidsbudgettet, er denne familie ikke testbar i den nuværende harness ved ugentlig kadence og bør redesignes (f.eks. færre, længere månedlige cykler på tværs af hele spændet) snarere

Defined-risk ugentlig put credit spread på Deribit ETH. I hver ugentlig udløbscyklus (~7 DTE) opløser rolling-options-rammeverket to put-ben (~5% og ~10% OTM); strategien mapper dem efter strike til et short-ben (højere strike, ~25-delta) og et long-ben (lavere strike, ~10-delta), SELLS shorten og BUYS longen med et identisk 1:1-kontraktantal og holder til roll-bufferen før europæisk cash settlement. Indgang er gatet på to richness-tests målt i cyklussens indgangsvindue: downside skew (short-put IV >= Deribit DVOL ATM IV x (1 + skew_margin)) og variance risk premium (ATM IV >= efterfølgende 14-dages realiseret vol x (1 + vrp_margin)). Benenes IV inverteres fra hvert bens egen USD-præmie-bar med Black-Scholes. Maksimalt tab pr. spread er (strike-bredde - nettokredit), fastsat ved indgang, og positionering risikerer præcis det: contracts = floor(equity x risk_frac / max_loss), cappet så brutto spread-bredde forbliver inden for 50% af egenkapitalen og gulvet ved Deribits 1-kontrakt ETH-minimum. 3 tunables (skew_margin, vrp_margin, risk_frac); gearing 1.0; ingen perp/underliggende handelsvej.

Verificering mislykkedes (lag 4 — gennemgang af QA) [klasse=code_defect]: - [edge_concern] Sandboxen avg_trade_return_pct er -45.45% på 2 handler med metrics_reliable=false og data_days=1 — dette er ikke en resultatdom (afkast pr. notional giver ikke mening for optionsben, hvor præmienotionalen << vingens notional, og sandboxen er en 1-dages smoke-test). Det videreføres kun som kontekst: Hvis loader-/lookback-problemet nedenfor bliver løst, og der opbygges en reel stikprøve af ugentlige optioner, bør analytikeren kontrollere igen, om den indsamlede nettokredit overstiger Deribits 0.03%/side for en round-trip på tværs af 4 ben (åbning+lukning x short+long) plus eventuel slippage ved tildeling, eftersom edge pr. notional for put-credit-spread strukturelt er tynd. - [kritisk] rolling_options.lookback_days=49 begrænser den ENTIRE opløselige optionskæde i ANY-backtesten til de ~49 dage, der slutter 'nu' = ~7 ugentlige cyklusser / ~14 optionsben, uanset Deribits 6.5-årige ETH-optionshistorik. Strategien ligger fladt resten af perioden og handler kun til sidst. Sandboxen bekræfter dette empirisk: bars_processed=2400 (~6.5 år), men data_days=1 og total_trades=2 (trades_count=4). En variance-risk-premium- og skew-edge kan ikke skelnes fra støj på ~7 cyklusser / ~14 ben — langt under de ~30-100 handler, der kræves til en målbar optionsstikprøve. Dette er præcis den afvejning mellem loaderomkostning og stikprøvestørrelse-22, som førte til, at den næsten identiske BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (samme handelsplads, samme lookback_days=49) blev opgivet for 4 lag siden. Udviklerens egen begrundelse anerkender begrænsningen ('lookback_days er 49 (7 cyklusser, 14 optionsben), fordi katalog-loaderen pr. bar-type koster ~10s pr. ben, og en større kæde risikerer lagets-3 maksimale køretid'). Som konfigureret kan strategien aldrig producere en målbar fuld backtest. — løsning: Gå ikke videre med ~7 cyklusser. Løs afvejningen mellem loaderomkostning og stikprøvestørrelse-22, før der indsendes igen: batch-/parallelisér eller cache catalog.bars()-indlæsningerne pr. ben på tværs af bars, så lookback_days kan nå mange års ugentlige cyklusser (~200-300 cyklusser) uden at overskride sandboxens maksimale køretid, og indstil derefter lookback_days, så den dækker hele testperioden. Hvis loaderen reelt ikke kan finde en målbar historik for ugentlige optioner inden for tidsbudgettet, kan denne familie ikke testes med ugentlig frekvens i det nuværende harness og bør redesignes (f.eks. færre cyklusser med længere løbetid på månedsbasis over hele perioden) i stedet

Verificering mislykkedes (lag 2 — syntetiske scenarier): Anvendte parametre: ['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'] Kontrollér, at __init__ sætter alle attributter fra self.parameters.get(). - steady_uptrend: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000)

Verificering mislykkedes (lag 2 — syntetiske scenarier): Anvendte parametre: ['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'] Kontrollér, at __init__ sætter alle attributter fra self.parameters.get(). - steady_uptrend: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() tager 1 positionsargument, men fik 2 (bartidsstempel: 1735691040000)

Verifikation mislykkedes (Layer 4 — QA-gennemgang) [klasse=hypothesis_mismatch]: - [edge_concern] Ikke grundlaget for konklusionen — blokeringen handler om fidelitet, ikke performance. (Til orientering er sandboxen også negativ: -2.9%, PF 0.13, win 0.125, en hale på -$2,149 på en bog, der angiveligt var stoppet — men det er resultatet fra den forkerte strategi.) - WHOLE-STRATEGY SWAP / MISLINK. Hypotesen er en ETH Deribit ugentlig PUT CREDIT SPREAD (sælg en put med ~25d, BUY en put med ~10d — vertikal spread med defineret risiko). Koden er den BTC Deribit ugentlige delta-neutrale SHORT STRANGLE (klassenavn, docstring, iter-3-begrundelse og alle mekanismer beskriver en strangle). Instrument og AND-mekanisme er begge forskellige → fejl-genereret/fejlknyttet artefakt, ikke denne hypotese. Generér/knyt det korrekte ETH put-credit-spread igen. - Forkert instrument: hypotesen er ETH, men instrument_id og bar_type er BTC-PERPETUAL.DERIBIT og rolling_options.underlying er 'BTC'. Der er ingen ETH nogen steder. - Forkert struktur / ingen defineret risiko: Hypotesen begrænser det maksimale tab med en PURCHASED put-vinge på ~10d. Koden indsender TWO ben SELL uden købt vinge NO; halen begrænses kun af et blødt stop på præmien for næste bar (sandbox largest_loss -$2,149 mod avg_win ~$214 viser, at det ikke begrænser halen) — præcis den ubegrænsede profil, som hypotesen forsøger at undgå. - Den centrale edge mangler: Hypotesens signal er rigelig downside-SKEW (25d-put IV mod ATM IV) plus IV>RV. Koden beregner ingen skew — kun gennemsnitlig strangle-IV/RV VRP. Put-skew-høsten, der adskiller denne hypotese, er ikke implementeret.

verification_loop: Verifikation mislykkedes (Lag 4 — QA-gennemgang) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct er -45.45% på 2 handler med metrics_reliable=false og data_days=1 — dette er ikke en performance-dom (afkast pr. notionel er ikke meningsfuldt for optionsben, hvor præmienotionel << wing-notionel, og sandboxen er en 1-dages smoke-test). Det videreføres kun som kontekst: hvis loader/lookback-problemet nedenfor løses, og en reel weekly-options-stikprøve opbygges, bør analytikeren genkontrollere, om den indsamlede nettokredit dækker Deribits 0.03%/side round-trip på tværs af 4 ben (åbn+luk x short+long) plus eventuel assignment-slippage, da put-credit-spread-kanten pr. notionel er strukturelt tynd. - [critical] rolling_options.lookback_days=49 begrænser den ENTIRE opløselige optionskæde for ANY-backtesten til de ~49 dage, der slutter 'nu' = ~7 ugentlige cykler / ~14 optionsben, uanset Deribits 6.5-årige ETH-optionshistorik. Strategien ligger fladt i resten af vinduet og handler kun i halen. Sandboxen bekræfter dette empirisk: bars_processed=2400 (~6.5 år), men data_days=1 og total_trades=2 (trades_count=4). En variance-risk-premium + skew-edge kan ikke skelnes fra støj på ~7 cykler / ~14 ben — langt under de ~30-100 handler, der kræves for en målbar optionsstikprøve. Dette er præcis den loader-cost-vs-sample-size-fælde-22, der gjorde, at den næsten identiske BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (samme venue, samme lookback_days=49) blev opgivet i lag 4 for dage siden. Udviklerens egen begrundelse anerkender loftet ('lookback_days er 49 (7 cycles, 14 option legs) fordi den per-bartype katalogloader koster ~10s per ben, og en større kæde risikerer lag-3-wall-clock'). Som konfigureret kan strategien aldrig producere en målbar fuld backtest. — fix: Bestå ikke på ~7 cykler. Løs loader-cost vs sample-size-fælden-22 før genindsendelse: batch/parallelisér eller cache de per-ben catalog.bars()-indlæsninger på tværs af barer, så lookback_days kan nå mange års ugentlige cykler (~200-300 cykler) uden at bryde sandboxens wall-clock, og sæt derefter lookback_days til at dække hele testvinduet. Hvis loaderen reelt ikke kan opløse en målbar weekly-options-historik inden for tidsbudgettet, er denne familie ikke testbar i den nuværende harness ved ugentlig kadence og bør redesignes (f.eks. færre, længere månedlige cykler på tværs af hele spændet) snarere