Existing Deribit APIs remain available. Standard WebSocket and REST order entry continue to work for supported instruments, but they are not wire- or behavior-compatible with Starbase SBE. They use separate credentials and sessions, have different response semantics, and do not expose live open-order state for orders submitted through Starbase.
To have your Test account enabled for Starbase, please reach out to your Account Manager or Technical Account Manager.
Architecture & Location
The Starbase matching engine and its gateways run in LD4 — none of Deribit’s infrastructure is deployed in the cloud. Clients on AWS can reach Starbase over AWS Private Link without traversing the public internet, but this is a connectivity option only, not a change in where the infrastructure runs. For server-level detail, see Server Infrastructure. There is no layering between Starbase protocols — SBE order entry and SBE market data talk directly to the matching engine and are not built on top of FIX or WebSocket internals (nor vice versa). SBE is the most performant option Deribit offers and is expected to remain so. For the lowest possible network latency, run the latency-sensitive trading stack in LD4 using hosted colocation or a cross-connect. A server in another region, including Tokyo, must still reach the matching engine in London and therefore cannot provide the same round-trip latency as an LD4 deployment. Remote infrastructure can still be used for monitoring, risk, research, and disaster recovery.Per-hop latency breakdowns (network, gateway, matching engine processing time, etc.) are not published yet. Deribit is deploying Corvil monitoring in LD4 to produce these figures.
Deployment Options
Starbase does not accept connections over the public internet. For hosted colocation, cross-connects, AWS connectivity, multicast delivery, PTP access, and network onboarding, contact colo-support@coinbase.com.
Commercial Costs
There is no single public price that applies to every deployment. The total cost depends on the connectivity model and the services purchased from the chosen data-center or hosting provider. Plan for the following line items:- Hosted-colocation fees, or rack space and power for clients operating their own LD4 footprint
- Cross-connect installation and recurring charges
- Network transit or AWS connectivity charges
- Optional managed hosting or remote-hands services
- Optional PTP service
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 Protocols and Interfaces
Compatibility with standard Deribit APIs
“Existing APIs remain available” means clients can continue using the standard APIs alongside Starbase. It does not mean requests, responses, or private event streams are interchangeable.
Design each protocol as a separate adapter and reconcile them through exchange-assigned identifiers and trade/position records. See Mass Quotes, Reference Data, and FIX Drop Copy for the protocol-specific behavior.
Recommended Production Architecture
Keep the execution path small and run order entry, book building, and strategy logic close together:- Subscribe to both A and B incremental and snapshot multicast feeds for every traded product group.
- Reconstruct and maintain the L3 order book locally.
- Connect to both A and B order-entry gateways for each traded product group.
- Load-balance order flow across A and B while retaining automatic failover.
- Consume FIX Drop Copy independently from order-entry sessions and persist its Execution Reports for reconciliation.
- Keep slower control-plane functions, analytics, and long-term storage outside the critical execution path.
FIX Drop Copy is the recommended source for a consolidated order and trade audit trail. Standard WebSocket APIs continue to expose Starbase trades and positions, but they do not expose open Starbase orders or their lifecycle updates.
Protocol Support
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.
- All sessions connected to a given gateway share a single inbound event-loop thread — requests from every session on that gateway are processed sequentially, in receipt order.
Rule 1 — Connection Limits per API Key
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
This design allows multiple API keys to be assigned to a single portfolio without creating portfolio-level bottlenecks.
Rule 3 — Rate Limits
Gateway-to-Product Mapping
- Order Entry Gateways: See Gateway Connectivity
- Multicast Market Data Channels: See Multicast Channels
Quick Reference
Failover Scenarios
Scenario 1 — Single Gateway Failure (A or B)
Scenario 2 — Connection Loss & Cancel on Disconnect (CoD)
Cancel on Disconnect is always enabled on Starbase and cannot be disabled or configured.
Connection loss is detected via:
- TCP connection closure
- Missing heartbeats (heartbeats cannot be disabled)
- Explicit logout
Scenario 3 — Reconnection After Disconnect
Scenario 4 — Cross-Session Amends and CoD
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
- Durable order/trade record-keeping — order history endpoints don’t retroactively return rejected or zero-fill orders, so persist Execution Reports from Drop Copy as they arrive (see the note on rejected orders in FIX Drop Copy)
Best Practices Summary
Connection Management
- Connect to both A and B gateways in each pair
- Implement robust connection monitoring and automatic reconnection
- Handle
OrdersCanceledmessages 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
Protocol Selection
- Use SBE order entry for the lowest-latency placement, amendment, and cancellation path.
- Use SBE multicast market data for the lowest-latency L3 book.
- Use FIX Drop Copy for consolidated order lifecycle events, fills, and durable reconciliation. Persist events as they arrive: rejected and zero-fill orders cannot always be recovered later from order-history endpoints.
- Use REST for utility and recovery workflows, not as the primary execution or live order-state path. In particular,
get_open_ordersis limited to one request per minute per portfolio. - Use the standard WebSocket API where its additional latency is acceptable or for data not yet available in the Starbase feed. Do not rely on it for open Starbase order updates.
Access and Capacity Planning
- Create a dedicated Starbase API key; standard Deribit API keys cannot authenticate to Starbase.
- Allowlist all source IP addresses that will establish Starbase connections.
- Size connections by product gateway and resilience requirements, not to multiply throughput. Rate limits are shared per Member, per gateway, and per quoting type across all keys, sessions, and portfolios.
- Use both sides of a gateway pair: A and B have independent rate-limit buckets.
- Use mass quotes for option quoting rather than sending equivalent batches of single orders.
- Discuss non-default rate-limit requirements with your Account Manager before production rollout.
Network Troubleshooting Checklist
When reporting a connectivity or latency issue, include enough detail to identify the route and reproduce the problem:- Environment: test or production
- Connectivity type: LD4 cross-connect, managed colocation, or AWS Private Link
- Account UID and Starbase ClientID
- Affected protocol or interface, gateway side, destination address, and port
- Source IP address and, for colocated clients, hosting provider and cross-connect identifier
- UTC timestamps with nanosecond precision where available
- Whether the issue affects side A, side B, or both
- TCP connection and application-session status, including the last successful heartbeat or sequence number
- Ping and TCP-connectivity results where supported by the network path
- A short packet capture covering the incident, with credentials and sensitive payloads removed
- Expected and observed behavior, including relevant reject codes or sequence gaps