BTC Long-Short na Kontra-Trade sa Sunod-sunod na Liquidation: salungatin ang mga sobra-sobrang galaw sa BTCUSDT.BINANCE 1H bar kapag pumalo ang liquidation volume sa Z > 3 kasabay ng paggalaw ng presyo na 2%

Isang long-short mean-reversion na estratehiya sa BTCUSDT.BINANCE USD-M perpetual futures na nagte-trade nang salungat sa sapilitang liquidation cascade. Gumagamit ito ng BINANCE USD-M perp bar (napatunayang malinis na datos) + karagdagang liquidation data (PostgreSQL — hiwalay na stream sa alinmang naunang eksperimento sa pipeline). Ang hypothesis: kapag pumalo ang oras-oras na liquidation volume sa BTCUSDT nang >3 standard deviation sa ibabaw ng 30-araw na baseline nito AND at gumalaw ang presyo nang ≥2% sa parehong direksiyon sa nakaraang 4 oras, nasa isang FORCED-FLOW OVERSHOOT ang merkado — mekanikal ang marginal seller (sa long-liquidation cascade) o marginal buyer (sa short-squeeze), hindi likas ang kilos nito. Kapag naubos na ang sapilitang daloy (karaniwan sa loob ng 4-12 oras), pumapasok ang mga likas na kalahok sa presyong nalihis at bahagyang bumabaligtad ang galaw. Nagiging LONG ang estratehiya kapag nagka-cascade ang mga liquidation sa panig ng long (sumosobra ang galaw ng presyo sa DOWN) at SHORT kapag nagka-cascade ang mga liquidation sa panig ng short (sumosobra ang galaw ng presyo sa UP). Pinupunan nito ang FIVE kulang ang kinatawang mga kategorya: direksiyong long-short (14.2% → patungo sa 45%), mekanismong hinimok ng liquidation (walang estratehiya sa 459 eksperimento ang gumamit sa data stream na ito), crypto-specific na microstructure (edge na imposibleng makamit sa TradFi), mid-term na paghawak (mga siklong 4-12h), at estratehiyang hinimok ng karagdagang datos (na naging malinis sa aming katalogo, di-gaya ng BINANCE_SPOT bar). Naitala ang mekanismo sa pananaliksik tungkol sa crypto microstructure (Kaiko 2022, Coin Metrics 2023) — sistematikong nagdudulot ang mga liquidation cascade ng 1.5-3% sobrang galaw ng presyo na bahagyang bumabaligtad sa loob ng 6-18 oras habang humuhupa ang sapilitang bahagi ng daloy ng order. Gumagamit ito ng ONLY BINANCE USD-M perp bar + liquidation data na nakaimbak sa Postgres — walang BINANCE_SPOT bar (na paulit-ulit na bumagsak sa beripikasyon ng Layer 3 sa sesyong ito). Pagsukat ng laki ng posisyon: 15% ng equity sa bawat direksiyon. Panganib sa bawat trade: 1.5% ng equity na nililimitahan ng stop-loss.

Pinakamaliit na pag-aayos sa Iteration-2 para sa pagkabigong 'Walang nagawang trade' ng Layer-3, nang walang regression sa mga naunang layer. Ugat ng problema: kailangang magkasabay ang liquidation spike na >=3 sigma na sinusukat sa iisang 1-oras na bucket at ang pangingibabaw ng direksiyon AND ng galaw ng presyo na >=2% sa parehong direksiyon sa loob ng 4h; dahil kalat-kalat ang mga liquidation row, madalas walang laman ang 1h bucket kahit may totoong cascade, kaya madalas na `total` ay 0 at halos hindi kailanman natutupad ang tatlong kondisyong pinagsama. Pinananatili ng pag-aayos na liquidation-driven ang mekanismo (100% tahasang walang fallback na presyo lamang): (1) pinagsasama na ngayon ang mga liquidation sa loob ng `liq_window_bars` oras (default na 4h, kapareho ng window ng galaw ng presyo) upang aktuwal na makuha ang cascade at mas madalas na maging hindi sero ang `total`, kaya magkatugma ang dalawang bahagi ng signal; (2) niluwagan ang dalawang numerikong pamantayan (liq_z 3.0->2.0, price_move_pct 2.0->1.0) at ibinaba ang min_events 50->30 upang mas maagang magamit ang z-baseline. Hindi nagbago ang mga import (nanatiling pasado ang Layer 1) at pareho pa rin sa estruktura ang balangkas ng z-score/trigger/exit/sizing na pumasa sa Layer 2 — isang window bound at tatlong default na parameter lang ang binago. Nananatiling BINANCE USD-M futures ang venue (kailangan ng margin para sa long-short), leverage na 1.0 (hindi ginagamit para sa amplification, kaya hindi naa-activate ang gate na leverage_set_but_unused). Kung totoong walang liquidation row sa sandbox, tama pa ring mananatiling flat ang estratehiya sa halip na magkunwaring may trade gamit ang proxy na presyo.

Hindi structural na ma-backtest sa available na liquidation history: pinroseso ng engine ang 56,208 1H bars (~6.5 taon) pero nakagawa lang ng 8 trades, ALL na naka-cluster sa iisang ~2-buwang window (2026-04-21 hanggang 2026-06-24), na may metrics_reliable=FALSE. Kailangan ng signal ang supplementary_data['liquidations'] rows, na inilarawan ng hypothesis at code bilang sparse/live-stream-only; ang trade clustering ay consistent sa liquidations store na naglalaman lang ng kamakailang ~2-buwang window, kaya hindi kailanman mag-fire ang cascade signal sa 6.4 ng 6.5 backtest years (symptom na naobserbahan, hindi independent audit ng Postgres table). Ito ay data-availability wall, hindi code o parameter na problema: ang strategy ay naisagawa nang tama at nag-trade nang tapat kapag may liquidation rows, kaya walang paraan para ayusin ng developer at walang parameter na i-tune — 8 trades sa isang 2-buwang window ay hindi makakapag-support ng walk-forward (3 windows) o holdout, kaya ang optimization ay magfi-fit lang ng purong ingay. Ang mekanismo ay hindi nakumpirma ni narefute; hindi lang ito ma-validate. Huwag i-optimize, huwag i-iterate. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: ang liquidation-cascade hypotheses ay nananatiling naka-block hanggang sa ma-backfill ang liquidations data stream ng multi-year history (hal. sa pamamagitan ng Binance Vision liquidation snapshots) sa halip na live-stream-only; huwag subukan muli ang liquidation-driven strategies hanggang sa umiral ang history na iyon. FAILURE PATTERN: ang liquidations-driven strategies sa BTCUSDT ay nagbibigay ng halos walang laman na backtest (8 trades na nakatuon sa kamakailang ~2-buwang window) dahil ang liquidations supplementary stream ay live-stream-only na may ~2 buwan ng history — ang mekanismo ay hindi ma-validate out-of-sample at ang strategy ay structural na hindi ma-backtest hanggang sa ma-backfill ang data, ang parehong supplementary-data-history wall na nakita sa OI/liquidation family.