
Deribit’s by Coinbase new matching engine marks a major upgrade to the exchange’s core trading infrastructure. It is built to handle high order volumes with lower and, just as importantly, more predictable latency.
The measured results are significant. Comparing six days before the rollout with six days after large-scale adoption (during which over 90% of order entry messages flowed through the new system):
| Latency metric | Classic API (pre) | Starbase (post) | Improvement |
|---|---|---|---|
| Median (p50) | 4.7 ms | 76 µs | ∼61× lower |
| p90 | 26.4 ms | 106 µs | ∼249× lower |
| p99 | 124 ms | 234 µs | ∼531× lower |
(A microsecond, µs, is a thousandth of a millisecond.)

The biggest gains came in the slowest responses. Before go-live, P99 latency was roughly 26× the median and swung from ∼80 ms in quiet hours to ∼600 ms at busy moments. After go-live, P99 is only about 3× the median and stays within a stable 180–420 µs band.
Latency percentiles
Latency is often reduced to a single number, but an average only shows the typical experience, not what happens when the exchange is under pressure;
- Median (P50): the typical request-response time. Half of requests are faster, half are slower.
- P90: the time within which 90% of requests complete.
- P99: the time within which 99% of requests complete, highlighting the slowest 1%.
For market makers and automated trading firms, these slower responses matter most. A delayed response can leave a quote active longer than intended or cause a system to act on outdated market data. By reducing these tail latencies, the new matching engine makes order handling more consistent, especially during high activity.
What changed
The new matching engine is designed for determinism and low latency. Order entry and market data now run on dedicated paths with fewer processing steps. Risk checks that used to sit on the critical path have been restructured where possible.
The Classic API remains fully supported. The new system trades breadth of functionality for speed and predictability.
The migration was completed incrementally while the Classic stack remained fully operational, allowing participants to move to the new order entry gateways at their own pace.
Performance under load
We analyzed the two heaviest days of the post window, 24 and 25 August, when the matching engine processed 1.02 billion events. Median latency rises just 10% from the quietest to the busiest conditions. Congestion shows up only in the tail.
The busiest single second, 25 August at 02:41:28 UTC, saw 23,836 requests. One 4.5 millisecond window alone contained 691 requests. Median latency rose to 609 µs against a 79 µs baseline, with the worst round trip just under 0.8 milliseconds. The backlog cleared within 2 milliseconds.
To rephrase: the largest spikes are now handled within the same timeframe that used to handle a single order.
What this means for Deribit users
For traders using the website or mobile app, no action is required. The upgrade improves the underlying trading environment without changing the user experience. When a new market microstructure is fully formed, these traders can expect tighter and deeper liquidity to trade against.
For brokers, technology providers, and firms operating at millisecond-level latency, Classic API connectivity remains available over the internet.
For institutional market makers and latency-sensitive participants, the new binary interfaces offer a direct, lower-overhead path to order entry and market data.
The main benefit is not simply speed. It is consistency: fewer extreme delays, stable performance under load, and a more predictable environment for automated trading strategies. More predictability allows the market to become more liquid by reducing execution uncertainty, helping participants manage adverse-selection risk, and improving hedging conditions.
Beyond the immediate latency improvements, the new matching engine gives Deribit the headroom to grow. With throughput no longer constrained by the bottlenecks of the previous system, we can list more products across more underlyings and instrument types without degrading performance for existing participants.
This scalability also supports features that were previously impractical at scale, such as broader cross-collateral adoption, which had limited uptake due to latency concerns.
Read the full technical paper
The peer-reviewed technical paper provides the complete methodology, measurement infrastructure, load analysis, microburst case study, and discussion of implications.
Technical resources
API documentation: docs.deribit.com/starbase
For technical integration questions: [email protected]
Disclaimer
Deribit FZE is regulated by the Virtual Assets Regulatory Authority. This material is for educational purposes only.
AUTHOR(S)
