Colheita do Diferencial de Financiamento entre Mercados — SOL neutra em delta: vender a perpétua com financiamento mais elevado / comprar a perpétua com financiamento mais baixo em BINANCE vs HYPERLIQUID, receber o financiamento SPREAD (não carry direcional), com stop de base, mantida durante dias (2 pernas, neutra ao mercado, 3 parâmetros)

Uma estratégia de valor relativo CROSS-VENUE, MARKET-NEUTRAL que colhe o FUNDING-RATE SPREAD entre o perpétuo do ativo SAME em duas bolsas diferentes — BINANCE USD-M SOLUSDT vs HYPERLIQUID SOLUSD. Ambas as pernas são perpétuos sobre o mesmo ativo subjacente, pelo que a posição é neutra em delta por construção: não está NOT a assumir uma direção de preço nem está NOT a fazer carry de financiamento numa única perna (o mecanismo que perdeu dinheiro na estratégia abandonada «SOL Persistent-Funding Contrarian Swing»). A fonte de PnL ONLY é o diferencial de financiamento — vende a descoberto SHORT o mercado que paga o financiamento mais positivo (as posições curtas recebem financiamento nesse mercado) e, em simultâneo, abre uma posição longa de notional igual LONG no mercado com financiamento inferior/negativo (as posições longas recebem ou pagam menos). Como as duas pernas acompanham o mesmo ativo subjacente, o PnL direcional do preço é neutralizado, ~0; a variância residual é apenas a pequena BASIS com reversão à média (diferença de preço entre os dois mercados), limitada por um stop de base rígido. Trata-se de arbitragem de financiamento entre bolsas (padrão entre mercados n.º 3, híbrido com n.º 2), uma vantagem estruturalmente pouco explorada e tolerante às comissões — captura um fluxo de caixa pago mecanicamente em vez de lutar contra a fricção. Foi escolhida porque a carteira tem pouca exposição entre mercados (7.4% face ao objetivo 15%) e long-short/neutra ao mercado (14.2%), e porque os dados de financiamento da Binance e Hyperliquid BOTH SOL existem no catálogo com histórico plurianual à resolução diária/4h (HL diária/4h não tem limitações de histórico). SOL foi escolhido por apresentar uma dispersão de financiamento significativa entre mercados (altcoin de beta mais elevado), mantendo-se entre os ativos mais líquidos em ambos. Apenas 3 parâmetros livres (limiar do spread de entrada, limiar do spread de saída, stop de base) para resistir ao sobreajustamento, o fator destrutivo n.º 1 neste caso.

A iteração 2 corrige o QA hypothesis_mismatch (intervalo temporal): o relógio de amostragem está agora fixado em barras de 4-HOUR nas pernas BOTH, correspondendo à «resolução diária/4h» e às posições mantidas durante dias indicadas na hipótese, ao nome desta classe e ao intervalo em que todos os parâmetros expressos em barras são calibrados (spread_smooth_bars 24 x 4H = 4 dias); 4H também é um divisor exato do intervalo de liquidação do financiamento da Binance de 8h, pelo que nenhuma liquidação fica repartida entre barras. Não há reamostragem unilateral para outro relógio. Foi verificado que ambas as pernas existem no catálogo em 4H (SOLUSDT.BINANCE-4-HOUR e SOLUSD.HYPERLIQUID-4-HOUR, histórico HL desde 2024-01), pelo que a verificação de dados multi-perna não pode abandonar a execução. A lógica dos sinais/entradas/saídas, as importações e a estrutura não foram alteradas face a previous_code (as camadas anteriores continuavam aprovadas); a única outra alteração declara o limite spread_smooth_bars [6, 48] em _param_bounds, para que o otimizador nunca procure valores que o código reescreva silenciosamente. Nota para registo: o texto de feedback QA citava um caso semanal vs diário ETHUSDT que não corresponde a este par SOL entre mercados, pelo que apliquei a regra geral de alinhamento temporal em vez dos detalhes literais ETH. Um notional USD igual em ambas as pernas mantém o delta líquido em ~0, conforme a lição L59; a alavancagem permanece em 1.0 e não é referida no dimensionamento.

A sandbox está essencialmente em break-even: total_return +0.167% ao longo de 2181 dias, avg_trade_return_pct 0.1135% (abaixo do mínimo de 0.15% nos futuros), profit_factor 1.013, win_rate 0.50 em apenas 22 trades. Trata-se de um smoke test não otimizado, pelo que não é bloqueante, mas há dois pontos que o analista deve verificar com números do histórico completo: (1) que o backtest do NautilusTrader credita efetivamente os fluxos de caixa de FUNDING dos perp em ambas as pernas — o funding é a fonte ENTIRE de PnL desta estratégia, e se o funding não for aplicado o retorno medido é apenas ruído da base menos comissões; (2) viabilidade de comissões/carry nos limiares reais — o diferencial (~8.6% APR ≈ 0.024%/dia) necessita de ~8 dias corretamente posicionados para compensar o round trip de 0.19% nas duas pernas, pelo que a edge por trade é reduzida e dependente da duração da detenção (hold médio observado ~29d). Note-se ainda impact_cost_pct 44.9% / capacidade ~$495K a per_leg_pct 0.50 (150% de exposição bruta) — um verdadeiro limite de capacidade, embora pontual na entrada/saída de baixo turnover de um book de ~22 trades.

Verificação falhada (Camada 2 — cenários sintéticos): Parâmetros utilizados: ['per_leg_pct', 'min_notional', '_param_bounds', 'max_hold_days', 'min_hold_hours', 'exit_spread_apr', 'enter_spread_apr', 'max_basis_stop_pct', 'spread_smooth_bars'] Confirme que __init__ define todos os atributos a partir de self.parameters.get(). - steady_uptrend: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() aceita 4 argumentos posicionais, mas foram fornecidos 5 (marca temporal da barra: 1735690740000) - steady_downtrend: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() aceita 4 argumentos posicionais, mas foram fornecidos 5 (marca temporal da barra: 1735690740000) - flat_ranging: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() aceita 4 argumentos posicionais, mas foram fornecidos 5 (marca temporal da barra: 1735690740000) - volatility_spike: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() aceita 4 argumentos posicionais, mas foram fornecidos 5 (marca temporal da barra: 1735690740000) - zero_volume: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() aceita 4 argumentos posicionais, mas foram fornecidos 5 (marca temporal da barra: 1735690740000) - price_gap: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() aceita 4 argumentos posicionais, mas foram fornecidos 5 (marca temporal da barra: 1735690740000)

Verificação falhou (Camada 4 — revisão QA): - A viabilidade de comissões/edge falha decisivamente no resultado do motor ACTUAL (lista de verificação n.º 7, L6/L26). A sandbox é um livro perdedor: total_return -2.17%, profit_factor 0.957 (<1.0), Sharpe -0.35, expetativa -$45/trade, e avg_trade_return_pct -0.0033% — NEGATIVE e ~45x abaixo do mínimo de futuros 0.15%. Numa amostra mensurável (82 trades, metrics_reliable: true), portanto um resultado genuíno sem edge. Funding WAS creditado (2580 eventos), pelo que mesmo com o diferencial pago na totalidade a estratégia não cobre o custo de ida e volta de ~0.19%. - A hipótese central — 'o PnL direcional de preço resulta líquido em ~0; a variância residual é apenas a base pequena e com reversão à média' — é NOT o que o motor produziu. O PnL por trade é dominado por enormes oscilações simétricas: avg_win $2,009 ~= avg_loss $2,099, maior ±$9,600-9,959, win_rate 0.50. Uma colheita de spread de funding genuinamente delta-neutral deveria apresentar um PnL uma ordem de magnitude menor e enviesado positivamente pelo carry; em vez disso, o diferencial (líquido -$45/trade) é dwarfed ~45:1 pelo ruído de base/preço. Assinatura idêntica às variantes abandonadas EthCrossVenueCashAndCarry e anteriores de captura de funding cross-venue.

Verificação falhada (Camada 4 — revisão QA) [classe=hypothesis_mismatch]: - [edge_concern] Não é o motivo do veredicto; fica registado para o analista caso a hipótese seja registada novamente: no relógio diário, o ambiente de teste é honesto e saudável (metrics_reliable=TRUE, 92 transações, Sharpe 0.79 CI [0.10,1.51], avg_trade_return_pct 3.61%, PF 1.48), mas regime_performance mostra ALL do retorno positivo concentrado no tercil de volatilidade «normal» (+489%, Sharpe 2.64), com os tercis «calmo» (-18.8%) e «sob tensão» (-21.8%, 56.7% DD) ambos negativos, e only_one_regime=true. Rebaixamento máximo 36%, com uma duração de 1038 dias abaixo do máximo. A vantagem é real, mas está concentrada num regime e implica um rebaixamento elevado; a dimensão e a robustez merecem análise no backtest completo. - TIMEFRAME MISMATCH face à hipótese pré-registada. A hipótese registada (título e descrição neste documento) especifica, de forma inequívoca e repetida, barras WEEKLY («em barras WEEKLY, mantendo posições durante semanas a meses»), mas config.bar_type é ETHUSDT.BINANCE-1-DAY-LAST-EXTERNAL. Não se trata de uma reamostragem cosmética: altera o número de transações (28 semanais -> 92 diárias), a duração média da posição (10.4 semanas -> 3 semanas) e todo o teste estatístico. O comentário de documentação do próprio módulo do programador admite que a iteração 3 fez esta mesma alteração para frequência diária e que QA «tinha razão em rejeitá-la: foi uma reformulação da hipótese feita unilateralmente no código». A situação não mudou materialmente: a hipótese registada continua a indicar frequência semanal, pelo que esta é novamente uma reformulação unilateral do intervalo temporal no código. A Camada 1.5 apenas valida o instrumento/mercado, não o intervalo temporal, pelo que esta verificação cabe a QA, e um intervalo temporal indicado na hipótese que difira de config.bar_type constitui uma incompatibilidade crítica. É precisamente este grau de liberdade do investigador que o sistema de pré-registo da fábrica existe para evitar: concluiu-se que a forma semanal era impossível de medir e, em seguida, alterou-se o relógio de amostragem para fabricar mensurabilidade.