BTC Strategia long-short contrarian sulle cascate di liquidazioni: sfruttare al contrario gli eccessi sulle barre BTCUSDT.BINANCE 1H quando il volume delle liquidazioni registra un picco Z > 3 con un movimento concomitante del prezzo di 2%

Una strategia long-short di mean reversion su futures perpetui BTCUSDT.BINANCE USD-M, che opera in direzione opposta alle cascate di liquidazioni forzate. Usa barre perp BINANCE USD-M (dati di comprovata pulizia) più dati supplementari sulle liquidazioni (PostgreSQL: flusso distinto da qualsiasi esperimento precedente della pipeline). L'ipotesi: quando il volume orario delle liquidazioni su BTCUSDT supera di >3 deviazioni standard il suo valore di riferimento di 30 giorni AND e il prezzo si è mosso di ≥2% nella stessa direzione nelle precedenti 4 ore, il mercato è in una FORCED-FLOW OVERSHOOT: il venditore marginale (in una cascata di liquidazioni di posizioni long) o l'acquirente marginale (in uno short squeeze) è mosso da fattori meccanici, non naturali. Quando il flusso forzato si esaurisce (in genere entro 4-12 ore), i partecipanti naturali intervengono al prezzo dislocato e il movimento si inverte parzialmente. La strategia va LONG quando si susseguono liquidazioni di posizioni long (il prezzo supera al ribasso DOWN) e SHORT quando si susseguono liquidazioni di posizioni short (il prezzo supera al rialzo UP). Questo colma FIVE categorie sottorappresentate: direzione long-short (14.2% → verso 45%), meccanismo basato sulle liquidazioni (nessuna strategia nei 459 esperimenti ha usato questo flusso di dati), microstruttura specifica delle criptovalute (un vantaggio impossibile nei mercati tradizionali), mantenimento di medio termine (cicli di 4-12h) e uso di dati supplementari (risultati puliti nel nostro catalogo, a differenza delle barre BINANCE_SPOT). Il meccanismo è documentato nella ricerca sulla microstruttura delle criptovalute (Kaiko 2022, Coin Metrics 2023): le cascate di liquidazioni producono sistematicamente eccessi di prezzo 1.5-3% che si riassorbono parzialmente entro 6-18 ore, quando la componente di flusso forzato degli ordini si dissipa. Usa barre perp ONLY BINANCE USD-M più dati sulle liquidazioni archiviati in Postgres; non usa barre BINANCE_SPOT (che in questa sessione hanno ripetutamente fallito la verifica di livello 3). Dimensionamento della posizione: 15% del capitale per direzione. Rischio per operazione: 1.5% del capitale, limitato dallo stop-loss.

Iterazione-2: correzione minima del fallimento «Nessuna operazione generata» al livello-3, senza regressioni nei livelli precedenti. Causa principale: l'ingresso richiedeva che un picco di liquidazioni >= 3 sigma, misurato in un singolo intervallo di 1 ore, coincidesse con una prevalenza direzionale AND di un movimento del prezzo nella stessa direzione di >= 2% su 4h; con righe di liquidazione rade, l'intervallo di 1h è spesso vuoto anche durante una cascata reale, quindi `total` era spesso 0 e la congiunzione dei tre requisiti non si verificava quasi mai. La correzione mantiene il meccanismo basato sulle liquidazioni 100% (esclude esplicitamente qualsiasi ripiego basato solo sul prezzo): (1) ora le liquidazioni vengono sommate su `liq_window_bars` ore (predefinito: 4h, la stessa finestra del movimento del prezzo), così la cascata viene effettivamente rilevata e `total` è diverso da zero molto più spesso, allineando le due componenti del segnale; (2) le due soglie numeriche vengono allentate (liq_z 3.0->2.0, price_move_pct 2.0->1.0) e min_events viene abbassato da 50 a 30, rendendo prima utilizzabile il valore di riferimento per lo z-score. Le importazioni restano invariate (il livello 1 rimane superato) e l'impianto dello z-score/segnale di attivazione/uscita/dimensionamento che ha superato il livello 2 è strutturalmente identico: è cambiato solo un limite della finestra e tre valori predefiniti dei parametri. La sede resta quella dei futures BINANCE USD-M (serve margine per operare long-short), leva 1.0 (non usata per amplificare, quindi il controllo leverage_set_but_unused non si attiva). Se la sandbox non contiene effettivamente righe di liquidazione, la strategia resta correttamente senza posizioni anziché inventare operazioni usando il prezzo come indicatore sostitutivo.

Impossibile sottoporre strutturalmente a backtest con la cronologia delle liquidazioni disponibile: il motore ha elaborato 56,208 barre 1H (circa 6.5 anni), ma ha generato solo 8 operazioni, ALL delle quali concentrate in un'unica finestra di circa 2 mesi (da 2026-04-21 a 2026-06-24), con metrics_reliable=FALSE. Il segnale richiede righe supplementary_data['liquidations'], che sia l'ipotesi sia il codice descrivono come rade e disponibili solo tramite flusso in tempo reale; la concentrazione delle operazioni è coerente con un archivio delle liquidazioni limitato a una finestra recente di circa 2 mesi, quindi il segnale di cascata non può attivarsi durante 6.4 dei 6.5 anni del backtest (sintomo osservato, non verifica indipendente della tabella Postgres). Questo è un limite di disponibilità dei dati, non un problema di codice o di parametri: la strategia è implementata correttamente e genera operazioni fedelmente quando sono presenti righe di liquidazione, quindi non c'è nulla da correggere per lo sviluppatore e nessun parametro da ottimizzare: 8 operazioni in un'unica finestra di 2 mesi non possono sostenere una validazione walk-forward (3 finestre) né un campione di verifica, perciò l'ottimizzazione si adatterebbe al puro rumore. Il meccanismo non è né confermato né smentito; semplicemente non può essere convalidato. Non ottimizzare, non iterare. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: le ipotesi sulle cascate di liquidazioni restano bloccate finché il flusso di dati sulle liquidazioni non viene integrato con una cronologia pluriennale (ad es. tramite snapshot delle liquidazioni di Binance Vision), invece di essere disponibile solo in tempo reale; non riprovare strategie basate sulle liquidazioni finché tale cronologia non sarà disponibile. FAILURE PATTERN: le strategie basate sulle liquidazioni su BTCUSDT producono un backtest quasi vuoto (8 operazioni limitate a una finestra recente di circa 2 mesi), perché il flusso supplementare delle liquidazioni è disponibile solo in tempo reale e copre circa 2 mesi di cronologia; il meccanismo non può essere convalidato fuori campione e la strategia è strutturalmente impossibile da sottoporre a backtest finché i dati non vengono integrati, lo stesso limite di cronologia dei dati supplementari osservato nell'intera famiglia OI/liquidazioni.