Deribit BTC wöchentliche, cash-besicherte OTM-Put-Verkaufsstrategie – Abschöpfen der Volatilitätsrisikoprämie, durch IV>RV freigegeben und trendgefiltert

Eine systematische, cashbesicherte PUT-WRITING-Strategie mit einem Leg für wöchentliche Deribit-BTC-Optionen, die die Krypto-Volatilitätsrisikoprämie (VRP) abschöpft: Die implizite Volatilität von BTC-Optionen liegt strukturell über der später realisierten Volatilität, sodass Verkäufer von Versicherung langfristig einen Vorteil erhalten. Dies ist die FIRST Optionsstrategie der Fabrik und schließt die größte Quotenlücke (Optionen 0.1% gegenüber dem Ziel von >=15%), während sie zugleich die Überrepräsentation von 80% BINANCE verringert. In jedem Zyklus wählt die Strategie den nächstliegenden wöchentlichen Verfall von Deribit-BTC (5-9 Tage entfernt) und schreibt ONE OTM-Put mit etwa 20 Delta, vollständig durch Bargeld besichert (FULLY; kein Hebel, kein Nachschussrisiko — der maximale Verlust ist durch den Ausübungspreis begrenzt, also entspricht dies der Vereinbarung, BTC mit Abschlag zu kaufen). Die Position unterliegt zwei strukturellen Filtern: (1) einem VRP-Gate — geschrieben wird nur, wenn die implizite Volatilität von ATM über 7 Tagen (aus dem Deribit-Greeks/IV-Feed) die realisierte Volatilität der vergangenen 10 Tage um einen bestimmten Abstand übersteigt (IV/RV > ~1.15); Versicherungen werden also nur verkauft, wenn sie hoch bewertet sind; (2) einem Regime-/Trend-Gate — geschrieben wird nur, wenn der Kassakurs von BTC über seinem 50-Tage-SMA liegt, um Puts in einem bestätigten Abwärtstrend oder in einen freien Fall hinein zu vermeiden (das zentrale Extremrisiko beim Put-Write). Ein Instrument pro Zyklus hält den Backtest auf dem sauberen Engine-Pfad und vermeidet Optimierungsartefakte durch mehrere Legs oder zusätzliche Leg-Feeds. Der Entwickler rollt wöchentlich über gelistete Deribit-BTC-Put-Instrumente (die Strategie wählt in jedem Zyklus den passenden Ausübungspreis und Verfall aus dem Katalog).

Iteration 3 ändert den Konfigurationswert ONE; die Strategielogik ist byte-identisch mit Iteration 2 (nur der Docstring PERF wurde aktualisiert, um die Diagnose festzuhalten). Ich habe den tatsächlichen Timeout gemessen, statt erneut zu raten: Der Sandbox-Subprozess wurde mit 22:05:22 gestartet und bei 22:10:24 (302s) beendet. Ursache ist die Arbeit pro Balken NOT — der Zustand pro Balken war nach Iteration 2 bereits O(1). Entscheidend ist die Anzahl der Katalog-QUERIES. BacktestRunner ruft catalog.bars() einmal pro Balkentyp auf, und bei 35,765 Balkenverzeichnissen in data/catalog dauert jeder Aufruf unabhängig von der Nutzlast etwa FIXED ~8.4s (Messung auf diesem Rechner: BTC-PERPETUAL 1-DAY, 365 Balken -> 8.31s; BTC-10APR26-63000-P, 19 Balken -> 8.27s; BTC-17APR26-68000-P, 24 Balken -> 8.77s). Die wöchentliche Kette über 365 Tage umfasst 52 Legs (im Laufprotokoll bestätigt: 'Deribit chain discovered contracts=52'), sodass allein das Laden der Daten 53 * 8.4s ~= 445s dauerte. Genau deshalb änderte der Wechsel von Iteration 2, 1-HOUR -> 1-DAY (24x weniger Balken), nichts. Lösung: lookback_days 365 -> 150, was etwa 21 wöchentliche Legs ergibt. Das Laden dauert damit etwa 22 * 8.4s ~= 185s, und der gesamte Lauf etwa 230s, mit ausreichend Spielraum unter dem Limit von 300s. Vor der Einreichung habe ich außerdem das kombinierte Gate FULL auf echten Daten über das verkürzte Zeitfenster probeweise ausgeführt (gemäß der Lektion zum kombinierten Gate): In den letzten 150 Tagen ist das VRP-Gate an 97/150 Tagen offen, das Trend-Gate an 70/150; BOTH an 51 Tagen, verteilt auf 11 von 23 Kalenderwochen. Die Kette wird also ungefähr 8-11 Puts schreiben und damit die Layer-3-Schwelle von >=1 Trades bequem überschreiten. Um einen Teil der durch die kürzere Kette verlorenen Stichprobe zurückzugewinnen, habe ich entry_window_hours 96 -> 120 erweitert (weiterhin innerhalb des Basisfensters entry..expiry-24h), sodass auch in einer Woche geschrieben wird, wenn die Gates mitten im Zyklus öffnen. Für den Analysten ist folgender Kompromiss festzuhalten: Der echte Backtest umfasst nun etwa 5 Monate / 10 Trades statt eines Jahres — das ist eine dünne Stichprobe, aber wegen des Sandbox-Limits angesichts der Katalogkosten von etwa 8.4s pro Leg erforderlich. Die Berechnung ist im Docstring dokumentiert (etwa 30 Abfragen sind das Maximum), sodass das Zeitfenster wieder erweitert werden kann, falls die Kosten der Katalogabfrage upstream behoben werden.

Verifizierung fehlgeschlagen (Layer 4 — Prüfung QA) [Klasse=not_measurable]: - [edge_concern] Die makellosen Kennzahlen der Sandbox (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) sind ein BENIGN-WINDOW ARTIFACT — das gesamte Risiko beim cashbesicherten Put-Write liegt im Crash-Schwanz, und dieses Zeitfenster von etwa 5 Monaten erfasste keinen solchen Fall; daher gewann jeder Put. Jeder Put-Write sieht kostenlos aus, bis ein Drawdown eintritt. avg_trade_return_pct 91.4% bezieht sich relativ auf die Prämie (nicht auf das Nominal des Ausübungspreises und nicht vergleichbar mit Mindestwerten für Kassakurs/Futures), und total_commission 0.0 bei 16 Deribit-Optionsgeschäften deutet darauf hin, dass Optionsgebühren nicht angewendet werden — beides lässt ein nicht aussagekräftiges Ergebnis zusätzlich vorteilhaft erscheinen. - Mit dieser Konfiguration nicht messbar. rolling_options.lookback_days ist auf 150 festgesetzt (die Lösung des Entwicklers für den Timeout der Katalogabfrage von etwa 8.4s pro Leg), wodurch die handelbare Kette auf etwa 5 Monate begrenzt ist und nur 16 wöchentliche Schreibvorgänge liefert. Diese Begrenzung ist in der Konfiguration festgelegt, daher ist auch der vollständige Backtest gleich stark begrenzt (etwa 16 Trades, unterhalb der Options-Mindestzahl von etwa 30, L26). 16 Schreibvorgänge ohne Extremereignisse können keinen VRP-Put-Write bewerten, dessen Vorteil und Risiko durch Crash-Drawdowns bestimmt werden — das Zeitfenster muss Jahre umfassen, um echte Ereignisse im linken Verteilungsschwanz zu erfassen. DVOL und Deribit-Kettendaten sind vorhanden; das Hindernis sind die vorgelagerten Kosten der Katalogabfrage pro Leg. Warten, bis diese Kosten behoben sind, damit eine mehrjährige Kette (>=2 Jahr, etwa 50-100 gefilterte Schreibvorgänge über mehrere Drawdowns) innerhalb des Budgets ausgeführt werden kann; lookback_days nicht einfach verlängern (dadurch tritt der Timeout erneut auf). - total_commission 0.0 bei 16 Deribit-Optionsgeschäften — Deribit erhebt Optionsgebühren (mindestens 0.03% des Basiswerts oder 12.5% der Prämie sowie Abrechnungskosten). Falls die Engine Optionskommissionen nicht anwendet, ist der Gewinn aus dem Prämienverkauf überhöht. Die Sorge betrifft die Gebührenanwendung der Engine und ist für den Analysten oder Backtest-Ingenieur relevant, kein Fehler im Strategiecode.

Verifizierung fehlgeschlagen (Layer 4 — Prüfung QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — Optionsverfall-Taktung x Gate-Filterung). Die Sandbox erzeugte 12 Trades über data_days=12 mit dem klassischen, nicht messbaren degenerierten Muster: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (eine unmögliche Kennzahl pro Trade für einen cashbesicherten Put-Write — die Berechnung von Optionsnominalwert/Rendite ist nicht vertrauenswürdig). Dies sind keine tatsächlichen Performance-Signale. Gemäß L26 (Zeitfenster/Verfall x Gate-Pass): lookback_days wurde von 365 auf 150 verkürzt, um das Limit von 300s einzuhalten, und das kombinierte VRP+Trend-Gate öffnet sich nur in etwa 11 von 23 Wochen -> etwa 8-11 Puts. Etwa 10 Trades liegen weit unter der Mindestzahl von etwa 30 Trades und können einen VRP-Vorteil nicht von Zufall unterscheiden. - INFRASTRUCTURE HARD-CAP macht die Stichprobe bei der Parametrisierung ANY nicht messbar. Laut eigenem Docstring des Entwicklers kostet jede catalog.bars()-Abfrage pauschal etwa 8.4s. Der Lauf ist unter dem Timeout von 300s auf etwa 30 Abfragen (~250s) begrenzt; der Backtest umfasst daher AT MOST ~30 wöchentliche Legs (~7 Monate) -> nach der Gate-Filterung etwa 15 Trades. lookback_days=150 war nötig, um den Timeout einzuhalten. Keine Schwellenwertanpassung überwindet die Obergrenze von etwa 30 Legs durch Katalogabfragen. - PUT-WRITE TAIL-RISK MASKING. Eine Stichprobe mit etwa 10 Trades über win_rate 1.0 ist das MOST irreführende Ergebnis für einen Short-Put: Es bedeutet, dass das Zeitfenster keine Crash-Woche enthielt, genau dann, wenn ein cashbesicherter Put seinen hohen Verlust im linken Verteilungsschwanz realisiert. Die schmeichelhafte Sandbox (nur Gewinne, kein Drawdown, Sharpe 31) zeigt den Theta-Verfall in ruhigen Wochen und verbirgt das einzige entscheidende Risiko. - Der Code ist CORRECT und setzt die Hypothese korrekt um: Put-Write-Richtung (P -> SELL), cashbesicherte, durch den Ausübungspreis begrenzte Positionsgröße, VRP-Gate (atm_iv >= rv*vrp_ratio), Trend-Gate (Kassakurs > SMA), kausale DVOL-Suche (searchsorted right-1, kein Look-ahead), Legs werden 24h vor der europäischen Abrechnung geschlossen, dokumentierter ungefilterter Rückgriff, wenn IV fehlt (kein stiller Austausch des Vorteils). Die Optionskorrektheit (# 12) ist gegeben. Festgehalten, damit der Entwickler keinem Phantom-Programmierfehler nachgeht.