Cross-post. Original: stellarbytecapital.com/blog/crypto-trading-bot-architecture
Most "how to build a trading bot" guides spend all their time on the strategy and none on the part that actually determines whether you make or lose money: the engineering around it. A crypto trading bot is maybe 10% strategy and 90% the unglamorous machinery that keeps it running, correct, and safe when things go wrong — which, on a live exchange, they will.
Here's the architecture that matters, component by component.
1. Exchange connectivity — the layer that lies to you
Your bot talks to an exchange over REST (orders, account state) and WebSocket (real-time market data and order updates). This layer is where most bots quietly break:
- Rate limits. Every exchange throttles you. Hit the limit at the wrong moment and your cancel order doesn't go through. Budget your request rate and back off gracefully.
- Reconnects. WebSockets drop. When they do, resync state — open orders, positions, balances — before trusting anything. A bot that keeps trading on stale data after a disconnect is how accounts blow up.
- Clock and nonce. Signed requests need correct timestamps and monotonic nonces. Get these wrong and the exchange silently rejects you.
2. Order execution — idempotent or bust
Placing an order is not "fire and forget." Networks time out after the exchange received your order but before you got the response. Retry naively and you've placed the order twice. Every order needs a client-generated ID so a retry is idempotent — the exchange dedupes it. Track every order through its full lifecycle (submitted → acknowledged → filled/cancelled) and reconcile against the exchange as the source of truth.
3. Risk management — the layer that saves the account
The part hype skips and professionals obsess over. Independent of the strategy, enforce hard limits the strategy cannot override:
- Max position size and max leverage
- Max daily loss → kill switch that flattens and halts
- Sanity checks on every order (price within X% of mid, size within bounds) before it's sent
- A dead-man's switch — if the bot loses connection or crashes, open orders should be cancellable automatically
Risk lives outside and above the strategy. A bug in the strategy should never be able to bypass the risk layer.
4. State & reconciliation
The exchange is the source of truth, always. Your bot's local view of positions and orders will drift — from missed messages, restarts, partial fills. On startup and periodically, reconcile local state against the exchange and trust the exchange. A bot that trades on its own stale bookkeeping is a bot that surprises you.
5. Observability
Log every decision, order, fill, and error with enough context to reconstruct what happened. When a bot does something unexpected at 3am — and it will — you need the trail. Metrics on latency, fill rates, and PnL let you see problems before they compound.
Keep the strategy separate and pure
Notice what's not in the strategy: connectivity, retries, risk enforcement, reconciliation. The strategy should be a pure decision function — given market state and position, return an intent. Everything above is infrastructure around it. This separation is what lets you backtest the exact code you run live, and swap strategies without touching the machinery that keeps you alive.
The bots that last aren't the ones with the cleverest signal. They're the ones that handle the dropped WebSocket, the double-submit, and the flash crash without losing the account.
We're Xingyao Byte — building quant trading systems, secure AI-execution layers, and payment platforms. Remote, async-first → stellarbytecapital.com
Top comments (0)