Arquitetura de um bot de trading na Deriv

Por Equipe Codexium · Publicado em 2026-11-03 · Atualizado em 2026-11-10 · 10 min de leitura · Robôs de trading

Quando se fala em robô de trading, a conversa costuma girar em torno da "estratégia": qual regra de entrada usar, qual contrato, qual gestão. Na prática, a estratégia é uma parte pequena do sistema. O que define se um robô é confiável é a arquitetura em volta dela: como ele se conecta, como guarda o estado, como verifica limites antes de cada ordem, como lida com quedas de conexão e como registra o que fez. Um robô com uma regra simples e uma arquitetura sólida é muito mais seguro do que um robô com uma regra sofisticada e uma arquitetura frágil.

Neste guia descrevemos, de forma técnica mas acessível, os componentes de um bot de trading para a Deriv e as decisões de projeto que importam. Ele serve tanto para quem quer construir quanto para quem quer avaliar uma ferramenta. Uma observação antes de começar: nenhuma arquitetura cria vantagem estatística. Os índices sintéticos são gerados por algoritmo aleatório e os pagamentos favorecem a plataforma no longo prazo. Uma boa arquitetura garante que as regras sejam executadas corretamente e com limites, e nada além disso.

Visão geral: as camadas

Um bot bem organizado separa responsabilidades em módulos que conversam por interfaces claras. Uma divisão comum:

1. Conexão: mantém o canal com a API (WebSocket), autenticação e reconexão.
2. Dados de mercado: recebe e normaliza ticks.
3. Estado: guarda a situação atual da sessão (saldo, contratos abertos, resultado, contadores).
4. Estratégia: recebe dados e estado e devolve uma intenção ("abrir contrato X com valor Y") ou nada.
5. Gestão de risco: aprova ou rejeita cada intenção com base nos limites.
6. Execução: transforma a intenção aprovada em ordens na API e acompanha até a liquidação.
7. Persistência e logs: grava operações e eventos.
8. Monitoramento e controle: alertas, painel e botão de parada.

A regra de ouro é que a estratégia nunca fala diretamente com a API. Ela só propõe. Quem decide se a proposta vira ordem é a gestão de risco, e quem envia é a execução. Essa separação é o que impede que um bug na estratégia vire uma série de ordens fora de controle.

1. Camada de conexão

A API da Deriv funciona sobre WebSocket: uma conexão persistente por onde o bot envia requisições em JSON e recebe respostas e assinaturas. A camada de conexão cuida de:

• Autorização: envio do comando authorize com o token obtido pelo OAuth da Deriv ou por um token de API com permissões mínimas.
• Keep-alive: envio periódico de ping para manter a conexão ativa e detectar quedas.
• Correlação: uso do campo req_id para associar cada resposta à requisição que a originou.
• Reconexão com backoff: se a conexão cair, tentar de novo com intervalos crescentes, reautorizar e restaurar as assinaturas.
• Limites de requisição: respeitar os limites da API para não ser bloqueado.

Um ponto crítico: depois de uma reconexão, o bot não sabe com certeza o que aconteceu durante a queda. Por isso a reconexão deve sempre disparar uma reconciliação (veja a seção 6) antes de qualquer nova ordem. O tutorial de Deriv API via WebSocket mostra as mensagens básicas.

2. Dados de mercado

O bot assina o fluxo de ticks do índice escolhido com o comando ticks e recebe, a cada atualização, preço e horário. Essa camada deve:

• Normalizar o preço com o número correto de casas decimais (essencial em contratos de dígitos, que dependem do último dígito).
• Descartar ticks duplicados ou fora de ordem, usando o horário (epoch) como referência.
• Detectar lacunas: se os ticks param de chegar, sinalizar para o restante do sistema em vez de seguir decidindo com dados velhos.
• Manter apenas a janela de histórico que a estratégia realmente usa.

3. Estado da sessão

O estado é a "memória" do bot: saldo atual, saldo inicial da sessão, número de operações, resultado acumulado, sequência atual de perdas, contratos abertos e se a sessão está ativa ou encerrada. Algumas boas práticas:

• Fonte única da verdade: todos os módulos leem o estado do mesmo lugar.
• Atualização por eventos confirmados: o resultado de um contrato só entra no estado quando a API confirma a liquidação, não quando o bot "acha" que ganhou ou perdeu.
• Persistência: gravar o estado em disco ou banco para que, se o processo reiniciar, a sessão não recomece do zero com os limites zerados.

Esse último item é mais importante do que parece. Um bot que reinicia e "esquece" que já atingiu metade do stop de perda pode perder o dobro do planejado.

4. Módulo de estratégia

A estratégia deve ser uma função o mais pura possível: recebe dados e estado, devolve uma intenção ou nada. Ela não envia ordens, não grava arquivos e não altera o estado diretamente. Vantagens dessa abordagem:

• Fica fácil testar com dados históricos, como em um backtest de robô.
• É possível trocar de estratégia sem mexer no resto do sistema.
• O comportamento é determinístico: os mesmos dados produzem a mesma decisão.

Cuidado com estratégias excessivamente ajustadas aos dados do passado. Quanto mais parâmetros, maior a chance de overfitting: regras que parecem ótimas no histórico e não se repetem depois.

5. Gestão de risco: o porteiro

Toda intenção da estratégia passa pela gestão de risco antes de virar ordem. Ela verifica, nesta ordem e sem exceções:

1. A sessão está ativa? Algum stop de perda ou de ganho já foi atingido?
2. O número máximo de operações da sessão foi alcançado?
3. O valor da entrada está dentro do máximo permitido e é proporcional ao saldo?
4. Há contratos abertos demais ao mesmo tempo?
5. Os dados de mercado estão atualizados e a conexão está saudável?
6. A conta selecionada é a esperada (demo ou real)?

Se qualquer verificação falhar, a intenção é descartada e o motivo é registrado. Os limites devem ser configurados antes de ligar o bot e não podem ser alterados pela estratégia. Explicamos como definir esses números em limites de sessão em robô. Um detalhe de projeto útil: calcular o stop considerando o pior caso dos contratos já abertos, e não só o resultado realizado, para que a sessão não ultrapasse o limite enquanto contratos ainda estão em andamento.

Progressões de recuperação, como Martingale e Fibonacci, conflitam diretamente com essa camada, porque aumentam a entrada justamente quando o risco já está alto. Se forem usadas, a gestão de risco precisa ter um teto rígido. Mostramos os números em Fibonacci na gestão de entrada.

6. Execução e reconciliação

Na Deriv, abrir um contrato normalmente envolve duas etapas: pedir uma cotação (proposal) com os parâmetros do contrato e, em seguida, comprar (buy) usando o identificador da cotação e um preço máximo aceitável. Depois, o bot acompanha o contrato (por exemplo, com proposal_open_contract) até a liquidação. Pontos de atenção:

• Conferir o pagamento: antes de comprar, verificar se o pagamento cotado está dentro do esperado. Se mudou, descartar.
• Idempotência: nunca reenviar uma compra sem saber se a anterior foi aceita. Um timeout não significa que a ordem falhou.
• Uma intenção, uma ordem: marcar cada intenção com um identificador e impedir que ela gere duas compras.
• Reconciliação: após reconexões, reinícios ou respostas ambíguas, consultar a API (saldo, contratos abertos, histórico recente) e ajustar o estado antes de continuar.
• Parada em inconsistência: se o estado local e o da API não baterem, a resposta segura é parar a sessão e alertar, não "tentar consertar" operando.

7. Persistência e logs

Um bot sem registro é uma caixa-preta. Duas coisas devem ser gravadas separadamente:

• Operações: horário, índice, contrato, valor, pagamento cotado, resultado confirmado, identificador do contrato na Deriv e qual regra gerou a entrada.
• Eventos: conexões, quedas, reconexões, intenções rejeitadas pela gestão de risco (com o motivo), stops atingidos e erros.

Esses registros são a base para medir o desempenho com honestidade. As métricas que importam, como taxa de acerto, resultado médio por operação e maior sequência de perdas, estão explicadas em métricas de desempenho de robô. E nunca grave tokens ou credenciais nos logs.

8. Monitoramento e botão de parada

Mesmo automatizado, um bot precisa de supervisão. O mínimo recomendável:

• Painel com estado da sessão, resultado, operações e saúde da conexão.
• Alertas quando um stop é atingido, quando a conexão cai por muito tempo ou quando ocorre uma inconsistência.
• Kill switch: um comando que encerra a sessão imediatamente e impede novas ordens, acessível de forma simples, inclusive pelo celular.
• Heartbeat: o bot sinaliza periodicamente que está vivo. Se o sinal parar, alguém precisa saber.

9. Configuração e implantação

Parâmetros como entrada, stops, índice e contrato devem ficar em configuração, não espalhados pelo código. Cada sessão deve registrar com qual configuração rodou, para que os resultados possam ser comparados. Para rodar continuamente, o bot costuma ficar em um servidor (VPS) com um supervisor de processos que o reinicia em caso de falha. Nesse cenário, a persistência do estado e a reconciliação na inicialização deixam de ser opcionais. Discutimos os prós e contras em robô 24 horas em VPS.

10. Testes em camadas

Antes de qualquer valor real, o bot deve passar por etapas de teste, cada uma pegando um tipo diferente de problema:

Um teste que vale a pena fazer de propósito: derrubar a conexão no meio de um contrato aberto e verificar se o bot reconcilia corretamente, sem ordens duplicadas e sem perder a contagem do stop.

Checklist para avaliar a arquitetura de um robô

• A estratégia está separada da execução, com uma camada de risco no meio?
• Os limites de sessão são verificados antes de cada ordem e não podem ser burlados pela estratégia?
• O estado sobrevive a um reinício do processo?
• O que acontece depois de uma queda de conexão? Há reconciliação?
• Existe proteção contra ordens duplicadas?
• Há histórico completo, inclusive das perdas e das ordens rejeitadas?
• Existe um botão de parada simples?
• A conexão usa autorização oficial com permissões mínimas?

Se o fornecedor não souber responder a essas perguntas, isso diz mais sobre o robô do que qualquer print de resultado. Complementamos esse ponto de vista em como avaliar um robô de trading.

Como o Codexium aplica esses princípios

O Codexium foi pensado com essa separação de responsabilidades: a conexão usa a autorização oficial da Deriv, os limites de sessão (entrada, stop de perda, stop de ganho) são verificados antes das ordens, nos modos manual e robô, e cada operação fica registrada no histórico. Isso torna a execução mais previsível e auditável, mas não muda a matemática dos contratos nem garante qualquer resultado. Recomendamos testar qualquer configuração na conta demo antes de considerar a conta real.

Resumo

A arquitetura de um bot de trading é o que separa um executor confiável de um gerador de surpresas. Separe conexão, dados, estado, estratégia, risco e execução; faça a gestão de risco aprovar cada ordem; persista o estado; reconcilie depois de qualquer falha; registre tudo; e mantenha monitoramento e um botão de parada. Teste em camadas, terminando na conta demo. Uma boa arquitetura não cria lucro, mas evita que erros técnicos se somem ao risco que já existe em cada contrato. Veja mais em robôs de trading.

Perguntas frequentes

Quais são os componentes de um bot de trading?

Em geral: conexão com a API, dados de mercado, estado da sessão, estratégia, gestão de risco, execução e reconciliação, persistência e logs, monitoramento com botão de parada e configuração.

Por que separar a estratégia da gestão de risco?

Para que nenhuma ordem saia sem passar por um porteiro independente que verifica stops, limites e saldo. Se a estratégia tiver um erro, a gestão de risco ainda pode bloquear a ordem.

O que é reconciliação em um robô de trading?

É conferir, depois de falhas ou reconexões, o que realmente aconteceu na conta, como contratos abertos e o extrato, antes de tomar novas decisões. Isso evita ordens duplicadas ou estado errado.

Como testar a arquitetura de um bot antes da conta real?

Teste em camadas: funções isoladas, simulações com dados históricos e, por fim, a conta demo com o mesmo código que vai para produção.

Uma boa arquitetura torna o robô lucrativo?

Não. Ela reduz falhas técnicas e erros de execução, mas o resultado depende da expectativa das operações, e operar continua envolvendo alto risco de perda.