ETH Deribit সাপ্তাহিক Put-Credit-Spread — Volatility-Risk-Premium + Downside-Skew Harvest (নির্ধারিত-ঝুঁকির অপশন, Skew-Gated, 3-প্যারামিটার)

একটি DEFINED-RISK, DERIBIT ETH সাপ্তাহিক মেয়াদপূর্তিতে একক-ভেন্যু অপশন কৌশল যা ক্রিপ্টো ভল সারফেসের স্থায়ীভাবে অতিমূল্যায়িত ডাউনসাইড বিক্রি করে। প্রতি সাপ্তাহিক চক্রে একবার (ফ্রন্ট মেয়াদ ~5-7 DTE), এবং ONLY যখন ডাউনসাইড সুরক্ষা প্রমাণযোগ্যভাবে ব্যয়বহুল (25-ডেল্টা পুট IV ATM IV-এর চেয়ে একটি স্কিউ মার্জিন AND ATM IV ট্রেলিং বাস্তবায়িত ভোলাটিলিটির উপরে ধনী), এটি একটি PUT CREDIT SPREAD খোলে: SELL একটি ~25-ডেল্টা পুট এবং BUY একই মেয়াদের একটি ~10-ডেল্টা পুট। সর্বোচ্চ ক্ষতি (স্ট্রাইক প্রস্থ − নিট ক্রেডিট)-এ সীমাবদ্ধ, তাই টেইল মুভ দ্বারা অ্যাকাউন্ট লিকুইডেট হতে পারে না — শর্ট-ভল কৌশল নিয়ে সবচেয়ে বড় ঝুঁকি-পর্যালোচনা উদ্বেগের সরাসরি সমাধান। এটি ইচ্ছাকৃতভাবে ফ্যাক্টরির একক বৃহত্তম পোর্টফোলিও ঘাটতি পূরণ করে: বইয়ের 4.7% বনাম ≥15% কোটার তুলনায় অপশন, কার্যত শূন্য পূর্ব কভারেজ সহ। এটি ইচ্ছাকৃতভাবে একটি সাধারণ শর্ট স্ট্র্যাঙ্গল থেকে আলাদা — ভিন্ন অন্তর্নিহিত (ETH), ভিন্ন কাঠামো (সংজ্ঞায়িত-ঝুঁকি ভার্টিক্যাল, নগ্ন দ্বিমুখী নয়), এবং ভিন্ন সংকেত (পুট-SKEW সমৃদ্ধি + VRP, কাঁচা IV/RV নয়)। ওভারফিটিং প্রতিরোধে মাত্র 3 টিউনযোগ্য প্যারামিটার যা 259 পূর্ববর্তী হাইপোথিসিসগুলোকে ধ্বংস করেছিল। NOT ফান্ডিং-ক্যারি (L33), NOT একটি মোমেন্টাম/ট্রেন্ড-কনফ্লুয়েন্স পোর্ট (নিঃশেষিত), NOT একটি মূল্য বিপরীত/ফেইড — P&L উৎস একটি কাঠামোগত বীমা প্রিমিয়াম প্লাস ক্রিপ্টো পুট-স্কিউ প্রিমিয়াম, দিকনির্দেশক মূল্য পূর্বাভাস নয়।

Layer-3 “কোনো ট্রেড তৈরি হয়নি / 0টি বার মূল্যায়ন করা হয়েছে” সমস্যাটির দুটি নির্দিষ্ট কারণ ছিল, এবং কোনোটিই এন্ট্রি থ্রেশহোল্ড ছিল না (ফিডব্যাকে ঠিকই বলা হয়েছে যে থ্রেশহোল্ড শিথিল করা যাবে না)। প্রথমত, “0টি বার মূল্যায়ন করা হয়েছে” লাইনটি এই পরিবারের ক্ষেত্রে বিভ্রান্তিকর: RollingOptionsStrategy.on_bar সম্পূর্ণভাবে FactoryStrategy.on_bar ওভাররাইড করে এবং _process_primary-তে কখনো পৌঁছায় না। তাই bars_seen সব রোলিং-অপশনস স্ট্র্যাটেজির জন্য 0, স্বাভাবিকভাবে ট্রেড করা স্ট্র্যাটেজিগুলোর ক্ষেত্রেও—এটি নিশ্চিত করতে আমি super().on_bar() কল যোগ না করে rolling_options_template.py ও base_template.py পড়েছি; এমন কল প্রাইমারি বারগুলোকে বেসের ক্রস-লেগ অ্যালাইনমেন্ট বাধায় পাঠাত, যেখানে মাঝেমধ্যে আসা অপশন লেগগুলো (প্রাইমারির সঙ্গে একই 1-DAY টাইমফ্রেমে) চিরতরে প্রসেসিং আটকে দিত। দ্বিতীয়ত, প্রকৃত বাধাগুলো: (a) ANNUALIZATION MISMATCH — উত্তরাধিকারসূত্রে পাওয়া realized-vol সেটিংস ছিল ঘণ্টাভিত্তিক (rv_window=168, bars_per_year=8760), অথচ রানটি চলছে 1-DAY বারে; ফলে দৈনিক লগ রিটার্নকে sqrt(8760) দিয়ে বার্ষিকীকরণ করা হচ্ছিল, sqrt(365) দিয়ে নয়, তাই RV 4.90x গুণ বেড়ে যাচ্ছিল (স্বাভাবিক 3%/দিনের ETH টেপে 281%-এর বদলে 57% দেখা যায়); এরপর VRP গেট iv >= rv*(1+margin) প্রায় 60% IV-এর সঙ্গে প্রায় 281% RV তুলনা করছিল এবং প্রতিটি সাইকেলে False হচ্ছিল। কনফিগার করা বার টাইপ থেকে bars_per_year নির্ণয় করে এবং RV উইন্ডোকে ক্যালেন্ডার দিনের হিসাবে প্রকাশ করে এটি ঠিক করা হয়েছে; ফলে যেকোনো ইন্টারভ্যালে এই বিচ্যুতি আর ঘটবে না (যাচাই করা হয়েছে: 1-DAY -> 365, 1-HOUR -> 8760, 4-HOUR -> 2190, এবং এখন স্বাভাবিক টেপে গেটটি পাস করে)। (b) ROLE MAPPING — উত্তরাধিকারসূত্রে পাওয়া কাঠামোটি অপশন ধরনের ভিত্তিতে লেগের কী নির্ধারণ করত এবং একটি কল ও একটি পুট (স্ট্র্যাঙ্গল) চাইত; ফলে পুট স্প্রেডের দুটি P লেগ একই কীতে সংঘর্ষে জড়াত, দ্বিতীয়টিকে ডুপ্লিকেট হিসেবে বাতিল করা হতো, readiness check-এ অনুপস্থিত একটি কল লেগ চাওয়া হতো, এবং প্রতিটি লেগ SELL জমা পড়ত (দুটি নগ্ন শর্ট পুট, নির্ধারিত-ঝুঁকির ভার্টিক্যাল নয়)। এখন স্ট্রাইক অনুযায়ী লেগগুলোকে শর্ট/লং হিসেবে ম্যাপ করা হয়; একই ক্যাশ করা কন্ট্র্যাক্ট সংখ্যায় শর্টটি বিক্রি এবং লংটি কেনা হয়, পারমাণবিকভাবে। উত্তরাধিকারসূত্রে পাওয়া প্রিমিয়াম-মাল্টিপল স্টপটিও সরিয়েছি: লং উইং ইতিমধ্যেই ক্ষতি সীমাবদ্ধ করে, তাই সীমাবদ্ধ কাঠামোতে স্টপ কেবল সীমিত ক্ষতি আগেই বাস্তবায়িত করে এবং ফি বাড়ায়। সাইজিংয়ের হিসাব শুরু থেকে শেষ পর্যন্ত যাচাই করা হয়েছে (150-প্রশস্ত স্প্রেড, $22 ক্রেডিট, $128 সর্বোচ্চ ক্ষতি -> 15টি কন্ট্র্যাক্ট = ইকুইটির 1.9% ঝুঁকিতে)। Layer 1-2-এ উত্তীর্ণ সবকিছু অক্ষত রেখেছি: পরিষ্কার ইমপোর্ট, Layer-2 staticmethod rebinding TypeError ঠিক করা মডিউল-স্তরের _bar_ts free function, DVOL parser, Black-Scholes IV inversion, এবং continuous calculate_signal। lookback_days হলো 49 (7টি সাইকেল, 14টি অপশন লেগ), কারণ প্রতি-বার-টাইপ ক্যাটালগ লোডারের প্রতিটি লেগে প্রায় 10s লাগে, আর বড় চেইনে Layer-3 wall clock অতিক্রমের ঝুঁকি আছে; এতে প্রাথমিক নমুনা সীমিত হয়, যা লোডারের বৈশিষ্ট্য, হাইপোথিসিসের নয়।

verification_loop: যাচাইকরণ ব্যর্থ (Layer 4 — QA পর্যালোচনা) [class=code_defect]: - [edge_concern] 2টি ট্রেডে Sandbox avg_trade_return_pct হলো -45.45%, যেখানে metrics_reliable=false এবং data_days=1 — এটি পারফরম্যান্স-সংক্রান্ত রায় নয় (অপশন লেগের ক্ষেত্রে notional-প্রতি রিটার্ন অর্থবহ নয়, কারণ প্রিমিয়াম notional << উইং notional, আর sandbox হলো 1-দিনের smoke test)। এটি কেবল প্রেক্ষাপট হিসেবে রাখা হয়েছে: নিচের লোডার/লুকব্যাক সমস্যা মিটলে এবং প্রকৃত সাপ্তাহিক-অপশন নমুনা জমলে, বিশ্লেষকের আবার দেখা উচিত সংগৃহীত নিট ক্রেডিট Deribit-এর প্রতি-সাইড 0.03% round-trip খরচ পেরোয় কি না—4টি লেগে (খোলা+বন্ধ x শর্ট+লং), সম্ভাব্য অ্যাসাইনমেন্ট স্লিপেজসহ; কারণ put-credit-spread-এর notional-প্রতি এজ কাঠামোগতভাবেই পাতলা। - [critical] rolling_options.lookback_days=49 সেটিংটি ANY ব্যাকটেস্টের ENTIRE পর্যন্ত সমাধানযোগ্য অপশন চেইনকে 'এখন' পর্যন্ত শেষ হওয়া প্রায় 49 দিনে সীমাবদ্ধ করে = প্রায় 7টি সাপ্তাহিক সাইকেল / প্রায় 14টি অপশন লেগ; Deribit-এর 6.5-বছরের ETH অপশন ইতিহাস থাকলেও। উইন্ডোর বাকি সময়ে স্ট্র্যাটেজিটি নিষ্ক্রিয় থাকে এবং কেবল একেবারে শেষ অংশে ট্রেড করে। Sandbox-এর ফলেও এটি দেখা যায়: bars_processed=2400 (প্রায় 6.5 বছর), তবু data_days=1 এবং total_trades=2 (trades_count=4)। প্রায় 7টি সাইকেল / প্রায় 14টি লেগে variance-risk-premium + skew এজকে noise থেকে আলাদা করা যায় না—পরিমাপযোগ্য অপশন নমুনার জন্য দরকারি প্রায় 30-100টি ট্রেডের চেয়ে অনেক কম। এই একই loader-cost-vs-sample-size জটিলতা-22-র কারণেই প্রায় অভিন্ন BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (একই venue, একই lookback_days=49)-কে 4 দিন আগে Layer-এ পরিত্যাগ করা হয়েছিল। ডেভেলপারের নিজের যুক্তিতেই সীমাটি স্বীকার করা হয়েছে ('lookback_days হলো 49 (7টি সাইকেল, 14টি অপশন লেগ), কারণ প্রতি-বার-টাইপ ক্যাটালগ লোডারের প্রতিটি লেগে প্রায় 10s লাগে, আর বড় চেইনে Layer-3 wall clock অতিক্রমের ঝুঁকি আছে')। বর্তমান কনফিগারেশনে স্ট্র্যাটেজিটি কখনোই পরিমাপযোগ্য পূর্ণ ব্যাকটেস্ট দিতে পারবে না। — সমাধান: প্রায় 7টি সাইকেলের ওপর পাস করবেন না। আবার জমা দেওয়ার আগে loader-cost vs sample-size জটিলতা-22 মেটান: প্রতি লেগের catalog.bars() লোডগুলো বারজুড়ে ব্যাচ/সমান্তরালভাবে চালান বা ক্যাশ করুন, যাতে sandbox wall-clock অতিক্রম না করেই lookback_days বহু বছরের সাপ্তাহিক সাইকেল (প্রায় 200-300টি সাইকেল) পর্যন্ত পৌঁছাতে পারে; তারপর lookback_days পুরো পরীক্ষার সময়সীমা জুড়ে সেট করুন। সময়সীমার মধ্যে পরিমাপযোগ্য সাপ্তাহিক-অপশন ইতিহাস উদ্ধার করা লোডারের পক্ষে সত্যিই সম্ভব না হলে, বর্তমান harness-এ সাপ্তাহিক cadence-এ এই পরিবার পরীক্ষা করা যায় না; তাই এটিকে নতুনভাবে নকশা করা উচিত (যেমন পুরো সময়সীমাজুড়ে কম সংখ্যক, দীর্ঘ মেয়াদের মাসিক সাইকেল ব্যবহার করে), বরং

Deribit ETH-এ নির্ধারিত-ঝুঁকির সাপ্তাহিক put credit spread। প্রতি সাপ্তাহিক মেয়াদপূর্তি সাইকেলে (প্রায় 7 DTE) rolling-options framework দুটি পুট লেগ নির্ধারণ করে (প্রায় 5% এবং 10% OTM); স্ট্র্যাটেজিটি স্ট্রাইক অনুযায়ী এগুলোকে শর্ট (উচ্চতর স্ট্রাইক, প্রায় 25-ডেল্টা) ও লং (নিম্নতর স্ট্রাইক, প্রায় 10-ডেল্টা) লেগে ম্যাপ করে, একই 1:1 কন্ট্র্যাক্ট সংখ্যায় শর্টটি SELLS এবং লংটি BUYS করে, এবং ইউরোপীয় ক্যাশ সেটেলমেন্টের আগে রোল বাফার পর্যন্ত ধরে রাখে। প্রবেশের সময় সাইকেলের এন্ট্রি উইন্ডোতে মাপা দুটি সমৃদ্ধতার পরীক্ষার ওপর এন্ট্রি নির্ভর করে: downside skew (short-put IV >= Deribit DVOL ATM IV x (1 + skew_margin)) এবং variance risk premium (ATM IV >= trailing 14-দিনের realized vol x (1 + vrp_margin))। Black-Scholes ব্যবহার করে প্রতিটি লেগের নিজস্ব USD-premium বার থেকে IV উল্টোভাবে নির্ণয় করা হয়। প্রতি স্প্রেডে সর্বোচ্চ ক্ষতি হলো (স্ট্রাইক-প্রস্থ - নিট ক্রেডিট), যা এন্ট্রির সময় স্থির হয়; সাইজিংয়ে ঠিক সেই পরিমাণ ঝুঁকি নেওয়া হয়: কন্ট্র্যাক্ট = floor(equity x risk_frac / max_loss), সর্বোচ্চ সীমা এমনভাবে নির্ধারিত যাতে মোট স্প্রেড-প্রস্থ ইকুইটির 50%-এর মধ্যে থাকে, এবং Deribit-এর 1-কন্ট্র্যাক্টের ETH সর্বনিম্ন সীমাও মানা হয়। 3টি tunable (skew_margin, vrp_margin, risk_frac); leverage 1.0; perp/underlying ট্রেডিংয়ের কোনো পথ নেই।

যাচাইকরণ ব্যর্থ হয়েছে (Layer 4 — QA পর্যালোচনা) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct হল -45.45% উপর 2 টি ট্রেডে যেখানে metrics_reliable=false এবং data_days=1 — এটি একটি performance verdict নয় (per-notional return option leg-গুলির জন্য অর্থপূর্ণ নয়, যেখানে premium notional << wing notional, এবং sandbox হল একটি 1 দিনের smoke test)। এটি শুধুমাত্র context হিসেবে এগিয়ে নেওয়া হয়েছে: নিচের loader/lookback সমস্যাটি সমাধান হলে এবং একটি বাস্তব weekly-options sample জমা হলে, analyst-এর পুনরায় পরীক্ষা করা উচিত যে সংগৃহীত net credit Deribit-এর 0.03%/side round-trip অতিক্রম করে কিনা 4 টি leg জুড়ে (open+close x short+long) plus যেকোনো assignment slippage, যেহেতু put-credit-spread per-notional edge কাঠামোগতভাবে পাতলা। - [critical] rolling_options.lookback_days=49 ANY backtest-এর ENTIRE resolvable option chain-কে 'now'-এ শেষ হওয়া ~49 দিনে সীমাবদ্ধ করে = ~7 টি weekly cycle / ~14 টি option leg, Deribit-এর 6.5 বছরের ETH option history নির্বিশেষে। Strategy-টি window-এর বাকি অংশে flat থাকে এবং শুধুমাত্র tail-এ ট্রেড করে। Sandbox-টি এটি empirically নিশ্চিত করে: bars_processed=2400 (~6.5 years) অথচ data_days=1 এবং total_trades=2 (trades_count=4)। একটি variance-risk-premium + skew edge ~7 টি cycle / ~14 টি leg-এ noise থেকে আলাদা করা যায় না — একটি পরিমাপযোগ্য options sample-এর জন্য প্রয়োজনীয় ~30-100 টি trade-এর চেয়ে অনেক কম। এটি ঠিক সেই loader-cost-vs-sample-size catch-22 যা প্রায়-অভিন্ন BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp-কে (same venue, same lookback_days=49) Layer 4 দিন আগে পরিত্যক্ত হওয়ার কারণ হয়েছিল। Developer-এর নিজস্ব যুক্তি cap-টি স্বীকার করে ('lookback_days হল 49 (7 টি cycle, 14 টি option leg) কারণ per-bar-type catalog loader-এর খরচ ~10s প্রতি leg এবং একটি বড় chain Layer-3 wall clock-এর ঝুঁকি তৈরি করে')। যেমন configured, strategy-টি কখনোই একটি পরিমাপযোগ্য full backtest তৈরি করতে পারে না। — fix: ~7 টি cycle দিয়ে পাস করবেন না। পুনরায় জমা দেওয়ার আগে loader-cost vs sample-size catch-22 সমাধান করুন: per-leg catalog.bars() load-গুলি bar জুড়ে batch/parallelize বা cache করুন যাতে lookback_days sandbox wall-clock লঙ্ঘন না করে বহু বছরের weekly cycle (~200-300 টি cycle) পর্যন্ত পৌঁছাতে পারে, তারপর full test window কভার করতে lookback_days সেট করুন। যদি loader time budget-এর মধ্যে একটি পরিমাপযোগ্য weekly-options history genuinely resolve করতে না পারে, তাহলে এই family বর্তমান harness-এ weekly cadence-এ testable নয় এবং পুনরায় ডিজাইন করা উচিত (e.g. full span জুড়ে fewer, longer-dated monthly cycle) বরং

যাচাইকরণ ব্যর্থ (স্তর 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() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000)

যাচাইকরণ ব্যর্থ (স্তর 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() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() 2টি positional argument পেয়েছে, যেখানে গ্রহণ করার কথা 1টি (বারের টাইমস্ট্যাম্প: 1735691040000)

যাচাইকরণ ব্যর্থ হয়েছে (স্তর 4 — QA পর্যালোচনা) [class=hypothesis_mismatch]: - [edge_concern] রায়ের ভিত্তি নয় — ব্লকটি ফিডেলিটি সম্পর্কিত, পারফরম্যান্স নয়। (রেকর্ডের জন্য স্যান্ডবক্সও নেতিবাচক: -2.9%, PF 0.13, win 0.125, থামানো হয়েছে বলে দাবি করা বুক-এ -$2,149 টেইল — তবে এটি ভুল কৌশলের ফলাফল।) - WHOLE-STRATEGY SWAP / MISLINK। হাইপোথিসিসটি একটি ETH Deribit সাপ্তাহিক PUT CREDIT SPREAD (প্রায় 25d পুট বিক্রি, BUY ~10d পুট — সংজ্ঞায়িত-ঝুঁকি ভার্টিক্যাল)। কোডটি হল BTC Deribit সাপ্তাহিক ডেল্টা-নিরপেক্ষ SHORT STRANGLE (ক্লাসের নাম, ডকস্ট্রিং, iter-3 যুক্তি, এবং প্রতিটি মেকানিজম স্ট্র্যাঙ্গল)। উপকরণ AND মেকানিজম উভয়ই ভিন্ন → ভুলভাবে তৈরি/ভুলভাবে লিঙ্ক করা আর্টিফ্যাক্ট, এই হাইপোথিসিস নয়। সঠিক ETH পুট-ক্রেডিট-স্প্রেড পুনরায় তৈরি/পুনরায় লিঙ্ক করুন। - ভুল উপকরণ: হাইপোথিসিস হল ETH, কিন্তু instrument_id এবং bar_type হল BTC-PERPETUAL.DERIBIT এবং rolling_options। underlying হল 'BTC'। কোথাও ETH নেই। - ভুল কাঠামো / সংজ্ঞায়িত-ঝুঁকি নয়: হাইপোথিসিস একটি PURCHASED ~10d পুট উইং দিয়ে সর্বোচ্চ ক্ষতি সীমাবদ্ধ করে। কোড NO কেনা উইং ছাড়াই TWO SELL লেগ জমা দেয়; টেইল কেবল একটি নরম পরবর্তী-বার প্রিমিয়াম স্টপ দ্বারা সীমাবদ্ধ (স্যান্ডবক্স largest_loss -$2,149 বনাম avg_win ~$214 দেখায় এটি টেইলকে সীমাবদ্ধ করে না) — ঠিক সেই আনক্যাপড প্রোফাইল যা হাইপোথিসিস এড়ায়। - মূল এজ অনুপস্থিত: হাইপোথিসিস সংকেত হল ডাউনসাইড-SKEW সমৃদ্ধি (25d-পুট IV বনাম ATM IV) প্লাস IV>RV। কোড কোনো স্কিউ গণনা করে না — কেবল গড়-স্ট্র্যাঙ্গল IV/RV VRP। এই হাইপোথিসিসকে আলাদা করা পুট-স্কিউ হারভেস্ট বাস্তবায়িত হয়নি।

verification_loop: যাচাইকরণ ব্যর্থ (Layer 4 — QA পর্যালোচনা) [class=code_defect]: - [edge_concern] 2টি ট্রেডে Sandbox avg_trade_return_pct হলো -45.45%, যেখানে metrics_reliable=false এবং data_days=1 — এটি পারফরম্যান্স-সংক্রান্ত রায় নয় (অপশন লেগের ক্ষেত্রে notional-প্রতি রিটার্ন অর্থবহ নয়, কারণ প্রিমিয়াম notional << উইং notional, আর sandbox হলো 1-দিনের smoke test)। এটি কেবল প্রেক্ষাপট হিসেবে রাখা হয়েছে: নিচের লোডার/লুকব্যাক সমস্যা মিটলে এবং প্রকৃত সাপ্তাহিক-অপশন নমুনা জমলে, বিশ্লেষকের আবার দেখা উচিত সংগৃহীত নিট ক্রেডিট Deribit-এর প্রতি-সাইড 0.03% round-trip খরচ পেরোয় কি না—4টি লেগে (খোলা+বন্ধ x শর্ট+লং), সম্ভাব্য অ্যাসাইনমেন্ট স্লিপেজসহ; কারণ put-credit-spread-এর notional-প্রতি এজ কাঠামোগতভাবেই পাতলা। - [critical] rolling_options.lookback_days=49 সেটিংটি ANY ব্যাকটেস্টের ENTIRE পর্যন্ত সমাধানযোগ্য অপশন চেইনকে 'এখন' পর্যন্ত শেষ হওয়া প্রায় 49 দিনে সীমাবদ্ধ করে = প্রায় 7টি সাপ্তাহিক সাইকেল / প্রায় 14টি অপশন লেগ; Deribit-এর 6.5-বছরের ETH অপশন ইতিহাস থাকলেও। উইন্ডোর বাকি সময়ে স্ট্র্যাটেজিটি নিষ্ক্রিয় থাকে এবং কেবল একেবারে শেষ অংশে ট্রেড করে। Sandbox-এর ফলেও এটি দেখা যায়: bars_processed=2400 (প্রায় 6.5 বছর), তবু data_days=1 এবং total_trades=2 (trades_count=4)। প্রায় 7টি সাইকেল / প্রায় 14টি লেগে variance-risk-premium + skew এজকে noise থেকে আলাদা করা যায় না—পরিমাপযোগ্য অপশন নমুনার জন্য দরকারি প্রায় 30-100টি ট্রেডের চেয়ে অনেক কম। এই একই loader-cost-vs-sample-size জটিলতা-22-র কারণেই প্রায় অভিন্ন BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (একই venue, একই lookback_days=49)-কে 4 দিন আগে Layer-এ পরিত্যাগ করা হয়েছিল। ডেভেলপারের নিজের যুক্তিতেই সীমাটি স্বীকার করা হয়েছে ('lookback_days হলো 49 (7টি সাইকেল, 14টি অপশন লেগ), কারণ প্রতি-বার-টাইপ ক্যাটালগ লোডারের প্রতিটি লেগে প্রায় 10s লাগে, আর বড় চেইনে Layer-3 wall clock অতিক্রমের ঝুঁকি আছে')। বর্তমান কনফিগারেশনে স্ট্র্যাটেজিটি কখনোই পরিমাপযোগ্য পূর্ণ ব্যাকটেস্ট দিতে পারবে না। — সমাধান: প্রায় 7টি সাইকেলের ওপর পাস করবেন না। আবার জমা দেওয়ার আগে loader-cost vs sample-size জটিলতা-22 মেটান: প্রতি লেগের catalog.bars() লোডগুলো বারজুড়ে ব্যাচ/সমান্তরালভাবে চালান বা ক্যাশ করুন, যাতে sandbox wall-clock অতিক্রম না করেই lookback_days বহু বছরের সাপ্তাহিক সাইকেল (প্রায় 200-300টি সাইকেল) পর্যন্ত পৌঁছাতে পারে; তারপর lookback_days পুরো পরীক্ষার সময়সীমা জুড়ে সেট করুন। সময়সীমার মধ্যে পরিমাপযোগ্য সাপ্তাহিক-অপশন ইতিহাস উদ্ধার করা লোডারের পক্ষে সত্যিই সম্ভব না হলে, বর্তমান harness-এ সাপ্তাহিক cadence-এ এই পরিবার পরীক্ষা করা যায় না; তাই এটিকে নতুনভাবে নকশা করা উচিত (যেমন পুরো সময়সীমাজুড়ে কম সংখ্যক, দীর্ঘ মেয়াদের মাসিক সাইকেল ব্যবহার করে), বরং