ETH اسپرد اعتباری فروش هفتگی دریبیت — برداشت صرف ریسک نوسان + چولگی سمت نزولی (آپشن با ریسک تعریف‌شده، مشروط به چولگی، 3-پارامتری)

فرضیه

یک استراتژی آپشن تک‌محل DEFINED-RISK روی سررسیدهای هفتگی DERIBIT ETH که سمت نزولی به‌طور مداوم بیش‌قیمت‌گذاری‌شده سطح نوسان کریپتو را می‌فروشد. یک‌بار در هر چرخه هفتگی (سررسید نزدیک ~5-7 DTE)، و ONLY زمانی که بیمه سمت نزولی به‌طور قابل اثبات گران است (پوت 25-دلتا IV غنی‌تر از ATM IV به اندازه مارجین چولگی AND ATM IV بالاتر از نوسان تحقق‌یافته گذشته)، یک PUT CREDIT SPREAD باز می‌کند: SELL یک پوت دلتای ~25 و BUY یک پوت دلتای ~10 از همان سررسید. حداکثر زیان در (پهنای استرایک − اعتبار خالص) سقف‌گذاری شده، بنابراین……نمایش بیشترنمایش کمتر

یک استراتژی آپشن تک‌محل 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 یک پرمیوم بیمه ساختاری به‌علاوه پرمیوم پوت-اسکیو کریپتو است، نه یک پیش‌بینی جهتی قیمت.

«عدم تولید معامله / 0 میله ارزیابی‌شده» لایه-3 دو علت مشخص داشت و هیچ‌کدام آستانه ورود نبود (بازخورد به‌درستی می‌گوید آستانه‌ها را شل نکنید). اول، خط «0 میله ارزیابی‌شده» برای این خانواده یک سرنخ گمراه‌کننده است: RollingOptionsStrategy.on_bar به‌طور کامل FactoryStrategy.on_bar را بازنویسی می‌کند و هرگز به _process_primary نمی‌رسد، بنابراین bars_seen برای هر استراتژی رولینگ-آپشن از جمله استراتژی‌هایی که به‌طور عادی معامله می‌کنند 0 است — من این را با خواندن rolling_options_template.py و base_template.py تأیید کردم……نمایش بیشترنمایش کمتر

«عدم تولید معامله / 0 میله ارزیابی‌شده» لایه-3 دو علت مشخص داشت و هیچ‌کدام آستانه ورود نبود (بازخورد به‌درستی می‌گوید آستانه‌ها را شل نکنید). اول، خط «0 میله ارزیابی‌شده» برای این خانواده یک سرنخ گمراه‌کننده است: RollingOptionsStrategy.on_bar به‌طور کامل FactoryStrategy.on_bar را بازنویسی می‌کند و هرگز به _process_primary نمی‌رسد، بنابراین bars_seen برای هر استراتژی رولینگ-آپشن از جمله استراتژی‌هایی که به‌طور عادی معامله می‌کنند 0 است — من این را با خواندن rolling_options_template.py و base_template.py تأیید کردم به‌جای افزودن فراخوانی super().on_bar() که میله‌های primary را به سد تراز cross-leg در کلاس پایه هدایت می‌کرد، جایی که لگ‌های متناوب آپشن (همان تایم‌فریم 1-DAY primary) پردازش را برای همیشه مسدود می‌کردند. دوم، مسدودکننده‌های واقعی: (الف) ANNUALIZATION MISMATCH — تنظیمات به‌ارث‌رسیده نوسان تحقق‌یافته ساعتی بودند (rv_window=168، bars_per_year=8760) در حالی که اجرا روی میله‌های 1-DAY است، بنابراین بازده لگاریتمی روزانه با sqrt(8760) به‌جای sqrt(365) سالانه شد و RV را به میزان 4.90x متورم کرد (یک نوار عادی 3%/day ETH به‌جای 57% عدد 281% را نشان می‌دهد)؛ سپس گیت VRP به‌صورت iv >= rv*(1+margin) حدود 60% IV را با حدود 281% RV مقایسه کرد و در هر چرخه False بود. با استخراج bars_per_year از نوع میله پیکربندی‌شده و بیان پنجره RV بر حسب روزهای تقویمی اصلاح شد، به‌طوری که این انحراف در هیچ بازه‌ای تکرار نمی‌شود (تأییدشده: 1-DAY -> 365، 1-HOUR -> 8760، 4-HOUR -> 2190، و گیت اکنون روی نوار عادی پاس می‌شود). (ب) ROLE MAPPING — داربست به‌ارث‌رسیده لگ‌ها را بر اساس نوع آپشن کلید می‌زد و به یک کال به‌علاوه یک پوت (یک استرنگل) نیاز داشت، بنابراین دو لگ P اسپرد پوت روی یک کلید تصادم کردند، دومی به‌عنوان تکراری رد شد، بررسی آمادگی یک لگ کال ناموجود را طلب کرد و هر لگ به‌صورت SELL ارسال شد (دو شورت پوت برهنه، نه ورتیکال با ریسک تعریف‌شده). اکنون لگ‌ها بر اساس استرایک به short/long نگاشت می‌شوند، شورت فروخته و لانگ با همان تعداد قرارداد کش‌شده به‌صورت اتمیک خریده می‌شود. همچنین استاپ چندبرابر پرمیوم به‌ارث‌رسیده را حذف کردم: بال لانگ از قبل زیان را محدود می‌کند، پس استاپ روی ساختار سقف‌دار فقط یک زیان محدود را زود محقق می‌کند و کارمزد اضافه می‌کند. محاسبات سایزینگ سرتاسری تأیید شد (اسپرد به پهنای 150، اعتبار $22، حداکثر زیان $128 -> 15 قرارداد = 1.9% ریسک روی اکوییتی). همه مواردی که لایه‌های 1-2 را پاس کرده بودند دست‌نخورده نگه داشتم: ایمپورت‌های تمیز، تابع آزاد _bar_ts در سطح ماژول که TypeError بازبایندینگ staticmethod لایه-2 را رفع می‌کند، پارسر DVOL، معکوس‌سازی IV بلک-شولز، و calculate_signal پیوسته. lookback_days برابر 49 است (7 چرخه، 14 لگ آپشن) زیرا لودر کاتالوگ per-bar-type حدود 10 ثانیه به‌ازای هر لگ هزینه دارد و زنجیره بزرگ‌تر ساعت دیواری لایه-3 را به خطر می‌اندازد؛ این نمونه اولیه را محدود می‌کند و ویژگی لودر است، نه ویژگی فرضیه.

verification_loop: راستی‌آزمایی ناموفق بود (بازبینی لایه 4 — QA) [class=code_defect]: - [edge_concern] avg_trade_return_pct سندباکس روی 2 معامله -45.45% است با metrics_reliable=false و data_days=1 — این یک حکم عملکردی نیست (بازده بر حسب نوشنال برای لگ‌های آپشن معنادار نیست، جایی که نوشنال پرمیوم << نوشنال بال است، و سندباکس یک تست دود 1 روزه است). این فقط به‌عنوان زمینه منتقل می‌شود: اگر مشکل لودر/لوک‌بک زیر حل شود و نمونه واقعی آپشن هفتگی انباشته شود، تحلیلگر باید دوباره بررسی کند که آیا اعتبار خالص جمع‌شده……نمایش بیشترنمایش کمتر

verification_loop: راستی‌آزمایی ناموفق بود (بازبینی لایه 4 — QA) [class=code_defect]: - [edge_concern] avg_trade_return_pct سندباکس روی 2 معامله -45.45% است با metrics_reliable=false و data_days=1 — این یک حکم عملکردی نیست (بازده بر حسب نوشنال برای لگ‌های آپشن معنادار نیست، جایی که نوشنال پرمیوم << نوشنال بال است، و سندباکس یک تست دود 1 روزه است). این فقط به‌عنوان زمینه منتقل می‌شود: اگر مشکل لودر/لوک‌بک زیر حل شود و نمونه واقعی آپشن هفتگی انباشته شود، تحلیلگر باید دوباره بررسی کند که آیا اعتبار خالص جمع‌شده هزینه رفت‌وبرگشت 0.03%/side دریبیت در سراسر 4 لگ (باز+بسته × شورت+لانگ) به‌علاوه هر لغزش اساینمنت را پوشش می‌دهد یا نه، زیرا لبه بر حسب نوشنال اسپرد اعتباری پوت به‌طور ساختاری نازک است. - [critical] rolling_options.lookback_days=49 زنجیره آپشن قابل تفکیک ENTIRE بک‌تست ANY را به ~49 روز پایانی منتهی به 'اکنون' محدود می‌کند = ~7 چرخه هفتگی / ~14 لگ آپشن، صرف‌نظر از تاریخچه 6.5 ساله آپشن ETH دریبیت. استراتژی برای بقیه پنجره فلت می‌ماند و فقط در انتها معامله می‌کند. سندباکس این را به‌صورت تجربی تأیید می‌کند: bars_processed=2400 (~6.5 سال) با این حال data_days=1 و total_trades=2 (trades_count=4). لبه صرف ریسک واریانس + چولگی را نمی‌توان روی ~7 چرخه / ~14 لگ از نویز تفکیک کرد — بسیار کمتر از ~30-100 معامله لازم برای نمونه آپشن قابل اندازه‌گیری. این دقیقاً همان بن‌بست هزینه-لودر در برابر اندازه-نمونه-22 است که باعث شد استراتژی تقریباً یکسان BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (همان ونیو، همان lookback_days=49) در لایه 4 چند روز پیش رها شود. استدلال خود توسعه‌دهنده سقف را تأیید می‌کند ('lookback_days برابر 49 است (7 چرخه، 14 لگ آپشن) زیرا لودر کاتالوگ per-bar-type حدود 10 ثانیه به‌ازای هر لگ هزینه دارد و زنجیره بزرگ‌تر ساعت دیواری لایه-3 را به خطر می‌اندازد'). با این پیکربندی، استراتژی هرگز نمی‌تواند بک‌تست کامل قابل اندازه‌گیری تولید کند. — اصلاح: روی ~7 چرخه پاس نکنید. بن‌بست هزینه-لودر در برابر اندازه-نمونه-22 را پیش از ارسال مجدد حل کنید: بارگذاری‌های per-leg catalog.bars() را در سراسر میله‌ها به‌صورت دسته‌ای/موازی یا کش کنید تا lookback_days بتواند بدون نقض ساعت دیواری سندباکس به سال‌ها چرخه هفتگی (~200-300 چرخه) برسد، سپس lookback_days را طوری تنظیم کنید که کل پنجره تست را پوشش دهد. اگر لودر واقعاً نتواند تاریخچه آپشن هفتگی قابل اندازه‌گیری را در بودجه زمانی تفکیک کند، این خانواده در هارنس فعلی با ضرباهنگ هفتگی قابل تست نیست و باید بازطراحی شود (مثلاً چرخه‌های ماهانه کمتر و طولانی‌تر در سراسر بازه کامل) به‌جای

پیاده‌سازی

اسپرد اعتباری پوت هفتگی با ریسک تعریف‌شده روی دریبیت ETH. در هر چرخه سررسید هفتگی (~7 DTE) فریم‌ورک رولینگ-آپشن دو لگ پوت (~5% و ~10% OTM) را تفکیک می‌کند؛ استراتژی آن‌ها را بر اساس استرایک به لگ شورت (استرایک بالاتر، دلتای ~25) و لگ لانگ (استرایک پایین‌تر، دلتای ~10) نگاشت می‌کند، شورت را SELLS و لانگ را BUYS با تعداد قرارداد 1:1 یکسان می‌کند و تا بافر رول پیش از تسویه نقدی اروپایی نگه می‌دارد. ورود مشروط به دو تست غنا در پنجره ورود چرخه است: چولگی سمت نزولی (IV شورت-پوت >= DVOL ATM IV دریبیت x (1 + skew_margin)) و صرف ریسک واریانس (ATM IV >= نوسان تحقق‌یافته 14 روزه گذشته x (1 + vrp_margin)). IV هر لگ از میله پرمیوم-USD خود همان لگ با بلک-شولز معکوس می‌شود. حداکثر زیان هر اسپرد برابر (پهنای استرایک − اعتبار خالص) است که در ورود ثابت می‌شود و سایزینگ دقیقاً همان را ریسک می‌کند: قراردادها = floor(اکوییتی x risk_frac / max_loss)، سقف‌دار به‌طوری که پهنای ناخالص اسپرد داخل 50% اکوییتی بماند و کف‌دار در حداقل ETH 1-قراردادی دریبیت. 3 قابل تنظیم (skew_margin، vrp_margin، risk_frac)؛ لوریج 1.0؛ بدون مسیر معاملاتی پرپ/آندرلاین.

نتایج تأیید

اعتبارسنجی ناموفق بود (لایهٔ 4 — بررسی QA) [class=code_defect]: - [edge_concern] avg_trade_return_pct در محیط sandbox برای 2 معامله با metrics_reliable=false و data_days=1، -45.45% است — این یک ارزیابی عملکرد نیست (بازده بر مبنای ارزش اسمی برای پایه‌های اختیار معامله معنادار نیست، زیرا ارزش اسمی پرمیوم بسیار کمتر از ارزش اسمی بال است و محیط sandbox یک آزمون سریع 1-روزه است). این مورد فقط به‌عنوان زمینه حفظ می‌شود: اگر مشکل بارگذار/دورهٔ بازنگری که در ادامه آمده برطرف شود و نمونهٔ واقعی اختیارهای هفتگی گردآوری……نمایش بیشترنمایش کمتر

اعتبارسنجی ناموفق بود (لایهٔ 4 — بررسی QA) [class=code_defect]: - [edge_concern] avg_trade_return_pct در محیط sandbox برای 2 معامله با metrics_reliable=false و data_days=1، -45.45% است — این یک ارزیابی عملکرد نیست (بازده بر مبنای ارزش اسمی برای پایه‌های اختیار معامله معنادار نیست، زیرا ارزش اسمی پرمیوم بسیار کمتر از ارزش اسمی بال است و محیط sandbox یک آزمون سریع 1-روزه است). این مورد فقط به‌عنوان زمینه حفظ می‌شود: اگر مشکل بارگذار/دورهٔ بازنگری که در ادامه آمده برطرف شود و نمونهٔ واقعی اختیارهای هفتگی گردآوری شود، تحلیلگر باید دوباره بررسی کند که آیا اعتبار خالص دریافتی، هزینهٔ رفت‌وبرگشت 0.03% به‌ازای هر سمت Deribit را در 4 پایه (بازکردن+بستن × فروش کوتاه+خرید بلند)، به‌علاوهٔ هرگونه لغزش ناشی از واگذاری، پوشش می‌دهد یا نه؛ زیرا مزیت ارزش اسمی در اسپرد اعتباری پوت از نظر ساختاری اندک است. - [بحرانی] rolling_options.lookback_days=49 زنجیرهٔ اختیار معاملهٔ قابل‌حل ENTIRE بک‌تست ANY را به حدود 49 روز منتهی به «اکنون» محدود می‌کند = حدود 7 چرخهٔ هفتگی / حدود 14 پایهٔ اختیار معامله، فارغ از سابقهٔ اختیارهای ETH سالهٔ 6.5 در Deribit. راهبرد در بقیهٔ بازه بدون موقعیت می‌ماند و فقط در انتهای آن معامله می‌کند. محیط sandbox این موضوع را به‌صورت تجربی تأیید می‌کند: bars_processed=2400 (حدود 6.5 سال)، اما data_days=1 و total_trades=2 (trades_count=4). برتری مبتنی بر پریمیوم ریسک واریانس + چولگی را نمی‌توان از نویز در حدود 7 چرخه / حدود 14 پایه متمایز کرد — بسیار کمتر از حدود 30-100 معاملهٔ لازم برای داشتن نمونه‌ای قابل‌اندازه‌گیری از اختیارها. این همان تلهٔ هزینهٔ بارگذار در برابر اندازهٔ نمونه-22 است که باعث شد BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp تقریباً مشابه (همان محل معامله، همان lookback_days=49) 4 روز پیش کنار گذاشته شود. استدلال خود توسعه‌دهنده این سقف را تأیید می‌کند («lookback_days برابر با 49 است (7 چرخه، 14 پایهٔ اختیار معامله)، زیرا بارگذار کاتالوگ به‌ازای هر نوع کندل برای هر پایه حدود 10 ثانیه هزینه دارد و زنجیرهٔ بزرگ‌تر خطر عبور از محدودیت زمان اجرای لایهٔ -3 را دارد»). با پیکربندی فعلی، راهبرد هرگز نمی‌تواند بک‌تستی کامل و قابل‌اندازه‌گیری تولید کند. — راه‌حل: روی حدود 7 چرخه متوقف نشوید. پیش از ارسال دوباره، تلهٔ هزینهٔ بارگذار در برابر اندازهٔ نمونه-22 را برطرف کنید: بارگذاری‌های catalog.bars() برای هر پایه را در میان کندل‌ها به‌صورت دسته‌ای/موازی انجام دهید یا ذخیره کنید تا lookback_days بتواند بدون عبور از محدودیت زمان اجرای sandbox به چندین سال چرخهٔ هفتگی (حدود 200-300 چرخه) برسد؛ سپس lookback_days را طوری تنظیم کنید که کل بازهٔ آزمون را پوشش دهد. اگر بارگذار واقعاً نتواند در محدودیت زمانی، سابقهٔ هفتگی اختیار معاملهٔ قابل‌اندازه‌گیری را فراهم کند، این خانواده با بسامد هفتگی در چارچوب فعلی قابل‌آزمون نیست و باید بازطراحی شود (برای مثال، چرخه‌های ماهانهٔ کمتر و با سررسیدهای بلندتر در کل بازه) به‌جای

تاریخچه تکرار

تأیید ناموفق بود (لایه 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 — سناریوهای مصنوعی): پارامترهای استفاده‌شده: ['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 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 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() تعداد 1……نمایش بیشترنمایش کمتر

تأیید ناموفق بود (لایه 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 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() تعداد 1 آرگومان موقعیتی می‌گیرد اما 2 داده شد (bar timestamp: 1735691040000)

تأیید ناموفق بود (لایه 3 — بک‌تست سندباکس): هیچ معامله‌ای تولید نشد نوع بار استفاده‌شده: ETH-PERPETUAL.DERIBIT-1-DAY-LAST-EXTERNAL، بارهای پردازش‌شده: 2400 تشخیص: calculate_signal() هرگز ارزیابی نشد (0 بار ارزیابی‌شده) -> هیچ بار اصلی به مسیر سیگنال قالب پایه نرسید -> اگر on_bar() را بازنویسی می‌کنید، super().on_bar(bar) را فراخوانی کنید؛ بررسی کنید bar_type با داده‌های ابزار مطابقت دارد. آستانه‌های ورود را NOT شل نکنید — منطق ورود هرگز اجرا نشد. اطمینان حاصل کنید که استراتژی شما با داده‌ها و پارامترهای داده‌شده معامله تولید می‌کند.

راستی‌آزمایی ناموفق بود (بازبینی لایه 4 — QA) [class=hypothesis_mismatch]: - [edge_concern] مبنای حکم نیست — انسداد از جنس صحت است، نه عملکرد. (برای ثبت، سندباکس نیز منفی است: -2.9%، PF 0.13، وین 0.125، یک دم -$2,149 روی دفتری که ظاهراً استاپ‌دار است — اما آن نتیجه استراتژی اشتباه است.) - WHOLE-STRATEGY SWAP / MISLINK. فرضیه یک ETH PUT CREDIT SPREAD هفتگی دریبیت است (فروش پوت 25d~، BUY پوت 10d~ — ورتیکال با ریسک تعریف‌شده). کد BTC SHORT STRANGLE دلتا-خنثی هفتگی دریبیت است (نام کلاس، داک‌استرینگ، استدلال iter-3 و……نمایش بیشترنمایش کمتر

راستی‌آزمایی ناموفق بود (بازبینی لایه 4 — QA) [class=hypothesis_mismatch]: - [edge_concern] مبنای حکم نیست — انسداد از جنس صحت است، نه عملکرد. (برای ثبت، سندباکس نیز منفی است: -2.9%، PF 0.13، وین 0.125، یک دم -$2,149 روی دفتری که ظاهراً استاپ‌دار است — اما آن نتیجه استراتژی اشتباه است.) - WHOLE-STRATEGY SWAP / MISLINK. فرضیه یک ETH PUT CREDIT SPREAD هفتگی دریبیت است (فروش پوت 25d~، BUY پوت 10d~ — ورتیکال با ریسک تعریف‌شده). کد BTC SHORT STRANGLE دلتا-خنثی هفتگی دریبیت است (نام کلاس، داک‌استرینگ، استدلال iter-3 و هر مکانیزم استرنگل هستند). هم ابزار AND و هم مکانیزم متفاوت‌اند → آرتیفکت اشتباه تولید/لینک شده، نه این فرضیه. ETH پوت-کردیت-اسپرد صحیح را دوباره تولید/لینک کنید. - ابزار اشتباه: فرضیه ETH است، اما instrument_id و bar_type برابر BTC-PERPETUAL.DERIBIT و rolling_options هستند.underlying برابر 'BTC' است. هیچ ETH در هیچ‌جا وجود ندارد. - ساختار اشتباه / بدون ریسک تعریف‌شده: فرضیه حداکثر زیان را با یک بال پوت PURCHASED ~10d سقف می‌گذارد. کد TWO لگ SELL با NO بال خریداری‌شده ارسال می‌کند؛ دم فقط با یک استاپ نرم پرمیومی میله-بعدی محدود شده (سندباکس largest_loss -$2,149 در برابر avg_win ~$214 نشان می‌دهد دم را سقف نمی‌گذارد) — دقیقاً همان پروفایل بدون سقف که فرضیه از آن پرهیز می‌کند. - لبه اصلی غایب است: سیگنال فرضیه غنای سمت-نزولی-SKEW است (25d-پوت IV در برابر ATM IV) به‌علاوه IV>RV. کد هیچ چولگی محاسبه نمی‌کند — فقط IV/RV VRP میانگین-استرنگل. برداشت پوت-اسکیو که این فرضیه را متمایز می‌کند پیاده‌سازی نشده است.

دلیل کنارگذاری

verification_loop: راستی‌آزمایی ناموفق بود (بازبینی لایه 4 — QA) [class=code_defect]: - [edge_concern] avg_trade_return_pct سندباکس روی 2 معامله -45.45% است با metrics_reliable=false و data_days=1 — این یک حکم عملکردی نیست (بازده بر حسب نوشنال برای لگ‌های آپشن معنادار نیست، جایی که نوشنال پرمیوم << نوشنال بال است، و سندباکس یک تست دود 1 روزه است). این فقط به‌عنوان زمینه منتقل می‌شود: اگر مشکل لودر/لوک‌بک زیر حل شود و نمونه واقعی آپشن هفتگی انباشته شود، تحلیلگر باید دوباره بررسی کند که آیا اعتبار خالص جمع‌شده……نمایش بیشترنمایش کمتر

verification_loop: راستی‌آزمایی ناموفق بود (بازبینی لایه 4 — QA) [class=code_defect]: - [edge_concern] avg_trade_return_pct سندباکس روی 2 معامله -45.45% است با metrics_reliable=false و data_days=1 — این یک حکم عملکردی نیست (بازده بر حسب نوشنال برای لگ‌های آپشن معنادار نیست، جایی که نوشنال پرمیوم << نوشنال بال است، و سندباکس یک تست دود 1 روزه است). این فقط به‌عنوان زمینه منتقل می‌شود: اگر مشکل لودر/لوک‌بک زیر حل شود و نمونه واقعی آپشن هفتگی انباشته شود، تحلیلگر باید دوباره بررسی کند که آیا اعتبار خالص جمع‌شده هزینه رفت‌وبرگشت 0.03%/side دریبیت در سراسر 4 لگ (باز+بسته × شورت+لانگ) به‌علاوه هر لغزش اساینمنت را پوشش می‌دهد یا نه، زیرا لبه بر حسب نوشنال اسپرد اعتباری پوت به‌طور ساختاری نازک است. - [critical] rolling_options.lookback_days=49 زنجیره آپشن قابل تفکیک ENTIRE بک‌تست ANY را به ~49 روز پایانی منتهی به 'اکنون' محدود می‌کند = ~7 چرخه هفتگی / ~14 لگ آپشن، صرف‌نظر از تاریخچه 6.5 ساله آپشن ETH دریبیت. استراتژی برای بقیه پنجره فلت می‌ماند و فقط در انتها معامله می‌کند. سندباکس این را به‌صورت تجربی تأیید می‌کند: bars_processed=2400 (~6.5 سال) با این حال data_days=1 و total_trades=2 (trades_count=4). لبه صرف ریسک واریانس + چولگی را نمی‌توان روی ~7 چرخه / ~14 لگ از نویز تفکیک کرد — بسیار کمتر از ~30-100 معامله لازم برای نمونه آپشن قابل اندازه‌گیری. این دقیقاً همان بن‌بست هزینه-لودر در برابر اندازه-نمونه-22 است که باعث شد استراتژی تقریباً یکسان BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp (همان ونیو، همان lookback_days=49) در لایه 4 چند روز پیش رها شود. استدلال خود توسعه‌دهنده سقف را تأیید می‌کند ('lookback_days برابر 49 است (7 چرخه، 14 لگ آپشن) زیرا لودر کاتالوگ per-bar-type حدود 10 ثانیه به‌ازای هر لگ هزینه دارد و زنجیره بزرگ‌تر ساعت دیواری لایه-3 را به خطر می‌اندازد'). با این پیکربندی، استراتژی هرگز نمی‌تواند بک‌تست کامل قابل اندازه‌گیری تولید کند. — اصلاح: روی ~7 چرخه پاس نکنید. بن‌بست هزینه-لودر در برابر اندازه-نمونه-22 را پیش از ارسال مجدد حل کنید: بارگذاری‌های per-leg catalog.bars() را در سراسر میله‌ها به‌صورت دسته‌ای/موازی یا کش کنید تا lookback_days بتواند بدون نقض ساعت دیواری سندباکس به سال‌ها چرخه هفتگی (~200-300 چرخه) برسد، سپس lookback_days را طوری تنظیم کنید که کل پنجره تست را پوشش دهد. اگر لودر واقعاً نتواند تاریخچه آپشن هفتگی قابل اندازه‌گیری را در بودجه زمانی تفکیک کند، این خانواده در هارنس فعلی با ضرباهنگ هفتگی قابل تست نیست و باید بازطراحی شود (مثلاً چرخه‌های ماهانه کمتر و طولانی‌تر در سراسر بازه کامل) به‌جای