BTC Counter-Trade likvidační kaskády long-short: Tlumení přestřelů na BTCUSDT.BINANCE 1H barech, když objem likvidací vystřelí Z > 3 se souběžným pohybem ceny 2%

Strategie long-short návratu k průměru na BTCUSDT.BINANCE USD-M perpetuálních futures, která obchoduje proti vynuceným likvidačním kaskádám. Používá BINANCE USD-M perp bary (prokázaná čistá data) + doplňková data likvidací (PostgreSQL — odlišný stream od jakéhokoli předchozího experimentu pipeline). Hypotéza: když hodinový objem likvidací na BTCUSDT vystřelí >3 směrodatných odchylek nad svou 30-denní baseline AND cena se pohybovala ≥2% stejným směrem v uplynulých 4 hodinách, trh je v FORCED-FLOW OVERSHOOT — marginální prodávající (v long-likvidační kaskádě) nebo marginální kupující (ve short-squeeze) je mechanický, ne přirozený. Jakmile vynucený tok vyčerpá (typicky do 4-12 hodin), přirození účastníci vstoupí za dislokovanou cenu a pohyb se částečně zvrátí. Strategie jde LONG, když longové likvidace kaskádovitě probíhají (cena přestřeluje DOWN), a SHORT, když shortové likvidace kaskádovitě probíhají (cena přestřeluje UP). To zaplňuje FIVE nedostatečně zastoupených bucketů: směr long-short (14.2% → směrem k 45%), mechanismus řízený likvidacemi (nula strategií v 459 experimentech nepoužilo tento datový stream), krypto-specifická mikrostruktura (TradFi-nemožný edge), střednědobý držení (4-12h cykly) a řízený doplňkovými daty (které byly v našem katalogu čisté na rozdíl od BINANCE_SPOT barů). Mechanismus je zdokumentován v krypto mikrostrukturálním výzkumu (Kaiko 2022, Coin Metrics 2023) — likvidační kaskády systematicky produkují 1.5-3% přestřelení ceny, která se částečně vracejí do 6-18 hodin, jak se složka vynuceného toku v order flow rozptyluje. Používá ONLY BINANCE USD-M perp barů + data likvidací uložená v Postgres — žádné BINANCE_SPOT bary (které opakovaně selhaly při ověřování Vrstvy 3 v této relaci). Velikost pozice: 15% kapitálu na směr. Riziko na obchod: 1.5% kapitálu omezené stop-lossem.

Iterace-2 minimální oprava selhání Vrstvy-3 'Nebyly vyprodukovány žádné obchody', bez regrese dřívějších vrstev. Hlavní příčina: vstup vyžadoval spike likvidací >=3-sigma měřený v jednom 1-hodinovém bucketu, aby se časově shodoval se směrovou dominancí AND a stejnosměrný pohyb ceny 4h >= 2%; s řídkými likvidačními řádky je 1h bucket často prázdný i během reálné kaskády, takže `total` bylo často 0 a trojitá konjunkce v podstatě nikdy nevystřelila. Oprava zachovává mechanismus 100% likvidacemi-řízený (výslovně žádný záložní mechanismus pouze na cenu): (1) likvidace jsou nyní sčítány přes `liq_window_bars` hodin (výchozí 4h, stejné okno jako pohyb ceny), takže kaskáda je skutečně zachycena a `total` je nenulové mnohem častěji, což zarovnává dvě poloviny signálu; (2) dvě číselné prahové hodnoty jsou uvolněny (liq_z 3.0->2.0, price_move_pct 2.0->1.0) a min_events sníženo 50->30, takže z-baseline je použitelná dříve. Importy jsou nezměněny (Vrstva 1 zůstává zelená) a lešení z-score/trigger/exit/sizing, které prošlo Vrstvou 2, je strukturálně identické — změněna pouze jedna hranice okna a tři výchozí hodnoty parametrů. Místo obchodování zůstává BINANCE USD-M futures (long-short potřebuje margin), páka 1.0 (nepoužita pro zesílení, takže se brána leverage_set_but_unused nespouští). Pokud sandbox skutečně nemá žádné likvidační řádky, strategie stále správně zůstává flat místo toho, aby falšovala obchody prostřednictvím cenového proxy.

Strukturálně nebacktestovatelné na dostupné historii likvidací: engine zpracoval 56,208 1H barů (~6.5 let), ale vyprodukoval pouze 8 obchodů, ALL shluknutých v jednom ~2-měsíčním okně (2026-04-21 až 2026-06-24), s metrics_reliable=FALSE. Signál vyžaduje řádky supplementary_data['liquidations'], které hypotéza i kód popisují jako řídké/pouze live-stream; shlukování obchodů je v souladu s tím, že úložiště likvidací drží pouze nedávné ~2-měsíční okno, takže signál kaskády nikdy nemůže vystřelit napříč 6.4 6.5 lety backtestu (pozorovaný příznak, ne nezávislý audit Postgres tabulky). Toto je zeď dostupnosti dat, ne problém s kódem nebo parametry: strategie je implementována správně a obchoduje věrně, když jsou přítomny likvidační řádky, takže není co vývojář opravit a žádný parametr k ladění — 8 obchodů v jednom 2-měsíčním okně nemůže podpořit walk-forward (3 oken) ani holdout, takže optimalizace by sedla čistý šum. Mechanismus není ani potvrzen, ani vyvrácen; prostě nemůže být validován. Neoptimalizovat, neiterovat. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: hypotézy likvidační kaskády zůstávají blokované, dokud není datový stream likvidací doplněn o víceletou historii (např. přes Binance Vision likvidační snapshoty) namísto pouze live-stream; nepokoušejte se znovu o strategie řízené likvidacemi, dokud tato historie neexistuje. FAILURE PATTERN: strategie řízené likvidacemi na BTCUSDT produkují téměř prázdný backtest (8 obchodů omezených na nedávné ~2-měsíční okno), protože doplňkový stream likvidací je pouze live-stream s ~2 měsíci historie — mechanismus nemůže být validován out-of-sample a strategie je strukturálně nebacktestovatelná, dokud nejsou data doplněna, stejná zeď historie doplňkových dat pozorovaná napříč rodinou OI/likvidací.