Deribit BTC กลยุทธ์เขียนพุต OTM แบบมีเงินสดค้ำประกันรายสัปดาห์ — เก็บเกี่ยวส่วนชดเชยความเสี่ยงจากความผันผวน คัดกรองด้วย IV>RV และแนวโน้ม

สมมติฐาน

กลยุทธ์ PUT-WRITING แบบเป็นระบบสำหรับออปชันรายสัปดาห์ BTC บน Deribit ซึ่งมีขาเดียวและมีหลักประกันครบถ้วน (พุตแบบมีเงินสดค้ำประกัน) เพื่อเก็บเกี่ยวส่วนชดเชยความเสี่ยงจากความผันผวนของคริปโต (VRP): ความผันผวนแฝงของออปชัน BTC สูงกว่าความผันผวนที่เกิดขึ้นจริงในเวลาต่อมาอย่างเป็นโครงสร้าง ดังนั้นผู้ขายประกันจึงได้รับความได้เปรียบสะสมเมื่อเวลาผ่านไป นี่คือกลยุทธ์ออปชัน FIRST ของโรงงาน และช่วยเติมช่องว่างโควตาที่ใหญ่ที่สุด (ออปชัน 0.1% เทียบกับเป้าหมาย >=15%) พร้อมกับลดสัดส่วนที่มากเกินไปของ 80% BINANCE ในแต่ละรอบ……แสดงเพิ่มเติมแสดงน้อยลง

กลยุทธ์ PUT-WRITING แบบเป็นระบบสำหรับออปชันรายสัปดาห์ BTC บน Deribit ซึ่งมีขาเดียวและมีหลักประกันครบถ้วน (พุตแบบมีเงินสดค้ำประกัน) เพื่อเก็บเกี่ยวส่วนชดเชยความเสี่ยงจากความผันผวนของคริปโต (VRP): ความผันผวนแฝงของออปชัน BTC สูงกว่าความผันผวนที่เกิดขึ้นจริงในเวลาต่อมาอย่างเป็นโครงสร้าง ดังนั้นผู้ขายประกันจึงได้รับความได้เปรียบสะสมเมื่อเวลาผ่านไป นี่คือกลยุทธ์ออปชัน FIRST ของโรงงาน และช่วยเติมช่องว่างโควตาที่ใหญ่ที่สุด (ออปชัน 0.1% เทียบกับเป้าหมาย >=15%) พร้อมกับลดสัดส่วนที่มากเกินไปของ 80% BINANCE ในแต่ละรอบ กลยุทธ์เลือกวันหมดอายุรายสัปดาห์ของ Deribit BTC ที่ใกล้ที่สุด (เหลือ 5-9 วัน) แล้วขายพุต OTM ที่เดลตาประมาณ 20 ONE โดยมีหลักประกันเป็นเงินสด FULLY (ไม่มีเลเวอเรจ ไม่มีความเสี่ยงถูกเรียกหลักประกัน — การขาดทุนสูงสุดจำกัดอยู่ที่ราคาใช้สิทธิ กล่าวคือเทียบเท่ากับการตกลงซื้อ BTC ในราคาส่วนลด) สถานะถูกควบคุมด้วยตัวกรองเชิงโครงสร้างสองตัว: (1) ตัวกรอง VRP — ขายพุตเฉพาะเมื่อความผันผวนแฝง ATM ระยะ 7 วัน (จากฟีด greeks/IV ของ Deribit) สูงกว่าความผันผวนที่เกิดขึ้นจริงย้อนหลังระยะ 10 วัน โดยมีส่วนต่าง (IV/RV > ประมาณ 1.15) เพื่อให้ขายประกันเฉพาะเมื่อมีราคาสูงคุ้มค่าเท่านั้น; (2) ตัวกรองภาวะตลาด/แนวโน้ม — ขายพุตเฉพาะเมื่อราคาสปอตของ BTC อยู่เหนือ SMA ระยะ 50 วัน เพื่อหลีกเลี่ยงการขายพุตระหว่างแนวโน้มขาลงที่ยืนยันแล้วหรือขณะราคากำลังร่วงแรง (ความเสี่ยงหางที่สำคัญที่สุดของการขายพุต) การใช้ตราสารเดียวต่อรอบทำให้การทดสอบย้อนหลังอยู่บนเส้นทางการทำงานที่สะอาด และหลีกเลี่ยงสิ่งผิดเพี้ยนจากการปรับแต่งหลายขา/ฟีดขาเพิ่มเติม ผู้พัฒนาหมุนสถานะรายสัปดาห์ผ่านตราสารพุต BTC ของ Deribit ที่มีการจดทะเบียน (กลยุทธ์เลือกราคาใช้สิทธิ/วันหมดอายุที่เหมาะสมจากแค็ตตาล็อกในแต่ละรอบ)

การทำซ้ำ 3 เปลี่ยนค่าการกำหนดค่า ONE; ตรรกะของกลยุทธ์เหมือนกับการทำซ้ำ 2 ทุกไบต์ (มีเพียงเอกสารกำกับ PERF ที่ปรับปรุงเพื่อบันทึกการวินิจฉัย) ฉันทำโปรไฟล์การหมดเวลาจริงแทนการคาดเดาอีกครั้ง: กระบวนการย่อยในแซนด์บ็อกซ์เริ่มทำงาน 22:05:22 และถูกยุติที่ 22:10:24 (302 วินาที) โดยมีต้นทุนจากงานต่อแท่ง NOT — สถานะทั้งหมดต่อแท่งเป็น O(1) อยู่แล้วหลังการทำซ้ำ 2 สาเหตุคือจำนวน QUERIES ของแค็ตตาล็อก BacktestRunner เรียก catalog.bars() หนึ่งครั้งต่อชนิดแท่ง และเมื่อมีไดเรกทอรีแท่ง 35,765 รายการใน data/catalog……แสดงเพิ่มเติมแสดงน้อยลง

การทำซ้ำ 3 เปลี่ยนค่าการกำหนดค่า ONE; ตรรกะของกลยุทธ์เหมือนกับการทำซ้ำ 2 ทุกไบต์ (มีเพียงเอกสารกำกับ PERF ที่ปรับปรุงเพื่อบันทึกการวินิจฉัย) ฉันทำโปรไฟล์การหมดเวลาจริงแทนการคาดเดาอีกครั้ง: กระบวนการย่อยในแซนด์บ็อกซ์เริ่มทำงาน 22:05:22 และถูกยุติที่ 22:10:24 (302 วินาที) โดยมีต้นทุนจากงานต่อแท่ง NOT — สถานะทั้งหมดต่อแท่งเป็น O(1) อยู่แล้วหลังการทำซ้ำ 2 สาเหตุคือจำนวน QUERIES ของแค็ตตาล็อก BacktestRunner เรียก catalog.bars() หนึ่งครั้งต่อชนิดแท่ง และเมื่อมีไดเรกทอรีแท่ง 35,765 รายการใน data/catalog แต่ละครั้งใช้เวลาคงที่ประมาณ FIXED ~8.4 วินาที ไม่ว่าปริมาณข้อมูลจะเป็นเท่าใด (วัดบนเครื่องนี้: BTC-PERPETUAL 1-DAY, 365 แท่ง -> 8.31 วินาที; BTC-10APR26-63000-P, 19 แท่ง -> 8.27 วินาที; BTC-17APR26-68000-P, 24 แท่ง -> 8.77 วินาที) ห่วงโซ่รายสัปดาห์ 365 วันขยายเป็น 52 ขา (ยืนยันในบันทึกการทำงาน: 'Deribit chain discovered contracts=52') ดังนั้นการโหลดข้อมูลเพียงอย่างเดียวใช้เวลา 53 * 8.4 วินาที ~= 445 วินาที — นี่คือเหตุผลพอดีที่การสลับจาก 1-HOUR -> 1-DAY ในการทำซ้ำ 2 (24x แท่งน้อยลง) ไม่ได้เปลี่ยนอะไร วิธีแก้: lookback_days 365 -> 150 ทำให้เหลือขารายสัปดาห์ประมาณ 21 ดังนั้นการโหลดใช้เวลาประมาณ 22 * 8.4 วินาที ~= 185 วินาที และการทำงานทั้งหมดจะใช้เวลาราว 230 วินาที โดยมีเวลาเผื่อเหลือใต้ขีดจำกัด 300 วินาที ฉันยังทดลองใช้ด่านผสม FULL กับข้อมูลจริงในช่วงเวลาที่สั้นลงก่อนส่งงานด้วย (ตามบทเรียนเรื่องด่านผสม): ในช่วง 150 วันที่ผ่านมา ด่าน VRP เปิดอยู่ 97/150 วัน ด่านแนวโน้มเปิดอยู่ 70/150, BOTH ใน 51 วัน ครอบคลุม 11 จาก 23 สัปดาห์ตามปฏิทิน — ดังนั้นห่วงโซ่จะเขียนพุตประมาณ 8-11 รายการ ผ่านเกณฑ์ Layer-3 ที่กำหนดการซื้อขายอย่างน้อย 1 รายการได้อย่างสบาย เพื่อชดเชยตัวอย่างบางส่วนที่เสียไปจากการทำห่วงโซ่ให้สั้นลง ฉันขยาย entry_window_hours 96 -> 120 (ยังอยู่ในช่วง entry..expiry-24h ของฐาน) ดังนั้นสัปดาห์ที่ด่านเปิดกลางรอบก็ยังถูกนำมาเขียนได้ ประเด็นแลกเปลี่ยนที่ต้องแจ้งนักวิเคราะห์: ตอนนี้แบ็กเทสต์จริงครอบคลุมประมาณ 5 เดือน / ประมาณ 10 รายการซื้อขาย แทนที่จะเป็นหนึ่งปี — ตัวอย่างนี้มีน้อย แต่เป็นข้อจำกัดที่ถูกบังคับด้วยขีดจำกัดของแซนด์บ็อกซ์เมื่อพิจารณาต้นทุนแค็ตตาล็อกประมาณ 8.4 วินาทีต่อขา และมีบันทึกการคำนวณไว้ในเอกสารกำกับ (เพดานอยู่ที่ประมาณ 30 คิวรี) เพื่อให้ขยายช่วงเวลาได้อีกครั้งหากแก้ต้นทุนคิวรีแค็ตตาล็อกในระบบต้นทางได้

verifying_stuck_3_timeouts

การนำไปใช้

กลยุทธ์เขียนพุต OTM แบบมีเงินสดค้ำประกันรายสัปดาห์ บนออปชัน BTC ของ Deribit (ขาเดียว, ~6% OTM, ~7 DTE) หมุนสถานะทุกสัปดาห์และปิดก่อนหมดอายุ 24 ชั่วโมง เขียนพุตเฉพาะเมื่อด่านเชิงโครงสร้างทั้งสองเปิดอยู่: ด่าน VRP (ความผันผวนโดยนัยของ Deribit DVOL >= ความผันผวนที่เกิดขึ้นจริงย้อนหลัง 10 วัน 1.15x) และด่านแนวโน้ม (ราคาสปอตอยู่เหนือ SMA ระยะ 50 วัน) การกำหนดขนาดใช้หลักประกันเป็นเงินสดและอิงส่วนของผู้ถือหุ้น (0.85 ของส่วนของผู้ถือหุ้นหารด้วยราคาสปอต ปัดลงให้เป็นสัญญา 0.1) เลเวอเรจ 1.0 ดังนั้นการขาดทุนสูงสุดจำกัดอยู่ที่ราคาใช้สิทธิ สัญญา Perp ของ Deribit ใช้เป็นเพียงเครื่องมือหลักสำหรับกำหนดเวลาหมุนรายสัปดาห์เท่านั้น ไม่มีการซื้อขายสินทรัพย์อ้างอิง

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

การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=not_measurable]: - [edge_concern] ตัวชี้วัดไร้ที่ติของแซนด์บ็อกซ์ (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) เป็น BENIGN-WINDOW ARTIFACT — ความเสี่ยงทั้งหมดของการเขียนพุตแบบมีเงินสดค้ำประกันคือความเสี่ยงหางจากตลาดร่วงหนัก และช่วงเวลาประมาณ 5 เดือนนี้ไม่มีเหตุการณ์นั้นเลย พุตทุกสัญญาจึงชนะ การเขียนพุตทุกแบบดูเหมือนได้กำไรโดยไม่มีความเสี่ยงจนกว่าจะเกิดการลดลงของเงินทุน avg_trade_return_pct 91.4%……แสดงเพิ่มเติมแสดงน้อยลง

การตรวจสอบไม่ผ่าน (Layer 4 — การทบทวน QA) [class=not_measurable]: - [edge_concern] ตัวชี้วัดไร้ที่ติของแซนด์บ็อกซ์ (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) เป็น BENIGN-WINDOW ARTIFACT — ความเสี่ยงทั้งหมดของการเขียนพุตแบบมีเงินสดค้ำประกันคือความเสี่ยงหางจากตลาดร่วงหนัก และช่วงเวลาประมาณ 5 เดือนนี้ไม่มีเหตุการณ์นั้นเลย พุตทุกสัญญาจึงชนะ การเขียนพุตทุกแบบดูเหมือนได้กำไรโดยไม่มีความเสี่ยงจนกว่าจะเกิดการลดลงของเงินทุน avg_trade_return_pct 91.4% คำนวณเทียบกับค่าพรีเมียม (ไม่ใช่มูลค่าตามราคาใช้สิทธิ และเทียบกับเกณฑ์ขั้นต่ำของสปอต/ฟิวเจอร์สไม่ได้) และ total_commission 0.0 จากการซื้อขายออปชัน Deribit 16 รายการ ชวนให้สงสัยว่าไม่มีการคิดค่าธรรมเนียมออปชัน ทั้งสองอย่างยิ่งทำให้ผลลัพธ์ที่ไม่มีข้อมูลบ่งชี้ชัดเจนนี้ดูดีเกินจริง - วัดผลไม่ได้ภายใต้การกำหนดค่านี้ rolling_options.lookback_days ถูกตรึงไว้ที่ 150 (การแก้ของนักพัฒนาสำหรับปัญหาหมดเวลาจากคิวรีแค็ตตาล็อกประมาณ 8.4 วินาทีต่อขา) ทำให้ห่วงโซ่ที่ซื้อขายได้จำกัดอยู่ที่ประมาณ 5 เดือน และได้การเขียนพุตรายสัปดาห์เพียง 16 ครั้ง ขีดจำกัดนี้ฝังอยู่ในการกำหนดค่า ดังนั้นแบ็กเทสต์เต็มจึงถูกจำกัดเหมือนกัน (ประมาณ 16 รายการ ต่ำกว่าเกณฑ์ขั้นต่ำของออปชันที่ประมาณ 30 รายการ L26) การเขียนพุต 16 รายการที่ไม่มีเหตุการณ์หางไม่สามารถประเมินกลยุทธ์เขียนพุต VRP ซึ่งความได้เปรียบ/ความเสี่ยงกำหนดโดยการลดลงของเงินทุนจากตลาดร่วงหนักได้ ช่วงเวลาต้องยาวหลายปีเพื่อให้ครอบคลุมเหตุการณ์หางซ้ายจริง มีข้อมูล DVOL และข้อมูลห่วงโซ่ Deribit อยู่แล้ว อุปสรรคคือค่าคิวรีแค็ตตาล็อกต่อขาจากระบบต้นทาง ให้พักงานไว้จนกว่าจะแก้ต้นทุนดังกล่าว เพื่อให้รันห่วงโซ่หลายปี (>=2 ปี, การเขียนพุตที่ผ่านด่านประมาณ 50-100 ครั้งในช่วงตลาดร่วงหลายรอบ) ได้ภายในงบ อย่าเพียงเพิ่ม lookback_days เพราะจะทำให้หมดเวลาอีกครั้ง - total_commission 0.0 จากการซื้อขายออปชัน Deribit 16 รายการ — Deribit คิดค่าธรรมเนียมออปชัน (ขั้นต่ำ 0.03% ของสินทรัพย์อ้างอิง หรือ 12.5% ของค่าพรีเมียม บวกค่าชำระราคา) หากเอนจินไม่คิดค่าคอมมิชชันออปชัน กำไรขาดทุนจากการเก็บเกี่ยวค่าพรีเมียมจะสูงเกินจริง ประเด็นนี้เป็นข้อกังวลเรื่องการคิดค่าธรรมเนียมของเอนจินสำหรับนักวิเคราะห์/วิศวกรแบ็กเทสต์ ไม่ใช่ข้อผิดพลาดในโค้ดกลยุทธ์

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

การตรวจสอบไม่ผ่าน (Layer 3 — แบ็กเทสต์ในแซนด์บ็อกซ์): การทดสอบเบื้องต้นเกินขีดจำกัดเวลาจริง 300 วินาที โดยส่วนใหญ่หมายถึงมีงานต่อแท่งที่เพิ่มตามความยาวของประวัติ — เช่น สแกนอนุกรมเงินทุน/ข้อมูลเสริมทั้งหมดซ้ำ หรือสร้างรายการใหม่แล้วเรียก min()/sorted() ภายใน calculate_signal()/on_bar() ในทุกแท่ง คำนวณอาร์เรย์เวลาประทับที่เรียงแล้ว ONCE ไว้ล่วงหน้าใน __init__ แล้วใช้ bisect หรือแคชผลค้นหาโดยใช้เวลาประทับเป็นคีย์ เพื่อให้ต้นทุนต่อแท่งเป็น O(log n) แทน O(n)

การตรวจสอบไม่ผ่าน (ชั้น 4 — การทบทวน QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — รอบการหมดอายุออปชัน x เงื่อนไขกรอง) แซนด์บ็อกซ์สร้างการเทรด 12 ครั้งในช่วง data_days=12 โดยมีรูปแบบเสื่อมสภาพที่วัดผลไม่ได้อย่างชัดเจน: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (ตัวเลขต่อการเทรดที่เป็นไปไม่ได้สำหรับการขายพุตแบบมีหลักประกันเต็มจำนวน — การคำนวณมูลค่าตามสัญญา/ผลตอบแทนของออปชันไม่น่าเชื่อถือ) สิ่งเหล่านี้ไม่ใช่สัญญาณผลการดำเนินงานจริง ตาม L26 (หน้าต่าง/วันหมดอายุ……แสดงเพิ่มเติมแสดงน้อยลง

การตรวจสอบไม่ผ่าน (ชั้น 4 — การทบทวน QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — รอบการหมดอายุออปชัน x เงื่อนไขกรอง) แซนด์บ็อกซ์สร้างการเทรด 12 ครั้งในช่วง data_days=12 โดยมีรูปแบบเสื่อมสภาพที่วัดผลไม่ได้อย่างชัดเจน: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (ตัวเลขต่อการเทรดที่เป็นไปไม่ได้สำหรับการขายพุตแบบมีหลักประกันเต็มจำนวน — การคำนวณมูลค่าตามสัญญา/ผลตอบแทนของออปชันไม่น่าเชื่อถือ) สิ่งเหล่านี้ไม่ใช่สัญญาณผลการดำเนินงานจริง ตาม L26 (หน้าต่าง/วันหมดอายุ x ผ่านเงื่อนไขกรอง): lookback_days ถูกลด 365->150 เพื่อให้อยู่ภายในขีดจำกัด 300s และเงื่อนไขกรองแบบผสม VRP+แนวโน้มเปิดเพียงประมาณ 11 จาก 23 สัปดาห์ -> พุตประมาณ 8-11 รายการ การเทรดประมาณ 10 ครั้งต่ำกว่าเกณฑ์ขั้นต่ำประมาณ 30 ครั้งมาก และไม่อาจแยกความได้เปรียบ VRP ออกจากสัญญาณรบกวนได้ - INFRASTRUCTURE HARD-CAP ทำให้ตัวอย่างวัดผลไม่ได้ที่การกำหนดพารามิเตอร์ ANY ตามเอกสารประกอบโค้ดของผู้พัฒนาเอง การเรียก catalog.bars() แต่ละครั้งมีต้นทุนคงที่ประมาณ 8.4s และการรันถูกจำกัดไว้ที่ประมาณ 30 ครั้ง (ประมาณ 250s) ภายใต้ระยะหมดเวลา 300s ดังนั้นแบ็กเทสต์จึงครอบคลุม AT MOST ประมาณ 30 ขารายสัปดาห์ (ประมาณ 7 เดือน) -> มีการเทรดประมาณ 15 ครั้งหลังใช้เงื่อนไขกรอง ต้องบังคับให้ lookback_days=150 ทำงานต่อเพื่อให้รอดพ้นระยะหมดเวลา การปรับเกณฑ์ใดก็ไม่อาจหลุดพ้นเพดานการเรียกแค็ตตาล็อกประมาณ 30 ขา - PUT-WRITE TAIL-RISK MASKING ตัวอย่าง win_rate 1.0 ที่มีการเทรดประมาณ 10 ครั้งเป็นผลลัพธ์ที่ MOST ทำให้เข้าใจผิดสำหรับพุตที่ขายไว้: หมายความว่าในหน้าต่างนั้นไม่มีสัปดาห์ที่ตลาดร่วงหนัก ซึ่งเป็นช่วงเดียวกับที่พุตแบบมีหลักประกันเต็มจำนวนจะขาดทุนหนักบริเวณหางซ้าย แซนด์บ็อกซ์ที่ดูดีเกินจริง (ชนะทั้งหมด ดรอดาวน์เป็นศูนย์ Sharpe 31) มาจากการลดลงของค่าเวลาในสัปดาห์ที่ตลาดสงบ และซ่อนความเสี่ยงเดียวที่สำคัญไว้ - โค้ด CORRECT และนำสมมติฐานไปใช้ได้ตรงตามที่ตั้งใจ: ทิศทางการขายพุต (P -> SELL), การกำหนดขนาดสถานะโดยจำกัดราคาใช้สิทธิและมีเงินสดค้ำประกันเต็มจำนวน, เงื่อนไขกรอง VRP (atm_iv >= rv*vrp_ratio), เงื่อนไขกรองแนวโน้ม (ราคาตลาด > SMA), การค้นหาค่า DVOL ตามลำดับเหตุและผล (searchsorted right-1, ไม่มีการมองข้อมูลอนาคต), ปิดขาก่อนการชำระราคาแบบยุโรป 24h, ระบุกรณีไหลผ่านโดยไม่มีเงื่อนไขกรองไว้เมื่อ IV หายไป (ไม่มีการสลับไปใช้ความได้เปรียบอื่นโดยไม่แจ้ง) การตรวจสอบความถูกต้องของออปชัน (#12) ผ่าน บันทึกเรื่องนี้ไว้เพื่อไม่ให้ผู้พัฒนาเสียเวลาตามหาข้อผิดพลาดในการเขียนโค้ดที่ไม่มีอยู่จริง