HyperliquidSolFundingExtremeContrarian

Hyperliquid SOL Perp Funding-Extreme Contrarian — Long-Short, Single-Name: FADE การถือครองที่แออัดเมื่อ Rolling Funding Z-Score แตะค่าผิดปกติ (Funding เป็นบวกมาก = Long ที่ใช้เลเวอเรจเกิน → SHORT; เป็นลบมาก = Short ที่ยอมจำนน → LONG) ยืนยันด้วยการที่ราคาไม่ยืนยันสัญญาณ, ออกจากสถานะเมื่อ Funding กลับคืนค่า / ATR Stop / Time Stop (SOLUSDT.HYPERLIQUID, 4H, 3-Parameter)

กลยุทธ์สวนทางแบบ LONG-SHORT, รายการเดียว, ขับเคลื่อนด้วย POSITIONING บน perpetual ของ Hyperliquid SOL ซึ่งสร้างขึ้นรอบสัญญาณเชิงกลแบบ NON-OHLCV — perpetual FUNDING — ใช้แนวทาง OPPOSITE กับตระกูล dead cash-and-carry ของโรงงาน นี่ไม่ใช่ carry แบบ delta-neutral (NOT) ซึ่งล้มเหลวเพราะ P&L จาก funding เล็กเกินไปเมื่อเทียบกับ noise ของ basis และไม่ใช่ price momentum (NOT) (HL momentum baskets เป็น 0/84) แต่ใช้ funding เป็นมาตรวัด crowding/positioning เพื่อจับจังหวะการทำ DIRECTIONAL fade: ผลลัพธ์ที่มีการบันทึกไว้อย่างดีว่าเมื่อ funding ของ perp เป็นบวกอย่างมาก long จะใช้เลเวอเรจเกินและจ่ายเงินเพื่อถือสถานะ — ภาวะที่ในอดีตมาก่อนผลตอบแทน perp ล่วงหน้า LOWER (ความเสี่ยง squeeze/washout) และในทางสมมาตร funding ที่ติดลบอย่างมากบ่งชี้ short ที่ยอมจำนนซึ่งมาก่อนการดีดกลับ เลือกเพื่อเติม bucket ที่มีตัวแทนน้อยสามประเภทพร้อมกัน: HYPERLIQUID (6.8% เทียบกับเป้าหมาย 20%), long_short (14.2%) และ edge แบบ non-OHLCV ที่ปลอดภัยต่อข้อมูลและไม่อยู่ในสุสาน overfit ของ OHLCV ตั้งใจให้เป็น single-name และ 3-parameter เพื่อให้ใช้งานได้จริง (ตะกร้า HL แบบหลายเครื่องมือล้มเหลวด้วย coding timeout) และเพื่อต้านทาน overfitting IMPLEMENTATION NOTE: รักษา baseline ของ funding เป็น rolling deque ที่อัปเดตแบบ incremental (O(1) ต่อการอัปเดต) — NEVER สแกนซีรีส์ funding ทั้งหมดซ้ำภายใน on_bar (รูปแบบดังกล่าวทำให้เกิด sandbox timeout ซ้ำ ๆ จำนวน 300)

Iteration 2 แก้ไขความล้มเหลวเพียงจุดเดียวของ Layer-2 (`FactoryStrategy._bar_ts() takes 1 positional argument but 2 were given`, ทั้งหกสถานการณ์) ส่วน Layer-2 `_StrategyProxy` ผูกแอตทริบิวต์ที่เรียกใช้งานได้ทุกตัวของกลยุทธ์ใหม่เข้ากับ wrapper ธรรมดาผ่าน `types.MethodType` ซึ่งแปลง staticmethod ของคลาสฐานที่รับอาร์กิวเมนต์หนึ่งตัว `_bar_ts` ให้เป็น bound method — ดังนั้น `self._bar_ts(bar)` จึงมาถึงพร้อมอาร์กิวเมนต์สองตัว การแก้ไขขั้นต่ำแทนที่การเรียกเพียงจุดเดียวนั้นด้วย helper ระดับโมดูล `_bar_timestamp_ns(bar)` ซึ่งอ่าน `bar.ts_event` โดยตรง (หากไม่มีให้ใช้ `ts_init`) — ให้พฤติกรรมเหมือนเดิมและไม่ถูกรบกวนจากการผูกใหม่ของ proxy ไม่มีสิ่งอื่นเปลี่ยนแปลง: imports, โครงสร้างคลาส, การแยกวิเคราะห์ funding, ตรรกะสัญญาณ, การเข้า, การออก และการกำหนดขนาดเหมือนกับ previous_code ทุกไบต์ ซึ่งผ่าน Layer 1 แล้ว โปรดทราบว่า `_bar_interval_ns` ยังคงถูกเรียกจาก `__init__` ซึ่งทำงานบนอินสแตนซ์จริงก่อนที่ proxy จะผูกสิ่งใดใหม่ ดังนั้นจึงไม่ได้รับผลกระทบ Leverage 2.0 ถูกใช้ใน `position_size` ผ่าน `self.config.leverage` ในเพดาน gross-notional

กลยุทธ์เทรดสวนการเคลื่อนไหวของสินทรัพย์รายตัวเมื่ออัตรา Funding อยู่ในระดับสุดขั้ว มีค่าคาดหวังเป็นลบ — ไม่มีความได้เปรียบให้ปรับให้เหมาะสม PF 0.60, total_return -33.7%, อัตราส่วน Sharpe -0.42, ค่าคาดหวัง -$156/เทรด และ avg_trade_return_pct -0.37% (เป็นลบ ต่ำกว่าเกณฑ์ขั้นต่ำเพื่อครอบคลุมค่าธรรมเนียม Hyperliquid ที่ 0.15%, L22) ขาดทุนทุกปี (2024 -14.8%, 2025 -13.8%, 2026 -6.5%) โดยทั้งฝั่ง Long และ Short มีอัตราชนะต่ำกว่า -43% และ avg_loss > avg_win — กลยุทธ์เทรดสวนนี้อยู่ผิดฝั่งของการเคลื่อนไหวอย่างเป็นระบบ และเดือนเดียวที่ให้ผลเป็นบวกนั้นเกิดจากวันผิดปกติเพียงวันเดียวที่ +10.77% (ค่าความโด่ง 9.8) กลไกถูกนำไปใช้อย่างดี (ไม่มีการหมดเวลา มีการลงบัญชี Funding) แต่จัดอยู่ในกลยุทธ์สองตระกูลที่ไม่มีตัวใดรอด: การกลับสู่ค่าเฉลี่ย/การเทรดสวนในสินทรัพย์รายตัว (L55) และการเทรดตามทิศทางในสัญญา Perpetual เดียวโดยใช้ข้อมูลเสริม (Funding) เป็นเงื่อนไขคัดกรอง (L73) เงื่อนไขคัดกรองที่กำหนดให้ราคาไม่ยืนยันสัญญาณไม่ได้เพิ่มความได้เปรียบที่แท้จริง ความได้เปรียบต่อเทรดมีเครื่องหมายเป็นลบ ซึ่งไม่มีการปรับพารามิเตอร์ใดพลิกให้เป็นบวกได้ ไม่คุ้มกับการใช้เวลา 2 ชั่วโมงในการปรับให้เหมาะสม รูปแบบความล้มเหลว: fee_edge/no_edge กลยุทธ์เทรดสวนในสัญญา Perpetual เดียวโดยใช้ Funding เป็นเงื่อนไขคัดกรอง

กลยุทธ์สวนทางแบบ long-short รายตัวบน Hyperliquid SOL perp (แท่ง 4H) ใช้ funding เป็นมาตรวัด crowding: z-score แบบ rolling ของข้อมูล hl_funding_rates เมื่อเทียบกับการกระจายย้อนหลังของตัวมันเอง จะถูกส่งคืนทุกแท่งเป็นสัญญาณต่อเนื่อง z ที่เป็นบวกสุดขั้ว (crowded, long ที่จ่ายแพงเกินไป) จะถูก fade ด้วย SHORT; z ที่เป็นลบสุดขั้ว (short ที่ยอมจำนน) จะถูก fade ด้วย LONG แต่เฉพาะเมื่อราคาไม่ยืนยัน crowd (ราคาปิดไม่ทำจุดสูง/ต่ำใหม่ในช่วง confirm_bars แท่ง) ออกจากสถานะเมื่อ funding กลับคืนค่า (|z| <= exit_z), stop แบบ ATR ที่บันทึกค่าไว้เมื่อเข้า หรือ time stop ตามปฏิทินที่วัดจาก position.ts_opened การกำหนดขนาดให้ความสำคัญกับความเสี่ยงก่อน: stop แบบ ATR มีต้นทุนประมาณ risk_frac ของ equity โดยมีเพดาน gross-notional แยกอิสระ

CLEAN RESTART 2026-09-04 — ประวัติคำตัดสินและบันทึกการเรียนรู้ของการรันนี้ถูกลบออก และเริ่มต้นใหม่จากการตรวจสอบ การยุติก่อนหน้านี้เกิดจากไปป์ไลน์ ไม่ใช่จากตลาด: harness ของ Layer-2 ผูก helper ของ @staticmethod ผิด (แก้ไขแล้ว), QA ออกคำตัดสินประสิทธิภาพขั้นสุดท้ายจาก smoke test ที่ยังไม่ได้ปรับให้เหมาะสม (นำออกแล้ว — ขณะนี้ QA ตัดสินเฉพาะความถูกต้องเท่านั้น) และ sandbox timeout เกิดจากการขาดแคลน backtest-slot (แก้ไขแล้ว) สมมติฐานและโค้ดกลยุทธ์ไม่เปลี่ยนแปลง ตรวจสอบโค้ดตามเนื้อแท้ของมัน; ประสิทธิภาพจะตัดสินภายหลังด้วย backtest เต็มรูปแบบและ optimizer

จำกัด _param_bounds ให้เหลือพารามิเตอร์หลักที่ปรับได้ 3 ตัว (entry_z, exit_z, funding_lookback_prints); ล็อกพารามิเตอร์ด้านความเสี่ยง/โครงสร้างการทำงานของระบบให้เป็นค่าคงที่

สมมติฐานเสนอการออกแบบแบบ '3-parameter โดยตั้งใจเพื่อป้องกัน overfitting' แต่ _param_bounds เปิดเผยพารามิเตอร์ที่ปรับให้เหมาะสมได้ 11 รายการ กลไกถูกต้อง แต่การค้นหา walk-forward แบบ 11-dim ขัดแย้งกับเหตุผลด้านการป้องกัน overfit ที่ระบุไว้ และเพิ่มความเสี่ยง PBO ไม่ใช่ประเด็นขัดขวาง

ไม่จำเป็นต้องดำเนินการ; บันทึกไว้สำหรับนักวิเคราะห์แล้ว

สัญญาณสังเคราะห์ของ Layer-2 ทั้งหมดถูกตรึงไว้ที่ 0.0 (ไม่มีการ inject funding) ดังนั้นเส้นทางการเทรดจึงถูกทดสอบโดย sandbox เท่านั้น (ซึ่งเทรด 65 ครั้งด้วย funding จริง) ไม่ร้ายแรง

กลไกทำงานอย่างราบรื่นและสร้างตัวอย่างที่เพียงพอ (201 เทรดใน 953 วัน) โดยไม่มี timeout — การใช้งาน funding แบบ O(log n) ทำงานตามที่ตั้งใจไว้

เครื่องมือเดียว, supplementary feed เดียว (hl_funding_rates), ไม่มีปัญหาด้านข้อมูล/การตรวจสอบ; funding ถูกบันทึกเข้า PnL

ความคาดหวังติดลบ: profit_factor 0.60, total_return -33.7%, ความคาดหวัง -$156/trade

avg_trade_return_pct -0.37% — เป็นลบและต่ำกว่าพื้นค่าธรรมเนียม Hyperliquid ที่ 0.15% มาก (L22)

ขาดทุนทั้งสามปี (2024 -14.8%, 2025 -13.8%, 2026 -6.5%) — เป็นการไม่มี edge อย่างต่อเนื่อง ไม่ใช่ edge ที่เสื่อมลง

ทั้งสองขาขาดทุน (win rate ของ long 42%, ของ short 42%) โดย avg_loss > avg_win — funding-extreme fade อยู่ผิดด้านของการเคลื่อนไหว

เดือนเดียวที่เป็นบวกคือวันผิดปกติแบบ outlier เพียงวันเดียวของ +10.77% (kurtosis 9.8); ข้อมูลราคาพื้นฐานเป็นลบโดยสม่ำเสมอ

กลยุทธ์ fade แบบ directional รายตัวที่มี funding เป็นเงื่อนไข — mean-reversion (0/174) และ directional แบบ single-perp supplementary-gated (L73) เป็นคลาสที่ไม่มีผู้รอดชีวิต

การตรวจสอบล้มเหลว (Layer 2 — สถานการณ์สังเคราะห์): พารามิเตอร์ที่ใช้: ['exit_z', 'entry_z', 'atr_bars', 'risk_frac', 'min_prints', 'confirm_bars', '_param_bounds', 'atr_stop_mult', 'max_hold_bars', 'max_lag_seconds', 'max_notional_frac', 'funding_lookback_prints'] ตรวจสอบว่า __init__ ตั้งค่าแอตทริบิวต์ทั้งหมดจาก self.parameters.get() - steady_uptrend: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่ง 1 รายการ แต่ได้รับ 2 รายการ (bar timestamp: 1735690500000) - steady_downtrend: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่ง 1 รายการ แต่ได้รับ 2 รายการ (bar timestamp: 1735690500000) - flat_ranging: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่ง 1 รายการ แต่ได้รับ 2 รายการ (bar timestamp: 1735690500000) - volatility_spike: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่ง 1 รายการ แต่ได้รับ 2 รายการ (bar timestamp: 1735690500000) - zero_volume: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่ง 1 รายการ แต่ได้รับ 2 รายการ (bar timestamp: 1735690500000) - price_gap: TypeError: FactoryStrategy._bar_ts() รับอาร์กิวเมนต์ตำแหน่ง 1 รายการ แต่ได้รับ 2 รายการ (bar timestamp: 1735690500000)