Deribit BTC MONTHLY barbesicherter OTM-Put-Write — einbeinige VRP-Vereinnahmung, mit IV>RV gefiltert, vorzeitiger Gewinnmitnahme-Schluss bei 50% (3-Parameter)

Ein SINGLE-LEG-Programm zum Schreiben von vollständig barbesicherten Puts auf Deribit-BTC-MONTHLY-Optionen. Es erweitert die einzige Optionsfamilie, die jemals Layer 3 bestanden und hier Paper-Trading erreicht hat (Deribit BTC WEEKLY barbesicherter Put-Write, Sharpe 12.2), auf die monatliche Laufzeit, die ein wesentlich anderes Risikoprofil aufweist: etwa 4x der Haltedauer, deutlich geringeres Gamma nahe dem Verfall, größere Liquidität bei OTM-Ausübungspreisen und Vereinnahmung des Zeitwertverfalls über einen ganzen Monat statt einer Woche. Strikt jeweils nur ONE Bein — keine Spreads, keine Wings, keine Absicherung (L2-konform; der monatliche Bull-Put-CREDIT SPREAD, der gerade gescheitert ist, war mehrbeinig, dies ist es nicht). Es schließt die größte nutzbare Lücke bei den Handelsplätzen: Optionen stehen bei 4.3% gegenüber einer Quote von 15%, und da Hyperliquid durch L11 blockiert ist, COIN-M durch Zeitüberschreitungen bei der Datenerfassung blockiert ist, Finanzierungssignale durch L13 blockiert sind, querschnittliche Körbe durch L12 blockiert sind und Liquidationsdatenströme durch L3 blockiert sind, bilden einbeinige Deribit-Optionen das einzige unterrepräsentierte Segment mit einem bewährten Ausführungspfad und bestätigten IV/Greeks-Daten. Nur 3 abgestimmte Parameter (otm_pct, min_iv_rv_spread, iv_rank_floor).

Iteration 2 berücksichtigt das Urteil der Backtest-Prüfung: Der negative Erwartungswert ist vollständig auf einen unbegrenzten linken Rand zurückzuführen (avg_loss ~6.2x avg_win), den die wirtschaftlichen Parameter von 3 nicht beheben können. Gemäß der Anweisung des Analysten, vor jeder Parametersuche einen Ausstieg mit definiertem Risiko BEFORE hinzuzufügen, habe ich in _manage_exits eine Extremverlustbegrenzung je Position ergänzt und die bereits erfolgreichen Signal-, Filter- und Zeitplanungslogiken unangetastet gelassen (damit keine frühere Verifizierungsebene Rückschritte macht). Zwei Absicherungen: (1) ein Stop auf Basis eines Prämienmultiplikators — unter Verwendung des bestehenden _put_pnl_pct (P&L des Short-Puts als Prozentsatz der vereinnahmten Prämie); schließen, wenn pnl <= -stop_loss_premium_mult*100 (Standardwert 2.0 => Put-Markierung erreicht 3x des Einstiegs, d. h. Verlust = 2x der Prämie), wodurch der schlimmste Einzelverlust direkt auf ein kleines Vielfaches der Prämie statt auf einen nahezu vollständigen Verlust der Barbesicherung begrenzt wird; und (2) ein Ausstieg bei Durchbruch des Ausübungspreises durch den Spotkurs (schließen, wenn spot <= strike*(1+strike_breach_buffer)) als vom Optionskurs unabhängige Absicherung für das Crash-Szenario, das den Extremverlust verursacht hat. Die Implementierung war minimal und gezielt: drei Parameter in __init__ hinzugefügt, 'strike' beim Einstieg im periodischen Zustand gespeichert, 'spot' an _manage_exits übergeben und die beiden elif-Zweige nach der bestehenden Gewinnmitnahmeprüfung hinzugefügt; die Ausstiegsbuchhaltung und -protokollierung erfasst bereits beliebige Gründe, sodass 'stop_loss'/'strike_breach' in der Zusammenfassung erscheinen. Entsprechend der Rückmeldung habe ich in diesem Durchgang bewusst NOT iv_rank_floor / min_iv_rv_spread verschärft — diese sollen erst dann erneut geprüft werden, wenn die Version mit begrenztem Extremverlust erneut getestet wurde und profit_factor > 1.1 bei positivem avg_trade_return_pct zeigt. Die Konfiguration behält den bewährten 1-DAY-Perpetual als Primärinstrument und den Zeitrahmen des rollierenden 1-DAY-Beins bei (vermeidet eine übermäßige Laufzeit), mit einem Rückblick von 365 Tagen für etwa 12 monatliche Verfallstermine.

Strukturell unzureichende Daten, kein Codefehler. Die Begrenzung der Extremverluste aus Iteration 1 funktionierte (positiver Erwartungswert, DD 0.62%), aber die monatliche Deribit-BTC-Optionskette umfasst nur 12 Verfallstermine (2025-07 → 2026-06 — etwa 1 Jahr monatlicher Optionshistorie), und der doppelte Volatilitätsfilter reduzierte dies auf 5 tatsächliche Trades / 5 Tagesrenditen (Bericht: metrics_reliable=false, 'Unzuverlässig: nur 5 Tagesrenditen'). Keine Änderung seitens der Entwickler kann weitere historische monatliche Verfallstermine schaffen, und eine Lockerung der Filter kommt nur auf etwa 12 Trades — immer noch viel zu wenige für die 3-Phasen-Pipeline (Walk-Forward-Fenster enthalten jeweils 1-2 Trades; der 15-Tage-Holdout enthält etwa 0 monatliche Trades), sodass die Optimierung dem Rauschen angepasst würde. Der VRP-Put-Write-Mechanismus ist solide und wurde im Paper-Trading auf der WEEKLY-Laufzeit validiert (ALREADY, Sharpe 12.2); diese liefert aus demselben Optionsdatenfenster etwa 4x der Stichproben. Das monatliche Gegenstück lässt sich mit den verfügbaren Daten schlicht nicht validieren. Es wird empfohlen, dass der Research Lead bis zur Erfassung von mehr als 2 Jahren monatlicher Optionshistorie keine einnamigen Deribit-Optionsprogramme mit monatlicher Laufzeit erneut vorschlägt — die wöchentliche Laufzeit ist die tragfähige Umsetzung dieses Vorteils.

NOT noch nicht zur Optimierung weiterleiten — die Strategie weist einen negativen Erwartungswert auf, der vollständig auf einen unbegrenzten linken Rand zurückzuführen ist (avg_loss $1678 gegenüber avg_win $270, etwa 6.2x); die 3 abstimmbaren Parameter können das Extremverlustrisiko nicht beheben. Vor jeder Parametersuche einen Ausstieg mit definiertem Risiko BEFORE hinzufügen: (1) einen Stop je Position, der den Short-Put schließt, wenn sein Preis auf ein Vielfaches der vereinnahmten Prämie steigt (z. B. Verlust = 2x-2.5x Prämie) oder wenn der Verlust einen festen Prozentsatz des Sicherheitenbudgets übersteigt, damit ein einzelner monatlicher Crash nicht mehr zu einem nahezu vollständigen Verlust führen kann; außerdem (2) erwägen, den Ausübungspreis nach unten zu rollen bzw. bei Durchbruch des Ausübungspreises durch den Spotkurs zu schließen, statt bis zum Verfall zu halten. Ebenfalls überdenken, ob der doppelte Filter bei monatlicher Laufzeit tatsächlich ausreichend hohe IV auswählt — bei 84% Gewinnen, die netto dennoch einen Verlust ergeben, glich die vereinnahmte Prämie die realisierte Extremvarianz nicht aus; daher iv_rank_floor / min_iv_rv_spread nur dann verschärfen, AFTER der Stop eingebaut ist. Erneut backtesten; nur dann mit der Optimierung fortfahren, wenn die Version mit begrenztem Extremverlust profit_factor > 1.1 und einen positiven avg_trade_return_pct bei einer ähnlichen oder größeren Handelszahl aufweist.