Expand description
Execution client implementations for various exchanges.
§Connector Comparison
| Connector | Reconnect | Dedup | Fill Recovery | Ended-order Recovery | Heartbeat | Cancel answers once |
|---|---|---|---|---|---|---|
binance | Auto (1s→30s backoff, 10 tries) | 10k LRU | REST after reconnect | REST after reconnect | 30s | cancelled |
alpaca | Auto (1s→30s backoff, 10 tries) | 2k LRU | REST after reconnect | REST after reconnect | 35s | accepted |
ibkr | ibapi-managed | 10k LRU, fills only | Executions request after reconnect | None | N/A | submitted |
hyperliquid | SDK-managed (every 1s, no limit) | 10k LRU, fills only | Venue snapshot on resubscribe | REST after reconnect | SDK-managed | cancelled |
“Reconnect” is how the account stream comes back after its connection drops, and when it gives
up: Binance and Alpaca end the stream once 10 reconnects in a row have failed (see
binance and
AlpacaClient’s account_stream).
“Ended-order Recovery” is whether a reconnect reports how an order the client held as live
ended while the stream was down, and only those clients implement OrderStatusClient. 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. That snapshot
is the only fill recovery: it holds recent fills, how many Hyperliquid does not say, so callers
needing older ones call ExecutionClient::fetch_trades, whose results are not deduplicated
against the stream. Once the snapshot has been sent on, a reconnect checks how the orders the
client holds as live ended, like Binance’s and Alpaca’s.
§Known Limitations
Only Binance (Spot and Margin), Alpaca and Hyperliquid (perpetuals and spot) recover the order
lifecycle events (cancelled, expired, rejected, a fill that completes an order) they missed
while disconnected, and only for the orders the client holds as live; IBKR recovers fills only
(#370). OrderStatusClient is the lookup that recovery is built on: given the orders a caller
still holds as live, it says how each that has ended did end. Binance Spot, Binance Margin,
Alpaca, both Hyperliquid clients and the mock client implement it.
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
Structs§
- Client
Instrument - An instrument an
ExecutionClientis about to be built to trade, asExecutionClient::validate_configsees it.
Traits§
- Borrow
Capacity Client - Extension trait for clients that can say how much more this account can borrow.
- Bracket
Order Client - Extension trait for exchanges that support native bracket orders.
- Execution
Client - Order
Status Client - Extension trait for clients that can say how an order ended at the venue.
- Shortability
Client - Extension trait for clients that can say what the venue would lend for a short sale.