Documentación — Arquitectura multi-bot fragmentada de emisores/receptores (Loxley AI)
Una marca, muchas instancias de bot, cero mensajes perdidos.
Cómo escala Loxley AI un solo bot de trading con marca a miles de usuarios: procesos coordinadores y workers, múltiples tokens de bot de Telegram (hasta 7), fragmentación pusher/receiver, estado compartido y patrones de resiliencia en Robinhood Chain.
Telegram limita la tasa de cada token de bot. Un bot de un solo token que sirve a unos miles de traders activos acabará perdiendo mensajes justo cuando más importa — durante un lanzamiento caliente, cuando todos los miembros quieren comprar a la vez. Loxley AI lo resuelve con una arquitectura multi-bot fragmentada (sharded): el bot de tu marca no es un proceso, sino una flota coordinada.
Topología
- Coordinador: el cerebro. Posee la detección de pares, el pipeline de seguridad, el seguimiento de posiciones, el motor de ventas y la contabilidad de comisiones. Decide; no habla con los miembros.
- Receptores (workers): un conjunto de procesos de tokens de bot (un operador puede configurar hasta 7 tokens de bot) que reciben los comandos de los miembros: menús de compra, creación de billeteras, solicitudes de venta, ajustes. Los receptores son frontends sin estado: traducen las interacciones de Telegram en trabajos para el coordinador y renderizan sus respuestas.
- Emisores (pushers): carriles de difusión pertenecientes a la flota que reparten las alertas (pares nuevos, veredictos, notificaciones) a los miembros en paralelo. Las alertas se fragmentan entre tokens, de modo que una ráfaga de miles de mensajes se reparte entre varias cuotas de Telegram en lugar de hacer cola detrás de una sola.
- Estado compartido: una capa rápida de datos en memoria más una base de datos durable guardan posiciones, ajustes de miembros y cachés de veredictos, de modo que cualquier receptor puede responder a cualquier miembro y el coordinador ve una sola verdad.
Qué aporta la fragmentación en la práctica
- Rendimiento: la difusión de alertas escala linealmente con el número de tokens. Una alerta de lanzamiento que llega a 5,000 miembros es una ráfaga fragmentada, no un goteo en serie durante minutos.
- Resiliencia: si un token se ve limitado por tasa o un proceso worker se reinicia, los carriles restantes absorben a sus miembros. El coordinador nunca depende de un único proceso frontend.
- Coherencia de marca: todos los tokens se configuran bajo la identidad de marca del operador. Los miembros perciben "el bot"; la flota es invisible.
- Aislamiento de carriles: los carriles de estrategias automatizadas, los carriles de auto-buy y los carriles de notificaciones están separados para que una tormenta de alertas intensa no pueda privar de recursos a la ejecución de órdenes, y las reglas de shadowing (solapamiento) evitan que dos modos de automatización compren a la vez en el mismo carril.
Billeteras a escala de flota
Cada miembro recibe una billetera integrada creada en el chat. El material de la clave privada se almacena cifrado con cifrado de sobre; los receptores nunca lo registran, los operadores no pueden leerlo y solo el coordinador lo usa en el momento de firmar dentro del pipeline de ejecución. Escalar la flota nunca multiplica la exposición de las claves porque estas viven en la capa del coordinador — un único perímetro de custodia sin importar cuántos tokens emitan mensajes.
Operaciones
Existen kill switches (interruptores de corte) en todos los niveles: la automatización por carril puede detenerse, un receptor puede drenarse y retirarse, y el auto-buy global puede apagarse sin redesplegar. Los despliegues de la flota son primero en canario: los cambios viajan en un worker antes que en toda la flota. Los operadores ven la salud de la flota en su panel; los miembros no ven nada más que un bot que responde.
Siguiente: motor de comisiones del operador → Toda la documentación
Built for operators, not slippage goblins. Talk to us →