Documentação — Arquitetura multi-bot fragmentada de emissores/receptores (Loxley AI)
Uma marca, muitas instâncias de bot, zero mensagens perdidas.
Como a Loxley AI escala um único bot de trading com a sua marca para milhares de usuários: processos coordenador e workers, múltiplos tokens de bot do Telegram (até 7), fragmentação pusher/receiver, estado compartilhado e padrões de resiliência na Robinhood Chain.
O Telegram aplica limite de requisições a cada token de bot. Um bot de token único atendendo alguns milhares de traders ativos vai acabar perdendo mensagens exatamente quando mais importa — durante um lançamento quente, quando todos os membros querem comprar ao mesmo tempo. A Loxley AI resolve isso com uma arquitetura multi-bot fragmentada (sharded): o bot da sua marca não é um processo, mas uma frota coordenada.
Topologia
- Coordenador: o cérebro. Ele cuida da detecção de pares, do pipeline de segurança, do rastreamento de posições, do motor de vendas e da contabilidade de taxas. Ele decide; não fala com os membros.
- Receptores (workers): um conjunto de processos de tokens de bot (um operador pode configurar até 7 tokens de bot) que recebem os comandos dos membros: menus de compra, criação de carteiras, pedidos de venda, configurações. Os receptores são frontends sem estado — traduzem as interações do Telegram em trabalhos para o coordenador e renderizam as respostas dele.
- Emissores (pushers): vias de difusão pertencentes à frota que distribuem os alertas (pares novos, vereditos, notificações) aos membros em paralelo. Os alertas são fragmentados entre os tokens, de modo que uma rajada de milhares de mensagens se espalha por várias cotas do Telegram em vez de fazer fila atrás de uma só.
- Estado compartilhado: uma camada rápida de dados em memória mais um banco de dados durável guardam posições, configurações de membros e caches de vereditos, de modo que qualquer receptor pode responder a qualquer membro e o coordenador enxerga uma única verdade.
O que a fragmentação entrega na prática
- Vazão: a distribuição de alertas escala linearmente com o número de tokens. Um alerta de lançamento chegando a 5,000 membros é uma rajada fragmentada, não um gotejamento serial ao longo de minutos.
- Resiliência: se um token é limitado por taxa ou um processo worker reinicia, as vias restantes absorvem seus membros. O coordenador nunca depende de um único processo frontend.
- Consistência de marca: todos os tokens são configurados sob a identidade de marca do operador. Os membros percebem "o bot"; a frota é invisível.
- Isolamento de vias: vias de estratégias automatizadas, vias de auto-buy e vias de notificação são separadas para que uma tempestade de alertas intensa não possa estrangular a execução de ordens, e as regras de shadowing (sobreposição) impedem que dois modos de automação comprem ao mesmo tempo na mesma via.
Carteiras em escala de frota
Cada membro recebe uma carteira integrada criada no chat. O material da chave privada é armazenado criptografado com criptografia de envelope; os receptores nunca o registram em logs, os operadores não podem lê-lo e só o coordenador o usa no momento da assinatura, dentro do pipeline de execução. Escalar a frota nunca multiplica a exposição das chaves, porque elas vivem na camada do coordenador — um único perímetro de custódia, não importa quantos tokens emitam mensagens.
Operações
Existem kill switches (interruptores de corte) em todos os níveis: a automação por via pode ser interrompida, um receptor pode ser drenado e removido e o auto-buy global pode ser desligado sem reimplantação. Os rollouts da frota começam em modo canário: as mudanças rodam em um worker antes de irem para a frota. Os operadores veem a saúde da frota no seu painel; os membros não veem nada além de um bot que responde.
A seguir: motor de taxas do operador → Toda a documentação
Built for operators, not slippage goblins. Talk to us →