Connect to every major crypto exchange through a single, normalized interface. Market data, account management, and trading — all abstracted behind a clean protocol layer.
Each exchange implements a standardized
exchangeProtocol_s struct. Adding a new exchange means implementing one header — the rest
of the framework doesn't change.
| Exchange | Market Data | Trading | Account | Fee Note |
|---|---|---|---|---|
| Binance | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Bybit | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| OKX | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Bitfinex | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Poloniex | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Kraken | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Bitstamp | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Bitget | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Hyperliquid | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Paradex | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Aster | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Lighter | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Phemex | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
| Interactive Brokers | Trades, BBO, Book | Market, Limit | ✅ | Standard maker/taker |
Each exchange publishes market data via WebSocket streams. ttTrader normalizes every exchange's format into a unified structure before your algo ever sees it.
Normalized fields: decPrice, decSize,
decSizeCvd (cumulative volume delta), fTakerIsSell,
dtTimestamp. Circular buffer stores the last 16,384 trades per instrument.
CVD is computed automatically from taker direction — no exchange-specific logic needed.
Best bid/ask with integrated spread tracking. 16,384-entry circular buffer per instrument.
Access the latest via marketdataInfo.bbo.back(). The getMid()
and spread history methods are built in — compute VWAP, micro-price, or spread percentiles on
the fly.
Up to 20 levels per side with singlePriceSize_s (price + aggregated size).
The book snapshot carries ui64UpdateId and ui64Sequence for
ordering guarantees. Book pressure and imbalance calculations are first-class.
exchangeProtocol_s — a struct with static methods for
identity, capabilities, and message building. The protocol declares what data formats it uses
(ce_fUsesBinaryData), whether book updates include BBO
(ce_fBookUpdatesBbo),
and provides factory methods for subscription messages, order creation, and order cancellation.
This design makes adding a new exchange a matter of implementing one well-defined interface.
Beyond market data, ttTrader manages the full account and trading lifecycle for each exchange.
The exchgManagerAccountT template manages per-exchange account state.
It handles WebSocket authentication, balance subscriptions, and asset tracking.
Each exchange protocol implements buildAccountSubscribe() /
buildAccountUnsubscribe() and a graceful canExitAccount() check.
Asset balances flow through the event system as assetBalanceInfo_s structs.
Your algo receives updates via onAssetUpdate() — monitor equity, available
margin, and unrealized P&L across all connected exchanges.
The exchgManagerTradingT template orchestrates order lifecycle per exchange.
It translates framework order objects into exchange-specific wire formats via
buildOrderCreate() and buildOrderCancel().
Orders flow through a state machine tracked in orderStateInfo_s:
EOPS_ALGO_CREATE → EOPS_MANAGER_CREATE →
EOPS_EXCHG_CREATE.
Location tracking confirms exchange acknowledgment. Error states provide detailed failure
reasons
(invalid trigger, margin issues, max slippage exceeded).
Trading operations (order create, cancel, modify) are sent via the same WebSocket connection
used for market data — no separate REST round-trips. The protocol builds binary or JSON wire
messages via netBuffer_s, sent through the network subsystem with automatic
reconnection and rate-limit awareness.
Active orders can be modified: change the limit price, adjust the stop trigger, or update the size. The framework tracks each modification through the processing state machine and validates that modifications are only applied to orders in modifiable states.
Each exchange connection gets its own set of API credentials. You can run the same exchange with multiple accounts simultaneously — each with independent key pairs, rate limits, and connection state.
The exchange subsystem tracks rate limits per connection. Before sending an order, the framework verifies that the rate limit budget is available — preventing 429 errors and potential account restrictions.
If a WebSocket connection drops, the exchange manager automatically reconnects with configurable backoff. Market data subscriptions and account authentication are re-established transparently — your algo doesn't need to handle reconnection logic.
ttTrader supports the full spectrum of crypto derivative instruments. Each instrument type carries type-specific metadata and constraints.
EIT_FUTURE_PERPETUAL — the most liquid crypto derivative.
Funding rate tracking, leverage up to exchange maximum (typically 50–125×).
Both linear (USDT-margined) and inverse (coin-margined) variants.
EIT_FUTURE — quarterly and monthly expiries.
EIT_FUTURE_VANILLA and EIT_FUTURE_CROSS for
exotic expiry types. Settlement date tracking built into instrument metadata.
EIT_SPOT — standard spot trading pairs.
No leverage, no funding rates. Available on all exchanges.
Used for basis trading and spot-futures arbitrage strategies.
EIT_OPTION_VANILLA — call and put options.
Strike price, expiry timestamp, and option right (EIOR_CALL /
EIOR_PUT)
embedded in instrument metadata. Greeks can be computed from book data.
Every instrument exposes instrumentMinMaxStepInfo_s for price
(mmsPrice), size (mmsSize), and leverage
(mmsLeverage). The makePrice(), makeSize(),
and isValid() methods ensure every order is exchange-compliant.
runtimeInfo.decFeeMaker and decFeeTaker are populated from
exchange data. decContractSize for calculating notional value.
isDerivate() helper to distinguish spot from derivatives at runtime.
ttTrader includes a built-in WebSocket server that streams real-time trading data to any connected frontend — browser dashboard, mobile app, or external monitoring system.
managerWebSocket_c module runs an internal WebSocket server. On connection,
it sends a full state snapshot (exchanges, instruments, orders, positions,
assets, algos, trades, BBO). Thereafter, it pushes incremental updates
on a configurable timer interval — trades, BBO changes, order state transitions, fills,
exchange status, asset balance changes, and playback/recording progress.
| Message Section | Content |
|---|---|
"snap" |
Full state snapshot (on connect) |
"exchg" |
Exchange status updates |
"instr" |
Instrument metadata & state |
"order" |
Order lifecycle events (JSON) |
"fills" |
Execution/fill notifications |
"pb" |
Playback state & recording progress |
The WebSocket protocol is bidirectional. A dashboard can send JSON commands:
| Command | Action |
|---|---|
{"t":"pb","action":"load","id":...} |
Load a playback file |
{"t":"pb","action":"play"} |
Start/resume playback |
{"t":"pb","action":"pause"} |
Pause playback |
{"t":"pb","action":"seek","position":...} |
Jump to position |
{"t":"pb","action":"setSpeed","speed":...} |
Adjust replay speed |
{"t":"rec","action":"start"} |
Start market data recording |
{"t":"rec","action":"stop"} |
Stop recording |
The WebSocket API enables a rich monitoring dashboard with zero additional server infrastructure: