Expand description
Execution client implementations for various exchanges.
§Connector Comparison
| Connector | Reconnect | Dedup | Fill Recovery | Heartbeat | Cancel answers once |
|---|---|---|---|---|---|
binance | Auto (1s→30s backoff) | 10k LRU | REST after reconnect | 30s | cancelled |
alpaca | Auto (1s→30s backoff) | 2k LRU | REST after reconnect | 35s | accepted |
ibkr | ibapi-managed | 10k LRU, fills only | Executions request after reconnect | N/A | submitted |
hyperliquid | SDK-managed | 10k LRU, fills only | Caller responsibility | SDK-managed | cancelled |
The last column is when ExecutionClient::cancel_order answers Ok. Only for “cancelled” has
the order ended by then; see that method.
§Resilience Philosophy
WebSocket-based connectors (Binance, Alpaca) implement auto-reconnection with fill recovery and deduplication. After reconnect, they query REST APIs for missed fills and deduplicate against the LRU cache to prevent duplicate processing.
IBKR uses TCP to local TWS/Gateway. ibapi reconnects that socket itself; the
account stream stays open across it and recovers the missed fills from TWS’s executions,
deduplicating against the LRU cache. Replacing a client that is gone for good requires IB
Gateway availability and client ID coordination — decisions that belong in the caller’s
wrapper. See ibkr module docs for caller responsibilities.
Hyperliquid delegates reconnection to the official SDK’s with_reconnect() mechanism, but
deduplicates fills itself: the SDK resubscribes on reconnect and the venue opens a userFills
subscription with a snapshot, so every reconnect redelivers fills already seen. It does not
recover fills missed while disconnected — callers needing that call
ExecutionClient::fetch_trades, whose results are not deduplicated against the stream.
§Known Limitations
No connector recovers the order lifecycle events (NEW, CANCELED, EXPIRED) it missed while disconnected; only fills are recovered (#370).
The engine closes part of that gap from the account snapshot each reconnect produces: an order a
complete list no longer shows is retired (see ExecutionClient::account_snapshot). That covers
the connectors whose snapshot declares its orders complete — Binance Spot and Margin,
Hyperliquid, Alpaca, and the mock venue — but not IBKR (#371), and it cannot tell how an order
ended. A caller that needs more reconciles against
ExecutionClient::fetch_open_orders after a reconnect.
Modules§
- alpaca
- binance
- Binance execution clients.
- hyperliquid
- Hyperliquid ExecutionClient implementations for perpetual futures and spot trading.
- ibkr
- Interactive Brokers ExecutionClient implementation.
- mock
Traits§
- Bracket
Order Client - Extension trait for exchanges that support native bracket orders.
- Execution
Client