BTC Contrapropada de Cascada de Liquidación Largo-Corto: Atenuar Sobreextensiones en Barras 1H de BTCUSDT.BINANCE Cuando los Picos de Volumen de Liquidación Z > 3 con Movimiento de Precio 2% Concurrente

Estrategia de reversión a la media long-short sobre futuros perpetuos de BTCUSDT.BINANCE USD-M que opera en sentido contrario a las cascadas de liquidaciones forzosas. Usa barras de perpetuos BINANCE USD-M (datos limpios comprobados) + datos suplementarios de liquidaciones (PostgreSQL — flujo distinto de cualquier experimento anterior del pipeline). La hipótesis: cuando el volumen horario de liquidaciones en BTCUSDT se dispara por encima de 3 desviaciones estándar respecto a su referencia de 30 días AND y el precio se ha movido ≥2% en la misma dirección durante las 4 horas anteriores, el mercado está en una FORCED-FLOW OVERSHOOT: el vendedor marginal (en una cascada de liquidaciones de posiciones largas) o el comprador marginal (en un short squeeze) actúa por razones mecánicas, no naturales. Una vez se agota el flujo forzoso (normalmente en 4-12 horas), los participantes naturales entran al precio desajustado y el movimiento se revierte parcialmente. La estrategia abre posiciones LONG cuando se produce una cascada de liquidaciones de posiciones largas (el precio se excede a la baja: DOWN) y SHORT cuando se produce una cascada de liquidaciones de posiciones cortas (el precio se excede a UP). Esto cubre FIVE categorías poco representadas: dirección long-short (14.2% → hacia 45%), mecanismo impulsado por liquidaciones (ninguna estrategia en 459 experimentos ha usado este flujo de datos), microestructura específica de cripto (una ventaja imposible en TradFi), mantenimiento a medio plazo (ciclos de 4-12h) e impulsada por datos suplementarios (que han sido limpios en nuestro catálogo, a diferencia de las barras BINANCE_SPOT). El mecanismo está documentado en la investigación sobre microestructura de cripto (Kaiko 2022, Coin Metrics 2023): las cascadas de liquidaciones producen sistemáticamente excesos de precio 1.5-3% que se revierten parcialmente en 6-18 horas, a medida que se disipa el componente de flujo forzoso del flujo de órdenes. Usa barras de perpetuos ONLY BINANCE USD-M + datos de liquidaciones almacenados en Postgres; no usa barras BINANCE_SPOT (que han fallado repetidamente la verificación de capa 3 en esta sesión). Tamaño de posición: 15% del capital por dirección. Riesgo por operación: 1.5% del capital, limitado por el stop-loss.

Corrección mínima de Iteration-2 para el fallo «no se produjeron operaciones» de Layer-3, sin regresiones en capas anteriores. Causa raíz: la entrada exigía que un pico de liquidaciones de >=3 sigmas, medido en un único intervalo de 1 horas, coincidiera con un predominio direccional AND de un movimiento del precio de >=2% 4h en la misma dirección; con filas de liquidaciones escasas, el intervalo de 1h suele estar vacío incluso durante una cascada real, por lo que `total` a menudo era 0 y la conjunción de las tres condiciones prácticamente nunca se cumplía. La corrección mantiene el mecanismo impulsado por liquidaciones 100% (sin alternativa explícita basada solo en el precio): (1) ahora se suman las liquidaciones durante `liq_window_bars` horas (valor predeterminado: 4h, el mismo intervalo que el movimiento del precio), para capturar la cascada y que `total` sea distinto de cero con mucha más frecuencia, alineando las dos partes de la señal; (2) se relajan los dos umbrales numéricos (liq_z 3.0->2.0, price_move_pct 2.0->1.0) y se reduce min_events de 50->30, para que la referencia z sea utilizable antes. Las importaciones no cambian (Layer 1 sigue aprobada) y la estructura de puntuación z/activación/salida/tamaño de posición aprobada en Layer 2 permanece idéntica; solo cambiaron un límite de ventana y tres valores de parámetros predeterminados. La plataforma sigue siendo BINANCE USD-M futures (long-short requiere margen), apalancamiento 1.0 (no se usa para amplificar, así que no se activa la condición de leverage_set_but_unused). Si el entorno aislado realmente no tiene filas de liquidaciones, la estrategia sigue correctamente sin operar en vez de inventar operaciones mediante un indicador indirecto del precio.

Estructuralmente imposible de evaluar con backtests con el historial de liquidaciones disponible: el motor procesó 56,208 barras de 1H (~6.5 años), pero produjo solo 8 operaciones, ALL concentradas en una única ventana de ~2 meses (2026-04-21 a 2026-06-24), con metrics_reliable=FALSE. La señal requiere filas de supplementary_data['liquidations'], que tanto la hipótesis como el código describen como escasas y disponibles solo en tiempo real; la concentración de operaciones concuerda con que el almacén de liquidaciones solo contenga una ventana reciente de ~2 meses, así que la señal de cascada no puede activarse durante 6.4 de los 6.5 años del backtest (síntoma observado, no auditoría independiente de la tabla de Postgres). Este es un límite de disponibilidad de datos, no un problema de código ni de parámetros: la estrategia está implementada correctamente y opera fielmente cuando hay filas de liquidaciones, así que el desarrollador no tiene nada que corregir y no hay parámetros que ajustar; 8 operaciones en una ventana de 2 meses no permiten hacer validación walk-forward (3 ventanas) ni reservar un conjunto de prueba, por lo que la optimización se ajustaría al ruido puro. El mecanismo no está confirmado ni refutado; simplemente no se puede validar. No optimizar, no iterar. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: las hipótesis sobre cascadas de liquidaciones siguen bloqueadas hasta que se complete el flujo de datos de liquidaciones con un historial de varios años (por ejemplo, mediante instantáneas de liquidaciones de Binance Vision), en lugar de disponer solo del flujo en tiempo real; no volver a intentar estrategias impulsadas por liquidaciones hasta que exista ese historial. FAILURE PATTERN: las estrategias impulsadas por liquidaciones en BTCUSDT generan un backtest casi vacío (8 operaciones confinadas a una ventana reciente de ~2 meses) porque el flujo suplementario de liquidaciones solo está disponible en tiempo real y contiene ~2 meses de historial; el mecanismo no se puede validar fuera de muestra y la estrategia es estructuralmente imposible de evaluar con backtests hasta que se completen los datos, el mismo límite de historial de datos suplementarios observado en toda la familia OI/liquidaciones.