Development of HFT Algorithm (High-Frequency Trading)
High-Frequency Trading in crypto is not the same as HFT in traditional markets. There is no co-location next to the exchange's matching engine, no direct FIX connections with microsecond latency. But the principles remain: execution speed, high transaction volume, position holding from milliseconds to minutes, profit on small moves with high leverage.
HFT Strategies in Crypto
Latency arbitrage — exploiting latency differences between market participants. If your WebSocket receives an order book update faster than other participants can react — there is a trading window.
Statistical arbitrage — trading on temporary deviations in price relationships between correlated assets. For example, BTC spot vs BTC perpetual futures.
Market making — constantly posting bid/ask orders on both sides. Profit from bid-ask spread minus inventory risk.
Order book imbalance — analyzing imbalance between bid and ask sides of the order book. Significant imbalance on one side predicts short-term price movement.
Momentum ignition — fast entry upon detecting the onset of short-term trend in tick data.
Low-Latency System Architecture
Key principle: each component is optimized for minimum latency.
Network layer:
- Co-location (VPS in the same data center as the exchange): AWS Tokyo for Binance, AWS Frankfurt for Kraken
- Direct WebSocket connection without intermediate proxies
- TCP optimization: TCP_NODELAY, increased SO_SNDBUF/SO_RCVBUF buffers
- Keep-alive connections, minimize reconnects
Language and runtime:
- C++ — maximum performance, sub-millisecond latency
- Rust — close to C++ in performance, safer
- Python + Cython/NumPy — acceptable for strategies with latency > 10ms
- Java — used in traditional HFT, less popular in crypto
Order book management:
// Incremental order book update
void OrderBook::update(Side side, Price price, Quantity qty) {
auto& book = (side == Side::Bid) ? bids_ : asks_;
if (qty == 0) {
book.erase(price);
} else {
book[price] = qty;
}
best_bid_ask_cache_dirty_ = true;
}
Full copy of order book in memory, updated via WebSocket diff stream. No REST requests in hot path.
WebSocket Stack for Low-Latency
Binance:
-
wss://stream.binance.com:9443/ws/btcusdt@depth@100ms— updates every 100ms -
wss://stream.binance.com:9443/ws/btcusdt@aggTrade— aggregated trades -
wss://stream.binance.com:9443/ws/btcusdt@bookTicker— best bid/ask in real time
Bybit:
-
wss://stream.bybit.com/v5/public/linear— perpetual orderbook (depth.1, depth.50, depth.200)
For minimum latency — subscribe to bookTicker (best bid/ask only) instead of full order book. This reduces data volume and parsing time.
Strategy: Order Book Imbalance
def calculate_imbalance(orderbook, n_levels=5):
bid_volume = sum(qty for _, qty in orderbook['bids'][:n_levels])
ask_volume = sum(qty for _, qty in orderbook['asks'][:n_levels])
total = bid_volume + ask_volume
if total == 0:
return 0
return (bid_volume - ask_volume) / total # [-1, 1]
Value > 0.3 → buying pressure, likely price increase in next few seconds. Value < -0.3 → selling pressure.
Signal is used for short-term entry with tight stop-loss (0.05–0.1% of price).
Execution and Risk Management
Order types: for HFT, limit orders (maker) and sometimes market orders (taker) are used. Limit orders save on fees (maker vs taker).
Position limits: maximum position size, maximum number of open positions, max drawdown per session.
Circuit breakers: if loss within N minutes exceeds M% — algorithm stops and requires manual intervention.
Latency monitoring: logging the time of each pipeline step — from receiving market data to sending an order. P99 latency should be below a defined threshold (e.g., 50ms).
HFT Backtesting
Backtesting HFT strategies requires tick data (or trade-aggregated data), not OHLCV. Simulate order book on historical data, account for latency, slippage, and fees.
Overfitting problem: HFT strategies are particularly prone to overfitting. Walk-forward analysis and out-of-sample testing are mandatory.
Backtesting infrastructure: nautilus_trader (Python/Rust) or backtrader for less demanding strategies. Tick data is stored in Parquet formats, ClickHouse for fast aggregations.
What We Develop
A low-latency system for HFT crypto strategies: WebSocket client with incremental order book update, selected strategies (OBI, statistical arb, market making), backtesting on tick data, risk management with circuit breakers, real-time latency and performance monitoring.