ETH डेरिबिट वीकली पुट-क्रेडिट-स्प्रेड — वोलैटिलिटी-रिस्क-प्रीमियम + डाउनसाइड-स्क्यू हार्वेस्ट (Defined-Risk Options, Skew-Gated, 3-Parameter)

एक DEFINED-RISK, DERIBIT ETH weekly expiries पर single-venue options रणनीति जो crypto vol surface के लगातार over-priced downside को बेचती है। प्रति weekly cycle एक बार (front expiry ~5-7 DTE), और ONLY जब downside insurance demonstrably महंगा हो (25-delta put IV ATM IV से richer है skew margin AND ATM IV से trailing realized vol के ऊपर), यह PUT CREDIT SPREAD खोलता है: SELL एक ~25-delta put और BUY एक ~10-delta put उसी expiry के। Max loss (strike width − net credit) पर capped है, इसलिए खाता tail move से liquidate नहीं हो सकता — short-vol रणनीतियों के साथ सबसे बड़ी risk-review चिंता को सीधे संबोधित करता है। यह जानबूझकर factory के सबसे बड़े portfolio gap को भरता है: options book का 4.7% हैं बनाम ≥15% quota, अनिवार्य रूप से शून्य prior coverage के साथ। यह plain short strangle से जानबूझकर अलग है — अलग underlying (ETH), अलग structure (defined-risk vertical, naked two-sided नहीं), और अलग signal (put-SKEW richness + VRP, raw IV/RV नहीं)। Overfitting का विरोध करने के लिए केवल 3 tunable parameters, जिसने 259 पूर्व hypotheses को मारा। NOT funding-carry (L33), NOT momentum/trend-confluence port (exhausted), NOT price reversal/fade — P&L स्रोत structural insurance premium प्लस crypto put-skew premium है, directional price forecast नहीं।

Layer-3 'No trades produced / 0 evaluated bars' के दो ठोस कारण थे, और दोनों में से कोई भी एंट्री थ्रेशोल्ड नहीं था (फीडबैक सही कहता है कि थ्रेशोल्ड ढीले न करें)। पहला, '0 evaluated bars' पंक्ति इस फैमिली के लिए red herring है: RollingOptionsStrategy.on_bar पूरी तरह FactoryStrategy.on_bar को ओवरराइड करता है और कभी _process_primary तक नहीं पहुँचता, इसलिए bars_seen हर रोलिंग-ऑप्शंस रणनीति के लिए 0 है, जिनमें सामान्य रूप से ट्रेड करने वाली रणनीतियाँ भी शामिल हैं — मैंने rolling_options_template.py और base_template.py पढ़कर इसकी पुष्टि की, बजाय super().on_bar() कॉल जोड़ने के जो प्राइमरी बार्स को बेस के cross-leg alignment barrier में भेज देता, जहाँ intermittent option legs (प्राइमरी जैसे ही 1-DAY टाइमफ्रेम) प्रोसेसिंग को हमेशा के लिए रोक देते। दूसरा, वास्तविक अवरोधक: (a) ANNUALIZATION MISMATCH — inherited realized-vol सेटिंग्स hourly थीं (rv_window=168, bars_per_year=8760) जबकि रन 1-DAY बार्स पर है, इसलिए दैनिक log returns को sqrt(8760) से वार्षिकीकृत किया गया जबकि sqrt(365) से होना चाहिए था, जिससे RV में 4.90x की वृद्धि हुई (सामान्य 3%/day ETH टेप में 281% पढ़ा जाता है जबकि 57% पढ़ा जाना चाहिए); फिर VRP गेट iv >= rv*(1+margin) ने ~60% IV की तुलना ~281% RV से की और हर साइकिल पर False रहा। bars_per_year को कॉन्फ़िगर किए गए bar type से निकालकर और RV विंडो को calendar days में व्यक्त करके ठीक किया गया, ताकि किसी भी interval पर यह drift दोबारा न हो (सत्यापित: 1-DAY -> 365, 1-HOUR -> 8760, 4-HOUR -> 2190, और गेट अब सामान्य टेप पर पास होता है)। (b) ROLE MAPPING — inherited scaffolding legs को option kind से key करती थी और एक call plus एक put (strangle) मांगती थी, इसलिए put spread के दो P legs एक ही key पर टकराए, दूसरे को duplicate कहकर अस्वीकार कर दिया गया, readiness check ने अस्तित्वहीन call leg मांगा, और हर leg SELL सबमिट हुआ (defined-risk vertical नहीं, बल्कि दो naked short puts)। अब legs को strike द्वारा short/long में मैप किया जाता है, short बेचा जाता है और long समान cached contract count पर atomic रूप से एक साथ खरीदा जाता है। मैंने inherited premium-multiple stop भी हटा दिया: long wing पहले ही नुकसान को सीमित करता है, इसलिए capped structure पर stop केवल सीमित नुकसान को समय से पहले realize करता है और फीस बढ़ाता है। Sizing अंकगणित end-to-end सत्यापित (150-wide spread, $22 credit, $128 max loss -> 15 contracts = 1.9% of equity risked)। Layers 1-2 पास करने वाली हर चीज़ को यथावत रखा: clean imports, module-level _bar_ts free function जो Layer-2 staticmethod rebinding TypeError को ठीक करता है, DVOL parser, Black-Scholes IV inversion, और continuous calculate_signal। lookback_days 49 है (7 cycles, 14 option legs) क्योंकि per-bar-type catalog loader की लागत प्रति leg ~10s है और बड़ी chain से Layer-3 wall clock का जोखिम है; यह प्रारंभिक sample को सीमित करता है और loader property है, hypothesis property नहीं।

verification_loop: सत्यापन विफल (Layer 4 — QA समीक्षा) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct -45.45% है, 2 ट्रेडों पर, metrics_reliable=false और data_days=1 के साथ — यह प्रदर्शन निर्णय नहीं है (per-notional रिटर्न ऑप्शन लेग्स के लिए अर्थपूर्ण नहीं है, जहाँ premium notional << wing notional है, और sandbox 1-दिवसीय smoke test है)। इसे केवल संदर्भ के रूप में आगे बढ़ाया गया है: यदि नीचे loader/lookback समस्या हल हो जाए और वास्तविक weekly-options sample जमा हो, तो analyst को पुनः जांचना चाहिए कि क्या एकत्र net credit Deribit के 0.03%/side round-trip को 4 लेग्स (open+close x short+long) पर प्लस किसी assignment slippage सहित पार करता है, क्योंकि put-credit-spread per-notional edge संरचनात्मक रूप से पतला है। - [critical] rolling_options.lookback_days=49 ENTIRE resolvable option chain को ANY बैकटेस्ट के ~49 दिनों तक सीमित करता है जो 'now' पर समाप्त होते हैं = ~7 weekly cycles / ~14 option legs, Deribit के 6.5-वर्षीय ETH option history के बावजूद। रणनीति शेष विंडो में flat रहती है और केवल अंत में ट्रेड करती है। Sandbox इसकी अनुभवजन्य पुष्टि करता है: bars_processed=2400 (~6.5 वर्ष) फिर भी data_days=1 और total_trades=2 (trades_count=4)। Variance-risk-premium + skew edge को ~7 cycles / ~14 legs पर noise से अलग नहीं किया जा सकता — मापने योग्य options sample के लिए आवश्यक ~30-100 ट्रेडों से बहुत कम। यह वही loader-cost-vs-sample-size catch-22 है जिसके कारण लगभग समान BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (same venue, same lookback_days=49) को Layer 4 पर दिनों पहले छोड़ दिया गया था। Developer का अपना तर्क cap को स्वीकार करता है ('lookback_days 49 है (7 cycles, 14 option legs) क्योंकि per-bar-type catalog loader की लागत प्रति leg ~10s है और बड़ी chain से Layer-3 wall clock का जोखिम है')। जैसा कॉन्फ़िगर है, रणनीति कभी मापने योग्य पूर्ण बैकटेस्ट नहीं दे सकती। — fix: ~7 cycles पर पास न करें। पुनः सबमिट करने से पहले loader-cost vs sample-size catch-22 को हल करें: प्रति-leg catalog.bars() loads को bars में batch/parallelize या cache करें ताकि lookback_days sandbox wall-clock तोड़े बिना कई वर्षों के weekly cycles (~200-300 cycles) तक पहुँच सके, फिर पूर्ण test window को कवर करने के लिए lookback_days सेट करें। यदि loader वास्तव में समय बजट के भीतर मापने योग्य weekly-options history resolve नहीं कर सकता, तो यह family वर्तमान harness में weekly cadence पर testable नहीं है और इसे पुनः डिज़ाइन किया जाना चाहिए (जैसे पूर्ण अवधि में fewer, longer-dated monthly cycles) बजाय

सत्यापन विफल (Layer 4 — QA समीक्षा) [class=code_defect]: - [edge_concern] 2 ट्रेडों पर सैंडबॉक्स avg_trade_return_pct -45.45% है, जहाँ metrics_reliable=false और data_days=1 — यह प्रदर्शन संबंधी निष्कर्ष नहीं है (प्रति-नॉशनल रिटर्न ऑप्शन लेग्स के लिए अर्थपूर्ण नहीं है, जहाँ प्रीमियम नॉशनल << विंग नॉशनल होता है, और सैंडबॉक्स 1-दिन का स्मोक टेस्ट है)। इसे केवल संदर्भ के रूप में आगे रखा जा रहा है: यदि नीचे बताई गई लोडर/लुकबैक समस्या हल हो जाती है और वास्तविक साप्ताहिक-ऑप्शंस नमूना जमा होता है, तो विश्लेषक को फिर जाँचना चाहिए कि एकत्र किया गया नेट क्रेडिट, Deribit के 0.03%/साइड राउंड-ट्रिप खर्च को 4 लेग्स (ओपन+क्लोज़ x शॉर्ट+लॉन्ग) और किसी भी असाइनमेंट स्लिपेज सहित पूरा करता है या नहीं, क्योंकि पुट-क्रेडिट-स्प्रेड का प्रति-नॉशनल लाभ संरचनात्मक रूप से बहुत कम होता है। - [गंभीर] rolling_options.lookback_days=49 के कारण ANY बैकटेस्ट की ENTIRE में समाधान योग्य ऑप्शन चेन केवल 'अब' पर समाप्त होने वाले लगभग 49 दिनों तक सीमित है = लगभग 7 साप्ताहिक चक्र / लगभग 14 ऑप्शन लेग्स, Deribit के 6.5-वर्ष के ETH ऑप्शन इतिहास की परवाह किए बिना। शेष अवधि में रणनीति निष्क्रिय रहती है और केवल अंतिम हिस्से में ट्रेड करती है। सैंडबॉक्स इसकी अनुभवजन्य पुष्टि करता है: bars_processed=2400 (लगभग 6.5 वर्ष), फिर भी data_days=1 और total_trades=2 (trades_count=4)। लगभग 7 चक्रों / लगभग 14 लेग्स के आधार पर variance-risk-premium + skew लाभ को शोर से अलग नहीं किया जा सकता — यह मापने योग्य ऑप्शंस नमूने के लिए आवश्यक लगभग 30-100 ट्रेडों से बहुत कम है। यही सटीक loader-cost-vs-sample-size अड़चन-22 है, जिसके कारण लगभग समान BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (वही वेन्यू, वही lookback_days=49) को 4 दिन पहले छोड़ दिया गया था। डेवलपर का अपना तर्क इस सीमा को स्वीकार करता है ('lookback_days 49 है (7 चक्र, 14 ऑप्शन लेग्स), क्योंकि प्रति-बार-प्रकार कैटलॉग लोडर प्रति लेग लगभग 10s लेता है और बड़ी चेन से Layer-3 की वॉल-क्लॉक सीमा पार होने का जोखिम है।')। मौजूदा कॉन्फ़िगरेशन में रणनीति कभी भी मापने योग्य पूर्ण बैकटेस्ट नहीं दे सकती। — समाधान: लगभग 7 चक्रों पर आगे न बढ़ें। दोबारा जमा करने से पहले loader-cost बनाम sample-size अड़चन-22 हल करें: प्रति-लेग catalog.bars() लोड को बारों के बीच बैच/समानांतर करें या कैश करें, ताकि lookback_days सैंडबॉक्स की वॉल-क्लॉक सीमा पार किए बिना कई वर्षों के साप्ताहिक चक्रों (लगभग 200-300 चक्र) तक पहुँच सके; फिर lookback_days को पूरी परीक्षण अवधि कवर करने के लिए सेट करें। यदि लोडर वास्तव में समय बजट के भीतर मापने योग्य साप्ताहिक-ऑप्शंस इतिहास हल नहीं कर सकता, तो वर्तमान हार्नेस में साप्ताहिक आवृत्ति पर इस परिवार का परीक्षण संभव नहीं है और इसे फिर से डिज़ाइन किया जाना चाहिए (उदाहरण के लिए, पूरी अवधि में कम, अधिक लंबी अवधि वाले मासिक चक्र), इसके बजाय

सत्यापन विफल (Layer 2 — कृत्रिम परिदृश्य): इस्तेमाल किए गए पैरामीटर: ['contracts', 'leg_sides', 'risk_frac', 'rv_window', 'atm_offset', 'skew_margin', 'iv_rv_margin', 'bars_per_year', 'min_contracts', 'iv_stale_hours', 'rv_slow_window', 'long_put_offset', 'rolling_options', 'short_put_offset', 'max_notional_frac', 'min_bars_required', 'roll_buffer_hours', 'entry_window_hours'] जाँचें कि __init__ में self.parameters.get() से सभी एट्रिब्यूट सेट किए गए हैं। - steady_uptrend: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000)

सत्यापन विफल (Layer 2 — कृत्रिम परिदृश्य): इस्तेमाल किए गए पैरामीटर: ['contracts', 'leg_sides', 'risk_frac', 'rv_window', 'stop_mult', 'put_offset', 'call_offset', 'iv_rv_margin', 'bars_per_year', 'min_contracts', 'iv_stale_hours', 'rv_slow_window', 'max_delta_ratio', 'rolling_options', 'max_notional_frac', 'min_bars_required', 'roll_buffer_hours', 'entry_window_hours'] जाँचें कि __init__ में self.parameters.get() से सभी एट्रिब्यूट सेट किए गए हैं। - steady_uptrend: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() को 1 positional argument चाहिए, लेकिन 2 दिए गए (बार टाइमस्टैम्प: 1735691040000)

सत्यापन विफल (Layer 4 — QA समीक्षा) [class=hypothesis_mismatch]: - [edge_concern] निर्णय का आधार नहीं — ब्लॉक fidelity का है, प्रदर्शन का नहीं। (रिकॉर्ड के लिए sandbox भी नकारात्मक है: -2.9%, PF 0.13, win 0.125, supposedly stopped book पर -$2,149 tail — लेकिन वह गलत रणनीति का परिणाम है।) - WHOLE-STRATEGY SWAP / MISLINK। Hypothesis ETH Deribit weekly PUT CREDIT SPREAD है (sell ~25d put, BUY ~10d put — defined-risk vertical)। Code BTC Deribit weekly delta-neutral SHORT STRANGLE है (class name, docstring, iter-3 rationale, और हर mechanism strangle है)। Instrument AND mechanism दोनों भिन्न हैं → mis-generated/mislinked artifact, यह hypothesis नहीं। सही ETH put-credit-spread को पुनः generate/re-link करें। - गलत instrument: hypothesis ETH है, लेकिन instrument_id और bar_type BTC-PERPETUAL.DERIBIT और rolling_options हैं।underlying 'BTC' है। कहीं भी ETH नहीं है। - गलत structure / defined-risk नहीं: hypothesis PURCHASED ~10d put wing से max loss को cap करता है। Code TWO SELL legs को NO bought wing के साथ सबमिट करता है; tail केवल soft next-bar premium stop से bounded है (sandbox largest_loss -$2,149 vs avg_win ~$214 दिखाता है कि यह tail को cap नहीं करता) — ठीक वही uncapped profile जिससे hypothesis बचता है। - Core edge अनुपस्थित: hypothesis signal downside-SKEW richness है (25d-put IV vs ATM IV) plus IV>RV। Code कोई skew compute नहीं करता — केवल mean-strangle IV/RV VRP। इस hypothesis को अलग करने वाला put-skew harvest implemented नहीं है।

verification_loop: सत्यापन विफल (Layer 4 — QA समीक्षा) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct -45.45% है, 2 ट्रेडों पर, metrics_reliable=false और data_days=1 के साथ — यह प्रदर्शन निर्णय नहीं है (per-notional रिटर्न ऑप्शन लेग्स के लिए अर्थपूर्ण नहीं है, जहाँ premium notional << wing notional है, और sandbox 1-दिवसीय smoke test है)। इसे केवल संदर्भ के रूप में आगे बढ़ाया गया है: यदि नीचे loader/lookback समस्या हल हो जाए और वास्तविक weekly-options sample जमा हो, तो analyst को पुनः जांचना चाहिए कि क्या एकत्र net credit Deribit के 0.03%/side round-trip को 4 लेग्स (open+close x short+long) पर प्लस किसी assignment slippage सहित पार करता है, क्योंकि put-credit-spread per-notional edge संरचनात्मक रूप से पतला है। - [critical] rolling_options.lookback_days=49 ENTIRE resolvable option chain को ANY बैकटेस्ट के ~49 दिनों तक सीमित करता है जो 'now' पर समाप्त होते हैं = ~7 weekly cycles / ~14 option legs, Deribit के 6.5-वर्षीय ETH option history के बावजूद। रणनीति शेष विंडो में flat रहती है और केवल अंत में ट्रेड करती है। Sandbox इसकी अनुभवजन्य पुष्टि करता है: bars_processed=2400 (~6.5 वर्ष) फिर भी data_days=1 और total_trades=2 (trades_count=4)। Variance-risk-premium + skew edge को ~7 cycles / ~14 legs पर noise से अलग नहीं किया जा सकता — मापने योग्य options sample के लिए आवश्यक ~30-100 ट्रेडों से बहुत कम। यह वही loader-cost-vs-sample-size catch-22 है जिसके कारण लगभग समान BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (same venue, same lookback_days=49) को Layer 4 पर दिनों पहले छोड़ दिया गया था। Developer का अपना तर्क cap को स्वीकार करता है ('lookback_days 49 है (7 cycles, 14 option legs) क्योंकि per-bar-type catalog loader की लागत प्रति leg ~10s है और बड़ी chain से Layer-3 wall clock का जोखिम है')। जैसा कॉन्फ़िगर है, रणनीति कभी मापने योग्य पूर्ण बैकटेस्ट नहीं दे सकती। — fix: ~7 cycles पर पास न करें। पुनः सबमिट करने से पहले loader-cost vs sample-size catch-22 को हल करें: प्रति-leg catalog.bars() loads को bars में batch/parallelize या cache करें ताकि lookback_days sandbox wall-clock तोड़े बिना कई वर्षों के weekly cycles (~200-300 cycles) तक पहुँच सके, फिर पूर्ण test window को कवर करने के लिए lookback_days सेट करें। यदि loader वास्तव में समय बजट के भीतर मापने योग्य weekly-options history resolve नहीं कर सकता, तो यह family वर्तमान harness में weekly cadence पर testable नहीं है और इसे पुनः डिज़ाइन किया जाना चाहिए (जैसे पूर्ण अवधि में fewer, longer-dated monthly cycles) बजाय