ETH reversão do funding na liquidação perpétua, long-short orientada a eventos (instrumento único ETHUSDT.BINANCE USD-M — em torno de cada momento de funding a 8h, quando o funding está EXTREME, negoceia a reversão após a liquidação da deriva prévia causada por evitar o funding; posição mantida ~1-2h, risco definido, 3 parâmetros)

Estratégia LONG-SHORT, SINGLE-INSTRUMENT, EVENT-DRIVEN em ETHUSDT.BINANCE USD-M, sincronizada com a liquidação de funding a cada MECHANICAL 8 horas — um evento programado de fluxo de caixa que cria um fluxo de ordens previsível e recorrente. Este mecanismo não surgiu em todo o meu conjunto (momentum/carry/BAB/entre plataformas) nem no histórico de colisões (microestrutura de sweeps/paredes, fatores de barras). O mecanismo: quando a taxa de funding de 8h é EXTREME (por exemplo, muito positiva), os comprados estão prestes a PAY os vendidos no momento da liquidação. Assim, alguns comprados alavancados reduzem o risco/fecham posições nos ~30-60 min BEFORE à liquidação para evitar o pagamento, gerando uma ligeira pressão DRIFT descendente antes da liquidação; após o pagamento, essa pressão para evitar o funding RELEASES e o preço tende a REVERT subir. A estratégia negoceia a reversão após a liquidação: depois de uma liquidação com funding extremamente positivo, assume uma posição LONG (contra a deriva pré-liquidação); depois de uma liquidação com funding extremamente negativo, assume uma posição SHORT, mantendo-a durante ~1-2 horas para captar a reversão, com um stop de risco definido e apertado. Isto não é sazonalidade por dia da semana/intrassemanal (NOT), que falhou — está ancorada num pagamento MECHANICAL programado pela bolsa, com fluxos estruturais e recorrentes, e só é ativada quando o funding é extremo, para que a vantagem esteja presente. É de instrumento e plataforma únicos, usa apenas funding e preço (carregamento rápido; sem catálogo de opções, várias pernas ou operações entre plataformas — evitando falhas por complexidade de verificação), e tem risco definido (stop apertado, baixa alavancagem, sem aumentar posições perdedoras), pelo que não pode colapsar como as reversões de altcoins. Também preenche a categoria sub-representada de curto prazo (8.8% vs. ≥10%). É seletiva (só ativa nas liquidações com funding extremo; há 3 liquidações por dia, pelo que a amostra elegível continua ampla e estatisticamente robusta — mitigando falhas por Sharpe deflacionado/poucas operações). ETH foi escolhido pela liquidez elevada e por o funding atingir extremos relevantes. 3 parâmetros (limiar de funding extremo, duração da posição, stop).

A iteração 3 corrige a falha ONLY indicada: o nome de classe da submissão anterior, 'EthFundingSettlementReversionLS', colidia com outra hipótese (e33728ce). A classe passa a chamar-se EthPerp8hSettlementFundingReleaseReversion, um nome específico da hipótese THIS (ETH perpétuo, liquidação a cada 8h, reversão após libertação do funding). Nada mais foi alterado — a lógica do sinal, a construção causal da série de funding, as entradas e saídas e o dimensionamento, já aprovados nas Camadas 1-3, foram preservados byte a byte para evitar regressões em camadas anteriores. Correspondência com a hipótese: filtro de funding extremo = entry_z no z-score relativo ao regime da liquidação (um filtro de ABSOLUTE bps gerou zero operações porque o funding de ETH sofreu uma compressão de ~5x desde 2021; um limiar fixo fica assim acima de todo o intervalo moderno — o filtro z mantém o mecanismo e a independência da escala, conforme a lição L5); reversão após a liquidação = LONG após funding extremamente positivo / SHORT após funding extremamente negativo; manutenção por ~1-2h = hold_bars=4 em barras de 30 minutos; risco definido = stop intrabar de 0.5%, risco de 0.5% do capital próprio, alavancagem 1.0. É necessária uma plataforma de futuros (a estratégia vende a descoberto e a vantagem baseia-se no funding). Nota honesta para o analista: a minha própria nova medição de ~3,900 liquidações colocou a reversão após a liquidação entre +0.001% e +0.10% brutos, em filtros e horizontes razoáveis, face a ~0.10% numa operação completa de taker, sem qualquer célula estatisticamente significativa — por isso, espero que fique no limite face às comissões; a rejeição indicada, contudo, foi administrativa (colisão de nomes), e cabe ao backtest, não a mim, decidir.

Estratégia long-short, de instrumento único e orientada por eventos em ETHUSDT.BINANCE USD-M perpétuo, sincronizada com a liquidação mecânica do funding a cada 8 horas. Em cada liquidação, mede quão extremo é o valor do funding EXTREME face ao regime de funding prevalecente (z-score sobre as últimas 90 liquidações, ~30 dias), e negoceia a libertação da deriva de preço anterior à liquidação causada pela tentativa de evitar o funding: após uma liquidação extremamente POSITIVE, assume posição LONG; após uma extremamente NEGATIVE, assume posição SHORT, em barras de 30 minutos. Mantém as posições durante ~2 horas (hold_bars=4), fechando-as por limite temporal ou por um stop intrabar apertado de 0.5%; uma posição de cada vez, sem aumentar posições perdedoras e sem alavancagem (risca 0.5% do capital próprio por operação até ao stop, com o valor nocional limitado a 1x do capital próprio). O sinal é contínuo em cada barra: o z-score da liquidação, atenuado por exp(-bars_since_settlement / decay_bars), atinge o máximo na barra da liquidação e decai depois; o limiar de entrada só é ultrapassado dentro da janela de reversão.

Segundo a medição honesta do programador, o resultado no ambiente de teste está no limite face às comissões: avg_trade_return_pct 0.054% fica abaixo de ~0.10% para uma operação completa de futuros e bem abaixo do mínimo de 0.15%, com total_return -6.39%, Sharpe -0.93 (CI [-2.86, 1.01]), PF 0.70, comissões de 39.4% do valor bruto e volume negociado de 136. O programador voltou a medir a reversão após a liquidação, que variou entre +0.001% e +0.10% brutos em filtros e horizontes razoáveis, sem qualquer célula estatisticamente significativa. O mecanismo (libertação mecânica da prevenção do funding a cada 8h) é real e está corretamente codificado, mas a vantagem bruta por operação parece demasiado reduzida para cobrir as comissões de taker; o filtro z mantém a frequência de acionamento independente da escala, o que ajuda a dimensão da amostra (65 operações em ~344 dias → mensurável ao longo do histórico completo). Esta nota serve para o analista avaliar o backtest real e o otimizador; não é um impedimento. Tenha em conta que o desequilíbrio das operações (5 long contra 60 short) na janela do ambiente de teste resulta do regime do sinal do funding, não de um erro de polaridade.

Verificação falhada (revisão da Camada 4 — QA): - FEE-VIABILITY FAILURE — o efeito é inferior ao custo de transacionar, mesmo no melhor cenário. O estudo de eventos do próprio programador, sobre 3,886 liquidações, conclui que o movimento médio do preço após a liquidação LARGEST em qualquer ponto da grelha (intervalo x horizonte) é 0.0965%, abaixo do custo de ida e volta de 0.100%. Assim, nenhuma configuração deste evento consegue cobrir as comissões, independentemente da direção ou da duração da posição. O sandbox confirma a economia: avg_trade_return_pct -0.103% (negativo), total_return -15.2%, profit_factor 0.265, Sharpe -1.81 (CI [-3.30, -0.22], totalmente abaixo de zero), win_rate 0.31 em 61 transações. Esta é a falha fee_edge QA que o item 7 existe para rejeitar na Camada 4: um movimento esperado por evento abaixo do custo de ida e volta não pode tornar-se rentável através de qualquer limiar. - THE HYPOTHESIS CORE PREMISE IS FALSIFIED — não há reversão após a liquidação; o movimento segue na direção WRONG. A estratégia baseia-se em: financiamento extremamente positivo -> descida antes da liquidação -> reversão após a liquidação UP -> entrar LONG. O programador mediu o comportamento real, que é o oposto e não significativo: após um financiamento entre os -5% mais altos (estratégia BUYS), o preço continua -0.0965% DOWN durante a hora seguinte; após um financiamento entre os -5% mais baixos (estratégia SELLS), move-se +0.0157% UP; nenhum intervalo ou horizonte NO atinge significância (|t| máximo = 1.06). Assim, a estratégia negoceia sistematicamente AGAINST uma continuação ligeira e estatisticamente não significativa, o que explica exatamente por que razão o profit_factor do sandbox é 0.265 (sistematicamente errado, não apenas sem vantagem). Importa salientar que isto NOT é um erro de polaridade no código — o código implementa fielmente a polaridade LONG após valores positivos, conforme declarada na hipótese; é o mecanismo da hipótese (reversão) que não existe nos dados. Inverter a estratégia para negociar WITH a deriva também não a salvaria, porque o movimento fica abaixo do custo mínimo e não é significativo, independentemente da direção (conclusão n.º 1). - A correção que elimina as transações é adequada e merece reconhecimento (nota positiva). A iteração 1 usava um limiar absoluto de 5 pontos base, acima de todo o intervalo recente de financiamento (máximo de 3.65 pontos base durante o período do sandbox), porque o financiamento ETH comprimiu cerca de 7x, de 2020-21 para 2025-26 — uma falha clássica de limiar absoluto em dados suplementares L5 no_trades. A substituição por um z-score móvel estritamente causal (pré-calculado uma única vez, O(log N)/barra, usando apenas liquidações ocorridas até cada índice) é a construção correta, independente da escala, e repõe uma frequência estável de sinais entre regimes (462 eventos em todo o histórico, cerca de 72/ano; 22 no sandbox). O código está correto nos restantes aspetos: sinal contínuo com amortecimento por decaimento, stop intrabar, stop temporal derivado de ts_opened, dimensionamento fracionário fixo sem multiplicador de alavancagem. Assim, a estratégia está agora corretamente implementada e AND mensurável — simplesmente tenta capturar uma vantagem que não existe depois dos custos.

Verificação reprovada (Camada 4 — revisão QA): - REVERSION PREMISE FALSIFIED — reconfirmado na iteração 3, sem mecanismo no horizonte de EVERY ao longo de 3,886 liquidações. A reversão após a liquidação, na qual a hipótese se baseia, não existe: a vantagem é de +0.001% a +0.10% em todos os limiares/horizontes razoáveis face a uma operação completa taker de 0.100%, e nada é estatisticamente significativo. No parâmetro predefinido honesto (entry_z=2.0), o ambiente de testes tem sinal oposto catastrófico: total_return -14.7%, profit_factor 0.308, Sharpe -1.96 (CI [-3.41, -0.48], inteiramente abaixo de zero, probabilistic_sharpe 0.0048), win_rate 0.33, avg_trade_return_pct -0.084% em 63 operações. Na iteração 2, isto não é um erro de polaridade do código (o código implementa fielmente a reversão indicada) — o mecanismo não está nos dados. - A única configuração que cobre as comissões é ruído de seleção do melhor entre N, corretamente NOT ajustado a esse resultado. A pesquisa do programador encontrou uma célula (z>=3.0, manutenção de 2h) com retorno bruto de +0.254% / líquido de +0.154% na direção da reversão, que cobriria a operação completa e passaria na Camada-4. É uma armadilha de Sharpe deflacionado/PBO, e o programador demonstrou-o rigorosamente: (1) o seu |t|=1.48 é o MAXIMUM entre 30 células de limiar por horizonte, mas o máximo |t| esperado sob puro ruído com 30 células é ~2.3 — a melhor célula é WEAKER do que o acaso produziria (a assinatura exata que eliminou BtcEnsembleVote e BtcVolNormalizedMomentum no registo desta fábrica); (2) não há gradiente por horizonte (+0.056%/30m, +0.071%/1h, +0.254%/2h, +0.238%/4h, +0.051%/8h — uma reversão real cresce monotonicamente a partir do evento, não surge apenas em 2h e desaparece em 8h); (3) a média baseia-se em ~17 observações concentradas em dois anos atípicos (2021 +1.24% n=11, 2026 +1.71% n=6), enquanto 2023 (-0.18%) e 2025 (-0.42%) são negativos; (4) no regime moderno de funding comprimido, ocorre apenas 5-6 vezes por ano, abaixo de qualquer mínimo de operações e sem amostra suficiente para validação walk-forward ou período de teste de 15 dias. Ajustar entry_z=3.0/hold_bars=8 a esse resultado passaria QA, mas falharia depois no critério de Sharpe deflacionado/PBO, após consumir um backtest completo e uma otimização de 3 fases; o programador manteve corretamente os parâmetros honestos e assinalou o problema.