ETH Deribit ukentlig put-credit-spread — høsting av volatilitetsrisikopremie + nedsideskjevhet (opsjoner med definert risiko, styrt av skjevhet, 3 parametere)

En DEFINED-RISK, enkelt-venue opsjonsstrategi på DERIBIT ETH ukentlige utløp som selger den vedvarende overprisede nedsiden av krypto-volatilitetsoverflaten. Én gang per ukentlig syklus (front utløp ~5-7 DTE), og ONLY når nedside-forsikring er påviselig dyr (25-delta put IV rikere enn ATM IV med en skjevhetsmargin AND ATM IV over etterslepende realisert volatilitet), åpner den en PUT CREDIT SPREAD: SELL én ~25-delta put og BUY én ~10-delta put av samme utløp. Maksimalt tap er takket ved (strike-bredde − netto kreditt), så kontoen kan ikke likvideres av et haleutslag — og adresserer direkte den største risiko-gjennomgang-bekymringen med kort-vol-strategier. Dette fyller bevisst fabrikkens eneste største portefølje-hull: opsjoner er 4.7% av boken mot en ≥15% kvote, med så godt som null tidligere dekning. Den er bevisst distinkt fra en enkel kort strangle — annen underliggende (ETH), annen struktur (definert-risiko-vertikal, ikke naked to-sidig), og et annet signal (put-SKEW-rikhet + VRP, ikke rå IV/RV). Bare 3 justerbare parametere for å motstå overtilpasningen som drepte 259 tidligere hypoteser. NOT funding-bærer (L33), NOT en momentum/trend-sammenflyt-port (utslitt), NOT en prisreversering/fade — P&L-kilden er en strukturell forsikringspremie pluss krypto-put-skjevhetspremien, ikke en retningsbestemt prisprognose.

Lag-3 'Ingen handler produsert / 0 evaluerte barer' hadde to konkrete årsaker, og ingen av dem var inngangsterskelen (tilbakemeldingen sier riktig at man ikke skal løsne terskler). For det første er '0 evaluerte barer'-linjen et villspor for denne familien: RollingOptionsStrategy.on_bar overstyrer FactoryStrategy.on_bar fullstendig og når aldri frem til _process_primary, så bars_seen er 0 for hver enkelt rullende-opsjoner-strategi, inkludert de som handler normalt — jeg bekreftet dette ved å lese rolling_options_template.py og base_template.py i stedet for å legge til et super().on_bar()-kall som ville ha rutet primærbarer inn i basens kryss-legsjusteringsbarriere, der de intermitterende opsjonsbeina (samme 1-DAY tidsramme som den primære) ville ha blokkert prosesseringen for alltid. For det andre, de faktiske blokkeringene: (a) ANNUALIZATION MISMATCH — de nedarvede realisert-volatilitet-innstillingene var timebaserte (rv_window=168, bars_per_year=8760) mens kjøringen er på 1-DAY barer, så daglige loggavkastninger ble annualisert med sqrt(8760) i stedet for sqrt(365), og blåste opp RV med 4.90x (en normal 3%/dag ETH-tape leser 281% i stedet for 57%); VRP-porten iv >= rv*(1+margin) sammenlignet da ~60% IV mot ~281% RV og var False på hver syklus. Fikset ved å utlede bars_per_year fra den konfigurerte bartypen og uttrykke RV-vinduet i kalenderdager, slik at driften ikke kan gjenta seg på noe intervall (verifisert: 1-DAY -> 365, 1-HOUR -> 8760, 4-HOUR -> 2190, og porten passerer nå på en normal tape). (b) ROLE MAPPING — det nedarvede stillasset nøklet bein etter opsjonstype og krevde én call pluss én put (en strangle), så et put-spreads to P-bein kolliderte på én nøkkel, det andre ble avvist som en duplikat, beredskapssjekken krevde et ikke-eksisterende call-bein, og hvert bein ble sendt inn SELL (to nakede korte puts, ikke en definert-risiko-vertikal). Bein er nå tilordnet etter strike inn i kort/lang, det korte selges og det lange kjøpes til samme bufrede kontraktantall, atomisk. Jeg fjernet også den nedarvede premie-multippel-stoppen: det lange vingebenet avgrenser allerede tapet, så en stopp på en takket struktur realiserer kun et begrenset tap tidlig og legger til gebyrer. Dimensjoneringsaritmetikk verifisert ende-til-ende (150-bredt spread, $22 kreditt, $128 maksimalt tap -> 15 kontrakter = 1.9% av egenkapital risikert). Jeg beholdt alt som passerte Lag 1-2 intakt: rene importer, modulnivå-_bar_ts-fri funksjon som fikser Lag-2-staticmethod-rebinding-TypeError, DVOL-parseren, Black-Scholes IV-inversjonen, og den kontinuerlige calculate_signal. lookback_days er 49 (7 sykluser, 14 opsjonsbein) fordi per-bar-type katalog-lasteren koster ~10s per bein og en større kjede risikerer Lag-3-veggklokken; det begrenser det innledende utvalget og er en laster-egenskap, ikke en hypotese-egenskap.

verification_loop: Verifisering mislyktes (Lag 4 — QA gjennomgang) [klasse=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 ytelsesdom (per-notional avkastning er ikke meningsfull for opsjonsbein, der premie-notional << vingebein-notional, og sandbox er en 1-dagers røyktest). Det videreføres kun som kontekst: hvis laster-/lookback-problemet nedenfor løses og et reelt ukentlig-opsjoner-utvalg akkumuleres, bør analytikeren sjekke på nytt om netto kreditt inndrevet dekker Deribits 0.03%/side round-trip på tvers av 4 bein (åpne+lukke x kort+lang) pluss eventuell tildelingsglidning, ettersom put-kreditt-spread per-notional edge er strukturelt tynn. - [kritisk] rolling_options.lookback_days=49 begrenser den ENTIRE løsbare opsjonskjeden til ANY backtest til de ~49 dagene som slutter 'nå' = ~7 ukentlige sykluser / ~14 opsjonsbein, uavhengig av Deribits 6.5-års ETH opsjonshistorikk. Strategien ligger flat resten av vinduet og handler kun ved halen. Sandbox bekrefter dette empirisk: bars_processed=2400 (~6.5 år) men data_days=1 og total_trades=2 (trades_count=4). En varians-risiko-premium + skjevhet-edge kan ikke skilles fra støy på ~7 sykluser / ~14 bein — langt under de ~30-100 handler som trengs for et målbart opsjonsutvalg. Dette er den nøyaktige laster-kostnad-vs-utvalgsstørrelse-felle-22 som fikk den nesten identiske BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (samme venue, samme lookback_days=49) til å bli forlatt på Lag 4 dager siden. Utviklerens egen begrunnelse anerkjenner taket ('lookback_days er 49 (7 sykluser, 14 opsjonsbein) fordi per-bar-type katalog-lasteren koster ~10s per bein og en større kjede risikerer Lag-3-veggklokken'). Som konfigurert kan strategien aldri produsere en målbar full backtest. — fiks: Ikke godkjenn på ~7 sykluser. Løs laster-kostnad-vs-utvalgsstørrelse-felle-22 før innsending på nytt: batch/paralleliser eller bufre per-bein catalog.bars()-lastinger på tvers av barer slik at lookback_days kan nå mange års ukentlige sykluser (~200-300 sykluser) uten å bryte sandbox-veggklokken, sett deretter lookback_days til å dekke hele testvinduet. Hvis lasteren genuint ikke kan løse en målbar ukentlig-opsjoner-historikk innen tidsbudsjettet, er denne familien ikke testbar i det nåværende testmiljøet ved ukentlig kadens og bør redesignes (f.eks. færre, lengre-daterte månedlige sykluser på tvers av hele spennet) heller

Definert-risiko ukentlig put-kreditt-spread på Deribit ETH. Hver ukentlig utløpssyklus (~7 DTE) løser det rullende-opsjoner-rammeverket to put-bein (~5% og ~10% OTM); strategien tilordner dem etter strike inn i et kort (høyere-strike, ~25-delta) og langt (lavere-strike, ~10-delta) bein, SELLS det korte og BUYS det lange til et identisk 1:1 kontraktantall, og holder til rullebufferen før europeisk kontantoppgjør. Inngang er portvoktet på to rikhetstester målt ved syklens oppføringsvindu: nedside-skjevhet (kort-put IV >= Deribit DVOL ATM IV x (1 + skew_margin)) og varians-risiko-premium (ATM IV >= etterslepende 14-dagers realisert volatilitet x (1 + vrp_margin)). Bein-IV-er inverteres fra hvert beins egen USD-premie-bar med Black-Scholes. Maksimalt tap per spread er (strike-bredde - netto kreditt), fastsatt ved inngang, og dimensjonering risikerer nøyaktig det: kontrakter = gulv(egenkapital x risk_frac / max_loss), taket slik at brutto spread-bredde holdes innenfor 50% av egenkapital og gulvet ved Deribits 1-kontrakt ETH-minimum. 3 justerbare parametere (skew_margin, vrp_margin, risk_frac); gearing 1.0; ingen perp/underliggende handelsbane.

Verifisering mislyktes (Lag 4 — QA-gjennomgang) [klasse=code_defect]: - [edge_concern] Sandkasse avg_trade_return_pct er -45.45% på 2 handler med metrics_reliable=false og data_days=1 — dette er ikke en ytelsesdom (avkastning per notional er ikke meningsfull for opsjonsben, der premie-notional << wing-notional, og sandkassen er en 1-dagers røyktest). Det videreføres bare som kontekst: hvis laster-/tilbakeblikk-problemet nedenfor er løst og et reelt ukentlig opsjonsutvalg påløper, bør analytikeren sjekke på nytt om netto kreditten som er samlet dekker Deribits 0.03%/side round-trip på tvers av 4 ben (åpne+lukk x short+long) pluss eventuell tildelingsglidning, ettersom put-credit-spread per-notional edge er strukturelt tynn. - [kritisk] rolling_options.lookback_days=49 begrenser den ENTIRE løsbare opsjonskjeden for ANY-tilbaketesten til de ~49 dagene som slutter ved 'now' = ~7 ukentlige sykluser / ~14 opsjonsben, uavhengig av Deribits 6.5-årige ETH-opsjonshistorie. Strategien ligger flat for resten av vinduet og handler bare ved halen. Sandkassen bekrefter dette empirisk: bars_processed=2400 (~6.5 år) men data_days=1 og total_trades=2 (trades_count=4). En varians-risiko-premie + skjevhets-edge kan ikke skilles fra støy på ~7 sykluser / ~14 ben — langt under de ~30-100 handlene som trengs for et målbart opsjonsutvalg. Dette er den nøyaktige laster-kost-vs-utvalgsstørrelse-fellen-22 som forårsaket at den nesten identiske BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (samme handelssted, samme lookback_days=49) ble forlatt på Lag 4 dager siden. Utviklerens egen begrunnelse anerkjenner taket ('lookback_days er 49 (7 sykluser, 14 opsjonsben) fordi per-bar-type katalog-lasteren koster ~10s per ben og en større kjede risikerer Lag-3-veggklokken'). Som konfigurert kan strategien aldri produsere en målbar full tilbaketest. — fiks: Ikke send videre på ~7 sykluser. Løs laster-kost-vs-utvalgsstørrelse-fellen-22 før du sender inn på nytt: batch/parallelliser eller bufre per-ben katalog.bars()-lastingene på tvers av barer slik at lookback_days kan nå mange år med ukentlige sykluser (~200-300 sykluser) uten å overskride sandkasse-veggklokken, og sett deretter lookback_days til å dekke hele testvinduet. Hvis lasteren virkelig ikke kan løse en målbar ukentlig opsjonshistorie innen tidsbudsjettet, er denne familien ikke testbar i den nåværende rammen ved ukentlig kadens og bør redesignes (f.eks. færre, lengre daterte månedlige sykluser over hele spennet) snarere

Verifisering mislyktes (lag 2 — syntetiske scenarioer): Brukte parametere: ['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'] Kontroller at __init__ setter alle attributter fra self.parameters.get(). - steady_uptrend: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000)

Verifisering mislyktes (lag 2 — syntetiske scenarioer): Brukte parametere: ['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'] Kontroller at __init__ setter alle attributter fra self.parameters.get(). - steady_uptrend: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() tar 1 posisjonsargument, men fikk 2 (bartidsstempel: 1735691040000)

Verifisering mislyktes (lag 4 — QA-gjennomgang) [klasse=hypothesis_mismatch]: - [edge_concern] Ikke grunnlaget for konklusjonen — blokken gjelder trofasthet, ikke ytelse. (Til orientering er sandkasseresultatet også negativt: -2.9%, PF 0.13, gevinst 0.125, en hale på -$2,149 i en angivelig stoppet bok — men dette er resultatet til feil strategi.) - WHOLE-STRATEGY SWAP / MISLINK. Hypotesen er en ETH Deribit ukentlig PUT CREDIT SPREAD (selg put med omtrent 25d, BUY put med omtrent 10d — vertikal spread med definert risiko). Koden er den BTC Deribit ukentlige delta-nøytrale SHORT STRANGLE (klassenavn, dokumentasjonsstreng, begrunnelse for iter-3 og alle mekanismene gjelder strangle). Instrument AND mekanisme er begge forskjellige → feilgenerert/feilkoblet artefakt, ikke denne hypotesen. Generer/koble til riktig ETH put-kredittspread på nytt. - Feil instrument: hypotesen er ETH, men instrument_id og bar_type er BTC-PERPETUAL.DERIBIT og rolling_options.underliggende er 'BTC'. Ingen ETH noe sted. - Feil struktur / ikke definert risiko: hypotesen begrenser maksimalt tap med en PURCHASED put-vinge på omtrent 10d. Koden sender inn TWO SELL ben uten NO kjøpt vinge; halen begrenses bare av en myk premiebasert stopp på neste bar (sandkasse largest_loss -$2,149 mot avg_win omtrent $214 viser at den ikke begrenser halen) — nettopp den ubegrensede profilen hypotesen unngår. - Kjernefordelen mangler: hypotesens signal er rikdom i nedside-SKEW (25d-put IV mot ATM IV) pluss IV>RV. Koden beregner ingen skjevhet — bare gjennomsnittlig strangle-IV/RV VRP. Innhøsting av put-skjevheten som skiller denne hypotesen fra andre, er ikke implementert.

verification_loop: Verifisering mislyktes (Lag 4 — QA gjennomgang) [klasse=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 ytelsesdom (per-notional avkastning er ikke meningsfull for opsjonsbein, der premie-notional << vingebein-notional, og sandbox er en 1-dagers røyktest). Det videreføres kun som kontekst: hvis laster-/lookback-problemet nedenfor løses og et reelt ukentlig-opsjoner-utvalg akkumuleres, bør analytikeren sjekke på nytt om netto kreditt inndrevet dekker Deribits 0.03%/side round-trip på tvers av 4 bein (åpne+lukke x kort+lang) pluss eventuell tildelingsglidning, ettersom put-kreditt-spread per-notional edge er strukturelt tynn. - [kritisk] rolling_options.lookback_days=49 begrenser den ENTIRE løsbare opsjonskjeden til ANY backtest til de ~49 dagene som slutter 'nå' = ~7 ukentlige sykluser / ~14 opsjonsbein, uavhengig av Deribits 6.5-års ETH opsjonshistorikk. Strategien ligger flat resten av vinduet og handler kun ved halen. Sandbox bekrefter dette empirisk: bars_processed=2400 (~6.5 år) men data_days=1 og total_trades=2 (trades_count=4). En varians-risiko-premium + skjevhet-edge kan ikke skilles fra støy på ~7 sykluser / ~14 bein — langt under de ~30-100 handler som trengs for et målbart opsjonsutvalg. Dette er den nøyaktige laster-kostnad-vs-utvalgsstørrelse-felle-22 som fikk den nesten identiske BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (samme venue, samme lookback_days=49) til å bli forlatt på Lag 4 dager siden. Utviklerens egen begrunnelse anerkjenner taket ('lookback_days er 49 (7 sykluser, 14 opsjonsbein) fordi per-bar-type katalog-lasteren koster ~10s per bein og en større kjede risikerer Lag-3-veggklokken'). Som konfigurert kan strategien aldri produsere en målbar full backtest. — fiks: Ikke godkjenn på ~7 sykluser. Løs laster-kostnad-vs-utvalgsstørrelse-felle-22 før innsending på nytt: batch/paralleliser eller bufre per-bein catalog.bars()-lastinger på tvers av barer slik at lookback_days kan nå mange års ukentlige sykluser (~200-300 sykluser) uten å bryte sandbox-veggklokken, sett deretter lookback_days til å dekke hele testvinduet. Hvis lasteren genuint ikke kan løse en målbar ukentlig-opsjoner-historikk innen tidsbudsjettet, er denne familien ikke testbar i det nåværende testmiljøet ved ukentlig kadens og bør redesignes (f.eks. færre, lengre-daterte månedlige sykluser på tvers av hele spennet) heller