Eine Marke, viele Bot-Instanzen, null verlorene Nachrichten.

Wie Loxley AI einen gebrandeten Trading-Bot auf tausende Nutzer skaliert: Koordinator- und Worker-Prozesse, mehrere Telegram-Bot-Tokens (bis zu 7), Pusher-/Receiver-Sharding, gemeinsamer Status und Resilienzmuster auf Robinhood Chain.

Telegram rate-limitet jedes Bot-Token. Ein Einzel-Token-Bot, der einige tausend aktive Trader bedient, wird irgendwann genau dann Nachrichten verlieren, wenn es am meisten zählt — während eines heißen Launches, wenn alle Mitglieder gleichzeitig kaufen wollen. Loxley AI löst das mit einer Multi-Bot-Sharded-Architektur — Sharding meint die Aufteilung der Last auf mehrere Bot-Instanzen: Der Bot Ihrer Marke ist nicht ein Prozess, sondern eine koordinierte Flotte.

Topologie

• Koordinator: das Gehirn. Er besitzt Pair-Erkennung, die Sicherheitspipeline, Positions-Tracking, die Sell-Engine und die Gebührenabrechnung. Er entscheidet; er spricht nicht mit Mitgliedern.
• Receiver (Worker): eine Gruppe von Bot-Token-Prozessen (ein Operator kann bis zu 7 Bot-Tokens konfigurieren), die Befehle der Mitglieder empfangen: Kaufmenüs, Wallet-Erstellung, Verkaufsanfragen, Einstellungen. Receiver sind zustandslose Frontends — sie übersetzen Telegram-Interaktionen in Jobs für den Koordinator und rendern dessen Antworten.
• Pusher: Broadcast-Lanes im Besitz der Flotte, die Alerts (neue Pairs, Urteile, Benachrichtigungen) parallel an die Mitglieder verteilen. Alerts werden über die Tokens geshardet, sodass ein Schub von tausenden Nachrichten sich über mehrere Telegram-Quoten verteilt, statt sich hinter einer einzigen anzustauen.
• Gemeinsamer Status: eine schnelle In-Memory-Datenschicht plus eine dauerhafte Datenbank halten Positionen, Mitgliedseinstellungen und Urteils-Caches, sodass jeder Receiver jedes Mitglied bedienen kann und der Koordinator eine Wahrheit sieht.

Was Sharding in der Praxis liefert

• Durchsatz: Der Fan-out für Alerts skaliert linear mit der Anzahl der Tokens. Ein Launch-Alert, der 5.000 Mitglieder erreicht, ist ein geshardeter Schub, kein serielles Getröpfel über Minuten.
• Resilienz: Wird ein Token rate-limitet oder startet ein Worker-Prozess neu, absorbieren die übrigen Lanes dessen Mitglieder. Der Koordinator hängt niemals an einem einzelnen Frontend-Prozess.
• Markenkonsistenz: Alle Tokens sind unter der Markenidentität des Operators konfiguriert. Mitglieder erleben „den Bot"; die Flotte bleibt unsichtbar.
• Lane-Isolation: Automatisierte Strategie-Lanes, Auto-Buy-Lanes und Benachrichtigungs-Lanes sind getrennt, sodass ein heftiger Alert-Sturm die Orderausführung nicht aushungern kann, und Shadowing-Regeln verhindern, dass zwei Automatisierungsmodi gleichzeitig in derselben Lane kaufen.

Wallets auf Flottengröße

Jedes Mitglied erhält eine eingebettete Wallet, die im Chat erstellt wird. Das Private-Key-Material wird mit Envelope Encryption verschlüsselt gespeichert; Receiver loggen es niemals, Operatoren können es nicht lesen, und allein der Koordinator verwendet es zum Signaturzeitpunkt innerhalb der Ausführungspipeline. Die Skalierung der Flotte vervielfacht niemals die Schlüsselexposition, denn die Schlüssel leben auf der Koordinator-Ebene — eine Custody-Grenze, unabhängig davon, wie viele Tokens Nachrichten pushen.

Betrieb

Kill-Switches — Not-Aus-Schalter, die Automatisierung sofort stoppen — existieren auf jeder Ebene: Automatisierung pro Lane kann angehalten werden, ein Receiver kann leergelaufen und entfernt werden, und der globale Auto-Buy lässt sich ohne Redeployment abschalten. Flotten-Rollouts sind Canary-first: Änderungen fahren zuerst auf einem Worker, dann auf der Flotte. Operatoren sehen die Flottengesundheit über ihr Dashboard; Mitglieder sehen nichts als einen Bot, der antwortet.

Weiter: Operator-Fee-Engine → Alle Dokumente

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