前面我们 já resolvemos o monitoramento de mercado (Scout) e o modelo matemático (AMM Math), agora chega a parte principal — a camada de estratégia (Strategy). Esta é a mente do robô de arbitragem, que precisa responder a três questões-chave em questão de milissegundos:

Há dinheiro a ganhar? A diferença de preço é suficiente para cobrir gas e slippage? Como operar? Comprar a preço baixo no Pool A, vender a preço alto no Pool B, ou operar na direção oposta? Como garantir que o lucro realmente seja obtido? Lockando a execução através de transações atômicas e empacotamento com Bundle.

Nesta edição, vamos analisar a lógica algorítmica de arbitragem cross-DEX na Solana e os desafios práticos de engenharia.

**De polling a evento-driven**

O ambiente de alto desempenho da Solana determina que a arquitetura de arbitragem deve ser reativa. Quando o estado do pool é atualizado, o robô entra imediatamente no fluxo de trabalho: mudança de estado acionada → cálculo de cotação local → comparação de spread → verificação se ultrapassa o limite → se sim, cálculo da direção e escala → construção de instruções de transação atômica → envio via Jito Bundle. Por outro lado, se o spread não atingir o limite, simplesmente abandona e espera pela próxima oportunidade.

Essa arquitetura reduz o tempo desde o monitoramento até a emissão da transação para milissegundos, rápido além da sua imaginação. Não é um polling do estado do pool, nem uma espera passiva, mas uma verdadeira arquitetura orientada a eventos.

**Por que usar Jito Bundle**

No ecossistema da Solana, mesmo que sua transação seja rápida, ela precisa ficar na fila. O papel do Jito Bundle é quebrar essa lógica de fila. O robô pode empacotar várias transações em uma única operação atômica e enviá-la ao validador, garantindo a ordem de execução e atomicidade. Uma vez dentro do Bundle, ou tudo é bem-sucedido, ou tudo falha — sem estados intermediários. Isso é crucial para arbitragem — você não pode aceitar uma transação bem-sucedida e outra falhando.

**O núcleo da lógica de decisão**

A detecção de spread é a primeira etapa. O robô deve calcular em tempo real todas as possíveis rotas de arbitragem (pode envolver dois pools, três pools ou até mais), filtrando aquelas com maior spread. Mas há um problema: as transações geram slippage, a taxa de gas é fixa, e em momentos de congestionamento a taxa do Bundle pode disparar. Portanto, esses fatores devem ser considerados no cálculo, para garantir que o lucro final seja positivo.

Depois, vem a decisão de direção. Suponha que o spread USDC/SOL apareça, o robô precisa determinar em qual pool comprar e em qual vender. Isso envolve profundidade de liquidez, limites de escala de transação e a variação dinâmica do slippage. Escala muito pequena não gera lucro, escala muito grande pode consumir o lucro com slippage — é preciso encontrar o ponto crítico.

Todo esse ciclo se repete continuamente, do momento de identificar a oportunidade até a execução da ordem, com quase nenhum atraso.