Hyperliquid क्रॉस-सेक्शनल फ़ंडिंग रेट का चरम-मीन रिवर्शन: BTC/ETH/SOL HL Perps में कम फ़ंडिंग वाला लॉन्ग + अधिक फ़ंडिंग वाला शॉर्ट, 8h रीबैलेंस

Hyperliquid परपेचुअल फ़्यूचर्स की डॉलर-न्यूट्रल क्रॉस-सेक्शनल फ़ंडिंग-रेट मीन-रिवर्शन रणनीति। हर 8 घंटे (HL की सबसे लगातार फ़ंडिंग अवधि के अनुरूप), यह Hyperliquid के 3 प्रमुख Perps (BTC, ETH, SOL—सभी का HL पर पूरा 3-वर्ष का इतिहास पुष्ट है) को नवीनतम फ़ंडिंग रेट के आधार पर क्रम देती है। सबसे नकारात्मक फ़ंडिंग वाले Perp को LONG करती है (जहाँ शॉर्ट, लॉन्ग को भुगतान कर रहे हैं; यह भीड़भाड़ वाली शॉर्ट स्थिति दर्शाता है, जिसके लौटने की प्रवृत्ति मानी गई है) और सबसे सकारात्मक फ़ंडिंग वाले Perp को SHORT करती है (जहाँ लॉन्ग, शॉर्ट को भुगतान कर रहे हैं; यह भीड़भाड़ वाली लॉन्ग स्थिति दर्शाता है, जिसके लौटने की प्रवृत्ति मानी गई है)। समान भार, डॉलर-न्यूट्रल। 8 घंटे रखकर फिर क्रम तय करती है। इससे एक साथ: (1) दोनों लेग के फ़ंडिंग भुगतान मिलते हैं (लॉन्ग लेग को भुगतान मिलता है और शॉर्ट लेग को भी सकारात्मक फ़ंडिंग मिलती है), और (2) चरम फ़ंडिंग वाली संपत्तियों का क्रॉस-सेक्शनल औसत की ओर लौटना पकड़ा जाता है। यह कम प्रतिनिधित्व वाले FIVE बकेट भरती है: HYPERLIQUID वेन्यू (7.3% → 20% की ओर बढ़ावा), लॉन्ग-शॉर्ट दिशा (14.3% → 45% की ओर), बहु-इंस्ट्रूमेंट दायरा (6.6% → पोर्टफ़ोलियो विविधता की ओर), फ़ंडिंग-रेट-आधारित तंत्र (कर्व-फ़िट जोखिम नहीं), और छोटे चक्र का रीबैलेंस (मध्य-अवधि होल्डिंग पैटर्न, लेकिन वॉक-फ़ॉरवर्ड सत्यापन के लिए घटनाओं की उच्च आवृत्ति)। इस सत्र की हर विफलता से इसका तंत्र बिल्कुल उलट है: इसमें NO मूल्य-पैटर्न निर्भरता, NO व्यवस्था से जुड़ा थ्रेशहोल्ड, NO कम ट्रेड-संख्या की समस्या (8h रीबैलेंस = 3 ट्रेड/दिन × 3 इंस्ट्रूमेंट = 3 वर्षों में ~3,300+ ट्रेड घटनाएँ HL पर)। स्थिति आकार: हर दिशा में इक्विटी का 15% (15% लॉन्ग लेग + 15% शॉर्ट लेग = 30% कुल एक्सपोज़र, डॉलर-न्यूट्रल)। प्रति ट्रेड जोखिम: छोटे प्रति-लेग मूल्य और 8h होल्डिंग अवधि के आधार पर इक्विटी का ~0.5%।

पुनरावृत्ति 3 ने लेयर-3 की शून्य-ट्रेड विफलता ठीक की। निदान: रणनीति supplementary_data['funding_rates_by_instrument'] से लेग क्रमित करती है—प्रति-लेग फ़ंडिंग मैप, जिसे वास्तविक बैकटेस्ट/ऑप्टिमाइज़ेशन सबप्रोसेस बनाता है (पुष्टि: load_for_subprocess सभी 3 HL लेग को 1675 ओवरलैपिंग फ़ंडेड बार से भरता है)। लेकिन लेयर-3 का इन-प्रोसेस सत्यापन पथ (_handle_verifying -> _collect_supplementary_data) केवल PRIMARY इंस्ट्रूमेंट के लिए सप्लीमेंटरी डेटा लोड करता है और funding_rates_by_instrument नहीं बनाता। इसलिए ETH/SOL फ़ंडिंग उपलब्ध नहीं थी, ‘हर लेग की फ़ंडिंग चाहिए’ जाँच हर बार जल्दी लौटती रही और कोई रीबैलेंस/ऑर्डर नहीं हुआ। सुधार (न्यूनतम, एक मेथड): _funding_series अब उस ANY लेग के लिए सपाट 'hl_funding_rates' सीरीज़ का सहारा लेती है जिसकी प्रति-लेग सीरीज़ उपलब्ध नहीं है—केवल प्राथमिक लेग के लिए नहीं। इससे बढ़त पूरी तरह फ़ंडिंग-आधारित रहती है (कोई मूल्य प्रॉक्सी नहीं, तंत्र में बदलाव नहीं) और यह केवल तभी सक्रिय होता है जब प्रति-लेग मैप उपलब्ध न हो (लेयर-3 स्मोक टेस्ट)। वास्तविक बैकटेस्ट में fbi हर लेग की अलग सीरीज़ रखता है, इसलिए यह फ़ॉलबैक कभी सक्रिय नहीं होता और वास्तविक क्रॉस-सेक्शनल फ़ंडिंग रैंकिंग का मूल्यांकन होता है। कोई इम्पोर्ट, क्लास-संरचना, थ्रेशहोल्ड या कॉन्फ़िग बदलाव नहीं—लेयर 1 और 2 अप्रभावित हैं; केवल अतिरिक्त लेग की फ़ंडिंग पहचान मज़बूत की गई ताकि बहु-लेग रीबैलेंस पथ चलकर ट्रेड उत्पन्न करे।

क्रॉस-सेक्शनल फ़ंडिंग-REVERSION की धारणा HL BTC/ETH/SOL पर गलत साबित हुई है और ऑप्टिमाइज़ करने के लिए कुछ नहीं है। यह साफ़, वास्तविक डॉलर-न्यूट्रल जाँच थी (2,137 संतुलित ट्रेड, 9.1% वार्षिकीकृत अस्थिरता, benchmark_meaningful=false), जिसे CURRENT इंजन पर चलाया गया जहाँ फ़ंडिंग IS क्रेडिट हुई (funding_events_available 53,001)—इसलिए रणनीति ने दोनों लेग पर वही फ़ंडिंग वास्तव में अर्जित की जिसे पाने के लिए उसे बनाया गया था। इसके बावजूद लगातार घाटा हुआ: total_return -42.7%, Sharpe -1.835 और पूरा CI नकारात्मक [-2.81, -0.82], Sortino -1.98, और probabilistic_sharpe 0.0002 (~99.98% संभावना कि वास्तविक Sharpe <= 0)। profit_factor 0.862 है और प्रति ट्रेड अपेक्षित लाभ -$18.4 है; EVERY वर्ष घाटे में है (2024 -18.1%, 2025 -23.1%, 2026 -3.8%)—पूरे लगभग 2.3-वर्ष के नमूने में समस्या कम ट्रेडों, कोड बग या किसी एक खराब व्यवस्था की नहीं, बल्कि लगातार नकारात्मक अपेक्षित लाभ वाले संकेत की है। मूल कारण: 3 प्रमुख कॉइनों पर अत्यधिक सकारात्मक फ़ंडिंग जारी रहने वाली गति के साथ होती है (CONTINUE), इसलिए सबसे नकारात्मक फ़ंडिंग वाले Perp पर लॉन्ग और सबसे सकारात्मक फ़ंडिंग वाले पर शॉर्ट करने से मूल्य वाले लेग में घाटा होता है और वह वास्तविक लेकिन छोटा फ़ंडिंग अर्जन से अधिक है। ऑप्टिमाइज़ेशन मदद नहीं कर सकता: तंत्र में मूलतः एक ही समायोज्य नियंत्रण है (per_leg_pct; REBALANCE_BARS स्थिर है और कोई z-score/थ्रेशहोल्ड नहीं), इसलिए स्वीप केवल एक्सपोज़र का आकार बदलेगा—घाटे वाले दिशात्मक दाँव का संकेत नहीं पलट सकता। कमीशन का असर (9.23% कुल मूल्य का) नकारात्मक सकल बढ़त के मुकाबले गौण है। ऑप्टिमाइज़ेशन के 2 घंटे खर्च करना उचित नहीं। NOTE FOR RESEARCH LEAD: उलटी बनावट—फ़ंडिंग-MOMENTUM (सबसे-POSITIVE-फ़ंडिंग वाले Perp पर लॉन्ग, सबसे-NEGATIVE पर शॉर्ट)—विपरीत दाँव है और ये आँकड़े परोक्ष रूप से इसी के पक्ष में हैं। लेकिन यह इस रणनीति का पैरामीटर बदलाव नहीं, एक अलग नई परिकल्पना है; अगर इसे परखें, तो 8h रीबैलेंस की लागत को देखते हुए इसे अपनी फ़ीस और डिफ़्लेशन जाँचें भी पार करनी होंगी।

सत्यापन विफल (लेयर 2 — सिंथेटिक परिदृश्य): इस्तेमाल किए गए पैरामीटर: ['per_leg_pct', 'min_notional'] जाँचें कि __init__ में self.parameters.get() से सभी एट्रिब्यूट सेट होते हैं। - steady_uptrend: TypeError: HlCrossSectionalFundingExtremeMeanReversionLS._funding_at() को 3 positional arguments चाहिए, लेकिन 4 दिए गए (बार टाइमस्टैम्प: 1735689840000) - steady_downtrend: TypeError: HlCrossSectionalFundingExtremeMeanReversionLS._funding_at() को 3 positional arguments चाहिए, लेकिन 4 दिए गए (बार टाइमस्टैम्प: 1735689840000) - flat_ranging: TypeError: HlCrossSectionalFundingExtremeMeanReversionLS._funding_at() को 3 positional arguments चाहिए, लेकिन 4 दिए गए (बार टाइमस्टैम्प: 1735689840000) - volatility_spike: TypeError: HlCrossSectionalFundingExtremeMeanReversionLS._funding_at() को 3 positional arguments चाहिए, लेकिन 4 दिए गए (बार टाइमस्टैम्प: 1735689840000) - zero_volume: TypeError: HlCrossSectionalFundingExtremeMeanReversionLS._funding_at() को 3 positional arguments चाहिए, लेकिन 4 दिए गए (बार टाइमस्टैम्प: 1735689840000) - price_gap: TypeError: HlCrossSectionalFundingExtremeMeanReversionLS._funding_at() को 3 positional arguments चाहिए, लेकिन 4 दिए गए (बार टाइमस्टैम्प: 1735689840000)