ETH Deribit Put-Credit-Spread รายสัปดาห์ — การเก็บเกี่ยว Volatility-Risk-Premium + Downside-Skew (ออปชันจำกัดความเสี่ยง, ใช้ Skew เป็นเงื่อนไขเข้า, 3 พารามิเตอร์)

สมมติฐาน

กลยุทธ์ออปชัน DEFINED-RISK บน DERIBIT venue ซึ่งเทรดรอบหมดอายุรายสัปดาห์ ETH รอบ โดยขาย downside ที่มีราคาแพงเกินจริงอย่างต่อเนื่องบนผิวความผันผวนของคริปโต หนึ่งครั้งต่อรอบรายสัปดาห์ (อายุสัญญาใกล้สุดประมาณ 5-7 DTE) และ ONLY เมื่อพิสูจน์ได้ว่าประกันความเสี่ยงขาลงมีราคาแพง (put delta 25 มี IV แพงกว่า ATM IV ด้วยส่วนเผื่อ skew AND ATM IV เหนือ realized vol ย้อนหลัง) กลยุทธ์จะเปิดสถานะ PUT CREDIT SPREAD: SELL put delta ประมาณ 25 หนึ่งขา และ BUY put delta ประมาณ 10 หนึ่งขาที่หมดอายุเดียวกัน ขาดทุนสูงสุดจำกัดไว้ที่……แสดงเพิ่มเติมแสดงน้อยลง

กลยุทธ์ออปชัน DEFINED-RISK บน DERIBIT venue ซึ่งเทรดรอบหมดอายุรายสัปดาห์ ETH รอบ โดยขาย downside ที่มีราคาแพงเกินจริงอย่างต่อเนื่องบนผิวความผันผวนของคริปโต หนึ่งครั้งต่อรอบรายสัปดาห์ (อายุสัญญาใกล้สุดประมาณ 5-7 DTE) และ ONLY เมื่อพิสูจน์ได้ว่าประกันความเสี่ยงขาลงมีราคาแพง (put delta 25 มี IV แพงกว่า ATM IV ด้วยส่วนเผื่อ skew AND ATM IV เหนือ realized vol ย้อนหลัง) กลยุทธ์จะเปิดสถานะ PUT CREDIT SPREAD: SELL put delta ประมาณ 25 หนึ่งขา และ BUY put delta ประมาณ 10 หนึ่งขาที่หมดอายุเดียวกัน ขาดทุนสูงสุดจำกัดไว้ที่ (ช่วงห่างระหว่าง strike − เครดิตสุทธิ) ดังนั้นการเคลื่อนไหวรุนแรงของราคาไม่อาจทำให้บัญชีถูกบังคับขายได้ — ตอบโจทย์ข้อกังวลใหญ่ที่สุดในการทบทวนความเสี่ยงของกลยุทธ์ short-vol โดยตรง กลยุทธ์นี้ตั้งใจเติมช่องว่างใหญ่ที่สุดเพียงช่องเดียวในพอร์ตโฟลิโอของ factory: ออปชันมีสัดส่วน 4.7% ของพอร์ต เทียบกับโควตา ≥15% และแทบไม่มีการลงทุนประเภทนี้มาก่อน กลยุทธ์นี้แตกต่างจาก short strangle ธรรมดาโดยตั้งใจ — underlying ต่างกัน (ETH), โครงสร้างต่างกัน (vertical ที่จำกัดความเสี่ยง ไม่ใช่ naked สองด้าน) และสัญญาณต่างกัน (ความแพงของ put-SKEW + VRP ไม่ใช่ IV/RV แบบดิบ) มีพารามิเตอร์ที่ปรับได้เพียง 3 รายการ เพื่อหลีกเลี่ยงการปรับให้เข้ากับข้อมูลมากเกินไปซึ่งทำให้สมมติฐานก่อนหน้า 259 รายการล้มเหลว NOT คือ funding-carry (L33), NOT คือพอร์ต momentum/trend-confluence (ใช้จนหมดแล้ว), NOT คือกลยุทธ์กลับตัว/สวนราคา — แหล่งที่มาของ P&L คือเบี้ยประกันเชิงโครงสร้างบวกเบี้ย put-skew ของคริปโต ไม่ใช่การคาดการณ์ทิศทางราคา

Layer-3 'ไม่มีการเทรดเกิดขึ้น / ประเมินแท่งราคา 0 แท่ง' มีสาเหตุที่ชัดเจนสองประการ และไม่มีข้อใดเกี่ยวกับเกณฑ์การเข้าเทรด (ข้อเสนอแนะระบุถูกต้องว่าไม่ควรผ่อนเกณฑ์) ประการแรก บรรทัด '0 แท่งที่ประเมินแล้ว' เป็นข้อมูลชวนให้เข้าใจผิดสำหรับกลยุทธ์ตระกูลนี้: RollingOptionsStrategy.on_bar เขียนทับ FactoryStrategy.on_bar ทั้งหมดและไม่เคยไปถึง _process_primary ดังนั้น bars_seen จึงเป็น 0 สำหรับกลยุทธ์ rolling-options ทุกตัว รวมถึงตัวที่เทรดตามปกติ — ฉันยืนยันเรื่องนี้ด้วยการอ่าน rolling_options_template.py และ……แสดงเพิ่มเติมแสดงน้อยลง

Layer-3 'ไม่มีการเทรดเกิดขึ้น / ประเมินแท่งราคา 0 แท่ง' มีสาเหตุที่ชัดเจนสองประการ และไม่มีข้อใดเกี่ยวกับเกณฑ์การเข้าเทรด (ข้อเสนอแนะระบุถูกต้องว่าไม่ควรผ่อนเกณฑ์) ประการแรก บรรทัด '0 แท่งที่ประเมินแล้ว' เป็นข้อมูลชวนให้เข้าใจผิดสำหรับกลยุทธ์ตระกูลนี้: RollingOptionsStrategy.on_bar เขียนทับ FactoryStrategy.on_bar ทั้งหมดและไม่เคยไปถึง _process_primary ดังนั้น bars_seen จึงเป็น 0 สำหรับกลยุทธ์ rolling-options ทุกตัว รวมถึงตัวที่เทรดตามปกติ — ฉันยืนยันเรื่องนี้ด้วยการอ่าน rolling_options_template.py และ base_template.py แทนการเพิ่มการเรียก super().on_bar() ซึ่งจะส่งแท่งราคาหลักเข้าไปยังด่านจัดแนวข้ามขาของคลาสฐาน โดยขาออปชันที่มีข้อมูลเป็นช่วง ๆ (กรอบเวลา 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 — โครงร่างที่สืบทอดมาจัดขาตามประเภทออปชันและต้องการหนึ่ง call กับหนึ่ง put (strangle) ดังนั้น P สองขาของ put spread จึงชนกันที่คีย์เดียวกัน ขาที่สองถูกปฏิเสธว่าเป็นรายการซ้ำ การตรวจสอบความพร้อมต้องการขา call ที่ไม่มีอยู่จริง และส่งคำสั่งทุกขาแบบ SELL (เป็น short put เปล่าสองสัญญา ไม่ใช่ vertical ที่จำกัดความเสี่ยง) ตอนนี้จับคู่ขาตาม strike เป็น short/long โดยขายขา short และซื้อขา long ด้วยจำนวนสัญญาที่แคชไว้เท่ากันแบบอะตอมมิก ฉันยังนำ stop แบบทวีคูณของพรีเมียมที่สืบทอดมาออกด้วย: long wing จำกัดผลขาดทุนอยู่แล้ว ดังนั้น stop บนโครงสร้างที่จำกัดความเสี่ยงเพียงทำให้รับรู้ผลขาดทุนที่ยังมีขอบเขตเร็วขึ้นและเพิ่มค่าธรรมเนียม ตรวจสอบการคำนวณขนาดสถานะตั้งแต่ต้นจนจบแล้ว (สเปรดกว้าง 150, เครดิต $22, ขาดทุนสูงสุด $128 -> 15 สัญญา = เสี่ยง 1.9% ของส่วนทุน) ฉันคงทุกอย่างที่ผ่าน Layers 1-2 ไว้ครบ: imports ที่สะอาด, ฟังก์ชันอิสระระดับโมดูล _bar_ts ซึ่งแก้ TypeError จากการผูก staticmethod ใน Layer-2, ตัวแยกวิเคราะห์ DVOL, การหาอินเวอร์สของ Black-Scholes IV และ calculate_signal แบบต่อเนื่อง lookback_days คือ 49 (7 รอบ, ขาออปชัน 14 ขา) เพราะตัวโหลดแค็ตตาล็อกแยกตามชนิดแท่งราคาใช้เวลาประมาณ 10 วินาทีต่อขา และ chain ที่ใหญ่ขึ้นเสี่ยงทำให้เกินเวลาสูงสุดของ Layer-3; ข้อจำกัดนี้จำกัดขนาดตัวอย่างเริ่มต้น และเป็นคุณสมบัติของตัวโหลด ไม่ใช่ของสมมติฐาน

verification_loop: การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct มีผล -45.45% จากการเทรด 2 ครั้ง โดย metrics_reliable=false และ data_days=1 — นี่ไม่ใช่คำตัดสินด้านผลการดำเนินงาน (ผลตอบแทนต่อมูลค่าตามราคาของสถานะไม่มีความหมายกับขาออปชัน ซึ่งมูลค่าพรีเมียมตามราคาตลาด << มูลค่าของ wing และ sandbox นี้เป็นการทดสอบควันระยะ 1 วัน) ผลนี้ถูกรวมไว้เป็นเพียงบริบทเท่านั้น: หากแก้ปัญหาตัวโหลด/ช่วง lookback ด้านล่างได้ และมีตัวอย่าง weekly-options จริงสะสมเพียงพอ……แสดงเพิ่มเติมแสดงน้อยลง

verification_loop: การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct มีผล -45.45% จากการเทรด 2 ครั้ง โดย metrics_reliable=false และ data_days=1 — นี่ไม่ใช่คำตัดสินด้านผลการดำเนินงาน (ผลตอบแทนต่อมูลค่าตามราคาของสถานะไม่มีความหมายกับขาออปชัน ซึ่งมูลค่าพรีเมียมตามราคาตลาด << มูลค่าของ wing และ sandbox นี้เป็นการทดสอบควันระยะ 1 วัน) ผลนี้ถูกรวมไว้เป็นเพียงบริบทเท่านั้น: หากแก้ปัญหาตัวโหลด/ช่วง lookback ด้านล่างได้ และมีตัวอย่าง weekly-options จริงสะสมเพียงพอ นักวิเคราะห์ควรตรวจอีกครั้งว่าเครดิตสุทธิที่เก็บได้ครอบคลุมค่าไปกลับ 0.03%/ด้านของ Deribit ตลอด 4 ขา (เปิด+ปิด x short+long) รวมถึง slippage จากการถูกใช้สิทธิหรือไม่ เพราะ edge ต่อมูลค่าตามราคาของ put-credit-spread มีขนาดบางโดยโครงสร้าง - [วิกฤต] rolling_options.lookback_days=49 จำกัด chain ออปชันที่ ENTIRE ของแบ็กเทสต์ ANY สามารถเรียกดูได้ไว้ที่ประมาณ 49 วันซึ่งสิ้นสุด ณ 'ตอนนี้' = ประมาณ 7 รอบรายสัปดาห์ / ขาออปชันประมาณ 14 ขา โดยไม่ขึ้นกับประวัติออปชัน ETH ระยะ 6.5 ปีของ Deribit กลยุทธ์ไม่มีสถานะตลอดช่วงเวลาที่เหลือและเทรดเฉพาะช่วงท้าย sandbox ยืนยันเรื่องนี้จากข้อมูลจริง: bars_processed=2400 (ประมาณ 6.5 ปี) แต่ data_days=1 และ total_trades=2 (trades_count=4) ไม่สามารถแยก edge จาก variance-risk-premium + skew ออกจากสัญญาณรบกวนได้ด้วยรอบประมาณ 7 รอบ / ขาประมาณ 14 ขา ซึ่งต่ำกว่าการเทรดประมาณ 30-100 ครั้งที่จำเป็นต่อการวัดตัวอย่างออปชันมาก นี่คือปัญหาชั่งน้ำหนักระหว่างต้นทุนตัวโหลดกับขนาดตัวอย่าง-22 แบบเดียวกับที่ทำให้เลิกใช้ BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp ซึ่งแทบจะเหมือนกันทุกประการ (venue เดียวกัน, lookback_days=49 เหมือนกัน) ที่ Layer 4 วันก่อน เหตุผลของผู้พัฒนาเองยอมรับข้อจำกัดนี้ ('lookback_days คือ 49 (รอบ 7 รอบ, ขาออปชัน 14 ขา) เพราะตัวโหลดแค็ตตาล็อกแยกตามชนิดแท่งราคาใช้เวลาประมาณ 10 วินาทีต่อขา และ chain ที่ใหญ่ขึ้นเสี่ยงทำให้เกินเวลาสูงสุดของ Layer-3') เมื่อตั้งค่าเช่นนี้ กลยุทธ์ไม่มีทางสร้างแบ็กเทสต์เต็มรูปแบบที่วัดผลได้ — วิธีแก้: อย่าส่งงานที่มีเพียงประมาณ 7 รอบ แก้ปัญหาชั่งน้ำหนักระหว่างต้นทุนตัวโหลดกับขนาดตัวอย่าง-22 ก่อนส่งใหม่: ประมวลผลแบบเป็นชุด/ขนาน หรือแคชการโหลด catalog.bars() ของแต่ละขาไว้ข้ามแท่งราคา เพื่อให้ lookback_days ครอบคลุมรอบรายสัปดาห์หลายปี (ประมาณ 200-300 รอบ) โดยไม่เกินเวลาสูงสุดของ sandbox จากนั้นตั้ง lookback_days ให้ครอบคลุมหน้าต่างทดสอบทั้งหมด หากตัวโหลดไม่สามารถดึงประวัติ weekly-options ที่วัดผลได้ภายในงบเวลาได้จริง กลยุทธ์ตระกูลนี้ก็ทดสอบไม่ได้ใน harness ปัจจุบันที่ความถี่รายสัปดาห์ และควรออกแบบใหม่ (เช่น ใช้รอบรายเดือนที่ห่างกันและมีอายุนานขึ้นจำนวนน้อยลงตลอดช่วงทั้งหมด) แทน

การนำไปใช้

สเปรดเครดิตพุตรายสัปดาห์ที่จำกัดความเสี่ยงบน Deribit ETH ในแต่ละรอบหมดอายุรายสัปดาห์ (~7 DTE) กรอบการทำงานของออปชันแบบโรลจะกำหนดขาพุตสองขา (~5% และ ~10% OTM); กลยุทธ์จับคู่ขาทั้งสองตามราคาใช้สิทธิเป็นขาชอร์ต (ราคาใช้สิทธิสูงกว่า, ~25-เดลตา) และขาลอง (ราคาใช้สิทธิต่ำกว่า, ~10-เดลตา) โดย SELLS ขาชอร์ตและ BUYS ขาลองด้วยจำนวนสัญญา 1:1 ที่เท่ากัน และถือสถานะไว้จนถึงช่วงกันชนก่อนโรล แล้วจึงชำระราคาเงินสดแบบยุโรป การเปิดสถานะต้องผ่านการทดสอบความแพงสองรายการ ซึ่งวัดในช่วงเวลาเข้ารอบ: ความเบ้ด้านขาลง (พุตชอร์ต IV >=……แสดงเพิ่มเติมแสดงน้อยลง

สเปรดเครดิตพุตรายสัปดาห์ที่จำกัดความเสี่ยงบน Deribit ETH ในแต่ละรอบหมดอายุรายสัปดาห์ (~7 DTE) กรอบการทำงานของออปชันแบบโรลจะกำหนดขาพุตสองขา (~5% และ ~10% OTM); กลยุทธ์จับคู่ขาทั้งสองตามราคาใช้สิทธิเป็นขาชอร์ต (ราคาใช้สิทธิสูงกว่า, ~25-เดลตา) และขาลอง (ราคาใช้สิทธิต่ำกว่า, ~10-เดลตา) โดย SELLS ขาชอร์ตและ BUYS ขาลองด้วยจำนวนสัญญา 1:1 ที่เท่ากัน และถือสถานะไว้จนถึงช่วงกันชนก่อนโรล แล้วจึงชำระราคาเงินสดแบบยุโรป การเปิดสถานะต้องผ่านการทดสอบความแพงสองรายการ ซึ่งวัดในช่วงเวลาเข้ารอบ: ความเบ้ด้านขาลง (พุตชอร์ต IV >= Deribit DVOL ATM IV x (1 + skew_margin)) และส่วนชดเชยความเสี่ยงจากความแปรปรวน (ATM IV >= ความผันผวนที่เกิดขึ้นจริงย้อนหลัง 14 วัน x (1 + vrp_margin)). ค่า IV ของแต่ละขาคำนวณย้อนกลับจากแท่ง USD-พรีเมียมของขานั้นเองด้วย Black-Scholes ขาดทุนสูงสุดต่อสเปรดเท่ากับ (ส่วนต่างราคาใช้สิทธิ - เครดิตสุทธิ) ซึ่งกำหนดไว้เมื่อเข้า และการกำหนดขนาดสถานะรับความเสี่ยงตามจำนวนนี้พอดี: สัญญา = floor(ส่วนของผู้ถือหุ้น x risk_frac / max_loss) โดยจำกัดไม่ให้มูลค่ารวมของความกว้างสเปรดเกิน 50% ของส่วนของผู้ถือหุ้น และกำหนดขั้นต่ำตามจำนวนสัญญา 1 ETH ของ Deribit 3 ค่าปรับแต่ง (skew_margin, vrp_margin, risk_frac); เลเวอเรจ 1.0; ไม่มีเส้นทางการซื้อขาย perp/สินทรัพย์อ้างอิง

ผลการตรวจสอบ

การตรวจสอบล้มเหลว (Layer 4 — การทบทวน QA) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct เป็น -45.45% บน 2 การเทรด โดยมี metrics_reliable=false และ data_days=1 — นี่ไม่ใช่คำตัดสินด้านประสิทธิภาพ (ผลตอบแทนต่อ notional ไม่มีความหมายสำหรับ option legs ซึ่ง premium notional << wing notional และ sandbox เป็นการทดสอบเบื้องต้น 1 วัน) นำส่งต่อเพียงเป็นบริบท: หากปัญหา loader/lookback ด้านล่างได้รับการแก้ไขและมีกลุ่มตัวอย่าง weekly options ที่แท้จริงสะสมขึ้น ผู้วิเคราะห์ควรตรวจสอบใหม่ว่า net credit……แสดงเพิ่มเติมแสดงน้อยลง

การตรวจสอบล้มเหลว (Layer 4 — การทบทวน QA) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct เป็น -45.45% บน 2 การเทรด โดยมี metrics_reliable=false และ data_days=1 — นี่ไม่ใช่คำตัดสินด้านประสิทธิภาพ (ผลตอบแทนต่อ notional ไม่มีความหมายสำหรับ option legs ซึ่ง premium notional << wing notional และ sandbox เป็นการทดสอบเบื้องต้น 1 วัน) นำส่งต่อเพียงเป็นบริบท: หากปัญหา loader/lookback ด้านล่างได้รับการแก้ไขและมีกลุ่มตัวอย่าง weekly options ที่แท้จริงสะสมขึ้น ผู้วิเคราะห์ควรตรวจสอบใหม่ว่า net credit ที่เก็บได้ชดเชย round-trip 0.03%/side ของ Deribit ข้าม 4 legs (open+close x short+long) บวกกับ assignment slippage ใดๆ หรือไม่ เนื่องจาก put-credit-spread per-notional edge มีความบางโดยโครงสร้าง - [critical] rolling_options.lookback_days=49 จำกัด option chain ที่แก้ไขได้ของ ENTIRE ของการ backtest ANY ไว้ที่ ~49 วันที่ลงท้ายด้วย 'now' = ~7 รอบรายสัปดาห์ / ~14 option legs โดยไม่ขึ้นกับประวัติ option ETH ของ Deribit 6.5 ปี กลยุทธ์นั่งนิ่งตลอดช่วงที่เหลือและเทรดเฉพาะที่ปลายเท่านั้น Sandbox ยืนยันเรื่องนี้ในเชิงประจักษ์: bars_processed=2400 (~6.5 ปี) แต่ data_days=1 และ total_trades=2 (trades_count=4) variance-risk-premium + skew edge ไม่สามารถแยกออกจากสัญญาณรบกวนได้บน ~7 รอบ / ~14 legs — ต่ำกว่ามากเมื่อเทียบกับการเทรด ~30-100 รายการที่จำเป็นสำหรับกลุ่มตัวอย่าง options ที่วัดผลได้ นี่คือ catch-22 ของ loader-cost-vs-sample-size ที่แน่นอนซึ่งทำให้ BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp ที่เกือบเหมือนกัน (venue เดียวกัน, lookback_days=49 เดียวกัน) ถูกละทิ้งที่ Layer 4 วันที่แล้ว เหตุผลของนักพัฒนาเองยอมรับขีดจำกัด ('lookback_days เป็น 49 (7 รอบ, 14 option legs) เนื่องจาก per-bar-type catalog loader มีค่าใช้จ่าย ~10s ต่อ leg และ chain ที่ใหญ่กว่าเสี่ยงต่อนาฬิกา Layer-3) ตามที่กำหนดค่าไว้ กลยุทธ์ไม่สามารถผลิต full backtest ที่วัดผลได้เลย — fix: อย่าผ่านบน ~7 รอบ แก้ไข catch-22 ของ loader-cost vs sample-size ก่อนส่งใหม่: batch/parallelize หรือ cache per-leg catalog.bars() loads ข้าม bars เพื่อให้ lookback_days สามารถเข้าถึงรอบรายสัปดาห์หลายปี (~200-300 รอบ) โดยไม่ละเมิดนาฬิกากำแพงของ sandbox จากนั้นตั้ง lookback_days ให้ครอบคลุมหน้าต่างทดสอบเต็ม หาก loader ไม่สามารถแก้ไขประวัติ weekly options ที่วัดผลได้ภายในงบประมาณเวลาอย่างแท้จริง ตระกูลนี้ไม่สามารถทดสอบได้ใน harness ปัจจุบันที่ cadence รายสัปดาห์และควรได้รับการออกแบบใหม่ (เช่น รอบรายเดือนที่น้อยลงและมีวันครบกำหนดนานขึ้นข้ามเต็มช่วง) มากกว่า

ประวัติรอบทดสอบ

การตรวจสอบล้มเหลว (ชั้น 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 รายการ (การประทับเวลาของแท่ง: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 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 — สถานการณ์จำลอง): พารามิเตอร์ที่ใช้: ['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 รายการ (การประทับเวลาของแท่ง: 1735691040000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - zero_volume: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000) - price_gap: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่งได้ 1 รายการ แต่ได้รับ 2 รายการ (การประทับเวลาของแท่ง: 1735691040000)

การตรวจสอบล้มเหลว (ชั้น 3 — การทดสอบย้อนหลังในแซนด์บ็อกซ์): ไม่มีการซื้อขายเกิดขึ้น ประเภทแท่งที่ใช้: ETH-PERPETUAL.DERIBIT-1-DAY-LAST-EXTERNAL, ประมวลผลแท่งแล้ว: 2400 การวินิจฉัย: ไม่เคยมีการประเมิน calculate_signal() (ประเมินแท่งแล้ว 0 แท่ง) -> ไม่มีแท่งหลักใดเข้าสู่เส้นทางสัญญาณของเทมเพลตพื้นฐาน -> หากคุณเขียนทับ on_bar() ให้เรียก super().on_bar(bar); ตรวจสอบว่า bar_type ตรงกับข้อมูลของตราสาร อย่า NOT ผ่อนปรนเกณฑ์การเข้า — ตรรกะการเข้าไม่เคยทำงาน ตรวจสอบให้แน่ใจว่ากลยุทธ์ของคุณสร้างการซื้อขายได้ด้วยข้อมูลและพารามิเตอร์ที่กำหนด

การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=hypothesis_mismatch]: - [edge_concern] ไม่ใช่พื้นฐานของคำตัดสิน — จุดติดขัดคือความเที่ยงตรง ไม่ใช่ผลการดำเนินงาน (เพื่อบันทึกไว้ sandbox ก็ให้ผลติดลบเช่นกัน: -2.9%, PF 0.13, อัตราชนะ 0.125, ขาดทุนช่วงท้าย -$2,149 ในพอร์ตที่อ้างว่ามี stop — แต่ผลนั้นเป็นของกลยุทธ์ผิดตัว) - WHOLE-STRATEGY SWAP / MISLINK สมมติฐานคือ ETH Deribit รายสัปดาห์แบบ PUT CREDIT SPREAD (ขาย put อายุประมาณ 25 วัน, BUY put อายุประมาณ 10 วัน — vertical ที่จำกัดความเสี่ยง) โค้ดเป็น BTC Deribit……แสดงเพิ่มเติมแสดงน้อยลง

การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=hypothesis_mismatch]: - [edge_concern] ไม่ใช่พื้นฐานของคำตัดสิน — จุดติดขัดคือความเที่ยงตรง ไม่ใช่ผลการดำเนินงาน (เพื่อบันทึกไว้ sandbox ก็ให้ผลติดลบเช่นกัน: -2.9%, PF 0.13, อัตราชนะ 0.125, ขาดทุนช่วงท้าย -$2,149 ในพอร์ตที่อ้างว่ามี stop — แต่ผลนั้นเป็นของกลยุทธ์ผิดตัว) - WHOLE-STRATEGY SWAP / MISLINK สมมติฐานคือ ETH Deribit รายสัปดาห์แบบ PUT CREDIT SPREAD (ขาย put อายุประมาณ 25 วัน, BUY put อายุประมาณ 10 วัน — vertical ที่จำกัดความเสี่ยง) โค้ดเป็น BTC Deribit รายสัปดาห์แบบ delta-neutral SHORT STRANGLE (ชื่อคลาส, docstring, เหตุผลของ iter-3 และกลไกทุกอย่างเป็น strangle) ทั้งกลไกของตราสาร AND ต่างกัน → เป็นอาร์ติแฟกต์ที่สร้าง/เชื่อมโยงผิด ไม่ใช่สมมติฐานนี้ สร้าง/เชื่อมโยง put-credit-spread ETH ที่ถูกต้องใหม่ - ตราสารผิด: สมมติฐานคือ ETH แต่ instrument_id และ bar_type เป็น BTC-PERPETUAL.DERIBIT และ rolling_options.underlying คือ 'BTC' ไม่มี ETH อยู่ที่ใดเลย - โครงสร้างผิด / ไม่ได้จำกัดความเสี่ยง: สมมติฐานจำกัดขาดทุนสูงสุดด้วย put wing อายุประมาณ 10 วัน ที่ strike PURCHASED โค้ดส่งคำสั่ง TWO ขาแบบ SELL โดยไม่มี wing ที่ซื้อไว้ NO; การขาดทุนช่วงท้ายถูกจำกัดเพียงด้วย stop พรีเมียมของแท่งถัดไปแบบไม่ตายตัว (sandbox largest_loss -$2,149 เทียบกับ avg_win ~$214 แสดงว่าไม่ได้จำกัดการขาดทุนช่วงท้าย) — ซึ่งเป็นรูปแบบไม่จำกัดความเสี่ยงแบบที่สมมติฐานต้องการหลีกเลี่ยงพอดี - ไม่มี edge หลัก: สัญญาณของสมมติฐานคือความแพงของ downside-SKEW (25 ของ put อายุ IV เทียบกับ ATM IV) ร่วมกับ IV>RV โค้ดไม่ได้คำนวณ skew — คำนวณเพียงค่าเฉลี่ย IV/RV VRP เท่านั้น ยังไม่ได้พัฒนาการเก็บเกี่ยว put-skew ซึ่งเป็นสิ่งที่ทำให้สมมติฐานนี้แตกต่าง

เหตุผลที่ยกเลิก

verification_loop: การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct มีผล -45.45% จากการเทรด 2 ครั้ง โดย metrics_reliable=false และ data_days=1 — นี่ไม่ใช่คำตัดสินด้านผลการดำเนินงาน (ผลตอบแทนต่อมูลค่าตามราคาของสถานะไม่มีความหมายกับขาออปชัน ซึ่งมูลค่าพรีเมียมตามราคาตลาด << มูลค่าของ wing และ sandbox นี้เป็นการทดสอบควันระยะ 1 วัน) ผลนี้ถูกรวมไว้เป็นเพียงบริบทเท่านั้น: หากแก้ปัญหาตัวโหลด/ช่วง lookback ด้านล่างได้ และมีตัวอย่าง weekly-options จริงสะสมเพียงพอ……แสดงเพิ่มเติมแสดงน้อยลง

verification_loop: การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=code_defect]: - [edge_concern] Sandbox avg_trade_return_pct มีผล -45.45% จากการเทรด 2 ครั้ง โดย metrics_reliable=false และ data_days=1 — นี่ไม่ใช่คำตัดสินด้านผลการดำเนินงาน (ผลตอบแทนต่อมูลค่าตามราคาของสถานะไม่มีความหมายกับขาออปชัน ซึ่งมูลค่าพรีเมียมตามราคาตลาด << มูลค่าของ wing และ sandbox นี้เป็นการทดสอบควันระยะ 1 วัน) ผลนี้ถูกรวมไว้เป็นเพียงบริบทเท่านั้น: หากแก้ปัญหาตัวโหลด/ช่วง lookback ด้านล่างได้ และมีตัวอย่าง weekly-options จริงสะสมเพียงพอ นักวิเคราะห์ควรตรวจอีกครั้งว่าเครดิตสุทธิที่เก็บได้ครอบคลุมค่าไปกลับ 0.03%/ด้านของ Deribit ตลอด 4 ขา (เปิด+ปิด x short+long) รวมถึง slippage จากการถูกใช้สิทธิหรือไม่ เพราะ edge ต่อมูลค่าตามราคาของ put-credit-spread มีขนาดบางโดยโครงสร้าง - [วิกฤต] rolling_options.lookback_days=49 จำกัด chain ออปชันที่ ENTIRE ของแบ็กเทสต์ ANY สามารถเรียกดูได้ไว้ที่ประมาณ 49 วันซึ่งสิ้นสุด ณ 'ตอนนี้' = ประมาณ 7 รอบรายสัปดาห์ / ขาออปชันประมาณ 14 ขา โดยไม่ขึ้นกับประวัติออปชัน ETH ระยะ 6.5 ปีของ Deribit กลยุทธ์ไม่มีสถานะตลอดช่วงเวลาที่เหลือและเทรดเฉพาะช่วงท้าย sandbox ยืนยันเรื่องนี้จากข้อมูลจริง: bars_processed=2400 (ประมาณ 6.5 ปี) แต่ data_days=1 และ total_trades=2 (trades_count=4) ไม่สามารถแยก edge จาก variance-risk-premium + skew ออกจากสัญญาณรบกวนได้ด้วยรอบประมาณ 7 รอบ / ขาประมาณ 14 ขา ซึ่งต่ำกว่าการเทรดประมาณ 30-100 ครั้งที่จำเป็นต่อการวัดตัวอย่างออปชันมาก นี่คือปัญหาชั่งน้ำหนักระหว่างต้นทุนตัวโหลดกับขนาดตัวอย่าง-22 แบบเดียวกับที่ทำให้เลิกใช้ BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp ซึ่งแทบจะเหมือนกันทุกประการ (venue เดียวกัน, lookback_days=49 เหมือนกัน) ที่ Layer 4 วันก่อน เหตุผลของผู้พัฒนาเองยอมรับข้อจำกัดนี้ ('lookback_days คือ 49 (รอบ 7 รอบ, ขาออปชัน 14 ขา) เพราะตัวโหลดแค็ตตาล็อกแยกตามชนิดแท่งราคาใช้เวลาประมาณ 10 วินาทีต่อขา และ chain ที่ใหญ่ขึ้นเสี่ยงทำให้เกินเวลาสูงสุดของ Layer-3') เมื่อตั้งค่าเช่นนี้ กลยุทธ์ไม่มีทางสร้างแบ็กเทสต์เต็มรูปแบบที่วัดผลได้ — วิธีแก้: อย่าส่งงานที่มีเพียงประมาณ 7 รอบ แก้ปัญหาชั่งน้ำหนักระหว่างต้นทุนตัวโหลดกับขนาดตัวอย่าง-22 ก่อนส่งใหม่: ประมวลผลแบบเป็นชุด/ขนาน หรือแคชการโหลด catalog.bars() ของแต่ละขาไว้ข้ามแท่งราคา เพื่อให้ lookback_days ครอบคลุมรอบรายสัปดาห์หลายปี (ประมาณ 200-300 รอบ) โดยไม่เกินเวลาสูงสุดของ sandbox จากนั้นตั้ง lookback_days ให้ครอบคลุมหน้าต่างทดสอบทั้งหมด หากตัวโหลดไม่สามารถดึงประวัติ weekly-options ที่วัดผลได้ภายในงบเวลาได้จริง กลยุทธ์ตระกูลนี้ก็ทดสอบไม่ได้ใน harness ปัจจุบันที่ความถี่รายสัปดาห์ และควรออกแบบใหม่ (เช่น ใช้รอบรายเดือนที่ห่างกันและมีอายุนานขึ้นจำนวนน้อยลงตลอดช่วงทั้งหมด) แทน