Deribiti BTC nädalased sularahaga tagatud OTM müügistrateegia — volatiilsusriskipreemia püüdmine, IV>RV tingimusega piiratud ja trendifiltriga kvantitatiivses kauplemises

Ühe jalaga, täielikult tagatisega süsteemne PUT-WRITING strateegia Deribiti BTC nädalastel optsioonidel püüab krüpto volatiilsusriskipreemiat (VRP): BTC optsioonide kaudne volatiilsus ületab struktuurselt hiljem realiseeruvat volatiilsust, nii et kindlustuse müüja saab aja jooksul eelise. See on strateegiatehase FIRST optsioonistrateegia ja aitab täita suurimat kvoodilünka (optsioone 0.1% vs siht >= 15%), vähendades samal ajal 80% BINANCE üleesindatust. Igas tsüklis valib strateegia lähima nädalase Deribiti BTC aegumise (5-9 päeva kaugusel) ja kirjutab ONE ~20-delta OTM put’i, mille tagatis on täielikult sularahas (FULLY; võimenduseta, marginaalinõude riski pole — maksimaalne kahjum on piiratud täitmishinnaga ehk sisuliselt lepitakse kokku BTC ostmises allahindlusega). Positsiooni juhivad kaks struktuurset filtrit: (1) VRP värav — put kirjutatakse ainult siis, kui 7-päeva ATM kaudne volatiilsus (Deribiti kreeka tähtede/IV andmevoost) ületab eelneva 10-päeva realiseerunud volatiilsuse marginaaliga (IV/RV > ~1.15), nii et kindlustust müüakse vaid siis, kui selle hind on kõrge; (2) režiimi/trendi värav — kirjutamine toimub ainult siis, kui BTC hetkehind on üle oma 50-päeva SMA, vältimaks put’ide kirjutamist kinnitatud langustrendi või langeva noa suunas (put’i kirjutamise peamine sabarisk). Üks instrument tsükli kohta hoiab tagasitesti puhtal mootorirajal ja väldib mitme jala/lisajala andmevoo optimeerimise artefakti. Arendaja vahetab positsiooni igal nädalal börsil noteeritud Deribiti BTC put-instrumentide vahel (strateegia valib kataloogist igas tsüklis sobiva täitmishinna ja aegumise).

Iteratsioon 3 muudab ONE konfiguratsiooniväärtust; strateegia loogika on iteratsiooniga 2 baiditäpselt identne (diagnoosi kirjeldamiseks uuendati ainult PERF dokstringi). Mõõtsin tegeliku ajalõpu, selle asemel et uuesti oletada: liivakasti alamprotsess käivitus 22:05:22 ja peatati ajal 22:10:24 (302s); kulu tuleb NOT baari kohta tehtavast tööst — kogu baari kohta käiv olek oli juba pärast iteratsiooni 2 O(1). Põhjus on kataloogis olevate QUERIES arv. BacktestRunner teeb iga baari tüübi kohta ühe catalog.bars() väljakutse ning kui kataloogis data/catalog on 35,765 baariandmete kataloogi, maksab iga väljakutse FIXED ~8.4s sõltumata andmemahust (mõõdetud selles arvutis: BTC-PERPETUAL 1-DAY, 365 baari -> 8.31s; BTC-10APR26-63000-P, 19 baari -> 8.27s; BTC-17APR26-68000-P, 24 baari -> 8.77s). 365-päevane nädalane optsiooniahel sisaldab 52 optsioonilepingut (käivituslogi kinnitab: 'Deribit chain discovered contracts=52'), seega kulus ainult andmete laadimisele 53 * 8.4s ~= 445s — just seepärast ei muutnud iteratsiooni 2 vahetus 1-HOUR -> 1-DAY (24x baari vähem) midagi. Lahendus: lookback_days 365 -> 150, nii et nädalas on ~21 optsioonilepingut; laadimine võtab seega ~22 * 8.4s ~= 185s ning kogu käivitus kestab ligikaudu 230s, jäädes 300s piirist selgelt allapoole. Enne esitamist katsetasin lühema perioodi pärisandmetel ka FULL liitväravat (liitvärava õppetunni järgi): viimase 150 päeva jooksul on VRP värav avatud 97/150 päeval, trendivärav 70/150, BOTH 51 päeval, mis hõlmavad 11 23 kalendrinädalast — seega kirjutab ahel ligikaudu 8-11 müügioptsiooni, ületades kindlalt Layer-3 värava nõude >=1 tehingut. Lühema ahela tõttu kaotatud valimi osaliseks taastamiseks laiendasin entry_window_hours 96 -> 120 (endiselt baasi sisenemisest aegumiseni kestva -24h akna piires), et tsükli keskel avanevate väravatega nädalal saaks endiselt müügioptsiooni kirjutada. Analüütikule märkimist vajav kompromiss: tegelik tagasitest hõlmab nüüd ligikaudu 5 kuud / 10 tehingut, mitte aastat — valim on väike, kuid liivakasti piirang sunnib seda, arvestades kataloogipäringu kulu ~8.4s ühe optsioonilepingu kohta; arvutus on dokstringis kirjas (30 päringut on ülempiir), nii et akent saab uuesti laiendada, kui kataloogipäringute kulu kunagi lähtekoodis parandatakse.

Kontroll ebaõnnestus (kiht 4 — QA ülevaatus) [klass=not_measurable]: - [edge_concern] Liivakasti laitmatud näitajad (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) on BENIGN-WINDOW ARTIFACT — kogu tagatisega put’i kirjutamise risk on krahhide saba, kuid selles ~5-kuulises perioodis seda ei esinenud, nii et kõik put’id võitsid. Iga put’i kirjutamise strateegia näib riskivaba, kuni saabub langus tipust. avg_trade_return_pct 91.4% on preemiaga suhteline (mitte täitmisnominaali põhjal ega võrreldav hetkehinna/forward-tehingute alampiiridega) ja total_commission 0.0 16 Deribiti optsioonitehingu kohta viitab, et optsioonitasusid ei arvestata — mõlemad muudavad niigi väheinformatiivse tulemuse veel soodsamaks. - Praeguse seadistusega pole tulemus mõõdetav. rolling_options.lookback_days on lukustatud väärtusele 150 (arendaja parandus kataloogipäringu jala kohta ~8.4s kestva ajalimiidi ületamise jaoks), piirates kaubeldava ahela ~5 kuuga ja andes ainult 16 iganädalast positsiooni. Piirang on konfiguratsiooni sisse kodeeritud, seega on ka kogu tagatest samamoodi piiratud (~16 tehingut, alla optsioonide ~30 tehingu alampiiri, L26). 16 sabariskita positsiooni kirjutamine ei võimalda hinnata VRP put’i kirjutamise strateegiat, mille eelise ja riski määravad krahhidega seotud langused tipust — periood peab hõlmama aastaid, et vasaku saba sündmusi tabada. DVOL + Deribiti ahela andmed on olemas; takistuseks on ülesvoolu kulu kataloogipäringule iga jala kohta. Peata töö, kuni see kulu parandatakse, et mitmeaastane ahel (>= 2yr, ~50-100 väravat läbinud positsiooni mitme languse ajal) mahuks eelarvesse; ära lihtsalt pikenda lookback_days (see toob ajalimiidi ületamise tagasi). - total_commission 0.0 16 Deribiti optsioonitehingu kohta — Deribit võtab optsioonitasu (min 0.03% alusvara või 12.5% preemiast, lisaks arveldustasu). Kui mootor optsioonitasusid ei rakenda, on preemia püüdmise kasum ja kahjum üle hinnatud. Mootori tasude rakendamise mure analüütikule/tagatesti insenerile, mitte strateegiakoodi viga.

Kontroll ebaõnnestus (kiht 4 — QA ülevaatus): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — optsioonide aegumise sagedus x väravapõhine piirang). Liivakast tekitas 12 tehingut perioodil data_days=12; tulemused näitavad klassikalist mõõtmatut ja moonutatud mustrit: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (tagatisega put’i kirjutamise kohta võimatu tehingupõhine näitaja — optsiooni nominaali/tulu arvutus pole usaldusväärne). Need ei ole tegelikud tootlussignaalid. L26 järgi (aken/aegumine x värava läbimine): lookback_days vähendati 365->150, et mahtuda 300s piirangu sisse, ning liitvärav VRP+trend avaneb vaid ligikaudu 11 nädalast 23 -> ~8-11 put’i. ~10 tehingut jääb tunduvalt alla ~30-tehingulisele alampiirile ega võimalda eristada VRP eelist mürast. - INFRASTRUCTURE HARD-CAP muudab valimi ANY parameetristuse korral mõõtmatuks. Arendaja enda dokstringi järgi maksab iga catalog.bars() päring fikseeritult ~8.4s ja käitus on piiratud ~30 päringuga (~250s) 300s ajalimiidi piires, mistõttu tagasitest hõlmab AT MOST ~30 nädalast jalga (~7 kuud) -> pärast väravapõhist piirangut ~15 tehingut. lookback_days=150 tuli ajalimiidi ületamise vältimiseks peale suruda. Lävendite häälestamine ei ületa kataloogipäringute ~30 jala ülempiiri. - PUT-WRITE TAIL-RISK MASKING. ~10-tehinguline win_rate 1.0 valim on lühikese put’i puhul kõige MOST eksitavam tulemus: see tähendab, et perioodis polnud ühtegi krahhinädalat — just siis realiseerub tagatisega put’i kirjutamise suur vasakpoolse saba kahjum. Meelitav liivakastitulemus (kõik tehingud võiduga, null langust tipust, Sharpe 31) näitab Theta kahanemist rahulikel nädalatel ja varjab ainsat olulist riski. - Kood on CORRECT ja rakendab hüpoteesi täpselt: put’i kirjutamise suund (P -> SELL), sularahaga tagatud, täitmishinnaga piiratud positsiooni suurus, VRP värav (atm_iv >= rv*vrp_ratio), trendivärav (hind > SMA), põhjuslik DVOL otsing (searchsorted right-1, tulevikku vaatamist pole), jalad suletakse 24h enne Euroopa arveldust, dokumenteeritud väravapiiranguta jätkukäitumine, kui IV puudub (eelist ei vahetata vaikselt). Optsioonide korrektsuse kontroll (# 12) läbitud. Märgitud, et arendaja ei hakkaks otsima olematut koodiviga.