Binance and Bybit Hedge Router
A multi-exchange execution service using WebSocket position truth, reduce-only safeguards, rate-limit handling, and client order IDs.
Problem and business goal
- Problem
- Manual hedging during funding windows created drift, missed fills, and unclear exposure after partial executions.
- Business goal
- Reduce manual hedge lag between Binance USDT-M futures and Bybit perpetual positions.
Architecture
- Strategy event
- Risk checks
- REST order router
- WebSocket fills
- Position reconciliation
- Incident alerts
Technology stack
- Python
- CCXT
- Binance API
- Bybit API
- WebSockets
- PostgreSQL
Development challenges
- Exchange precision rules differ by symbol and venue.
- REST success does not mean the target position is fully filled.
- Rate limits and disconnects can leave exposure unmanaged without reconciliation.
Implementation
- Built venue adapters that normalize symbols, quantity precision, and order flags.
- Added reduce-only and max-exposure checks before routing hedge orders.
- Stored client order IDs and compared intended exposure with live WebSocket position updates.
Results
- Exposure drift was easier to detect and correct.
- Partial fills no longer created silent mismatches between intended and actual position.
- Operations team received actionable alerts instead of raw API errors.
Lessons learned
- A serious exchange bot needs both REST execution and WebSocket truth.
- Client order IDs are essential for support, reconciliation, and incident review.
Frequently asked questions
Can this architecture work for KuCoin or MEXC?
Yes, with exchange-specific adapters. CCXT helps normalize common behavior, but native API differences still need testing.
Is this high-frequency trading?
No. This is production API execution and hedging. True HFT requires a different infrastructure budget and latency model.