CCXT vs the Mode Trade API

Mode Trade is the perpetuals exchange on the Mode Ethereum L2. It does not publish a client library under its own name. It is a broker front end on Orderly Network's shared EVM orderbook — the API host CCXT's modetrade class talks to is api-evm.orderly.org, and Orderly's launch announcement describes Mode Trade as built on Orderly's infrastructure, with over 100 pairs and up to 50x leverage.

So the realistic alternative to CCXT is not a Mode SDK. It is Orderly's own connectors: orderly-evm-connector-python (MIT, on PyPI as orderly-evm-connector) and Orderly's TypeScript SDKs. The question is: do you want Orderly's API shapes, or Mode Trade behind the same interface as every other venue you trade?

TL;DR

• Pick Orderly's connector if you are building against the Orderly stack itself, in Python or TypeScript, and want method and field names that match Orderly's reference one-for-one.
• Pick CCXT if you want Mode Trade as one venue among many: 56 unified capabilities, 10 watch* streaming methods, and the same code in TypeScript, JavaScript, Python, PHP, C#/.NET, Go or Java.
• Both sign the same way. Orderly authenticates with an ed25519 key pair (orderly-key, orderly-secret, orderly-account-id), and CCXT implements that signing internally — the choice is about API shape and portability, not cryptography.

At a glance

_{Figures verified September 2026 against CCXT v4.5.77, the OrderlyNetwork GitHub organisation's repository listing and READMEs, and the orderly-evm-connector PyPI record (v0.2.9, published June 2026).}

The same job, written both ways

Fetch a funding rate

import ccxt

exchange = ccxt.modetrade()
rate = exchange.fetch_funding_rate('BTC/USDC:USDC')
print(rate['fundingRate'], rate['fundingTimestamp'])

CCXT returns a unified funding rate structure — the same keys, types and units you get from Binance or Bybit, so a cross-venue funding monitor does not need a Mode-shaped branch. The connector returns Orderly's payload, keyed by PERP_BTC_USDC, which you map yourself.

One gap worth naming up front: modetrade declares fetchTicker: false and fetchTickers: false in CCXT. Last price and 24h stats come from fetch_ohlcv, from the order book, or over the socket with watch_ticker — which is implemented.

Place a limit order

import ccxt

exchange = ccxt.modetrade({
    'apiKey': 'ed25519:...',      # orderly key
    'secret': 'ed25519:...',      # orderly secret
    'accountId': '0x...',
})
order = exchange.create_order('BTC/USDC:USDC', 'limit', 'buy', 0.001, 60000)
print(order['id'], order['status'])

The credentials are identical because the signing is identical: CCXT builds the same orderly-account-id / orderly-key / orderly-timestamp / orderly-signature headers, signing timestamp + method + path + body with ed25519 over a base58-decoded secret. What differs is everything above that line — the order object CCXT hands back is a unified order structure, and create_order takes the same five arguments on Bybit, OKX or Kraken.

Trigger, stop-loss, take-profit and reduce-only orders go through unified params rather than separate call shapes:

order = exchange.create_order(
    'BTC/USDC:USDC', 'limit', 'buy', 0.001, 60000,
    {'takeProfitPrice': 66000, 'stopLossPrice': 57000})

Stream an order book

import ccxt.pro
import asyncio

async def main():
    exchange = ccxt.pro.modetrade()
    while True:
        orderbook = await exchange.watch_order_book('BTC/USDC:USDC')
        print(orderbook['bids'][0], orderbook['asks'][0])

asyncio.run(main())

Two different programming models. CCXT is pull-shaped — you await a method and get a value, so the streaming code reads like the REST code next to it. The connector is push-shaped: you register on_message / on_close callbacks and hand control to the client.

The connector does handle reconnection (its README documents up to 30 retries at 5-second intervals, with resubscription after reconnect). What it does not do is assemble an order book for you: it exposes request_orderbook, get_orderbook and get_orderbookupdate as separate subscriptions, and aligning the snapshot with the delta stream is your code. watch_order_book returns a live, merged book with that alignment, gap detection and bounded caching already done — and it returns the same order book structure as fetch_order_book.

CCXT implements 10 streaming methods for modetrade: watchOrderBook, watchTrades, watchOHLCV, watchTicker, watchTickers, watchBidsAsks, watchBalance, watchOrders, watchMyTrades and watchPositions.

Where the differences actually bite

Seven languages, one API

CCXT is written once in TypeScript and transpiled to JavaScript, Python, PHP, C#/.NET, Go and Java, with identical method names and return structures in every one. Orderly publishes Python and TypeScript; if your execution service is in Go, C# or Java, CCXT is the option that exists.

import ccxt
exchange = ccxt.modetrade()
orderbook = exchange.fetch_order_book('BTC/USDC:USDC')

Rate limits you do not have to model

CCXT ships a token-bucket throttler that is on by default (enableRateLimit = true, rateLimit = 100 ms for modetrade), with per-endpoint weights encoded in the exchange definition. Orderly's connector documents no throttler — pacing and back-off on a 429 are your code.

One error hierarchy

CCXT maps Orderly's error codes onto a typed exception tree — InsufficientFunds, InvalidOrder, OrderNotFound, RateLimitExceeded, AuthenticationError, NetworkError, ExchangeNotAvailable and 34 more, all descending from BaseError. The connector raises ClientError for 4XX and ServerError for 5XX, with the venue's numeric code as a property you match on yourself.

Precision, rounding and string math

load_markets() pulls Mode Trade's tick and step sizes, and CCXT exposes them through amount_to_precision, price_to_precision and cost_to_precision, backed by the Precise string-arithmetic class so quantities never drift through float rounding into a rejected order.

amount = exchange.amount_to_precision('BTC/USDC:USDC', 0.0012345678)
price = exchange.price_to_precision('BTC/USDC:USDC', 61234.56789)

Nothing is hidden — the implicit API

Alongside the 56 unified capabilities, all 115 endpoints in the API definition are generated as callable implicit methods, with signing, rate-limit accounting and error mapping applied:

# any raw endpoint, camelCased from its path
response = exchange.v1_private_get_client_holding()

Browse them on the modetrade implicit API page.

Testnet without a second code path

exchange = ccxt.modetrade({'apiKey': '...', 'secret': '...', 'accountId': '0x...'})
exchange.set_sandbox_mode(True)   # swaps in the testnet REST and WebSocket URLs

What Orderly's connectors do better

An honest list:

• They are first-party to the API. Orderly writes the API and the connector. A new Orderly endpoint appears in their own client before it is modelled as a unified CCXT method (CCXT's implicit API usually closes the gap on day one, but a unified wrapper can lag).
• Field names match the Orderly reference exactly. PERP_BTC_USDC, order_quantity, order_price — when you are debugging with the vendor docs open, a one-to-one mapping is one less hop than CCXT's deliberate abstraction.
• Smaller dependency for a single venue. If all you do is call the Orderly EVM API from Python, orderly-evm-connector is a much smaller install than a library covering 104 exchanges.
• The TypeScript SDKs cover more than trading. Orderly's js-sdk includes wallet integration and React building blocks for a front end — territory CCXT does not enter at all.
• Ticker-shaped market data. The connector's get_futures_info_for_one_market() and get_futures_info_for_all_markets() return last price and 24h stats directly. CCXT declares fetchTicker: false for modetrade, so on the REST side you assemble that from fetch_ohlcv or the order book.
• Orderly-specific concepts stay explicit. Broker ids, account-id derivation and on-chain deposit flows are surfaced directly by the Orderly stack; CCXT abstracts what it can and leaves the rest to the implicit API.

If you are building on Orderly itself — a broker, a front end, or a service pinned to one venue — Orderly's own connectors are the more direct route.

Migrating from Orderly's connector to CCXT

Start with Install, then the Manual, then the modetrade unified API reference.

FAQ

Does Mode Trade have its own API SDK? Not under its own name. Mode Trade runs on Orderly Network's EVM orderbook, and the client libraries for that API are published by Orderly: orderly-evm-connector-python for Python and js-sdk / orderly-sdk-js for TypeScript. CCXT's modetrade class talks to the same host, api-evm.orderly.org.

Does CCXT support Mode Trade WebSockets? Yes — 10 watch* methods, covering order book, trades, OHLCV, tickers, bids/asks, balance, orders, positions and own trades. Use ccxt.pro.modetrade and await exchange.watch_order_book('BTC/USDC:USDC').

What credentials does CCXT need for Mode Trade? An Orderly ed25519 key and secret plus an account id: ccxt.modetrade({'apiKey': 'ed25519:...', 'secret': 'ed25519:...', 'accountId': '0x...'}). CCXT accepts the keys with or without the ed25519: prefix and does the signing for you.

Can I test against a testnet? Yes. exchange.set_sandbox_mode(True) swaps in the testnet REST and WebSocket URLs in one call, with no second code path.

Do I need CCXT Pro separately for WebSockets? No. CCXT Pro is included in the ccxt package. Use ccxt.pro.modetrade and call watch* methods.

Is CCXT free? Yes. MIT-licensed, including the WebSocket support.

Next steps

• Install CCXT in your language
• Manual — the unified API, structures and conventions
• modetrade unified API reference
• modetrade implicit API — every raw endpoint
• CCXT Pro manual — WebSocket methods
• More comparisons