ETH BINANCE_SPOT + ETH HYPERLIQUID: dodatni funding rate i carry z bazy między platformami dla kontraktu perpetual (neutralna rynkowo para, monitoring co 4H, 3 parametrów, bez kierunkowego stopu)

Strategia DOLLAR-NEUTRAL CROSS-VENUE PAIR, która wykorzystuje TWO nakładające się przewagi strukturalne na ETH: (a) dochód z finansowania kontraktu perpetual Hyperliquid, gdy stopa finansowania jest trwale dodatnia, oraz (b) konwergencję bazy między kontraktem perpetual Hyperliquid a rynkiem spot Binance, gdy kontrakt HL jest notowany z premią. Mechanizm: przy zamknięciu każdego słupka 4H odczytaj najnowszą stopę finansowania HL 8h i oblicz bazę HL_perp_close / BINANCE_SPOT_close - 1. Gdy jednocześnie spełnione są warunki BOTH (HL finansowania >= +0.02% na 8h, baza AND HL/spot >= +0.15%), otwórz neutralną rynkowo parę: LONG ETH na BINANCE_SPOT oraz SHORT ETH na kontrakcie perpetual HYPERLIQUID, z równą wartością w dolarach wynoszącą 20% kapitału na każdą nogę (40% łącznie zaangażowanego kapitału). Gdy para jest otwarta, krótka noga HL RECEIVES dodatnie płatności za finansowanie co 8h (dochód gotówkowy), a my czekamy na konwergencję bazy HL/spot (zysk/strata z bazy). Zamknij parę (jednocześnie zamknij obie nogi BOTH po cenie rynkowej), gdy zajdzie ANY z warunków: finansowanie HL spadnie poniżej 0 (wyczerpanie źródła dochodu z finansowania), baza zbiegnie do <= 0 (realizacja zysku z bazy) lub upłynie 14 dni kalendarzowych (limit czasu). Bez kierunkowego stop lossa, ponieważ pozycja jest neutralna dolarowo; zamiast tego wyłącznik awaryjny PnL portfela zamyka obie nogi, jeśli łączna niezrealizowana strata przekroczy -5% kapitału (wychwytuje rozbieżności wykonania / gwałtowne rozszerzenie bazy). To rozwiązanie jawnie unika klas mechanizmów, które nie zadziałały w tej sesji: NOT strategii momentum/wybicia (osłabionej przez zmianę reżimu), NOT krótkiej pozycji na samej stopie finansowania (niewłaściwej w hossie), NOT strategii przekrojowej na skorelowanych głównych aktywach (załamanie korelacji), NOT pary MR na kontraktach perpetual (4-nogowa luka w opłatach). Przewaga wynika z MECHANICAL CASH FLOW + BASIS CONVERGENCE na aktywie SINGLE na TWO rynkach, a nie ze statystycznego powrotu do średniej ani zakładu kierunkowego. Jednocześnie realizuje 4 niedostatecznie reprezentowane kwoty portfelowe: HYPERLIQUID (4.9% wobec celu 20%), BINANCE_SPOT (10.5% wobec celu 15%), CROSS-VENUE (6.3% wobec celu 15%), kierunek LONG+SHORT (12.6% dostępnego limitu 45%).

Informacja zwrotna potwierdziła, że strategia jest poprawnie zaimplementowana, ale zbyt selektywna (4 wejść w ciągu 28 miesięcy -> ~1 transakcja na okno walk-forward, co oznaczałoby dopasowanie do szumu). Wskazała też, że warunek bazowy 0.15% AND ogranicza strategię, ponieważ baza ETH kontraktu perpetual HL/spot Binance rzadko osiąga 15 bps. Najmniejsza poprawka to zalecane poluzowanie parametrów i dodanie diagnostyki częstotliwości, przy zachowaniu całej logiki mechanizmu: (1) wartość domyślna entry_basis_pct 0.0015 -> 0.0, by baza była miękkim filtrem wykluczającym dyskonto, a nie twardym współwarunkiem, i by głównym czynnikiem było carry fundingowe (przewaga, którą silnik niezawodnie nalicza krótkiej nodze poprzez funding_accrual); (2) wartość domyślna entry_funding_8h 0.0002 -> 0.00005, w kierunku dolnej granicy trwałego dodatniego funding rate, aby wejścia pojawiały się w okresach dodatniego funding rate; (3) jednorazowy log częstotliwości (emitowany co 1000 świec z narastającymi wartościami) raportuje dla całego okresu, jak często funding>=próg, baza>=próg oraz oba warunki BOTH są spełnione — bezpośrednio pokazując, czy carry występuje dostatecznie często, by można było nim handlować, zgodnie z żądaniem. Wszystko inne — odczyt szeregów funding rate (funkcje pomocnicze na poziomie modułu, by działały przez proxy Layer-2), obliczanie bieżącej bazy, wejście w obie nogi (HL SELL + spot BUY o równej wartości w dolarach), wyjścia przy wyczerpaniu funding rate / zbieżności bazy / limicie czasu / zadziałaniu przełącznika awaryjnego, zamykanie obu nóg i ustalanie wielkości pozycji neutralnej dolarowo — pozostaje identyczne bajt po bajcie. Zachowano zatem wcześniejsze zaliczone etapy oraz mechanizm funding rate naliczany przez silnik, a także zasadę braku awaryjnego uzupełniania brakującej ceny (nieznany funding rate => brak wejścia). Dźwignia pozostaje na poziomie 1.0 (neutralność dolarowa; dźwignia>1 ponownie wprowadziłaby betę ETH), więc warunek niewykorzystanej dźwigni nie ma zastosowania. Zgodnie z regułą decyzyjną z informacji zwrotnej: ponownie uruchom backtest i potwierdź >=50 transakcji parami oraz dodatni, niezerowy zwrot netto po opłatach; jeśli poluzowane warunki nadal wykażą, że carry fundingowe i bazowe jest z natury zbyt małe na ETH (log częstotliwości to zmierzy), porzuć strategię albo przenieś ją na platformę/aktywo z trwale wyższym funding rate lub bazą, zamiast bezproduktywnie ją zmieniać.

Carry z finansowania+bazy między giełdami ETH jest prawidłowo skonstruowany i neutralny rynkowo (beta 0.0002, zmienność 0.48%), finansowanie IS zostało zaksięgowane (zgodnie z rejestrem naliczania finansowania silnika), a historia finansowania HL załadowała się prawidłowo (496 dni, 268 wpisów) — więc NOT nie jest to problem z wiarygodnością zaksięgowania ani z dostępem do danych. Oceniana na podstawie wyniku CREDITED strategia konsekwentnie przynosi straty netto: Sharpe -6.48, profit_factor 0.94, oczekiwana wartość -$15.66/transakcję, CAGR -1.77%, przy nieustannym ubytku od -0.02% do -0.05%/dzień i ujemnych stopach zwrotu w niemal każdym miesiącu. ROOT CAUSE: zaksięgowane finansowanie ETH-HL oraz carry z bazy są zbyt małe, by pokryć koszty realizacji zleceń między giełdami — prowizja wynosi 10.51% wartości brutto w transakcji w obie strony obejmującej 4 nogi (wejście i wyjście na dwóch giełdach), a avg_win ($499) jest zasadniczo równe avg_loss ($507), co oznacza, że przychód z finansowania nie przechyla systematycznie pozycji w stronę zysku. Historia iteracji potwierdza strukturalne ograniczenie, a nie błąd strojenia: przy selektywnym progu bazy 0.15% (iteracja 1) sygnał pojawił się tylko 4x w ciągu 28 miesięcy (zbyt rzadko, by optymalizować), a obniżenie progu do bazy>=0 / finansowanie>=0.00005 (iteracja 2) generuje 268x, ale każda transakcja przynosi stratę netto — nie ma pośredniego progu, przy którym carry ETH HL występuje dostatecznie często, by mieć znaczenie, i jest dostatecznie duże, by pokryć prowizje. Nie optymalizować: parametry 3 nie pozwalają uniknąć tego ograniczenia — podniesienie progu finansowania prowadzi z powrotem do niemożliwego do przetestowania reżimu 4 transakcji, a ograniczający koszt (opłaty wobec niewielkiego zaksięgowanego carry na płynnym głównym instrumencie) nie zmienia się wraz z parametrami. Nie iterować: mechanizm działa prawidłowo (neutralność delta, zaksięgowane finansowanie, obliczona baza) i przeszedł już jedną iterację; nie ma błędu, po prostu nie ma tu przewagi po uwzględnieniu opłat. FAILURE PATTERN: carry z finansowania i bazy pojedynczego aktywa między giełdami na głównym instrumencie (ETH, rynek spot Binance wobec kontraktu perpetual HL) nie pokrywa własnych opłat między giełdami — zaksięgowane carry jest strukturalnie zbyt małe (prowizja 10.51% wartości brutto, avg_win~avg_loss, stały ujemny odpływ, Sharpe -6.48) i napotyka ograniczenie progowe (selektywny próg => 4 transakcji/28 mies.; łagodny próg => 268 transakcji ze stratą netto). To zmierzony wynik wskazujący na niewielką przewagę w relacji do opłat w przypadku carry CREDITED, odmienny od wcześniejszej (obecnie odwróconej) wątpliwości dotyczącej wiarygodności zaksięgowania; carry na płynnym głównym instrumencie z finansowaniem jest rzeczywiste, ale mniejsze niż koszt realizacji zlecenia z 4 nogami.

Neutralna dolarowo para carry między platformami ETH: krótka pozycja na kontrakcie perpetual ETHUSD.HYPERLIQUID + długa na ETHUSDT.BINANCE_SPOT, o równej wartości 20% kapitału na nogę, monitorowana na świecach 4H. Krótka noga HL otrzymuje dodatni funding (przepływ pieniężny naliczany przez silnik), a pozycja zarabia na zbieżności bazy HL/spot. Iteracja 2 poluzowuje zbyt selektywny warunek wejścia, który uruchomił się tylko 4 razy w ciągu 28 miesięcy: entry_basis_pct zostaje obniżone do 0.0 (wymagane jest tylko, by HL nie było z dyskontem, więc baza staje się miękkim filtrem), a entry_funding_8h zostaje obniżone w kierunku dolnej granicy trwałego funding rate (0.005%/8h), dzięki czemu wejścia są napędzane głównie dodatnim carry fundingowym. Dodano log częstotliwości dla całego okresu, podający odsetek świec, na których spełniony jest warunek funding rate / bazy / obu warunków, aby decyzja o kontynuacji lub porzuceniu strategii opierała się na danych. Wyjście następuje po przejściu funding rate na wartość ujemną, zbieżności bazy, limicie czasu wynoszącym 14 dni lub zadziałaniu przełącznika awaryjnego łącznego PnL na poziomie -5%. Trzy regulowane parametry: entry_funding_8h, entry_basis_pct, per_leg_pct.

Strategia jest poprawnie wdrożona, ale zbyt selektywna, by ją optymalizować: łączny warunek wejścia zadziałał tylko 4 razy w ciągu około 28 miesięcy (8 transakcji na nogach, data_days=26). Przy około 1 transakcji na okno testowania kroczącego optymalizacja dopasowałaby się do czystego szumu, a próbka testowa byłaby zdegenerowana. Przed ponownym uruchomieniem optymalizacji zwiększ liczbę transakcji do statystycznie znaczącego poziomu (cel: >= 50 transakcji parą w całym okresie) i sprawdź ich częstość na podstawie rozkładu FUNDING COVERAGE / bazy, który strategia już zapisuje w logach. SPECIFIC CHANGES: (1) Wiążącym ograniczeniem jest warunek bramkujący AND bazy 0.15% — baza między kontraktem perpetual Hyperliquid a rynkiem spot Binance rzadko osiąga 0.15% przy ETH, co blokuje niemal wszystkie wejścia. Znacznie obniż entry_basis_pct (np. przetestuj 0.0003-0.0005 lub 0.0), aby strategia opierała się głównie na dochodzie z dodatniej stopy finansowania — przewadze, którą silnik teraz niezawodnie uwzględnia — a baza pełniła rolę filtra pomocniczego, zamiast być bezwzględnym warunkiem. (2) Obniż entry_funding_8h w kierunku dolnego poziomu trwale dodatniego finansowania i sprawdź, jak często samo finansowanie HL przekracza ten próg. (3) Dodaj jednorazowy log pokazujący dla całego okresu odsetek słupków, w których finansowanie>=progu, baza>=progu oraz oba warunki BOTH są spełnione — to bezpośrednio pokaże, czy istnieje wystarczająca częstość transakcji. (4) Wykonaj ponowny backtest i potwierdź >= 50 transakcji oraz niezerową stopę zwrotu netto, zanim przejdziesz do optymalizacji. IMPORTANT: jeśli diagnostyka pokaże, że połączenie finansowania i bazy jest z natury rzadkie na ETH, nawet po złagodzeniu warunków, albo luźniejsze warunki nie zapewnią dodatniej przewagi netto po opłatach, porzuć strategię (lub przeformułuj ją dla rynku lub aktywa o trwale wyższym finansowaniu/bazie) zamiast bezproduktywnie próbować dalej — przedstaw rozkład, aby kolejna decyzja opierała się na danych.