Rodei 12+ bots de trading por um ano. Eis o que sobreviveu, o que morreu, e o que aprendi.

A maior parte do conteúdo "construí um trading bot" na internet é narrativa de success-bias. Alguém deploya uma estratégia, funciona por um mês, escreve o post, o post viraliza, o bot silenciosamente para de funcionar três meses depois e o postmortem nunca é publicado. A lição — a maioria dos trading bots de varejo falha em formas específicas e repetíveis — nunca entra no corpus público.

Rodamos uma fleet pelos últimos doze meses. Mais de uma dúzia de bots entre duas venues: OKX para perpétuos cripto (demo até qualquer estratégia única sobreviver 60+ live trades net-of-fee), Interactive Brokers para equities tradfi (paper até 30+ trades + um soak de 3-6 meses). No pico, ~$300k de notional estava deployado entre os books demo + paper. Todo trade audit-logged. Todo PnL reconciliado contra os próprios livros do broker — nunca contra o database interno do bot.

A maior parte do que rodamos falhou. Os padrões de como falharam são o que esse artigo é.

A estrutura da fleet

Duas venues, duas superfícies de execução:

• Lado OKX: BTC, ETH, SOL, e uma lista curada de pares de perp negociados por btc-quantum, eth-quantum, regime-rotator, e a família tuned-perps. Demo-account-only até uma estratégia passar pelo audit gate live. Posições live da OKX são capital do usuário, nunca capital de cliente — veja /bots/public para o readout live atual.
• Lado IBKR: 32+ nomes tradfi entre o universo do superciclo de IA (semi, memória, energia, networking), originalmente divididos em bots single-name (nvda-ibkr, aapl-ibkr, amd-fast-rsi-bounce-ibkr, etc.), desde então consolidados em tradfi-ibkr-bot com o universo FIB_BASKET. Conta paper; ramp live adiado até o book consolidado ter os 30+ trades + soak exigidos por nossa própria política paper-to-live.

Doze meses dentro, shipamos postmortems suficientes para identificar seis classes distintas de falha e exatamente dois sobreviventes. As classes de falha generalizam. Se você está rodando ou planejando rodar um book algo de varejo, provavelmente vai bater em pelo menos três delas — melhor reconhecer a forma agora do que de dentro.

Classe de falha 1: exaustão de alpha em perps cripto

A lição mais dolorosa. Tínhamos quatro classes inteiras de estratégia — momentum, range-mean-reversion, breakout, funding-arb — rodando contra o universo de perp da OKX em Q4 2025 / Q1 2026. Cada uma tinha passado seu audit de walk-forward individualmente. Combinadas geraram 213 demo trades.

O PnL bruto: +$122. As fees: $131. O líquido: −$9.

Quatro estratégias, duzentos trades, um trimestre de atenção do operador, e o resultado líquido estava dentro do erro de arredondamento de zero — e no lado errado de zero. O alpha era meio real no nível bruto. O custo de execução comeu tudo.

A lição é brutal na sua especificidade: em tamanho retail de perp em 2026, qualquer estratégia cujo backtest não modela explicitamente as fees da exchange ESTÁ mentindo para você. Maker rebates não te salvam se sua estratégia é taker. Fee tiers não te salvam se você não está em $10M+ de volume mensal. A suposição "fees são negligíveis" que funcionou em mercados de perp cripto 2018-2022 não vale mais — os spreads apertaram e o alpha que vivia dentro dos spreads mais largos sumiu.

O que fizemos sobre isso: trimamos o regime-rotator para um universo de 4 pares (SOL/INJ/LINK/AVAX), blacklistamos SUI/YFI/IOTA e outros 8 pares liquidez-marginais, e fizemos toda analytics NET-of-fee dali em diante. O decision gate para re-expandir o universo agora é 60 live trades net-positive — não bruto.

Classe de falha 2: "passa walk-forward" não é igual a "alpha"

Construímos dois bots single-name genuinamente sofisticados no início de 2026:

• nvda-ibkr — um bot de swing NVDA de ~1.100 linhas com ensembling multi-estratégia e overlay de risco. Resultado walk-forward: 5/5 PASS.
• aapl-ibkr — um bot AAPL mais compacto. Resultado walk-forward: 4/4 PASS, Profit Factor 2.05.

Ambos os bots pareciam, por toda métrica padrão que a literatura de trading sistemático recomenda, vencedores. Deployamos no paper, rodamos por dois meses, e depois comparamos seu retorno cumulativo ao benchmark mais burro possível: segurar o ticker subjacente, mesmo tamanho em dólar, sem rebalanceamento, sem overlay.

• nvda-ibkr capturou 3% do retorno buy-and-hold da NVDA no período.
• aapl-ibkr capturou 2,2% do retorno buy-and-hold da AAPL.

Os bots não estavam perdendo dinheiro. Eram buy-and-hold com risco gerenciado e custo de oportunidade massivo. O "PASS" do walk-forward não estava medindo alpha; estava medindo "não explode." Essas são propriedades muito diferentes.

A lição mais profunda: validação walk-forward te diz que uma estratégia sobrevive à história. Não te diz que a estratégia vale a pena rodar. Uma estratégia cujo alpha depois de custos é menor que o drift natural do subjacente é pior que estratégia nenhuma. O benchmark contra o qual você compara importa enormemente. Desde então adicionamos "captura pelo menos 30% do retorno notional B&H" como hard gate no pipeline de audit; sem ele, "passar" é vibe, não fato.

Classe de falha 3: ficção de PnL

Em maio de 2026 rodamos uma reconciliação contra o próprio fill log da OKX no btc-quantum. O vault SQLite interno do bot reportava PnL cumulativo de +$1.309. Verdade do broker OKX: −$373.

Fonte da lacuna: o analytics.record_trade() do bot estava registrando preços de fill brutos sem subtrair a fee que a OKX deduziu do mesmo trade. Componha isso por uma centena de trades e você constrói um drift fictício de PnL de $1.700. O dashboard do bot, o JSON de status live, e a telemetria voltada ao usuário estavam todos reportando o número fictício.

A lição arquitetural: toda visão interna de PnL de um bot é um cache, não verdade. A única fonte de verdade é o fill log + extrato de posição do próprio broker. Databases internos derivam porque bots são escritos por humanos que esquecem de subtrair fees, perdem partial fills, ou ficam confusos quando uma ordem é cancelada e resubmetida. A disciplina de reconciliação é não-negociável — e na maioria das vezes, a primeira reconciliação revela pelo menos um bug.

Agora rodamos um diff noturno: bot-DB-PnL versus broker-fill-PnL. Qualquer divergência maior que 0,5% pagina um operador antes da abertura da manhã seguinte.

Classe de falha 4: morte silenciosa

Em maio de 2026 tivemos dois incidentes separados de "bot está morto mas ninguém percebeu":

• eth-quantum travou por 18 horas num único TCP read stale da OKX. O socket nunca recebeu um TCP RST, o read() de camada de aplicação nunca retornou, o loop principal do bot estava bloqueado mas o container estava Up. Fix: socket.setdefaulttimeout(30) no start do processo, mais um heartbeat de camada de aplicação que o watchdog lê.
• btc-quantum tinha um guard de duplicate-block que devia prevenir o bot de re-submeter uma ordem na mesma barra duas vezes. O guard era no-op (um bug na comparação) e o bot era fail-deadly em rejeições do lado do broker, então submissões duplicadas silenciosamente passaram. PR #71 consertou o guard.

Na mesma semana, o watchdog falso-positivamente alertou que eth-quantum estava morto há 7,7 horas quando o bot estava na verdade vivo e negociando — o watchdog estava lendo uptime do container, não heartbeat de aplicação.

Lição líquida: container Up não é saúde. Heartbeat de aplicação é saúde. Construa um heartbeat explícito — um valor que o bot escreve num arquivo conhecido a cada N segundos — e faça o watchdog ler AQUILO, não o status de container do Docker. Construa um timeout de socket na camada de rede de toda chamada externa. A combinação pega ambos os tipos de morte silenciosa.

Classe de falha 5: deconflição

Operações multi-bot quebram em formas sutis quando bots compartilham recursos.

• Três bots OKX brigaram pela mesma conta OKX em abril de 2026 (btc-quantum, um experimental eth-grid, e tsla-bot). Sem regras de propriedade por par, dois bots simultaneamente decidiriam "long ETH-PERP" com tamanhos diferentes e um adotaria a posição do outro pensando ser a sua.
• Dois bots IBKR (amd-microswing-ibkr e amd-fast-rsi-bounce-ibkr) compartilhavam a conta paper, ambos observavam AMD, e o mesmo padrão de adoção órfã se desenrolou — um bot via uma posição AMD aberta do outro e "adotava" para seu próprio estado, e então começava a gerenciar lógica de saída contra uma posição que não abriu.

Solução: 1-bot-por-par, ponto final. O fleet registry atribui propriedade explícita; qualquer par que outro bot quer é bloqueado. Quando consolidamos cinco bots IBKR single-name em tradfi-ibkr-bot ($10k cap), toda a lógica de deconflição virou interna a um processo em vez de negociada entre containers. Menos elegante, mais confiável.

Classe de falha 6: deploy faminto de dados

nvda-bot foi um bot de estratégia perp que deployamos na OKX no início de 2026. A estratégia exigia pelo menos 202 barras diárias de contexto histórico. A listagem NVDA-perp da OKX tem 59 barras diárias no total.

O bot estava tomando decisões com dados insuficientes — todo signal que gerava era essencialmente ruído dentro do intervalo de confiança da estratégia. Matamos. A nota no nosso project memory diz "restart ~dezembro 2026" — quando a OKX terá histórico NVDA-perp suficiente para a janela de lookback da estratégia.

Lição: antes de deployar uma estratégia, verifique a janela de dados que a estratégia precisa contra a janela de dados que a venue de fato tem. O erro aqui era trivial de cometer — tínhamos projetado a estratégia em dados sintéticos e assumido que a venue alcançaria. Não alcançou.

O que sobreviveu

Dos doze+ bots, duas estratégias genuinamente bateram seus benchmarks em ciclos consecutivos de walk-forward + soak:

1. reg_channel_mr + ema_crossover (mean-reversion tradfi em cestas de equity). Ambas alcançaram 15 vereditos ROBUST cada no leaderboard do sweep de maio de 2026, batendo fib_mean_reversion em 31 de 32 nomes testados. Essas são agora as estratégias roteadas no bot IBKR consolidado.
2. fib_mean_reversion com filtro SMA50, no coorte HIGH_VOL de 5 nomes apenas. Recalibrada maio de 2026 (PR #278): cesta PF 1,53→1,76, Sharpe 1,08→1,42, +23,7% cumulativo de três anos, walk-forward 4/5 PASS. Coexiste com a mudança de roteamento de escopo 1H por ticker mais ampla do sweep de 19 de maio — ortogonal.

Ambos os sobreviventes são mean-reversion tradfi. Ambos rodam em timeframes diários. Ambos batem B&H depois de fees. É isso. Dois sobreviventes em dezenas de tentativas.

Notavelmente ausente da lista de sobreviventes: qualquer estratégia direcional pura de perp cripto. Pela classe de falha 1, esse alpha está atualmente exausto em tamanho retail. Mantemos bots cripto rodando no demo gate não porque esperamos que encontrem novo alpha amanhã, mas porque no dia em que o alpha retornar (uma mudança de estrutura de mercado, uma nova venue, um novo produto), queremos a infraestrutura já no lugar para detectá-lo.

Meta-padrões transversais

Quatro lições que generalizam entre todas as seis classes de falha:

1. Fees compõem mais rápido que alpha. Toda estratégia deve ser modelada net-of-fee desde a linha um. A lacuna entre bruto e líquido é a causa única mais comum de uma estratégia "vencedora" ser net loser. Faça seu pipeline de audit rejeitar qualquer backtest que não tenha modelagem explícita de fees.

2. Walk-forward diz "não explode." Não diz "bate benchmark." Adicione um hard gate de comparação com benchmark à sua validação. "Captura pelo menos 30% do retorno notional B&H" é nossa barra atual; antes de tê-la, "estratégias passantes" estavam silenciosamente underperformando o subjacente.

3. Database interno é cache. Fill log do broker é verdade. Reconcilie noturnamente. Pagine em divergência. A maioria dos bots live tem pelo menos um bug de PnL-fiction; a primeira reconciliação geralmente o encontra.

4. Container Up não é saúde. Heartbeat de aplicação é saúde. Construa um heartbeat explícito de dentro do processo do bot. Faça o watchdog ler AQUILO, não o Docker. Adicione timeouts de socket em toda chamada externa de API para que reads bloqueados não possam travar o loop principal.

Quanto isso tudo custou

Doze meses. Aproximadamente cinco meses de atenção integral de operador (é um side project em cima da própria plataforma QA). Dezenas de postmortems. Múltiplas perdas de paper em notional de seis dígitos, denominadas em custo de oportunidade mais que dólares (estamos usando contas paper + demo exatamente por essa razão). Provavelmente vinte rebuilds de estratégias que pareciam promissoras em backtest e morreram em soak.

A maior parte dos traders de varejo pula esse custo parando depois do primeiro backtest lucrativo, deployando live, e descobrindo uma das seis classes de falha acima com dinheiro real. O custo de pular a disciplina de postmortem é o custo de descobrir em live trade. Escolhemos descobrir em paper.

Se você quer ver os resultados live + paper atuais em tempo real, são públicos: /bots/public. Curvas de equity atualizam diariamente; as colunas de PnL são reconciliadas contra verdade do broker.

Se isso ressoa

Deployamos nossos bots paper IBKR via o runbook documentado em um artigo separado sobre rodar IBKR Trader Workstation para bots sistemáticos. Para a escolha do broker em si, veja por que IBKR para o trade do superciclo de IA. O lado cripto roda contra OKX pelas razões nessa peça de comparação.

Para rodar sua própria paper fleet do zero:

1. Para tradfi: abra uma conta na Interactive Brokers — contas paper são gratuitas, a API funciona desde o dia um, e o programa da IBKR atualmente dá à nova conta até $1,000 em ações da IBKR (termos aplicam). Raciocínio completo + a fricção que batemos na nossa página de broker.
2. Para perps cripto: abra uma conta na OKX — o ambiente demo espelha live, a API é documentada, os fee tiers escalam. Raciocínio completo na nossa página de broker.
3. Construa a disciplina de audit antes da primeira estratégia. Net-of-fee desde o dia um. Gate de comparação com benchmark. Reconciliação noturna. Watchdog baseado em heartbeat. Os quatro meta-padrões acima são baratos de adicionar upfront e caros de retrofitar depois do primeiro incidente de PnL-fiction.

Os doze+ bots vão se tornar dois sobreviventes. Essa é a taxa. Planeje capacidade de acordo — o valor não está em deployar dez estratégias em paralelo, está em matar as oito que não funcionam rápido e alimentar as duas que funcionam.