Pular para o conteúdo
Todas as estratégias

Estratégias

Cash-and-carry de BTC com convergência da base trimestral, neutro ao mercado (compra de BTCUSDT.BINANCE_SPOT + venda do futuro BTC USD-M DATED QUARTERLY com vencimento mais próximo, mantido até a liquidação para capturar a base de contango DETERMINISTICALLY-CONVERGENT — NOT funding de perp, rolagem no vencimento, 2 parâmetros)

Resultado: Abandonada

BtcQuarterlyBasisConvergenceCarryNeutral

Resumo do resultado

Esta estratégia propôs uma vantagem realmente diferente dos carries de funding de perp malsucedidos da fábrica: um cash-and-carry BTC neutro em delta que captura a base de futuros trimestrais com vencimento definido, cuja convergência é determinística; mantido até a liquidação e rolado a cada trimestre, com apenas dois parâmetros ajustáveis. Ela nunca gerou um backtest: em 3 iterações, a execução falhou porque o motor não conseguiu obter histórico de funding para a perna trimestral 'BTCUSDT_230929.BINANCE', tratando o contrato com vencimento definido como um perp e bloqueando a execução por precisão. Sem backtest, revisão do backtest, otimização ou etapa de análise jamais alcançados, a estratégia foi abandonada por uma dependência de dados/infraestrutura, e não por mérito econômico. A hipótese havia alertado explicitamente que a disponibilidade de dados de contratos trimestrais era a dependência decisiva, e foi exatamente aí que o pipeline parou.

Hipótese

Um cash-and-carry MARKET-NEUTRAL sobre BTC que captura a base de QUARTERLY-FUTURE, categoricamente diferente de todas as estratégias de carry com funding/perp que morreram nesta fábrica. Os carries malsucedidos (BTC/AVAX/BNB/ETH spot-perp, todos fee_edge) dependiam do funding de PERP — um fluxo de caixa pequeno (~1bp/8h na mediana), sem convergência, que nunca supera o custo de ida e volta. Um futuro trimestral DATED é diferente por natureza: precisa convergir ao spot em AT SETTLEMENT (determinístico,……Mostrar maisMostrar menos

Um cash-and-carry MARKET-NEUTRAL sobre BTC que captura a base de QUARTERLY-FUTURE, categoricamente diferente de todas as estratégias de carry com funding/perp que morreram nesta fábrica. Os carries malsucedidos (BTC/AVAX/BNB/ETH spot-perp, todos fee_edge) dependiam do funding de PERP — um fluxo de caixa pequeno (~1bp/8h na mediana), sem convergência, que nunca supera o custo de ida e volta. Um futuro trimestral DATED é diferente por natureza: precisa convergir ao spot em AT SETTLEMENT (determinístico, contratual), e os trimestrais de BTC negociam com CONTANGO persistentes, geralmente de 5-15% ANNUALIZED (~125-375 bps em uma manutenção de ~90 dias) — uma ordem de magnitude acima da ida e volta de duas pernas de ~0.30%; além disso, supera com folga o limite de >20bps/ciclo de L1, pois a base é um prêmio de prazo, não um tick de funding. Estrutura: spot LONG BTC + o trimestral BTC USD-M listado mais próximo em SHORT, com notional igual (neutro em delta); manter até (ou quase até) a liquidação para capturar a convergência, com essencialmente ONE custo de ida e volta na entrada e sem giro na saída (as pernas convergem por conta própria); depois, rolar para o próximo trimestral. Isso evita os problemas recorrentes de ALL: FEE_EDGE — base muito maior que as taxas, e manter até a liquidação significa ~2 execuções por trimestre, com giro quase zero; MULTI-REGIME — a base existe e converge em mercados de alta e de baixa (AND), sem ser um artefato de beta de um único regime como os temporizadores comprados; OVERFIT — parâmetros 2 (limite da base de entrada, momento da rolagem), sem superfície de seleção; além disso, não pertence à classe de reversão abandonada. Preenche as lacunas de estratégias entre venues (7.3%) e direcionais neutras ao mercado, ambas pouco representadas. CRITICAL DATA DEPENDENCY (marcado para falhar rápido, em vez de entrar em loop): isso exige cobertura histórica de klines dos contratos trimestrais DATED BTC USD-M no catálogo — o desenvolvedor precisa confirmar que há histórico de futuros trimestrais disponível para o período de backtest BEFORE da codificação; se houver apenas candles de perp/spot, abandonar imediatamente (não substituir pelo perp, pois isso faria a estratégia voltar a ser o carry de funding malsucedido).

A iteração 3 corrige o único bloqueio da Camada -3: o teste de fumaça do sandbox excedeu 300s. Meu trabalho por barra já é O(1) (um loop de tamanho fixo pela cadeia trimestral — sem reexaminar o histórico, sem min()/sorted() por barra sobre os dados), portanto o diagnóstico genérico de “trabalho por barra que aumenta com o histórico” não se aplicava. O custo real vinha de DATA VOLUME: spot 1-DAY abrange 2017→2026 (~9 anos, confirmado pelo intervalo do arquivo de catálogo), e os trimestrais 11 em 4-HOUR……Mostrar maisMostrar menos

A iteração 3 corrige o único bloqueio da Camada -3: o teste de fumaça do sandbox excedeu 300s. Meu trabalho por barra já é O(1) (um loop de tamanho fixo pela cadeia trimestral — sem reexaminar o histórico, sem min()/sorted() por barra sobre os dados), portanto o diagnóstico genérico de “trabalho por barra que aumenta com o histórico” não se aplicava. O custo real vinha de DATA VOLUME: spot 1-DAY abrange 2017→2026 (~9 anos, confirmado pelo intervalo do arquivo de catálogo), e os trimestrais 11 em 4-HOUR acrescentaram ~12 mil eventos de barras; assim, o fluxo combinado de vários instrumentos (~15 mil eventos em 12 pernas de instrumento, cada uma com cálculos de taxas/análises/linha de base) excedeu o orçamento. A menor correção eficaz mantém inalterado todo o código da estratégia (crédito atribuído corretamente, rolagem validada) e reduz apenas o volume de dados pela configuração: (1) reduza a cadeia de 11 para 8 contratos consecutivos (ainda ~2 anos, 2023H2–2025H1, abrangendo a recuperação do mercado de baixa de 2023 e o mercado de alta de 2024 — ~8 convergências, decisivamente diagnósticas em comparação com a falha n=1 da iteração -2); e (2) torne mais espaçados os dados trimestrais extras, de 4-HOUR para 12-HOUR (2 barras/dia → ~360 por contrato, em comparação com ~1090). Isso reduz o orçamento de eventos de ~15 mil para ~6.1 mil (~2.4×) e o número de instrumentos de 12 para 9, o que deve manter a execução bem abaixo de 300s; a resolução de 12-HOUR continua muito mais fina do que o necessário para um carry de base de ~90 dias e permanece em um período DIFFERENT ao principal de 1-DAY (portanto, fica isenta da barreira de alinhamento de períodos iguais, que causaria impasse com contratos vencidos). Verifiquei que todos os 8 contratos têm barras 12-HOUR não vazias (nenhum trimestre ignorado silenciosamente) e formam uma cadeia consecutiva sem lacunas de Sep23→Jun25, mantendo a continuidade da rolagem. Nenhuma lógica de código, importação ou os dois parâmetros ajustáveis foram alterados — as Camadas 1–2 e o comportamento validado da rolagem foram preservados; apenas a lista de extras e o período deles mudaram para caber no orçamento de desempenho.

backtest_failed: RuntimeError: dados de funding indisponíveis para a perna perp 'BTCUSDT_230929.BINANCE' — a coleta sob demanda falhou ou a venue não tem histórico de funding (backtest bloqueado para preservar a precisão; defina SF_DISABLE_ONDEMAND_FUNDING=1 para contornar) Traceback (most recent call last): File "/opt/strategy-factory/src/agents/backtest_agent.py", line 190, in _run_backtest await self._ensure_funding_for_perp_legs(instrument_id, extra_instrs) File "/opt/strategy-factory/src/agents/backtest_agent.py", line 406, in _ensure_funding_for_perp_legs raise RuntimeError( RuntimeError: dados de funding indisponíveis para a perna perp 'BTCUSDT_230929.BINANCE' — a coleta sob demanda falhou ou a venue não tem histórico de funding (backtest bloqueado para preservar a precisão; defina SF_DISABLE_ONDEMAND_FUNDING=1 para contornar)

Implementação

Cash-and-carry BTC neutro ao mercado que captura a base de futuros trimestrais DATED e ROLLS ao longo de uma cadeia de trimestres consecutivos. Principal = BTCUSDT.BINANCE_SPOT (1-DAY, contínuo, determina o relógio); extras = oito contratos trimestrais consecutivos BTC USD-M com vencimento definido (BTCUSDT_230929 … 250627) em candles de 12-HOUR (período mais amplo e diferente do principal, para que contratos vencidos ou ainda não listados não travem a barreira de alinhamento do mesmo período e o fluxo de eventos……Mostrar maisMostrar menos

Cash-and-carry BTC neutro ao mercado que captura a base de futuros trimestrais DATED e ROLLS ao longo de uma cadeia de trimestres consecutivos. Principal = BTCUSDT.BINANCE_SPOT (1-DAY, contínuo, determina o relógio); extras = oito contratos trimestrais consecutivos BTC USD-M com vencimento definido (BTCUSDT_230929 … 250627) em candles de 12-HOUR (período mais amplo e diferente do principal, para que contratos vencidos ou ainda não listados não travem a barreira de alinhamento do mesmo período e o fluxo de eventos multi-instrumento continue pequeno). A cada candle spot, identifica o contrato trimestral com vencimento mais próximo entre os LIVE que ainda tenha prazo para convergir (≥ min_entry_days), calcula sua base anualizada ((futuro − spot)/spot × 365/dias até o vencimento) e, quando não há posição aberta, inicia o carry se essa base for ≥ entry_basis_annual: spot LONG com notional igual (seguro para CASH BUY) + posição SHORT no trimestral (BINANCE MARGIN), neutra em delta. Ela HOLDS até roll_buffer_days antes da liquidação, CLOSES ambas as pernas e, em seguida, rola para o próximo trimestre vigente — ~4 convergências/ano. Uma proteção contra perna descoberta zera ambas as pernas se uma delas existir sozinha. O vencimento é extraído do símbolo de cada contrato; o dimensionamento é linear (notional/preço) e limitado sem depender do caminho. Dois parâmetros ajustáveis: entry_basis_annual, roll_buffer_days.

Resultados da verificação

Verificação reprovada (Camada 3 — backtest no sandbox): o teste de fumaça excedeu o limite de 300s de tempo de execução. Isso quase sempre significa que o trabalho por barra aumenta com o histórico — por exemplo, reexaminar toda a série de funding/suplementar ou reconstruir uma lista e chamar min()/sorted() dentro de calculate_signal()/on_bar() a cada barra. Pré-calcule arrays de timestamps ordenados ONCE em __init__ e use bisect, ou armazene consultas em cache indexadas por timestamp, para que o custo por barra seja O(log n), não O(n).

Estenda extra_instruments à cadeia trimestral de FULL BTC (~16-20 contratos desde 2020), usando barras trimestrais mais espaçadas de 12H/1D para ficar dentro do orçamento do sandbox, de modo que metrics_reliable=true e cada janela walk-forward contenha várias convergências. Apenas extensão da configuração — a lógica de rolagem já processa cadeias de qualquer extensão.

A contagem de convergências é marginal (8) e metrics_reliable=false — abaixo do ~16-20 que defini em iter-1. O desenvolvedor limitou a cadeia a 8 contratos pelo orçamento de Layer-3. UNLIKE os seguidores de tendência macro que falharam, este é um refinamento de configuração corrigível, não um limite intrínseco: é fácil obter mais convergências listando mais contratos trimestrais históricos datados de BTC (até ~2020). É crucial que a vantagem tenha respaldo diagnóstico mesmo com n=8: Sharpe CI [1.14, 46.66] tem limite inferior de POSITIVE (exclui zero) e a distribuição é bem comportada (assimetria -0.56, curtose 2.37) — um contraste marcante com os seguidores de tendência, cujos ICs abrangiam valores fortemente negativos. A vantagem da convergência determinística faz de 8 eventos quase independentes evidência real, não sorte.

Avalie principalmente pelas convergências walk-forward (cadeia estendida), não pelo holdout de 15 dias; sinalize ao operador se o critério do holdout bloquear carries válidos mantidos por um trimestre.

Ressalva de horizonte (como nas estratégias macro): manutenções de ~90 dias significam que o holdout de 15 dias contém ~0 convergências fechadas, tornando estruturalmente difícil avaliar o critério de holdout. Isso é menos impeditivo que para estratégias seguidoras de tendência, porque a cadeia estendida oferece convergências suficientes para janelas walk-forward diagnósticas, mas o operador deve observar que o holdout exige um tratamento sensível ao horizonte para carries mantidos por um trimestre.

Confirmar a neutralidade em delta e a contribuição da base por trimestre no backtest completo da cadeia estendida.

Duas verificações de sanidade dos analistas (nenhuma é defeito de código): (1) exposure_pct 227% — para um par spot comprado + futuro vendido delta-neutro a capital_frac 0.45/perna, o bruto esperado é ~0.90x; 227% provavelmente é um artefato de notional bruto/marcação valorizada (beta 0.0105, max_dd 3.24%, ganhos/perdas quase simétricos de largest_win confirmam que o livro está IS neutro), mas confirme que não há desvio no dimensionamento ao longo da cadeia estendida. (2) avg_loss ($13,905) supera ligeiramente avg_win ($12,384) em win_rate 0.5625 — resultado líquido positivo, mas alguns trimestres convergem de forma desfavorável (backwardation/ampliação da base antes da rolagem); confirme que a vantagem não depende de um ou dois trimestres com contango elevado.

Nenhum problema no código — a rolagem é sólida e reutilizável em uma cadeia de qualquer extensão.

CREDIT (sem defeito): o ROLL está implementado corretamente conforme solicitado na iteração -1 — _candidate seleciona o contrato trimestral ativo mais próximo do vencimento, com margem de tempo (3 dias de verificação de defasagem _live + _dte por contrato), mantém a posição até roll_buffer_days antes da liquidação e então rola para o próximo trimestre, vencimento interpretado por contrato, proteção contra perna descoberta, pernas delta-neutras com notional igual (margem linear em USDT), spot apenas em BUY (seguro para CASH), dimensionamento limitado e independente do caminho, trabalho O(1) por barra. O período trimestral 12-HOUR (diferente do período primário 1-DAY) evita corretamente o impasse de alinhamento no mesmo período para contratos vencidos/não listados. Mecanismo validado: 8 convergências limpas em 90 dias, ~4/ano, viável após taxas (1.06% de comissão).

Histórico de Iterações

Verificação reprovada (Camada 4 — revisão QA): - O desenho declarado na hipótese, de ROLLING MULTI-QUARTER “rolados no vencimento”, não foi NOT implementado. O título (“Rolado no vencimento”) e a descrição (“depois rolar para o próximo trimestral”) especificam uma série contínua, mas o código negocia o contrato com vencimento mais próximo SINGLE (BTCUSDT_241227) e para após uma convergência — não há rolagem. Por isso, o backtest produz exatamente uma operação. A lógica de carry por contrato está correta, mas……Mostrar maisMostrar menos

Verificação reprovada (Camada 4 — revisão QA): - O desenho declarado na hipótese, de ROLLING MULTI-QUARTER “rolados no vencimento”, não foi NOT implementado. O título (“Rolado no vencimento”) e a descrição (“depois rolar para o próximo trimestral”) especificam uma série contínua, mas o código negocia o contrato com vencimento mais próximo SINGLE (BTCUSDT_241227) e para após uma convergência — não há rolagem. Por isso, o backtest produz exatamente uma operação. A lógica de carry por contrato está correta, mas falta o mecanismo de rolagem que torna a estratégia repetível e mensurável. - UNMEASURABLE — o sandbox produziu apenas 1 convergência (total_trades 2 = um par de pernas), metrics_reliable=false (“apenas 1 retorno diário”), data_days 1, Sharpe/PSR/CI todos como null. Uma única operação não permite diagnóstico (L16/L26): uma captura favorável da base em um mercado de alta 2024-H2 não valida persistência, e a otimização em 3 fases (sensibilidade, janelas 3 walk-forward, holdout) não pode ser executada com n=1. Essa é a consequência estrutural da falta de rolagem — um carry mantido até a liquidação tem ~4 operações/ano, então um único contrato fornece apenas 1. - CREDIT (sem defeito) + ressalva sobre os dados para a versão com rolagem: a implementação de contrato único está CORRECT e o mecanismo é realmente novo e promissor — lê o trimestral DATED real (não o perp, portanto NOT o carry de funding que fracassou), calcula corretamente a base anualizada, pernas delta-neutras com notional igual (linear com margem em USDT, evitando a armadilha COIN-M), perna spot apenas BUY (CASH-segura), vencimento obtido do símbolo, proteção contra perna descoberta, dimensionamento limitado e independente do caminho; a única convergência teve resultado líquido positivo (+1.80%), com comissão de 0.64% do bruto — superando decisivamente os custos; é o primeiro mecanismo realmente diferente e neutro ao mercado após uma sequência de reversões fracassadas. Ao implementar a rolagem, verifique a cobertura de klines por trimestre para que um contrato ausente não faça trimestres serem ignorados silenciosamente.

RuntimeError: dados de funding indisponíveis para a perna perp 'BTCUSDT_230929.BINANCE' — a coleta sob demanda falhou ou a venue não tem histórico de funding (backtest bloqueado para preservar a precisão; defina SF_DISABLE_ONDEMAND_FUNDING=1 para contornar) Traceback (most recent call last): File "/opt/strategy-factory/src/agents/backtest_agent.py", line 190, in _run_backtest await self._ensure_funding_for_perp_legs(instrument_id, extra_instrs) File "/opt/strategy-factory/src/agents/backtest_agent.py", line 406, in _ensure_funding_for_perp_legs raise RuntimeError( RuntimeError: dados de funding indisponíveis para a perna perp 'BTCUSDT_230929.BINANCE' — a coleta sob demanda falhou ou a venue não tem histórico de funding (backtest bloqueado para preservar a precisão; defina SF_DISABLE_ONDEMAND_FUNDING=1 para contornar)

Resumo do resultado

A hipótese apontou a disponibilidade de dados/klines de vencimentos trimestrais históricos como uma dependência que deveria interromper o processo imediatamente, e isso foi decisivo: o requisito de dados de funding do harness de backtest para a perna de futuros precisa ser atendido (ou contornado por SF_DISABLE_ONDEMAND_FUNDING) antes mesmo que um carry de base trimestral possa ser avaliado.

Foi abandonado após 3 iterações, quando o backtest falhou com um RuntimeError: não havia dados de funding disponíveis para a perna 'BTCUSDT_230929.BINANCE' — o mecanismo tratou o futuro trimestral com vencimento definido como um perp que exigia histórico de funding, bloqueando o backtest para preservar a precisão.

Um cash-and-carry BTC neutro ao mercado que compra BTCUSDT à vista e vende o futuro trimestral USD-M com vencimento mais próximo, mantendo a posição até a liquidação para capturar a base de contango com convergência determinística (~5-15% anualizada), em vez do pequeno funding de perp.

Não há métricas de desempenho — o backtest nunca foi concluído, portanto não há retorno, Sharpe ou contagem de operações; a etapa de otimização nunca foi alcançada.

Motivo do Abandono

backtest_failed: RuntimeError: dados de funding indisponíveis para a perna perp 'BTCUSDT_230929.BINANCE' — a coleta sob demanda falhou ou a venue não tem histórico de funding (backtest bloqueado para preservar a precisão; defina SF_DISABLE_ONDEMAND_FUNDING=1 para contornar) Traceback (most recent call last): File "/opt/strategy-factory/src/agents/backtest_agent.py", line 190, in _run_backtest await self._ensure_funding_for_perp_legs(instrument_id, extra_instrs) File "/opt/strategy-factory/src/agents/backtest_agent.py", line 406, in _ensure_funding_for_perp_legs raise RuntimeError( RuntimeError: dados de funding indisponíveis para a perna perp 'BTCUSDT_230929.BINANCE' — a coleta sob demanda falhou ou a venue não tem histórico de funding (backtest bloqueado para preservar a precisão; defina SF_DISABLE_ONDEMAND_FUNDING=1 para contornar)

Stratmill é uma ferramenta de pesquisa e paper trading, não uma consultoria financeira ou corretora. Resultados de backtest e paper trading são hipotéticos. Negociar envolve risco de perda.