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 a broad range of instrument types. Each type carries type-specific metadata and constraints, and the instrument framework is data-driven — new asset classes are a localized extension, not a rewrite. Types marked on request are not built in yet but can be added on demand.
Standard spot trading pairs. No leverage, no funding rates. Available on all exchanges. Used for basis trading and spot-futures arbitrage strategies.
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.
Quarterly and monthly expiries, plus vanilla and cross exotic expiry types. Settlement date tracking built into instrument metadata.
Coin-margined futures settled in the underlying. Margin and P&L are denominated in the base currency rather than a stablecoin.
Call and put options. Strike price, expiry timestamp, and option right (call / put) embedded in instrument metadata. Greeks can be computed from book data.
Reference/index instruments (e.g. spot-composite underlyings for perpetual mark/index pricing). Non-tradable; used as a data source for pricing and P&L.
Equities trade like any other instrument — symbol mapping, lot sizes, and trading-hours metadata are handled by the same normalized pipeline. Supported out of the box.
FX pairs are supported — pip-precision sizing and base/quote handling run through the same normalized market-data and order pipeline as every other instrument type.
Fixed income and ETFs are not built in yet. They can be added with type-specific metadata (coupon, maturity, NAV). Reach out and we extend the model to your asset class.
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.
Beyond the basics, here is exactly what ttTrader provides today across order-book depth, perpetual instruments, and multi-exchange inventory — and where the exchange feed is the limiting factor.
On subscription the framework receives a full L2 snapshot (up to 20 levels per
side, aggregated singlePriceSize_s). It then applies
L2 incremental updates to the local book — no full re-snapshot on every tick.
Each book carries ui64UpdateId and ui64Sequence for ordering.
The sequence counter is tracked per instrument. On a detected gap or mismatch the framework re-syncs by requesting a fresh snapshot — so the local book stays consistent even if a WebSocket frame is dropped.
The normalized book is aggregated by price level (price + size), not order-by-order. True L3 (individual order IDs and sizes at each level) is available on request — it can be added where an exchange exposes the raw order stream, at the cost of higher memory and processing overhead.
Book pressure and imbalance are first-class. With the snapshot + incremental model you can compute depth, spread percentiles, and micro-price on the fly for quoting decisions.
For EIT_FUTURE_PERPETUAL instruments the following fields are surfaced
where the exchange provides the feed — ttTrader normalizes and exposes them, but
availability depends on the individual exchange's API.
| Perp Field | Status | Notes |
|---|---|---|
| Funding Rate | Supported | Funding rate tracking built into the perpetual instrument model. |
| Mark Price | If provided | Exposed when the exchange streams a mark price feed. |
| Index Price | If provided | Exposed when the exchange streams an index/spot composite feed. |
| Liquidation Feeds | If provided | Available as a market-data stream where the exchange publishes forced-liquidation events. |
| Leverage / Margin | Supported | Up to exchange maximum (typically 50–125×). Set via setLeverage(); limits in
mmsLeverage. |
| Position Mode | If provided | Hedge vs. one-way netting mode exposed when the exchange reports it per account. |
The risk layer tracks positions per exchange and per instrument. It does not automatically merge the same symbol across different venues into a single net position — but the architecture gives you several clean ways to build that yourself:
onAssetUpdate() / position callbacks and maintains the net view in your own state:
BTC-PERP Binance: +1.2 BTCBTC-PERP OKX: -0.8 BTCBTC-PERP Lighter: +0.3 BTCNet: +0.7 BTC
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: