BTC Motposisjonering mot likvidasjonskaskader, long-short: Fade overskytinger på BTCUSDT.BINANCE 1H-barer når likvidasjonsvolumet får et Z-utslag > 3 med samtidig prisbevegelse på 2%

En long-short mean-reversjonsstrategi på BTCUSDT.BINANCE USD-M perpetual futures som handler mot tvangslikvidasjonskaskader. Bruker BINANCE USD-M perp-barer (dokumentert rene data) + likvidasjonstilleggsdata (PostgreSQL — distinkt strøm fra enhver tidligere pipeline-eksperiment). Hypotesen: når timelikvidasjonsvolum på BTCUSDT spisser >3 standardavvik over sin 30-dags grunnlinje AND pris har beveget seg ≥2% i samme retning over de siste 4 timene, er markedet i en FORCED-FLOW OVERSHOOT — den marginale selgeren (i en long-likvidasjonskaskade) eller marginale kjøperen (i en short-squeeze) er mekanisk, ikke naturlig. Når tvangsflow er oppbrukt (typisk innen 4-12 timer), trer naturlige deltakere inn til den disloserte prisen og bevegelsen reverseres delvis. Strategien går LONG når long-side-likvidasjoner kaskader (pris overskrider DOWN) og SHORT når short-side-likvidasjoner kaskader (pris overskrider UP). Dette fyller FIVE underrepresenterte bøtter: long-short-retning (14.2% → mot 45%), likvidasjonsdrevet mekanisme (null strategier i 459-eksperimenter har brukt denne datastrømmen), kryptospesifikk mikrostruktur (en TradFi-umulig edge), mellomlangs hold (4-12h-sykluser), og tilleggsdatadrevet (som har vært ren i vår katalog i motsetning til BINANCE_SPOT-barer). Mekanismen er dokumentert i krypto-mikrostrukturforskning (Kaiko 2022, Coin Metrics 2023) — likvidasjonskaskader produserer systematisk 1.5-3% prisoverskridelser som delvis reverserer innen 6-18 timer ettersom tvangsflow-komponenten av ordreflowen avtar. Bruker ONLY BINANCE USD-M perp-barer + Postgres-lagrede likvidasjonsdata — ingen BINANCE_SPOT-barer (som gjentatte ganger har feilet Lag 3-verifisering i denne sesjonen). Posisjonsstørrelse: 15% av egenkapital per retning. Risiko per handel: 1.5% av egenkapital begrenset av stop-loss.

Iterasjon-2 minimal fiks for Lag-3 'Ingen handler produsert'-feilen, uten regresjon av tidligere lag. Rotårsak: inngangen krevde en >=3-sigma likvidasjonsspiss målt i en enkelt 1-timers bøtte for å sammenfalle med retningsdominans AND en >=2% samme-retnings 4t prisbevegelse; med sparsomme likvidasjonsrader er 1t-bøtten ofte tom selv under en reell kaskade, så `total` var ofte 0 og trippelkonjunksjonen utløses i praksis aldri. Fiksen beholder mekanismen 100% likvidasjonsdrevet (uttrykkelig ingen pris-bare fallback): (1) likvidasjoner summeres nå over `liq_window_bars` timer (standard 4t, det samme vinduet som prisbevegelsen) slik at kaskaden faktisk fanges opp og `total` er ikke-null langt oftere, noe som justerer de to halvdelene av signalet; (2) de to numeriske tersklene er slappet (liq_z 3.0->2.0, price_move_pct 2.0->1.0) og min_events senket 50->30 slik at z-grunnlinjen er brukbar tidligere. Importene er uendret (Lag 1 forblir grønt) og z-score/trigger/avslutning/størrelse-stillaset som bestod Lag 2 er strukturelt identisk — kun én vindusgrense og tre parameterstandarder er endret. Handelsplass forblir BINANCE USD-M futures (long-short trenger margin), leverage 1.0 (ikke brukt for amplifikasjon, så leverage_set_but_unused-porten utløses ikke). Hvis sandkassen genuint ikke har noen likvidasjonsrader forblir strategien korrekt flat i stedet for å fabrikkere handler via en prisproxy.

Strukturelt ikke-backtestbar på tilgjengelig likvidasjonshistorikk: motoren prosesserte 56,208 1H-barer (~6.5 år) men produserte kun 8 handler, ALL klynget i et enkelt ~2-måneders vindu (2026-04-21 til 2026-06-24), med metrics_reliable=FALSE. Signalet krever supplementary_data['liquidations']-rader, som både hypotesen og koden beskriver som sparsom/kun-live-strøm; handelsklyngingen er konsistent med at likvidasjonslageret kun inneholder et nylig ~2-måneders vindu, så kaskadesignalet kan aldri utløses over 6.4 av de 6.5 backtest-årene (symptom observert, ikke en uavhengig revisjon av Postgres-tabellen). Dette er en datatilgjengelighetsmur, ikke et kode- eller parameterproblem: strategien er implementert korrekt og handler troverdig når likvidasjonsrader er til stede, så det er ingenting for utvikleren å fikse og ingen parameter å justere — 8 handler i ett 2-måneders vindu kan ikke støtte walk-forward (3 vinduer) eller et holdout, så optimalisering ville tilpasse ren støy. Mekanismen er verken bekreftet eller avkreftet; den kan ganske enkelt ikke valideres. Ikke optimaliser, ikke iterer. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: likvidasjonskaskadehypoteser forblir blokkert inntil likvidasjonsdatastrømmen er etterfylt med flerårig historikk (f.eks. via Binance Vision-likvidasjonsøyeblikksbilder) i stedet for kun-live-strøm; ikke gjør nye forsøk på likvidasjonsdrevne strategier før den historikken eksisterer. FAILURE PATTERN: likvidasjonsdrevne strategier på BTCUSDT produserer en nesten-tom backtest (8 handler avgrenset til et nylig ~2-måneders vindu) fordi likvidasjonstilleggsstrømmen kun er live-strøm med ~2 måneders historikk — mekanismen kan ikke valideres ut-av-prøve og strategien er strukturelt ikke-backtestbar inntil dataene er etterfylt, den samme tilleggsdata-historikk-muren sett på tvers av OI/likvidasjonsfamilien.