BTC การเทรดสวนทาง Liquidation Cascade แบบ Long-Short: ทำกำไรจากการย้อนกลับของราคาที่ Overshoot บนแท่ง BTCUSDT.BINANCE 1H เมื่อปริมาณการล้างพอร์ตพุ่งขึ้น Z > 3 พร้อมการเคลื่อนไหวของราคา 2% ในทิศทางเดียวกัน

กลยุทธ์ mean-reversion แบบ long-short บน perpetual futures BTCUSDT.BINANCE USD-M ที่เทรดสวนทางกับ forced-liquidation cascades ใช้แท่ง perp BINANCE USD-M (ข้อมูลที่พิสูจน์แล้วว่าสะอาด) + ข้อมูลเสริม liquidations (PostgreSQL — สตรีมที่แตกต่างจากการทดลอง pipeline ก่อนหน้า) สมมติฐาน: เมื่อปริมาณการล้างพอร์ตรายชั่วโมงบน BTCUSDT พุ่งขึ้น >3 ส่วนเบี่ยงเบนมาตรฐานเหนือ baseline 30-วันของมัน AND ราคาเคลื่อนไหว ≥2% ในทิศทางเดียวกันใน 4 ชั่วโมงก่อนหน้า ตลาดอยู่ใน FORCED-FLOW OVERSHOOT — ผู้ขายรายขอบ (ใน long-liquidation cascade) หรือผู้ซื้อรายขอบ (ใน short-squeeze) เป็นเชิงกล ไม่ใช่ตามธรรมชาติ เมื่อ flow แบบบังคับหมดลง (โดยทั่วไปภายใน 4-12 ชั่วโมง) ผู้เข้าร่วมตามธรรมชาติจะเข้ามาที่ราคาที่ dislocated และการเคลื่อนไหวจะย้อนกลับบางส่วน กลยุทธ์จะ LONG เมื่อ long-side liquidations เป็น cascade (ราคา overshoot DOWN) และ SHORT เมื่อ short-side liquidations เป็น cascade (ราคา overshoot UP) สิ่งนี้เติมเต็ม bucket ที่มีการเป็นตัวแทนน้อย FIVE: ทิศทาง long-short (14.2% → สู่ 45%), กลไกที่ขับเคลื่อนด้วย liquidations (ไม่มีกลยุทธ์ใดในการทดลอง 459 ที่ใช้สตรีมข้อมูลนี้), microstructure เฉพาะ crypto (edge ที่เป็นไปไม่ได้ใน TradFi), การถือระยะกลาง (รอบ 4-12h), และขับเคลื่อนด้วยข้อมูลเสริม (ซึ่งสะอาดในแคตตาล็อกของเรา ไม่เหมือนแท่ง BINANCE_SPOT) กลไกได้รับการบันทึกในงานวิจัย crypto microstructure (Kaiko 2022, Coin Metrics 2023) — liquidation cascades สร้างการ overshoot ของราคา 1.5-3% อย่างเป็นระบบที่ย้อนกลับบางส่วนภายใน 6-18 ชั่วโมงเมื่อองค์ประกอบ forced-flow ของ order flow จางหายไป ใช้แท่ง perp ONLY BINANCE USD-M + ข้อมูล liquidations ที่เก็บใน Postgres — ไม่มีแท่ง BINANCE_SPOT (ซึ่งล้มเหลวในการยืนยัน Layer 3 ซ้ำๆ ในเซสชั่นนี้) ขนาดตำแหน่ง: 15% ของ equity ต่อทิศทาง ความเสี่ยงต่อการเทรด: 1.5% ของ equity จำกัดด้วย stop-loss

Iteration-2 การแก้ไขขั้นต่ำสำหรับความล้มเหลว 'No trades produced' ของ Layer-3 โดยไม่มีการถดถอยของ layers ก่อนหน้า ต้นเหตุ: การเข้าต้องการ liquidation spike >= 3-sigma ที่วัดใน 1-ชั่วโมง bucket เดียว เพื่อให้ตรงกับความเด่นของทิศทาง AND การเคลื่อนไหวของราคาในทิศทางเดียวกัน 4h ขนาด >= 2%; ด้วยแถว liquidation ที่เบาบาง 1h bucket มักจะว่างเปล่าแม้ในช่วง cascade จริง ดังนั้น `total` จึงมักจะเป็น 0 และการร่วมสามเกือบจะไม่เกิดขึ้นเลย การแก้ไขยังคงกลไก 100% liquidation-driven (อย่างชัดเจนไม่มี price-only fallback): (1) liquidations ถูกรวมในตอนนี้ในช่วง `liq_window_bars` ชั่วโมง (ค่าเริ่มต้น 4h หน้าต่างเดียวกับการเคลื่อนไหวของราคา) ดังนั้น cascade จึงถูกจับได้จริงๆ และ `total` ไม่เป็นศูนย์บ่อยขึ้นมาก โดยจัดแนวสองครึ่งของสัญญาณ; (2) สอง thresholds ตัวเลขถูกคลาย (liq_z 3.0->2.0, price_move_pct 2.0->1.0) และ min_events ถูกลด 50->30 เพื่อให้ z-baseline ใช้งานได้เร็วขึ้น Imports ยังไม่เปลี่ยน (Layer 1 ยังคงเขียว) และโครงสร้าง z-score/trigger/exit/sizing ที่ผ่าน Layer 2 มีโครงสร้างเหมือนกัน — มีเพียง window bound หนึ่งและค่าเริ่มต้นพารามิเตอร์สามค่าเปลี่ยนไป Venue ยังคงเป็น BINANCE USD-M futures (long-short ต้องการ margin) leverage 1.0 (ไม่ใช้สำหรับขยาย ดังนั้น gate leverage_set_but_unused จึงไม่ trigger) หาก sandbox ไม่มีแถว liquidation จริงๆ กลยุทธ์ยังคงอยู่ flat อย่างถูกต้องแทนที่จะปลอมการเทรดผ่าน price proxy

โครงสร้างไม่สามารถ backtest ได้บนประวัติ liquidation ที่มีอยู่: เอ็นจิ้นประมวลผลแท่ง 56,208 1H (~6.5 ปี) แต่สร้างการเทรดเพียง 8 ครั้ง โดย ALL เกาะกลุ่มอยู่ในหน้าต่างเวลา ~2-เดือน (2026-04-21 ถึง 2026-06-24) ด้วย metrics_reliable=FALSE สัญญาณต้องการแถว supplementary_data['liquidations'] ซึ่งทั้งสมมติฐานและโค้ดอธิบายว่าเป็นแบบ sparse/live-stream-only; การเกาะกลุ่มของการเทรดสอดคล้องกับการที่ที่เก็บ liquidations มีเพียงหน้าต่างเวลา ~2-เดือนที่ผ่านมา ดังนั้นสัญญาณ cascade จึงไม่สามารถทำงานได้ทั่ว 6.4 ของปี backtest 6.5 (อาการที่สังเกตได้ ไม่ใช่การตรวจสอบอิสระของตาราง Postgres) นี่คือกำแพงการมีอยู่ของข้อมูล ไม่ใช่ปัญหาของโค้ดหรือพารามิเตอร์: กลยุทธ์ถูกนำไปใช้อย่างถูกต้องและเทรดอย่างถูกต้องเมื่อมีแถว liquidation อยู่ ดังนั้นจึงไม่มีอะไรให้นักพัฒนาแก้ไขและไม่มีพารามิเตอร์ให้ปรับแต่ง — การเทรด 8 ในหน้าต่างเวลา 2-เดือน ไม่สามารถรองรับ walk-forward (หน้าต่าง 3) หรือ holdout ได้ ดังนั้นการปรับแต่งจะ fit แค่สัญญาณรบกวนล้วนๆ กลไกไม่ได้รับการยืนยันหรือหักล้าง; มันแค่ไม่สามารถตรวจสอบความถูกต้องได้ ไม่ optimize ไม่ iterate META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: สมมติฐาน liquidation-cascade ยังคงถูกบล็อกจนกว่าสตรีมข้อมูล liquidations จะถูก backfill ด้วยประวัติหลายปี (เช่น ผ่าน Binance Vision liquidation snapshots) แทนที่จะเป็นแบบ live-stream-only; อย่าพยายามกลยุทธ์ที่ขับเคลื่อนด้วย liquidation ซ้ำจนกว่าประวัตินั้นจะมีอยู่ FAILURE PATTERN: กลยุทธ์ที่ขับเคลื่อนด้วย liquidations บน BTCUSDT สร้าง backtest ที่เกือบว่างเปล่า (8 การเทรดที่อยู่ในหน้าต่างเวลา ~2-เดือนที่ผ่านมา) เนื่องจากสตรีมเสริม liquidations เป็นแบบ live-stream-only ที่มีประวัติ ~2 เดือน — กลไกไม่สามารถตรวจสอบความถูกต้องแบบ out-of-sample ได้และกลยุทธ์ไม่สามารถ backtest ได้โครงสร้างจนกว่าข้อมูลจะถูก backfill ซึ่งเป็นกำแพงประวัติข้อมูลเสริมแบบเดียวกันที่พบในตระกูล OI/liquidation