BTC Estratégia long-short contrária à cascata de liquidações: aproveitar os excessos de preço em barras de BTCUSDT.BINANCE 1H quando o volume de liquidações dispara para Z > 3 com um movimento de preço simultâneo de 2%

Uma estratégia de reversão à média long-short em futuros perpétuos BTCUSDT.BINANCE USD-M que opera contra cascata de liquidações forçadas. Utiliza BINANCE USD-M barras perp (dados limpos comprovados) + dados suplementares de liquidações (PostgreSQL — fluxo distinto de qualquer experiência anterior do pipeline). A hipótese: quando o volume de liquidações horário em BTCUSDT dispara >3 desvios-padrão acima da sua linha de base de 30 dias AND o preço moveu-se ≥2% na mesma direção nas 4 horas anteriores, o mercado está num FORCED-FLOW OVERSHOOT — o vendedor marginal (numa cascata de liquidações long) ou comprador marginal (num short-squeeze) é mecânico, não natural. Uma vez que o fluxo forçado se esgota (tipicamente dentro de 4-12 horas), os participantes naturais entram ao preço deslocado e o movimento reverte parcialmente. A estratégia entra LONG quando as liquidações do lado long cascateiam (o preço ultrapassa DOWN) e SHORT quando as liquidações do lado short cascateiam (o preço ultrapassa UP). Isto preenche FIVE categorias sub-representadas: direção long-short (14.2% → em direção a 45%), mecanismo impulsionado por liquidações (zero estratégias nas experiências 459 utilizaram este fluxo de dados), microestrutura específica de cripto (uma vantagem impossível em TradFi), manutenção a médio prazo (ciclos de 4-12h), e orientada por dados suplementares (que têm sido limpos no nosso catálogo ao contrário das barras BINANCE_SPOT). O mecanismo está documentado em investigação de microestrutura de cripto (Kaiko 2022, Coin Metrics 2023) — as cascata de liquidações produzem sistematicamente ultrapassagens de preço 1.5-3% que revertem parcialmente dentro de 6-18 horas à medida que o componente de fluxo forçado da ordem se dissipa. Utiliza ONLY BINANCE USD-M barras perp + dados de liquidações armazenados em Postgres — sem barras BINANCE_SPOT (que falharam repetidamente a verificação de Camada 3 nesta sessão). Dimensionamento de posição: 15% do capital por direção. Risco por operação: 1.5% do capital limitado por stop-loss.

Correção mínima da iteração -2 para a falha «Não foram geradas transações» da Camada -3, sem regressões nas camadas anteriores. Causa principal: a entrada exigia que um pico de liquidações de >=3 sigma, medido num único intervalo de 1 horas, coincidisse com dominância direcional AND um movimento de preço de >= 2% na mesma direção ao longo de 4h; com registos de liquidações escassos, o intervalo de 1h fica frequentemente vazio mesmo durante uma cascata real, pelo que `total` era muitas vezes 0 e a conjunção tripla praticamente nunca era acionada. A correção mantém o mecanismo impulsionado por liquidações 100% (sem alternativa baseada apenas no preço, explicitamente): (1) as liquidações são agora somadas ao longo de `liq_window_bars` horas (por predefinição, 4h, a mesma janela que o movimento do preço), para que a cascata seja efetivamente captada e `total` seja diferente de zero com muito mais frequência, alinhando as duas partes do sinal; (2) os dois limiares numéricos são reduzidos (liq_z 3.0->2.0, price_move_pct 2.0->1.0) e min_events é reduzido de 50 para 30, para que a referência z seja utilizável mais cedo. As importações não foram alteradas (Camada 1 continua aprovada) e a estrutura de pontuação z/sinalização/saída/dimensionamento aprovada na Camada 2 mantém-se estruturalmente idêntica — apenas mudou um limite de janela e três valores predefinidos de parâmetros. O mercado continua a ser futuros BINANCE USD-M (long-short exige margem), alavancagem 1.0 (não é usada para amplificação, pelo que a verificação leverage_set_but_unused não é acionada). Se a sandbox não tiver realmente registos de liquidações, a estratégia continua corretamente sem posições, em vez de inventar transações através de uma aproximação baseada no preço.

Estruturalmente impossível de testar retroativamente com o histórico de liquidações disponível: o motor processou 56,208 barras de 1H (~6.5 anos), mas gerou apenas 8 transações, ALL concentradas numa única janela de ~2 meses (2026-04-21 a 2026-06-24), com metrics_reliable=FALSE. O sinal exige registos supplementary_data['liquidations'], que tanto a hipótese como o código descrevem como escassos/disponíveis apenas em tempo real; a concentração das transações é consistente com o armazenamento de liquidações conter apenas uma janela recente de ~2 meses, pelo que o sinal de cascata nunca pode ser acionado ao longo de 6.4 dos 6.5 anos do backtest (sintoma observado, não uma auditoria independente da tabela Postgres). Trata-se de uma barreira de disponibilidade de dados, não de um problema de código ou de parâmetros: a estratégia está corretamente implementada e gera transações fielmente quando há registos de liquidações, pelo que não há nada para o programador corrigir nem parâmetros para ajustar — 8 transações numa única janela de 2 meses não permitem validação walk-forward (3 janelas) nem um conjunto de retenção, pelo que a otimização ajustaria apenas ruído puro. O mecanismo não está confirmado nem refutado; simplesmente não pode ser validado. Não otimizar, não iterar. META-NOTE FOR RESEARCH LEAD / DATA ENGINEER: as hipóteses sobre cascatas de liquidações continuam bloqueadas até o fluxo de dados de liquidações ser preenchido com um histórico de vários anos (por exemplo, através de snapshots de liquidações da Binance Vision), em vez de estar disponível apenas em tempo real; não voltar a tentar estratégias impulsionadas por liquidações até existir esse histórico. FAILURE PATTERN: as estratégias impulsionadas por liquidações em BTCUSDT geram um backtest quase vazio (8 transações confinadas a uma janela recente de ~2 meses), porque o fluxo suplementar de liquidações está disponível apenas em tempo real, com ~2 meses de histórico — o mecanismo não pode ser validado fora da amostra e a estratégia é estruturalmente impossível de testar retroativamente até os dados serem preenchidos; é a mesma barreira relativa ao histórico de dados suplementares observada na família OI/liquidação.