Deribit BTC tedenska prodaja prodajnih opcij OTM, zavarovana z gotovino — izkoriščanje premije za tveganje volatilnosti, s pogojem IV>RV in trendnim filtrom

Hipoteza

Sistematična strategija PUT-WRITING na tedenskih opcijah BTC Deribita, z eno nogo in v celoti zavarovana z denarjem, ki izkorišča premijo za tveganje kriptovalutne volatilnosti (VRP): implicitna volatilnost opcij BTC je strukturno višja od pozneje realizirane volatilnosti, zato prodajalec zavarovanja skozi čas prejema prednost. To je FIRST opcijska trgovalna strategija tovarne in zapolnjuje največjo vrzel v kvoti (opcije 0.1% proti cilju >=15%), hkrati pa zmanjšuje preveliko zastopanost 80% BINANCE. V vsakem……Prikaži večPrikaži manj

Sistematična strategija PUT-WRITING na tedenskih opcijah BTC Deribita, z eno nogo in v celoti zavarovana z denarjem, ki izkorišča premijo za tveganje kriptovalutne volatilnosti (VRP): implicitna volatilnost opcij BTC je strukturno višja od pozneje realizirane volatilnosti, zato prodajalec zavarovanja skozi čas prejema prednost. To je FIRST opcijska trgovalna strategija tovarne in zapolnjuje največjo vrzel v kvoti (opcije 0.1% proti cilju >=15%), hkrati pa zmanjšuje preveliko zastopanost 80% BINANCE. V vsakem ciklu strategija izbere najbližji tedenski iztek Deribita BTC (5-9 dni do izteka) in zapiše prodajo ONE prodajne opcije z delto približno 20 OTM, v celoti zavarovane z denarjem (FULLY; brez finančnega vzvoda in tveganja poziva h kritju — največja izguba je omejena z izvršilno ceno, kar je enakovredno dogovoru o nakupu BTC s popustom). Pozicijo določata dva strukturna filtra: (1) pogoj VRP — prodajna opcija se zapiše le, ko 7-dnevna implicitna volatilnost ATM (iz vira Deribit greeks/IV) presega drsečo 10-dnevno realizirano volatilnost za določeno razliko (IV/RV > ~1.15); zavarovanje torej prodajamo le, ko je bogato ovrednoteno; (2) režimski/trendni pogoj — prodajna opcija se zapiše le, ko je promptna cena BTC nad svojim 50-dnevnim SMA, da se izognemo prodaji opcij ob potrjenem padajočem trendu oziroma lovljenju padajočega noža (prevladujoče repno tveganje pisanja prodajnih opcij). En instrument na cikel ohranja backtest na čisti poti izvajanja in preprečuje artefakt optimizacije z več nogami oziroma dodatnim virom podatkov za noge. Razvijalec tedensko podaljšuje pozicije prek trgovanih instrumentov prodajnih opcij BTC Deribita (strategija v vsakem ciklu izbere ustrezno izvršilno ceno in iztek iz kataloga).

Iteracija 3 spremeni konfiguracijsko vrednost ONE; logika strategije je bajtno enaka kot pri iteraciji 2 (posodobljen je samo docstring PERF, da zabeleži diagnozo). Namesto ponovnega ugibanja sem profiliral dejanski časovni limit: podproces v peskovniku je zagnal 22:05:22 in bil ustavljen pri 22:10:24 (302s), strošek pa je delo NOT na posamezno svečko — vse stanje za posamezno svečko je bilo že O(1) po iteraciji 2. Gre za število katalogskih QUERIES. BacktestRunner za vsak tip svečke izvede en klic……Prikaži večPrikaži manj

Iteracija 3 spremeni konfiguracijsko vrednost ONE; logika strategije je bajtno enaka kot pri iteraciji 2 (posodobljen je samo docstring PERF, da zabeleži diagnozo). Namesto ponovnega ugibanja sem profiliral dejanski časovni limit: podproces v peskovniku je zagnal 22:05:22 in bil ustavljen pri 22:10:24 (302s), strošek pa je delo NOT na posamezno svečko — vse stanje za posamezno svečko je bilo že O(1) po iteraciji 2. Gre za število katalogskih QUERIES. BacktestRunner za vsak tip svečke izvede en klic catalog.bars(), vsak klic pa ob prisotnosti 35,765 imenikov s svečkami v data/catalog stane FIXED ~8.4s ne glede na količino podatkov (izmerjeno na tem računalniku: BTC-PERPETUAL 1-DAY, 365 svečk -> 8.31s; BTC-10APR26-63000-P, 19 svečk -> 8.27s; BTC-17APR26-68000-P, 24 svečk -> 8.77s). Tedenska veriga za 365 dni se razširi na 52 nog (potrjeno v dnevniku izvajanja: 'Deribit chain discovered contracts=52'), zato je samo nalaganje podatkov trajalo 53 * 8.4s ~= 445s — prav zato prehod v iteraciji 2 z 1-HOUR na 1-DAY (24x manj svečk) ni ničesar spremenil. Rešitev: lookback_days 365 -> 150, kar pomeni ~21 tedenskih nog; nalaganje tako traja ~22 * 8.4s ~= 185s, celotno izvajanje pa približno ~230s, z dovolj rezerve pod omejitvijo 300s. Pred oddajo sem na resničnih podatkih in skrajšanem obdobju izvedel tudi poskusni zagon sestavljenega pogoja FULL (v skladu s spoznanjem o sestavljenem pogoju): v zadnjih 150 dneh je pogoj VRP odprt 97/150 dni, trendni pogoj pa 70/150; BOTH v obdobju 51 dni, ki zajema 11 od 23 koledarskih tednov — veriga bo torej zapisala približno 8-11 put opcij, kar zanesljivo presega prag >=1 poslov za Layer-3. Da bi delno nadomestil vzorec, izgubljen zaradi krajše verige, sem razširil entry_window_hours 96 -> 120 (še vedno znotraj osnovnega okna vstop..zapadlost-24h), zato se bo zapisala tudi pozicija v tednu, ko se pogoji odprejo sredi cikla. Analitik naj upošteva kompromis: dejanski backtest zdaj zajema ~5 mesecev / ~10 poslov namesto celega leta — vzorec je majhen, vendar ga zaradi stroška ~8.4s na katalogsko nogo vsiljuje omejitev peskovnika; izračun je dokumentiran v docstringu (zgornja meja je ~30 poizvedb), zato je mogoče obdobje znova razširiti, če se strošek kataloških poizvedb kdaj odpravi v nadrejenem sistemu.

verifying_stuck_3_timeouts

Implementacija

Tedensko pisanje zavarovane prodajne opcije OTM na opcije BTC Deribita (ena noga, ~6% OTM, ~7 DTE), s tedenskim podaljšanjem in zaprtjem 24h pred iztekom. Prodajna opcija se zapiše le, ko sta odprta oba strukturna pogoja: pogoj VRP (implicitna volatilnost Deribita DVOL >= drseča 10-dnevna realizirana volatilnost 1.15x) in trendni pogoj (promptna cena nad svojim 50-dnevnim SMA). Velikost pozicije je zavarovana z denarjem in sorazmerna kapitalu (0.85 kapitala, deljeno s promptno ceno, zaokroženo navzdol na 0.1 pogodbo); finančni vzvod je 1.0, zato je največja izguba omejena z izvršilno ceno. Perpetualna pogodba Deribita je primarni instrument zgolj kot ura za tedensko podaljšanje; osnovni instrument se nikoli ne trguje.

Rezultati preverjanja

Preverjanje ni uspelo (Layer 4 — pregled QA) [class=not_measurable]: - [edge_concern] Brezhibni kazalniki peskovnika (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) so BENIGN-WINDOW ARTIFACT — celotno tveganje prodaje prodajnih opcij, zavarovanih z gotovino, je zlom na levem repu; to približno 5-mesečno obdobje ga ni zajelo, zato je bila vsaka prodajna opcija dobičkonosna. Vsaka prodaja prodajne opcije je videti brezplačna, dokler ne nastopi padec.……Prikaži večPrikaži manj

Preverjanje ni uspelo (Layer 4 — pregled QA) [class=not_measurable]: - [edge_concern] Brezhibni kazalniki peskovnika (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) so BENIGN-WINDOW ARTIFACT — celotno tveganje prodaje prodajnih opcij, zavarovanih z gotovino, je zlom na levem repu; to približno 5-mesečno obdobje ga ni zajelo, zato je bila vsaka prodajna opcija dobičkonosna. Vsaka prodaja prodajne opcije je videti brezplačna, dokler ne nastopi padec. avg_trade_return_pct 91.4% se meri glede na premijo (ne glede na nominalno vrednost izvršilne cene in ni primerljiv s pragovi za promptne cene/terminske pogodbe), total_commission 0.0 pri 16 poslih z opcijami Deribit pa nakazuje, da provizije za opcije niso obračunane — oboje še dodatno polepša neinformativni rezultat. - Pri trenutni konfiguraciji rezultatov ni mogoče meriti. rolling_options.lookback_days je omejen na 150 (razvijalčev popravek za časovno omejitev kataloške poizvedbe ~8.4s na posel), kar skrajša verigo trgovalnih pogodb na približno 5 mesecev in prinese samo 16 tedenskih prodaj. Ta omejitev je vgrajena v konfiguracijo, zato je tudi celoten preizkus za nazaj enako omejen (~16 poslov, pod pragom za opcije ~30, L26). 16 prodaj brez dogodkov v levem repu ne more ovrednotiti prodaje prodajnih opcij VRP, katere prednost/tveganje določajo padci ob zlomu — obdobje mora zajemati več let, da zajame resnične dogodke v levem repu. DVOL + podatki o verigi Deribit obstajajo; ovira je strošek kataloške poizvedbe na posel v nadrejenem sistemu. Počakajte, da se ta strošek odpravi, in šele nato izvedite večletno verigo (>=2yr, ~50-100 prodanih opcij po uporabi pogojev skozi več padcev); ne podaljšujte zgolj lookback_days (s tem se znova pojavi časovna omejitev). - total_commission 0.0 pri 16 poslih z opcijami Deribit — Deribit zaračunava provizije za opcije (najmanj 0.03% osnovnega sredstva ali 12.5% premije, poleg poravnave). Če pogon ne obračunava provizij za opcije, je dobiček iz pobiranja premije precenjen. To je pomislek glede obračunavanja provizij v pogonu za analitika/inženirja za preizkuse za nazaj, ne napaka v kodi strategije.

Zgodovina iteracij

Preverjanje ni uspelo (Layer 3 — preizkus za nazaj v peskovniku): preizkusni zagon je presegel časovno omejitev 300s. To skoraj vedno pomeni delo na vsaki svečki, ki se povečuje z dolžino zgodovine — na primer ponovno pregledovanje celotne serije financiranja/dodatnih podatkov ali ponovno sestavljanje seznama in klic min()/sorted() znotraj calculate_signal()/on_bar() ob vsaki svečki. V __init__ vnaprej izračunajte urejena polja časovnih žigov ONCE in uporabite bisect ali predpomnite poizvedbe, indeksirane po časovnem žigu, tako da je strošek za posamezno svečko O(log n), ne O(n).

Preverjanje ni uspelo (Layer 4 — pregled QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — ritem izteka opcij x pogojevanje). Peskovnik je ustvaril 12 poslov v obdobju data_days=12 z značilnim neizmerljivim degeneriranim podpisom: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (nemogoč podatek na posamezni posel za zavarovano pisanje prodajnih opcij — izračun nominalne vrednosti donosa opcij ni zanesljiv). To niso resnični signali uspešnosti. Po L26 (obdobje/iztek x……Prikaži večPrikaži manj

Preverjanje ni uspelo (Layer 4 — pregled QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — ritem izteka opcij x pogojevanje). Peskovnik je ustvaril 12 poslov v obdobju data_days=12 z značilnim neizmerljivim degeneriranim podpisom: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (nemogoč podatek na posamezni posel za zavarovano pisanje prodajnih opcij — izračun nominalne vrednosti donosa opcij ni zanesljiv). To niso resnični signali uspešnosti. Po L26 (obdobje/iztek x prestani pogoj): lookback_days je bil skrajšan z 365 na 150, da bi ustrezal omejitvi 300s, sestavljeni pogoj VRP+trend pa se odpre v le ~11 od 23 tednov -> ~8-11 prodajnih opcij. ~10 poslov je daleč pod spodnjo mejo ~30 poslov in ne more ločiti prednosti VRP od šuma. - INFRASTRUCTURE HARD-CAP naredi vzorec neizmerljiv pri parametrizaciji ANY. Po lastnem docstringu razvijalca vsaka poizvedba catalog.bars() stane fiksno ~8.4s, zagon pa je omejen na ~30 poizvedb (~250s) pri časovni omejitvi 300s; zato backtest zajema AT MOST ~30 tedenskih nog (~7 mesecev) -> ~15 poslov po uporabi pogojev. lookback_days=150 je bil nujen za izogib prekoračitve časa. Nobeno prilagajanje pragov ne preseže meje ~30 nog zaradi kataloških poizvedb. - PUT-WRITE TAIL-RISK MASKING. Vzorec ~10 poslov win_rate 1.0 je pri kratki prodajni opciji najbolj MOST zavajajoč izid: pomeni, da v obdobju ni bilo tedna s padcem trga, ravno takrat pa zavarovana prodajna opcija ustvari veliko izgubo v levem repu porazdelitve. Laskav rezultat peskovnika (vsi posli dobičkonosni, ničelni drawdown, Sharpe 31) je posledica časovnega razkroja vrednosti v mirnih tednih in prikriva edino pomembno tveganje. - Koda je CORRECT in zvesto izvaja hipotezo: usmerjenost pisanja prodajne opcije (P -> SELL), velikost zavarovana z denarjem in omejena z izvršilno ceno, pogoj VRP (atm_iv >= rv*vrp_ratio), trendni pogoj (promptna cena > SMA), vzročno iskanje DVOL (searchsorted right-1, brez vpogleda v prihodnje podatke), zapiranje nog 24h pred evropsko poravnavo, dokumentiran padec na nefiltrirano delovanje, kadar IV manjka (brez tihe zamenjave prednosti). Preverjanje pravilnosti opcij (#12) je uspešno. Zabeleženo, da razvijalec ne bi iskal neobstoječe napake v kodi.