I Thought the Hardest Part of a Trading Bot Was the Strategy

When the author began building CryptoBot, they believed the most challenging aspect would be devising the trading strategy. This included technical indicators such as RSI, MACD, moving averages, momentum, and backtesting. However, as they delved further into the project, they encountered a different set of problems. Even a well-designed strategy could lead to incorrect decisions if the market data was outdated, the exchange connection failed, or the application was uncertain about whether an order had been executed.

This shift in perspective led them to consider the broader system components of market data, validation, strategy, risk management, execution, exchange, reconciliation, and recovery.

The author emphasized that the strategy is merely one part of the overall trading bot system. While the basic flow of a trading bot seems straightforward—market data, strategy, risk check, order, and exchange—the reality is far more complex. Issues can arise at any point, such as WebSocket disconnections, stale data, API timeouts, application crashes, missed events, and local state discrepancies with the exchange.

These challenges form the foundation of the interesting engineering work required to build robust trading bots.

A WebSocket can reconnect but may still be out of sync with the current market state. During disconnections, market conditions may change, orders could be filled or cancelled, or multiple events may occur. Therefore, simply reconnecting isn't the same as recovering. The bot must synchronize with the system, validate its state, and ensure it is trading with accurate and up-to-date information.

Stale data is often more dangerous than a crash. A crashed application is easily noticeable, but stale data can cause a running application to make decisions based on outdated information. To prevent this, the author suggests implementing freshness checks, such as a maximum data age threshold. If the time since the last market update exceeds this threshold, the bot should stop trading until it can obtain fresh data.

Another critical aspect is determining whether an order has been executed successfully. When a bot submits an order, it may not receive a response from the exchange, leaving the bot uncertain about the order's status. The bot should treat the result as unknown and query the exchange to determine the order's status. This is especially important when considering the order's lifecycle, which can include various states such as CREATED, SUBMITTED, ACCEPTED, PARTIALLY_FILLED, FILLED, REJECTED, CANCELLED, or UNKNOWN.

An incomplete or incorrect local state can lead to significant issues, such as operating on outdated information, duplicate orders, or discrepancies between local and exchange states.

The author stresses that local state is not reality; it is only the application's current understanding of the actual market state. This local state can become incorrect due to missed events, network failures, application restarts, or local state inconsistencies. To mitigate these risks, reconciliation is crucial. Reconciliation involves comparing the local state with the actual state from the exchange and updating the local state accordingly.

This process ensures that the bot's decisions are based on accurate information, preventing potential losses or unintended trades.

In conclusion, building a successful trading bot involves more than just creating a sophisticated trading strategy. It requires a deep understanding of the entire system, including market data handling, validation, risk management, execution, and reconciliation. By acknowledging and addressing these challenges, developers can create more resilient and reliable trading bots that operate accurately and safely in the dynamic world of cryptocurrency trading.