BTC Long-short de contre-tendance aux cascades de liquidations : jouer les excès de cours sur des bougies de BTCUSDT.BINANCE 1H lorsque le volume des liquidations bondit à Z > 3 avec un mouvement simultané du prix de 2%

Une stratégie de mean-reversion long-short sur les contrats à terme perpétuels BTCUSDT.BINANCE USD-M qui trade à contre-courant des cascades de liquidations forcées. Utilise BINANCE barres perp USD-M (données propres avérées) + données supplémentaires de liquidations (PostgreSQL — flux distinct de toute expérience de pipeline antérieure). L'hypothèse : lorsque le volume de liquidation horaire sur BTCUSDT dépasse de >3 écarts-types sa baseline sur 30 jours AND que le prix a bougé de ≥2% dans la même direction sur les 4 heures précédentes, le marché est dans un FORCED-FLOW OVERSHOOT — le vendeur marginal (dans une cascade de liquidation de positions longues) ou l'acheteur marginal (dans un short-squeeze) est mécanique, pas naturel. Une fois que le flux forcé s'épuise (typiquement en 4-12 heures), les participants naturels interviennent au prix disloqué et le mouvement s'inverse partiellement. La stratégie va LONG lorsqu'une cascade de liquidations côté long se produit (le prix dépasse DOWN) et SHORT lorsqu'une cascade de liquidations côté short se produit (le prix dépasse UP). Cela remplit FIVE buckets sous-représentés : direction long-short (14.2% → vers 45%), mécanisme piloté par les liquidations (aucune stratégie dans les expériences 459 n'a utilisé ce flux de données), microstructure spécifique à la crypto (un edge impossible en TradFi), horizon moyen terme (cycles de 4-12h), et piloté par données supplémentaires (qui ont été propres dans notre catalogue contrairement aux barres BINANCE_SPOT). Le mécanisme est documenté dans la recherche en microstructure crypto (Kaiko 2022, Coin Metrics 2023) — les cascades de liquidation produisent systématiquement des dépassements de prix 1.5-3% qui s'inversent partiellement en 6-18 heures à mesure que la composante de flux forcé du flux d'ordres se dissipe. Utilise ONLY barres perp BINANCE USD-M + données de liquidations stockées dans Postgres — pas de barres BINANCE_SPOT (qui ont échoué à plusieurs reprises à la vérification de la couche 3 dans cette session). Dimensionnement de position : 15% des capitaux propres par direction. Risque par trade : 1.5% des capitaux propres plafonné par le stop-loss.

Correction minimale de l’itération -2 à l’échec « aucune transaction générée » de la couche -3, sans régression des couches précédentes. Cause principale : l’entrée exigeait qu’un pic de liquidations supérieur ou égal à 3 écarts-types, mesuré dans un seul intervalle de 1 heures, coïncide avec une dominance directionnelle AND un mouvement du prix d’au moins 2% dans la même direction sur 4h ; avec des lignes de liquidation rares, l’intervalle de 1h est souvent vide même lors d’une véritable cascade, de sorte que `total` était souvent 0 et que la conjonction des trois conditions ne se déclenchait pratiquement jamais. La correction conserve le mécanisme fondé sur les liquidations 100% (aucun recours explicite à un signal de prix seul) : (1) les liquidations sont désormais additionnées sur `liq_window_bars` heures (par défaut 4h, la même fenêtre que pour le mouvement du prix), afin de mieux capter la cascade et de rendre `total` non nul bien plus souvent, en alignant les deux composantes du signal ; (2) les deux seuils numériques sont assouplis (liq_z 3.0->2.0, price_move_pct 2.0->1.0) et min_events est abaissé de 50->30 afin que la référence du score z soit exploitable plus tôt. Les imports sont inchangés (la couche 1 reste validée) et la structure du score z, du déclencheur, de la sortie et du dimensionnement des positions ayant passé la couche 2 reste identique — seules une limite de fenêtre et trois valeurs de paramètre par défaut ont changé. La plateforme reste les contrats à terme BINANCE USD-M (le long-short nécessite une marge), avec un levier de 1.0 (non utilisé pour amplifier les positions, donc le contrôle leverage_set_but_unused ne se déclenche pas). Si le bac à sable ne contient réellement aucune ligne de liquidation, la stratégie reste à juste titre sans position au lieu de fabriquer des transactions à partir d’un indicateur de prix de substitution.

Structurellement non-backtestable sur l'historique de liquidation disponible : le moteur a traité 56,208 barres 1H (~6.5 ans) mais n'a généré que 8 trades, ALL regroupés dans une seule fenêtre de ~2 mois (2026-04-21 à 2026-06-24), avec metrics_reliable=FALSE. Le signal nécessite des lignes supplementary_data['liquidations'], que l'hypothèse et le code décrivent tous deux comme rares/uniquement en flux temps réel ; le regroupement des trades est cohérent avec le fait que le store de liquidations ne contient qu'une fenêtre récente de ~2 mois, donc le signal de cascade ne peut jamais se déclencher sur 6.4 des 6.5 années de backtest (symptôme observé, pas un audit indépendant de la table Postgres). Il s'agit d'un mur de disponibilité des données, pas d'un problème de code ou de paramètres : la stratégie est implémentée correctement et trade fidèlement lorsque des lignes de liquidation sont présentes, donc il n'y a rien à corriger pour le développeur et aucun paramètre à régler — 8 trades dans une fenêtre de 2 mois ne peuvent pas supporter de walk-forward (3 fenêtres) ni de holdout, donc l'optimisation ajusterait du pur bruit. Le mécanisme n'est ni confirmé ni réfuté ; il ne peut tout simplement pas être validé. Ne pas optimiser, ne pas itérer. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER : les hypothèses de cascade de liquidation restent bloquées jusqu'à ce que le flux de données de liquidations soit réinjecté avec un historique sur plusieurs années (par ex. via les snapshots de liquidation Binance Vision) plutôt qu'en flux temps réel uniquement ; ne pas réessayer les stratégies pilotées par les liquidations jusqu'à ce que cet historique existe. FAILURE PATTERN : les stratégies pilotées par les liquidations sur BTCUSDT produisent un backtest quasi vide (8 trades confinés à une fenêtre récente de ~2 mois) parce que le flux supplémentaire de liquidations est en flux temps réel uniquement avec ~2 mois d'historique — le mécanisme ne peut pas être validé out-of-sample et la stratégie est structurellement non-backtestable jusqu'à ce que les données soient réinjectées, le même mur d'historique de données supplémentaires observé dans toute la famille OI/liquidation.