BTC Likvideringskaskad motkonträr long-short: tona ned överdrivna rörelser på BTCUSDT.BINANCE 1H-staplar när likvideringsvolymens Z-värde överstiger 3 med en samtidig prisrörelse på 2%

En long-short mean-reversion-strategi på BTCUSDT.BINANCE USD-M perpetual futures som handlar mot tvångslikvidation-kaskader. Använder BINANCE USD-M perp-barer (bevisat ren data) + likvidations kompletterande data (PostgreSQL — distinkt stream från alla tidigare pipeline-experiment). Hypotesen: när timvis likvidationsvolym på BTCUSDT spikar >3 standardavvikelser över sin 30-dagars baslinje AND har priset rört sig ≥2% i samma riktning under de föregående 4 timmarna, är marknaden i en FORCED-FLOW OVERSHOOT — den marginella säljaren (i en lång-likvidationskaskad) eller marginella köparen (i en short squeeze) är mekanisk, inte naturlig. När tvångsflödet tar slut (typiskt inom 4-12 timmar), kliver naturliga deltagare in till det dislocerade priset och rörelsen återgår delvis. Strategin går LONG när långsida-likvidationer kaskaderar (priset överskjuter DOWN) och SHORT när kortsida-likvidationer kaskaderar (priset överskjuter UP). Detta fyller FIVE underrepresenterade buckets: long-short-riktning (14.2% → mot 45%), likvidationsdriven mekanism (inga strategier i 459-experiment har använt denna dataström), krypto-specifik mikrostruktur (en TradFi-omöjlig edge), medellång hållning (4-12h-cykler), och kompletterande-datadriven (vilket har varit rent i vår katalog till skillnad från BINANCE_SPOT-barer). Mekanismen är dokumenterad i krypto-mikrostruktursforskning (Kaiko 2022, Coin Metrics 2023) — likvidationskaskader producerar systematiskt 1.5-3%-prisöverskjutningar som delvis reverteras inom 6-18 timmar när tvångsflödeskomponenten av orderflödet dissipar. Använder ONLY BINANCE USD-M perp-barer + Postgres-lagrad likvidationsdata — inga BINANCE_SPOT-barer (vilka upprepade gånger misslyckats Lager 3-verifiering i denna session). Positionstorlek: 15% av eget kapital per riktning. Risk per affär: 1.5% av eget kapital takad av stop-loss.

Iteration-2 minimal fix för Lager-3 'Inga affärer producerade'-misslyckandet, utan regression av tidigare lager. Grundorsak: ingången krävde en ≥3-sigma likvidationsspik uppmätt i en enskild 1-timmars bucket för att sammanfalla med riktningsdominans AND en ≥2% samma-riktnings 4h-prisrörelse; med glesa likvidationsrader är 1h-bucket ofta tom även under en riktig kaskad, så `total` var ofta 0 och trippelkonjunktionen avfyrades i princip aldrig. Fixen behåller mekanismen 100% likvidationsdriven (uttryckligen ingen pris-only fallback): (1) likvidationer summeras nu över `liq_window_bars` timmar (standard 4h, samma fönster som prisrörelsen) så att kaskaden faktiskt fångas och `total` är icke-noll mycket oftare, vilket anpassar de två halvorna av signalen; (2) de två numeriska tröskelvärdena lossas (liq_z 3.0->2.0, price_move_pct 2.0->1.0) och min_events sänks 50->30 så att z-baslinjen är användbar tidigare. Imports är oförändrade (Lager 1 förblir grönt) och den z-score/trigger/exit/storlek-ställning som passerade Lager 2 är strukturellt identisk — endast en fönstergräns och tre parameterstandardvärden ändrades. Venue förblir BINANCE USD-M-futures (long-short behöver marginal), hävstång 1.0 (inte använd för amplifiering, så leverage_set_but_unused-grinden triggar inte). Om sandlådan genuint saknar likvidationsrader stannar strategin korrekt platt snarare än att fejka affärer via en prisproxy.

Strukturellt omöjlig att backtesta på tillgänglig likvidationshistorik: motorn bearbetade 56,208 1H-barer (~6.5 år) men producerade endast 8 affärer, ALL klustrade i ett enda ~2-månadersfönster (2026-04-21 till 2026-06-24), med metrics_reliable=FALSE. Signalen kräver supplementary_data['liquidations']-rader, vilket både hypotesen och koden beskriver som gles/endast live-stream; handelsklustringen är konsistent med att likvidationslagret endast håller ett sent ~2-månadersfönster, så kaskadsignalen kan aldrig avfyras över 6.4 av 6.5 backtest-år (observerad symtom, inte en oberoende granskning av Postgres-tabellen). Detta är en datatillgänglighets-vägg, inte ett kod- eller parameterproblem: strategin är korrekt implementerad och handlar troget när likvidationsrader finns, så det finns inget för utvecklaren att fixa och ingen parameter att justera — 8 affärer i ett 2-månadersfönster kan inte stödja walk-forward (3 fönster) eller ett holdout, så optimering skulle passa ren brus. Mekanismen är varken bekräftad eller motbevisad; den kan helt enkelt inte valideras. Inte optimera, inte iterera. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: likvidationskaskad-hypoteser förblir blockerade tills likvidations-dataströmmen fylls på med flerårig historik (t.ex. via Binance Vision-likvidationssnapshots) snarare än endast live-stream; försök inte likvidationsdrivna strategier igen förrän den historiken finns. FAILURE PATTERN: likvidationsdrivna strategier på BTCUSDT producerar en nästan tom backtest (8 affärer begränsade till ett sent ~2-månadersfönster) eftersom likvidations kompletterande stream är endast live-stream med ~2 månaders historik — mekanismen kan inte valideras out-of-sample och strategin är strukturellt omöjlig att backtesta tills datan fylls på, samma kompletterande-data-historik-vägg som ses över OI/likvidations-familjen.