Deribit BTC wekelijkse cash-secured OTM-putwrite — oogsten van volatiliteitsrisicopremie, IV>RV-gate, trendfilter

Een systematische, single-leg PUT-WRITING-strategie met volledige cashdekking op Deribit BTC-weekopties, die de cryptovolatiliteitsrisicopremie (VRP) benut: de impliciete volatiliteit van BTC-opties ligt structureel hoger dan de achteraf gerealiseerde volatiliteit, waardoor de verzekeringsverkoper op termijn een voordeel ontvangt. Dit is de FIRST-optiestrategie van de strategy factory en vult het grootste quotatekort aan (opties 0.1% tegenover een doel van >=15%), terwijl tegelijk de oververtegenwoordiging van 80% BINANCE wordt verminderd. Elke cyclus kiest de strategie de eerstvolgende wekelijkse Deribit-expiratie van BTC (5-9 dagen verder) en schrijft ONE ~20-delta OTM-put, FULLY gedekt met cash (geen hefboom, geen risico op een margin call — het maximale verlies is begrensd door de uitoefenprijs, vergelijkbaar met afspreken BTC met korting te kopen). De positie wordt begrensd door twee structurele filters: (1) een VRP-filter — alleen schrijven wanneer de impliciete volatiliteit van 7 dagen (ATM, via de Deribit-greeks/IV-feed) de trailing gerealiseerde volatiliteit over 10 dagen met een marge overstijgt (IV/RV > ~1.15), zodat we alleen verzekering verkopen wanneer die hoog geprijsd is; (2) een regime-/trendfilter — alleen schrijven wanneer de spotprijs van BTC boven het 50-daags SMA ligt, om puts schrijven in een bevestigde neerwaartse trend of bij een vallend mes te vermijden (het voornaamste staart risico van put-writing). Eén instrument per cyclus houdt de backtest op het schone engine-pad en voorkomt het optimalisatieartefact van meerdere legs of een extra leg-feed. De ontwikkelaar rolt wekelijks door de genoteerde Deribit BTC-putinstrumenten (de strategie kiest per cyclus de passende uitoefenprijs en expiratie uit de catalogus).

Iteratie 3 wijzigt de configuratiewaarde ONE; de strategielogica is byte-identiek aan die van iteratie 2 (alleen de PERF-docstring is bijgewerkt om de diagnose vast te leggen). Ik heb de daadwerkelijke time-out geprofileerd in plaats van opnieuw te gokken: het sandbox-subproces startte 22:05:22 en werd beëindigd na 22:10:24 (302s); de kosten komen door NOT werk per bar — alle status per bar was na iteratie 2 al O(1). Het gaat om het aantal catalogus-QUERIES. BacktestRunner doet één aanroep van catalog.bars() per bartype, en met 35,765 bardirectory's in data/catalog kost elke aanroep een vaste FIXED ~8.4s, ongeacht de payload (gemeten op deze machine: BTC-PERPETUAL 1-DAY, 365 bars -> 8.31s; BTC-10APR26-63000-P, 19 bars -> 8.27s; BTC-17APR26-68000-P, 24 bars -> 8.77s). De wekelijkse keten van 365 dagen breidt uit naar 52 legs (bevestigd in het uitvoeringslog: 'Deribit chain discovered contracts=52'), dus alleen al het laden van data kostte 53 * 8.4s ~= 445s — precies waarom de wijziging van 1-HOUR -> 1-DAY in iteratie 2 (24x minder bars) niets veranderde. Oplossing: lookback_days 365 -> 150, wat ongeveer 21 wekelijkse legs oplevert; laden kost dan ~22 * 8.4s ~= 185s en de hele run komt uit op ongeveer 230s, met voldoende ruimte onder de limiet van 300s. Voor inzending heb ik de samengestelde FULL-gate ook droog getest op echte data binnen het verkorte venster (volgens de les over de samengestelde gate): in de afgelopen 150 dagen staat de VRP-gate open op 97/150 dagen, de trendgate op 70/150, BOTH op 51 dagen verspreid over 11 van de 23 kalenderweken — dus de keten schrijft ongeveer 8-11 puts, ruim boven de gate van >=1 trades voor Layer-3. Om een deel van de steekproef terug te winnen die door de kortere keten verloren ging, heb ik entry_window_hours verbreed van 96 -> 120 (nog steeds binnen het entry..expiry-24h-venster van de basis), zodat een week waarin de gates halverwege de cyclus opengaan alsnog een put krijgt. Aandachtspunt voor de analist: de daadwerkelijke backtest bestrijkt nu ongeveer 5 maanden / ~10 trades in plaats van een jaar — dat is weinig, maar de sandboxlimiet dwingt dit af gezien de cataloguskosten van ~8.4s per leg. De berekening staat in de docstring (~30 queries is het maximum), zodat het venster weer kan worden verruimd als de kosten van catalogusqueries upstream worden opgelost.

Verificatie mislukt (laag 4 — beoordeling QA) [klasse=not_measurable]: - [edge_concern] De foutloze metrics van de sandbox (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) zijn een BENIGN-WINDOW ARTIFACT — het volledige risico van cashgedekt puts schrijven zit in de crashstaart, en deze periode van ~5 maanden bevatte die niet, dus elke put won. Elke put-write lijkt gratis totdat een drawdown optreedt. avg_trade_return_pct 91.4% is relatief aan de premie (niet aan de nominale waarde van de strike en niet vergelijkbaar met spot- of futuresbodems), en total_commission 0.0 bij 16 Deribit-optietransacties suggereert dat optiekosten niet worden toegepast — beide maken een niet-informatief resultaat nog gunstiger. - Niet meetbaar met de huidige configuratie. rolling_options.lookback_days staat vast op 150 (de oplossing van de ontwikkelaar voor de time-out van ~8.4s per leg bij catalogusopvraging), waardoor de verhandelbare optieketen beperkt blijft tot ~5 maanden en er slechts 16 wekelijkse writes zijn. Die limiet zit ingebakken in de configuratie, dus de volledige backtest heeft dezelfde limiet (~16 transacties, onder de optievloer van ~30, L26). 16 writes zonder crashstaart kunnen een VRP put-write niet beoordelen, waarvan de edge en het risico worden bepaald door crashdrawdowns — de periode moet jaren beslaan om echte gebeurtenissen in de linkerstaart te omvatten. DVOL + Deribit-ketengegevens zijn beschikbaar; de blokkade is de upstream-kost per leg voor catalogusopvraging. Zet dit in de wacht totdat die kost is opgelost, zodat een meerjarige keten (>=2jr, ~50-100 writes met gating tijdens meerdere drawdowns) binnen het budget kan draaien; verleng alleen lookback_days niet (dan keert de time-out terug). - total_commission 0.0 over 16 Deribit-optietransacties — Deribit rekent optiekosten (minimaal 0.03% van de onderliggende waarde of 12.5% van de premie, plus afwikkeling). Als de engine geen optiecommissies toepast, is de PnL uit premie-inkomsten te hoog weergegeven. Dit is een aandachtspunt rond kostenverwerking in de engine voor de analist/backtesting-engineer, geen fout in de strategiecode.

Verificatie mislukt (Layer 4 — beoordeling van QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — optie-expiratiefrequentie x gating). De sandbox leverde 12 trades op over data_days=12, met het klassieke, niet meetbare degeneratieve patroon: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (een onmogelijk cijfer per trade voor een cash-secured putwrite — de berekening van de optienotional/het rendement is onbetrouwbaar). Dit zijn geen echte prestatiesignalen. Volgens L26 (venster/expiratie x gate geslaagd): lookback_days werd ingekort van 365->150 om binnen de limiet van 300s te blijven, en de samengestelde VRP+trendgate opent slechts in ~11 van de 23 weken -> ~8-11 puts. ~10 trades ligt ver onder de ondergrens van ~30 trades en kan een VRP-voordeel niet onderscheiden van ruis. - INFRASTRUCTURE HARD-CAP maakt de steekproef niet meetbaar met parameterinstelling ANY. Volgens de eigen docstring van de ontwikkelaar kost elke catalog.bars()-query een vaste ~8.4s en is de run beperkt tot ~30 queries (~250s) binnen de time-out van 300s. De backtest bestrijkt dus AT MOST ~30 wekelijkse legs (~7 maanden) -> ~15 trades na gating. lookback_days=150 was nodig om binnen de time-out te blijven. Geen enkele drempelafstelling komt voorbij de limiet van ~30 legs voor catalogusqueries. - PUT-WRITE TAIL-RISK MASKING. Een steekproef van ~10 trades win_rate 1.0 is voor een short put de MOST misleidende uitkomst: het betekent dat het venster geen crashweek bevatte, precies wanneer een cash-secured put het grote verlies in de linkerstaart realiseert. De flatterende sandboxresultaten (alles winstgevend, geen drawdown, Sharpe 31) zijn het gevolg van theta-verval in rustige weken en verhullen het enige risico dat ertoe doet. - De code is CORRECT en implementeert de hypothese correct: putwrite-polariteit (P -> SELL), cash-secured omvang begrensd door de uitoefenprijs, VRP-gate (atm_iv >= rv*vrp_ratio), trendgate (spot > SMA), causale DVOL-lookup (searchsorted right-1, geen vooruitkijken), legs gesloten 24h voor Europese afwikkeling, gedocumenteerde ongegate terugval wanneer IV ontbreekt (geen stille vervanging van het voordeel). De controle op de juistheid van opties (#12) slaagt. Vermeld zodat de ontwikkelaar niet op zoek gaat naar een niet-bestaande programmeerfout.