BTC Counter-Trade Long-Short pe Cascadă de Lichidare: Atenuare Supra-corrigeri pe Bare BTCUSDT.BINANCE 1H Când Volumul de Lichidare Spike Z > 3 cu Mișcare de Preț 2% Concomitentă

O strategie long-short de reversie la medie pe contracte perpetue BTCUSDT.BINANCE USD-M care tranzacționează contrar cascadelor de lichidare forțată. Utilizează BINANCE bare perp USD-M (date curate dovedite) + date suplimentare despre lichidări (PostgreSQL — flux distinct față de orice experiment anterior din pipeline). Ipoteza: când volumul orar de lichidări pe BTCUSDT face spike >3 abateri standard peste linia de bază de 30 zile AND prețul s-a mișcat ≥2% în aceeași direcție pe parcursul ultimelor 4 ore, piața se află într-o FORCED-FLOW OVERSHOOT — vânzătorul marginal (într-o cascadă de lichidare long) sau cumpărătorul marginal (într-un short squeeze) este mecanic, nu natural. Odată ce fluxul forțat se epuizează (de obicei în 4-12 ore), participanții naturali intervin la prețul dislocat și mișcarea se reversează parțial. Strategia merge LONG când lichidările long cascadă (prețul supra-corrigează DOWN) și SHORT când lichidările short cascadă (prețul supra-corrigează UP). Aceasta umple FIVE bucket-uri sub-reprezentate: direcție long-short (14.2% → spre 45%), mecanism determinat de lichidări (nicio strategie din experimentele 459 nu a folosit acest flux de date), microstructură specifică crypto (un avantaj imposibil în TradFi), deținere pe termen mediu ( cicluri 4-12h) și bazat pe date suplimentare (care au fost curate în catalogul nostru, spre deosebire de barele BINANCE_SPOT). Mecanismul este documentat în cercetarea de microstructură crypto (Kaiko 2022, Coin Metrics 2023) — cascadele de lichidare produc sistematic supra-corrigeri de preț 1.5-3% care se reversează parțial în 6-18 ore pe măsură ce componenta de flux forțat al fluxului de ordine se disipează. Utilizează ONLY BINANCE bare perp USD-M + date de lichidări stocate în Postgres — fără bare BINANCE_SPOT (care au eșuat repetat verificarea Layer 3 în această sesiune). Dimensionarea poziției: 15% din capital pe direcție. Risc per tranzacție: 1.5% din capital, limitat de stop-loss.

Iterarea-2 fix minimal pentru eșecul 'Nu s-au produs tranzacții' al Layer-3, fără regresie a layer-elor anterioare. Cauza rădăcină: intrarea necesita un spike de lichidare >=3-sigma măsurat într-un singur bucket de 1 ore care să coincidă cu dominanța direcțională AND o mișcare de preț 4h în aceeași direcție >=2%; cu rânduri de lichidare sparse, bucket-ul de 1h este frecvent gol chiar și în timpul unei cascade reale, deci `total` era adesea 0 și conjuncția triplă practic nu se declanșa niciodată. Corecția păstrează mecanismul 100% determinat de lichidări (explicit fără fallback doar pe preț): (1) lichidările sunt acum însumate pe `liq_window_bars` ore (implicit 4h, aceeași fereastră ca mișcarea de preț) astfel încât cascada este efectiv capturată și `total` este non-zero mult mai des, aliniind cele două jumătăți ale semnalului; (2) cele două praguri numerice sunt relaxate (liq_z 3.0->2.0, price_move_pct 2.0->1.0) și min_events coborât 50->30 astfel încât linia de bază z să fie utilizabilă mai devreme. Importurile sunt neschimbate (Layer 1 rămâne verde) iar schela z-score/trigger/exit/sizing care a trecut Layer 2 este structural identică — s-a schimbat doar o limită de fereastră și trei implicite de parametri. Sala rămâne futures BINANCE USD-M (long-short necesită marjă), levier 1.0 (nu este folosit pentru amplificare, deci poarta leverage_set_but_unused nu se declanșează). Dacă sandbox-ul nu are genuin niciun rând de lichidare, strategia corect rămâne neutră în loc să fabrice tranzacții printr-un proxy de preț.

Structural imposibil de testat retroactiv pe istoricul de lichidări disponibil: motorul a procesat 56,208 bare 1H (~6.5 ani), dar a generat doar 8 tranzacții, ALL grupate într-o singură fereastră de ~2 luni (2026-04-21 până la 2026-06-24), cu metrics_reliable=FALSE. Semnalul necesită rânduri supplementary_data['liquidations'], pe care atât ipoteza, cât și codul le descriu ca rare/disponibile doar în fluxul live; gruparea tranzacțiilor este în concordanță cu faptul că depozitul de lichidări conține doar o fereastră recentă de ~2 luni, astfel încât semnalul de cascadă nu se poate declanșa în 6.4 din cei 6.5 ani ai backtestului (simptom observat, nu audit independent al tabelului Postgres). Acesta este un blocaj de disponibilitate a datelor, nu o problemă de cod sau de parametri: strategia este implementată corect și tranzacționează conform așteptărilor când sunt prezente rânduri de lichidări, deci dezvoltatorul nu are nimic de remediat și nu există parametri de ajustat — 8 tranzacții într-o singură fereastră de 2 luni nu pot susține o analiză walk-forward (3 ferestre) sau un eșantion de validare, așadar optimizarea s-ar potrivi pe zgomot pur. Mecanismul nici nu este confirmat, nici infirmat; pur și simplu nu poate fi validat. Nu optimizați, nu iterați. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: ipotezele privind cascadele de lichidări rămân blocate până când fluxul de date despre lichidări este completat cu istoric pe mai mulți ani (de exemplu, prin instantanee de lichidări Binance Vision), în loc să fie disponibil doar în fluxul live; nu reluați strategiile bazate pe lichidări înainte ca istoricul să existe. FAILURE PATTERN: strategiile bazate pe lichidări pe BTCUSDT produc un backtest aproape gol (8 tranzacții limitate la o fereastră recentă de ~2 luni), deoarece fluxul suplimentar de lichidări este disponibil doar în fluxul live și are ~2 luni de istoric — mecanismul nu poate fi validat în afara eșantionului, iar strategia este structural imposibil de testat retroactiv până când datele sunt completate; este același blocaj legat de istoricul datelor suplimentare observat în întreaga familie OI/lichidări.