Starbase is Deribit’s high-performance matching engine offering a new set of APIs targeted at clients who are market making or deploying high-frequency strategies. These APIs provide lower latency access to the matching engine with new connectivity options, networking requirements, and protocols. Deribit and Starbase are colocated in LD4.
Existing Deribit APIs are unaffected. Standard WebSocket and REST APIs continue to work for all instruments, but will not offer the same latency as the Starbase-native APIs.
To have your Test account enabled for Starbase, please reach out to your Account Manager or Technical Account Manager.
Getting Started
Starbase API Key
Starbase uses a separate API key from your standard Deribit API key. See Creating a Starbase API Key for setup instructions.
Available APIs
| API | Purpose |
|---|
| SBE — Order Entry | Place, amend, and cancel orders via the binary protocol |
| SBE — Market Data | Low-latency L3 multicast market data feeds |
| SBE — Retransmit | Request retransmission of missed market data packets |
| FIX Drop Copy | Consolidated account-wide order and trade feed |
| REST | Utility endpoints (order snapshot, purge, reference data) |
Gateway Architecture
Starbase uses a distributed gateway architecture designed for high availability and horizontal scaling:
- Gateways run in hot-hot A/B pairs — both gateways in a pair are fully active at all times; neither is a standby.
- Each gateway pair provides access to a specific set of order books.
- Order books for the same underlying asset are always on the same gateway pair, ensuring atomicity of MMP and implied matching.
Rule 1 — Connection Limits per API Key
| Rule | Detail |
|---|
| One connection per gateway per API key | Each API key can establish exactly one connection to each gateway instance |
| Multi-gateway connections allowed | The same API key can connect to all gateway pairs simultaneously |
| Duplicate connection handling | A second connection attempt with the same key to the same gateway disconnects the first |
With 4 gateway pairs, a single API key can establish up to 8 simultaneous connections — one to each instance: 1A, 1B, 2A, 2B, 3A, 3B, 4A, 4B.
Rule 2 — Event Scoping
| Rule | Detail |
|---|
| Session-scoped events | An SBE connection only receives events for orders sent by that API key on that specific gateway |
| No cross-session event sharing | Orders on Gateway A with API Key X will not generate events on Gateway B or on any connection using API Key Y |
| Per-key isolation | Orders submitted with API Key A will not generate events on connections using API Key B |
This design allows multiple API keys to be assigned to a single portfolio without creating portfolio-level bottlenecks.
Rule 3 — Rate Limits
| Rule | Detail |
|---|
| Independent rate limits | Rate limits on Gateway A and B are completely independent |
| Effective combined rate | A rate limit of 100 req/s per gateway yields an effective combined rate of 200 req/s per pair |
Gateway-to-Product Mapping
Quick Reference
| Trading Focus | Order Entry Gateways | Market Data Channels |
|---|
| BTC only | 1A + 1B | BTC Perps + BTC Options (A+B) |
| ETH only | 2A + 2B | ETH Perps + ETH Options (A+B) |
| BTC + ETH | 1A + 1B + 2A + 2B | BTC + ETH channels (A+B) |
| Tier 2 Alts | 3A + 3B | Tier 2 channels (A+B) |
| Tier 3 Alts | 4A + 4B | Tier 3 channels (A+B) |
| Equity Perps | TBD | Equity Perps channel (A+B) |
| All products | All 8 gateways | All multicast channels |
Failover Scenarios
Scenario 1 — Single Gateway Failure (A or B)
| Situation | Action |
|---|
| Gateway A fails | Continue trading on Gateway B |
| Gateway B fails | Continue trading on Gateway A |
| Impact | No service interruption if connected to both |
Always connect to both A and B gateways in each pair, send orders to both for optimal latency, and implement automatic failover logic in your client.
Scenario 2 — Connection Loss & Cancel on Disconnect (CoD)
Cancel on Disconnect is always enabled on Starbase and cannot be disabled or configured.
| Behavior | Detail |
|---|
| Scope | Session-scoped — only cancels orders from the disconnected session |
| Trigger | Immediate upon connection loss |
| Impact on other sessions | Losing Gateway A does not affect orders open on Gateway B |
- TCP connection closure
- Missing heartbeats (heartbeats cannot be disabled)
- Explicit logout
Scenario 3 — Reconnection After Disconnect
| Rule | Detail |
|---|
| Orders not restored | Previously cancelled orders are not automatically restored after reconnection |
| Resubmission required | Clients must resubmit orders to re-establish their order book |
| CoD remains enabled | The new session also has CoD always enabled |
Scenario 4 — Cross-Session Amends and CoD
| Rule | Detail |
|---|
| CoD is bound to the originating session | CoD tracks whichever session originally submitted the order |
| No rebinding on amend | If an order submitted on Session A is amended from Session B, disconnecting Session A will still cancel the order — even if Session B remains connected |
Consolidated View: FIX Drop Copy
Because SBE connections are session-scoped, use FIX Drop Copy for:
- A consolidated view of all activity across a single portfolio
- Reconciliation across all gateways
- Aggregated trade feed
Best Practices Summary
Connection Management
- Connect to both A and B gateways in each pair
- Implement robust connection monitoring and automatic reconnection
- Handle
OrdersCanceled messages to maintain accurate order state
- Re-evaluate and resubmit orders after reconnection based on current market conditions
- Use graceful logout when intentionally disconnecting
Order Management
- Remember each SBE session is fully independent
- Orders submitted on one session only generate events on that session
- Avoid cross-session amends when CoD behavior is critical
- Use the same API key across gateways for a simpler audit trail
Market Data
- Subscribe to both A and B multicast feeds — they have similar latency profiles
- Subscribe to both Snapshot and Incremental channels
- Implement full order book reconstruction from L3 data
