Built for your desk.
Pick your desk. Each path shows how Chronix is deployed, what changed, and the numbers behind it.
Share infrastructure. Separate client controls.
Manage multiple clients, accounts and venues through one operational system, with risk, limits and account state kept separate for each client.
- Client problem
- Smaller clients couldn't individually generate enough volume to keep favorable exchange conditions — lower rate limits, higher trading fees.
- What Chronix did
- Aggregate 100+ client trading flows through shared infrastructure while each client's risk, positions and attribution stay separate.
saved in trading fees per month
higher order rate limit
clients on best market conditions
Everything above, in full: the prime brokers page →
Every use case above runs on the same Chronix engine. Here's how it's built, module by module.
Five roles. One engine.
Every desk role plugs into the same core through its own surface. Pick one and follow its path from people to venues.
Risk on the same path. Before the exchange.
Every order clears your limits before it leaves for the venue. Breach one and it never arrives. An alert fires before you even reach a soft limit.
Pre-trade gate
Every order clears your limits before it leaves for the venue. Breach one and it never arrives, and an alert fires before you even reach a soft limit.
Backtest is live. The same code.
One code path in research and in production. Historical market data, real fills, your live engine. What you test is what you trade.
Don't take the four cards above on faith.
One evening of our own trading, recorded in full and replayed through the simulator. The files are below, the console queries them in your browser, and the same check is on offer for your fills.
Traded live
A deliberately simple market-making strategy on Bybit USDT perpetuals, five contracts, orders of about $50, one evening on our own account. No signal, no hedge — nothing clever, so only the simulator is under test.
Recorded everything
Every best bid/ask update, book change and public trade, with exchange timestamps, by an independent recorder. Every placement, amend, cancel, ack and fill of ours. Market-data and ack latency, measured that evening.
Replayed and matched
Our order stream fed to the simulator at its recorded times, against that tape. The simulator alone decides what fills. Live and simulated fills matched one-to-one: same side, within 60 s, within 2 ticks.
-- overview
match rule: same side, |dt| ≤ 60 s, |dprice| ≤ 2 ticks, one-to-one nearest in time
→ same query, your fillsYour fills. Same check.
Send a month of your order log — placements, cancels, fills. We replay it against our tape and hand you this console for your own data: every fill paired, every miss named.
no strategy code needed · order log only · bybit perps on our tape, other venues on request
Double-digit µs in the engine.
We won't pretend a round trip to the exchange is microseconds; that leg is physics. The part we own, we make fast: strategy to the wire in 15–20 µs, and we colocate so the hop to the venue stays sub-millisecond. A generic stack loses an order of magnitude at both.
Your strategy to low-latency connectivity in ~15–20 µs.
Colocated link to the venue: sub-millisecond, not milliseconds.
The exchange round trip is physics. We don't call it microseconds.
One engine. Three ways in.
The same low-latency core runs behind a strategy SDK, your own stack, or the terminal. The terminal is one surface on the engine, not the engine itself.
Strategy SDK
your algosCode against the engine
Write your strategy in Rust, C/C++ or Python. The same compiled binary runs in backtest and live, so research never drifts from production.
use chronix::prelude::*;#[strategy] // your alpha, one structimpl Momentum {fn on_tick(&mut self, book: &Book) {let edge = self.signal(book);if edge > self.threshold {self.buy(book.best_ask, self.size) // routed through risk.post_only().submit();}}}let engine = Chronix::connect(); // Rust · C/C++ · Pythonengine.strategy(Momentum::default()).backtest(jan..jun) // same compiled binary.go_live(); // unchanged, in prod▋
Headless
your stackThe engine, no UI
Run the core behind your own front end and infrastructure. Market data, orders and risk are all driven over a typed API. Everything the terminal does, headless.
POST /sessions // auth, a typed clientGET /md/stream?symbols=BTC,ETH // normalized book, 12 venues← bbo · depth · trades, one schemaPOST /orders // execution + risk, one path{ side, qty, type: "post_only" }← 202 staged, risk ok, liveGET /positions // cross-venue state, real-timeWS /fills // streaming fills + acks▋
Terminal & UI
desk · agent · adminThe full trading desk
Dual-venue DOM ladders, multi-symbol charts, blotter, positions and balances on one screen. The terminal is the engine with a face, not a separate app talking to it.
Or just tell the agent
Ask in plain language and the agent reads the live terminal state through typed tools, then builds widgets, formulas or layouts against it. Staged, approved, audited. AI that never trades unwatched.
And the admin panel
Start, stop or archive a strategy; pause, resume, hedge or unwind from one bar. Limits, spreads, formulas: every parameter is live-editable and submitted under audit.
