BTC Likvidācijas kaskādes pretdarījums Long-Short: Pretdarbība pārspīlējumiem uz BTCUSDT.BINANCE 1H joslām, kad likvidācijas apjoma smailes Z > 3 ar vienlaicīgu 2% cenas kustību

Long-short vidējās atgriešanās stratēģija uz BTCUSDT.BINANCE USD-M beztermiņa nākotnes līgumiem, kas tirgo pretēji piespiedu likvidācijas kaskādēm. Izmanto BINANCE USD-M perp joslas (pierādīti tīri dati) + likvidāciju papildu datus (PostgreSQL — atšķirīga plūsma no jebkuras iepriekšējās konveijera eksperimenta). Hipotēze: kad likvidācijas apjoms stundā uz BTCUSDT pārsniedz >3 standartnovirzes virs tās 30 dienu bāzes līnijas AND cena ir pārvietojusies ≥2% tajā pašā virzienā pēdējo 4 stundu laikā, tirgus atrodas FORCED-FLOW OVERSHOOT — marginālais pārdevējs (long likvidācijas kaskādē) vai marginālais pircējs (short saspiešanā) ir mehānisks, ne dabisks. Kad piespiedu plūsma izsīkst (parasti 4-12 stundu laikā), dabiskie dalībnieki iesaistās pie dislocētās cenas un kustība daļēji atgriežas. Stratēģija iet LONG, kad long puses likvidāciju kaskāde (cena pārspīlē DOWN), un SHORT, kad short puses likvidāciju kaskāde (cena pārspīlē UP). Tas aizpilda FIVE nepietiekami pārstāvētus segmentus: long-short virziens (14.2% → virzienā uz 45%), likvidāciju virzīts mehānisms (nulles stratēģijas 459 eksperimentos nav izmantojušas šo datu plūsmu), kriptovalūtai specifiska mikrostruktūra (TradFi neiespējama priekšrocība), vidēja termiņa turējums (4-12h cikli), un papildu datu virzīts (kas ir bijis tīrs mūsu katalogā, atšķirībā no BINANCE_SPOT joslām). Mehānisms ir dokumentēts kriptovalūtas mikrostruktūras pētījumos (Kaiko 2022, Coin Metrics 2023) — likvidācijas kaskādes sistemātiski rada 1.5-3% cenas pārspīlējumus, kas daļēji atgriežas 6-18 stundu laikā, kamēr piespiedu plūsmas komponente izklīst. Izmanto ONLY BINANCE USD-M perp joslas + Postgres glabātos likvidāciju datus — nav BINANCE_SPOT joslu (kas atkārtoti nav izturējušas Slāņa 3 verifikāciju šajā sesijā). Pozīcijas lielums: 15% no kapitāla katrā virzienā. Risks uz darījumu: 1.5% no kapitāla, ierobežots ar stop-loss.

Iterācija-2 minimāls labojums Slāņa-3 'Nav saražotu darījumu' kļūmei, bez iepriekšējo slāņu regresijas. Saknes cēlonis: ievade prasīja >= 3-sigma likvidācijas smaili, kas izmērīta vienā 1 stundu spainī, lai sakristu ar virziena dominanci AND >= 2% tāda paša virziena 4h cenas kustību; ar retām likvidāciju rindām 1h spainis bieži ir tukšs pat reālas kaskādes laikā, tāpēc `total` bieži bija 0 un trīskāršā savienojuma būtībā nekad nenostrādāja. Labojums saglabā mehānismu 100% likvidāciju virzītu (tieši bez cenas vienīgi rezerves): (1) likvidācijas tagad tiek summētas virs `liq_window_bars` stundām (noklusējums 4h, tas pats logs kā cenas kustībai), lai kaskāde patiešām tiktu uztverta un `total` ir nenulles daudz biežāk, saskaņojot signāla divas puses; (2) divi skaitliskie sliekšņi tiek atslābināti (liq_z 3.0->2.0, price_move_pct 2.0->1.0) un min_events pazemināts 50->30, lai z-bāzes līnija būtu izmantojama ātrāk. Importi nemainās (Slānis 1 paliek zaļš) un z-rezultāta/trigera/izejas/lieluma sastatnes, kas izturēja Slāni 2, ir strukturāli identiskas — mainīta tikai viena loga robeža un trīs parametru noklusējumi. Vieta paliek BINANCE USD-M nākotnes līgumi (long-short prasa maržu), sviras efekts 1.0 (netiek izmantots pastiprināšanai, tāpēc leverage_set_but_unused vārti netiek aktivizēti). Ja smilšu kastē patiešām nav likvidācijas rindu, stratēģija joprojām pareizi paliek plakana, nevis izdomā darījumus, izmantojot cenu starpnieku.

Strukturāli netestējams pieejamajā likvidācijas vēsturē: dzinējs apstrādāja 56,208 1H joslas (~6.5 gadus), bet saražoja tikai 8 darījumus, ALL koncentrētus vienā ~2 mēnešu logā (2026-04-21 līdz 2026-06-24), ar metrics_reliable=FALSE. Signāls prasa supplementary_data['liquidations'] rindas, ko gan hipotēze, gan kods apraksta kā retas/tikai tiešraides straumes; darījumu koncentrēšanās ir saskanīga ar to, ka likvidāciju krātuve satur tikai nesenu ~2 mēnešu logu, tāpēc kaskādes signāls nekad nevar nostrādāt 6.4 no 6.5 backtesta gadiem (novērotais simptoms, nevis neatkarīgs Postgres tabulas audits). Šī ir datu pieejamības siena, nevis koda vai parametru problēma: stratēģija ir pareizi īstenota un ticami veic darījumus, kad likvidāciju rindas ir klātesošas, tāpēc izstrādātājam nav ko labot un nav parametru, ko pielāgot — 8 darījumi vienā 2 mēnešu logā nevar atbalstīt walk-forward (3 logi) vai holdout, tāpēc optimizācija uzstādītu tīru troksni. Mehānisms nav ne apstiprināts, ne noraidīts; to vienkārši nevar validēt. Neoptimizēt, neatkārtot. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: likvidācijas kaskādes hipotēzes paliek bloķētas, kamēr likvidāciju datu plūsma netiek papildināta ar daudzgadu vēsturi (piemēram, izmantojot Binance Vision likvidācijas momentuzņēmumus), nevis tikai tiešraides straumi; nemēģināt atkārtoti likvidāciju virzītas stratēģijas, kamēr šāda vēsture nepastāv. FAILURE PATTERN: likvidāciju virzītas stratēģijas uz BTCUSDT saražo gandrīz tukšu backtestu (8 darījumi ierobežoti nesenu ~2 mēnešu logā), jo likvidāciju papildu plūsma ir tikai tiešraides straume ar ~2 mēnešu vēsturi — mehānismu nevar validēt ārpus izlases un stratēģija ir strukturāli netestējama, kamēr dati netiek papildināti, tā pati papildu datu vēstures siena, kas novērota visā OI/likvidācijas saimē.