Module client 

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)	10k LRU	REST after reconnect	REST after reconnect	30s	cancelled
alpaca	Auto (1s→30s backoff)	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	10k LRU, fills only	Venue snapshot on resubscribe	REST after reconnect	SDK-managed	cancelled

“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

ClientInstrument

An instrument an ExecutionClient is about to be built to trade, as ExecutionClient::validate_config sees it.

Traits

BorrowCapacityClient

Extension trait for clients that can say how much more this account can borrow.

BracketOrderClient

Extension trait for exchanges that support native bracket orders.

ExecutionClient

OrderStatusClient

Extension trait for clients that can say how an order ended at the venue.

ShortabilityClient

Extension trait for clients that can say what the venue would lend for a short sale.