One brand, many bot instances, zero dropped messages.

How Loxley AI scales one branded trading bot to thousands of users: coordinator and worker processes, multiple Telegram bot tokens (up to 7), pusher/receiver sharding, shared state, and resilience patterns on Robinhood Chain.

Telegram rate-limits every bot token. A single-token bot serving a few thousand active traders will eventually drop messages exactly when it matters most — during a hot launch, when every member wants to buy at once. Loxley AI solves this with a multi-bot sharded architecture: your brand's bot is not one process, but a coordinated fleet.

Topology

• Coordinator: the brain. It owns pair detection, the safety pipeline, position tracking, the sell engine and fee accounting. It decides; it does not talk to members.
• Receivers (workers): a set of bot-token processes (an operator can configure up to 7 bot tokens) that receive member commands: buy menus, wallet creation, sell requests, settings. Receivers are stateless frontends — they translate Telegram interactions into jobs for the coordinator and render its responses.
• Pushers: broadcast lanes owned by the fleet that fan out alerts (new pairs, verdicts, notifications) to members in parallel. Alerts are sharded across tokens so a burst of thousands of messages spreads over multiple Telegram quotas instead of queueing behind one.
• Shared state: a fast in-memory data layer plus a durable database hold positions, member settings and verdict caches, so any receiver can answer any member and the coordinator sees one truth.

What sharding delivers in practice

• Throughput: fan-out for alerts scales linearly with the number of tokens. A launch alert reaching 5,000 members is a sharded burst, not a serial drip over minutes.
• Resilience: if one token is rate-limited or a worker process restarts, the remaining lanes absorb its members. The coordinator never depends on any single frontend process.
• Brand consistency: all tokens are configured under the operator's brand identity. Members experience "the bot"; the fleet is invisible.
• Lane isolation: automated strategy lanes, auto-buy lanes and notification lanes are separated so a busy alert storm cannot starve order execution, and shadowing rules prevent two automation modes from both buying in the same lane.

Wallets at fleet scale

Each member gets an embedded wallet created in chat. Private key material is stored encrypted with envelope encryption; receivers never log it, operators cannot read it, and the coordinator alone uses it at signing time inside the execution pipeline. Scaling the fleet never multiplies key exposure because keys live with the coordinator tier — one custody boundary regardless of how many tokens push messages.

Operations

Kill switches exist at every level: per-lane automation can be halted, a receiver can be drained and removed, and global auto-buy can be switched off without a redeploy. Fleet rollouts are canary-first: changes ride one worker before the fleet. Operators see fleet health through their dashboard; members see nothing but a bot that answers.

Next: operator fee engine → All docs

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