Une marque, de nombreuses instances de bot, zéro message perdu.

Comment Loxley AI fait passer un bot de trading à votre marque à des milliers d'utilisateurs : processus coordinateur et workers, multiples tokens de bot Telegram (jusqu'à 7), sharding (répartition) pusher/receiver, état partagé et schémas de résilience sur Robinhood Chain.

Telegram impose un rate limit (limite de débit) à chaque token de bot. Un bot à token unique servant quelques milliers de traders actifs finira par perdre des messages exactement au pire moment — pendant un lancement chaud, quand chaque membre veut acheter en même temps. Loxley AI résout ce problème avec une architecture multi-bot shardée : le bot de votre marque n'est pas un processus unique, mais une flotte coordonnée.

Topologie

• Coordinateur : le cerveau. Il détient la détection des paires, le pipeline de sécurité, le suivi des positions, le moteur de vente et la comptabilité des frais. Il décide ; il ne parle pas aux membres.
• Receivers (receveurs, workers) : un ensemble de processus à tokens de bot (un opérateur peut configurer jusqu'à 7 tokens de bot) qui reçoivent les commandes des membres : menus d'achat, création de wallet, demandes de vente, réglages. Les receivers sont des frontends sans état — ils traduisent les interactions Telegram en tâches pour le coordinateur et rendent ses réponses.
• Pushers (émetteurs) : des voies de diffusion détenues par la flotte qui distribuent les alertes (nouvelles paires, verdicts, notifications) aux membres en parallèle. Les alertes sont shardées entre les tokens, de sorte qu'une rafale de milliers de messages se répartit sur plusieurs quotas Telegram au lieu de faire la queue derrière un seul.
• État partagé : une couche de données rapide en mémoire plus une base de données durable contiennent les positions, les réglages des membres et les caches de verdicts, de sorte que n'importe quel receiver peut répondre à n'importe quel membre et que le coordinateur voit une seule vérité.

Ce que le sharding (répartition) apporte en pratique

• Débit : la distribution des alertes évolue linéairement avec le nombre de tokens. Une alerte de lancement atteignant 5 000 membres est une rafale shardée, pas un goutte-à-goutte en série de plusieurs minutes.
• Résilience : si un token atteint sa limite de débit ou qu'un processus worker redémarre, les voies restantes absorbent ses membres. Le coordinateur ne dépend jamais d'un seul processus frontend.
• Cohérence de marque : tous les tokens sont configurés sous l'identité de marque de l'opérateur. Les membres vivent « le bot » ; la flotte est invisible.
• Isolation des voies : les voies de stratégie automatisée, les voies d'auto-buy et les voies de notification sont séparées, de sorte qu'une tempête d'alertes chargée ne peut pas affamer l'exécution des ordres, et les règles de shadowing empêchent deux modes d'automatisation d'acheter tous deux dans la même voie.

Les wallets à l'échelle de la flotte

Chaque membre reçoit un wallet intégré créé dans le chat. Le matériel de clé privée est stocké chiffré avec un chiffrement enveloppe ; les receivers ne le journalisent jamais, les opérateurs ne peuvent pas le lire, et le coordinateur seul l'utilise au moment de la signature dans le pipeline d'exécution. Passer la flotte à l'échelle ne multiplie jamais l'exposition des clés, car les clés vivent au niveau du coordinateur — une seule frontière de garde, quel que soit le nombre de tokens qui poussent des messages.

Opérations

Des kill switches (interrupteurs d'arrêt d'urgence) existent à chaque niveau : l'automatisation par voie peut être arrêtée, un receiver peut être vidé puis retiré, et l'auto-buy global peut être désactivé sans redéploiement. Les déploiements de la flotte se font en mode canary (canari) d'abord : les changements voyagent sur un worker avant la flotte. Les opérateurs voient la santé de la flotte dans leur tableau de bord ; les membres ne voient rien d'autre qu'un bot qui répond.

Suivant : le moteur de frais opérateur → Toute la doc

Built for operators, not slippage goblins. Talk to us →