Em 22 de abril de 2026, o Robson abriu sua primeira operação com capital real: uma posição long em futuros perpétuos de BTCUSDT, com entrada a $77.932,40, stop derivado do gráfico a $76.158,25 e risco máximo de $4.
Esse número é intencional. A primeira operação foi dimensionada de forma conservadora por design. O objetivo não era gerar retornos expressivos. Era confirmar, de ponta a ponta, que o sistema funciona em condições de produção: credenciais reais, exchange real, fluxo de ordens real, monitor de posição real registrando um tick a cada vinte segundos.
Este post descreve como o sistema foi construído, o que o processo de validação confirmou e como está a arquitetura agora que o Robson está operacional.
A migração que tornou isso possível
O caminho até a primeira operação real envolveu uma mudança arquitetural significativa na camada de exchange.
O Robson operava originalmente através de Margem Isolada da Binance, colocando ordens contra posições em spot com alavancagem aplicada por símbolo. Esse modelo tem limites estreitos: contas de margem isolada estão sujeitas a restrições de posição, o comportamento de liquidação difere dos futuros e a API de ordens não corresponde à API USD-M Futures que governa os contratos perpétuos.
A migração moveu o Robson para os Futuros Perpétuos USD-M da Binance. Trata-se de um tipo de conta diferente, uma superfície de API diferente e um conjunto diferente de restrições. O modo de posição deve ser One-way (não Hedge mode). A alavancagem deve ser configurada explicitamente por símbolo antes de qualquer ordem ser colocada. Os requisitos de precisão de quantidade são mais rígidos. O modelo de taxa de financiamento é diferente dos juros de margem.
Isso não foi uma mudança de configuração. Exigiu reescrever o adaptador de exchange do zero, atualizar todos os caminhos que tocavam posicionamento de ordens, tratamento de preenchimento e reconciliação de posições, e atualizar os runbooks de validação para cobrir modos de falha específicos de futuros.
Visão geral da arquitetura
O Robson segue uma arquitetura hexagonal organizada em seis crates Rust.
O crate de domínio não tem dependências externas. Ele define os tipos centrais: posições, eventos, configuração de risco, distâncias de stop técnico e quantidade. Todo valor financeiro usa rust_decimal::Decimal, nunca ponto flutuante.
O crate de engine contém a lógica de decisão. Ele recebe um DetectorSignal contendo um preço de entrada e um nível de stop derivado do gráfico. Ele calcula o tamanho da posição usando a fórmula:
tamanho_posição = risco_máximo / distância_stop
onde risco_máximo é 1% do capital configurado e distância_stop é a distância absoluta em preço do entry proposto até o stop derivado do gráfico. Isso produz uma quantidade em BTC. O engine então aplica a alavancagem de 10x dos futuros para calcular a margem necessária.
O crate do daemon expõe uma API HTTP. Rotas mutantes (ARM, approve, panic, cancel) requerem um bearer token. Rotas somente leitura (health, status, events, metrics) são não autenticadas. O endpoint de métricas Prometheus permite monitoramento externo sem credenciais.
O adaptador de exchange valida as configurações de futuros antes de cada entrada: ele chama a API da Binance para confirmar que a conta está no modo de posição One-way, e então chama set_leverage para o símbolo. Ambas as operações são idempotentes. Se a conta estiver em modo Hedge, o adaptador retorna um erro de violação de segurança e a operação não prossegue.
Event sourcing como camada de auditoria
Toda decisão que o Robson toma é registrada em um event log append-only.
Quando a requisição ARM chega, um evento position_armed é gravado. Quando o detector dispara um sinal, um evento detector_signal_emitted é gravado com o preço de entrada proposto e o nível de stop derivado do gráfico. Quando o risk engine aprova a operação, um evento risk_engine_approved é gravado com o contexto completo da avaliação de risco. Quando a ordem de entrada é colocada, um evento entry_order_placed é gravado com o ID da ordem na exchange e um cycle_id que vincula essa ordem à aprovação de risco que a autorizou.
O cycle_id não é um campo de conveniência. É o mecanismo de auditoria. Toda ordem na exchange pode ser rastreada de volta a uma aprovação de risco específica no event log. Uma posição sem um entry rastreável é, por definição, não rastreada. Posições não rastreadas são uma condição P0: o sistema as fecha imediatamente e entra em halt.
O monitor de posição adiciona um evento position_monitor_tick em cada ciclo, independentemente de o trailing stop ter se movido. Isso torna possível verificar que o monitor está rodando e processando ticks durante sessões de validação curtas, sem precisar aguardar movimento de preço para acionar um ajuste de stop.
O gate de aprovação
O Robson não entra em posições automaticamente após um sinal. Toda posição que excede um limiar de nocional configurado requer aprovação explícita do operador antes que a ordem de entrada seja colocada.
Quando o gate de aprovação é acionado, o sistema registra a operação proposta em uma fila de aprovações pendentes. O operador revisa o preço de entrada, o nível de stop, a quantidade calculada e o valor nocional, e então aprova ou rejeita explicitamente. Uma aprovação não respondida expira após um timeout configurável. O daemon rearma automaticamente se a posição ainda for viável.
Na primeira operação real, o sinal apareceu duas vezes. A primeira aprovação expirou antes de o operador responder. O daemon rearmou, detectou um novo sinal e apresentou uma segunda aprovação. O operador revisou os parâmetros e aprovou. A ordem de entrada foi colocada imediatamente.
A sequência de validação
Antes de habilitar capital real, a equipe concluiu duas fases formais de validação.
A VAL-001 rodou no testnet com credenciais sintéticas da Binance. Ela confirmou o ciclo completo de vida da posição em cinco checkpoints sequenciais: ARM, sinal do detector, verificação de preenchimento, monitoramento de trailing stop e saída. Cada checkpoint tem um critério de pass/fail verificado no event log. A sessão rodou em 22 de abril e confirmou um ciclo limpo com zero posições não rastreadas.
A VAL-002 ativou a produção. Ela seguiu uma sequência definida: armazenar credenciais reais da Binance, atualizar o secret do cluster, reiniciar o daemon, verificar o endpoint de produção nos logs, executar verificações de segurança no event log e na conta da exchange, e habilitar o monitor de posição via GitOps. A mudança no monitor foi commitada no repositório de infraestrutura e aplicada pelo pipeline de entrega contínua. O daemon reiniciou com o monitor habilitado e confirmou conectividade com o endpoint real da Binance.
Dez minutos de monitoramento pós-ativação não produziram posições não rastreadas, nenhuma saída de safety net e nenhum evento inesperado. As verificações de segurança confirmaram zero linhas abertas no ledger de posições e zero posições abertas na exchange antes de o monitor ser habilitado.
O que a primeira operação confirmou
O detector de cruzamento de médias móveis disparou um sinal em um feed ao vivo de BTCUSDT. O risk engine calculou um tamanho de posição de aproximadamente 0,0022 BTC, um valor nocional de $178 e um requisito de margem de cerca de $18 contra a alavancagem de 10x. O gate de aprovação apresentou esses valores ao operador. O operador aprovou.
A entrada foi preenchida a $77.932,40. O stop derivado do gráfico foi fixado a $76.158,25, uma distância de $1.774,15 do entry. O trailing stop está agora ativo, ajustando para cima conforme o preço se move a favor da posição.
O sistema funcionou exatamente conforme projetado: o adaptador de exchange definiu a alavancagem, confirmou o modo One-way, colocou uma ordem a mercado, recebeu o preenchimento, registrou o evento entry_order_placed com o ID da ordem na exchange, e iniciou o monitor de posição. O daemon está rodando com zero reinicializações.
A posição está aberta. O trailing stop está rastreando. O event log está registrando cada tick.
O que vem a seguir
A prioridade imediata é supervisionar esta posição ao longo de seu ciclo completo de vida: ticks do monitor, ajustes de trailing stop e o eventual evento de saída. Assim que a posição fechar e a saída for confirmada no event log, a equipe revisará a trilha de auditoria completa e avaliará se os parâmetros de dimensionamento e aprovação precisam de ajuste para operações subsequentes.
A camada de persistência de estado mensal (EP-006) está ativa em produção. Ela rastreia a base de capital e as perdas realizadas ao longo do mês de trading, alimentando o limite de perda diária do risk gate e a alocação dinâmica de slots. Esses mecanismos foram construídos antes da primeira operação. Eles estão agora rodando contra dados reais.