190,000-200,000 transactions per second, measured not marketed
Every number on this page is a real, reproducible measurement against a live, running system — not a projection. We'd rather publish a smaller number we can stand behind than a bigger one we can't.
Verified throughput, with room to grow
Built for headroom, not just a peak
At today's throughput ceiling, the matching engine is comfortably below full utilization — the limit is how conservatively we choose to guarantee durability, not raw processing power. That's a deliberate trade-off: a recent tuning pass alone lifted throughput nearly 3× with no change to that guarantee and no code rewritten, which tells you there's real, unclaimed headroom left before this platform would ever need to scale out.
We haven't published a latency benchmark yet, and we're not going to publish a number we haven't actually run. Ask us for the current state of that work if latency is your binding constraint.
How we measure it
Reference hardware
A real, production-grade server — not a projection. We'll always tell you what hardware a number came from, since throughput claims without that context aren't worth much.
Workload profile
Realistic simulated order flow — a mix of new orders, cancels and crossing trades, pushed until achieved throughput stops responding to more load.
How throughput is counted
Directly, from the engine's own confirmed order count after each run — the same mechanism it uses to recover after a real crash, not separate, unverified instrumentation.
Your workload may differ
Throughput depends on instrument count, trade-fill rate, and message size. We'll benchmark against your own flow profile on our reference hardware on request.