Skip to main content

Connectivity

Test Environment

The test network does not mirror the production gateway topology. Test uses a single A/B order-entry pair because the full production hardware footprint is not available in the test environment. Production retains A/B redundancy but is sharded into separate BTC, ETH, Tier 2, Tier 3, and RWA gateway pairs. Build routing from the environment-specific tables below rather than reusing test addresses or connection assumptions in production.

Production Environment

Retransmit uses one port per market data channel. For the mapping of each product type to its retransmit port in both environments, see Multicast Channels.

Gateway Architecture

Starbase will have multiple gateways available for order entry. Gateways will always be run in pairs, A and B, for resilience. Both gateways run in a hot-hot configuration, meaning they are both fully active at all times and neither should be treated as a backup. For optimal latency you should connect to and use both gateways in a pair simultaneously. Rate limits on A and B are independent. For example, a rate limit of 100 requests/s means you can send 100 requests/s on Gateway A and 100 requests/s on Gateway B, for an effective combined rate of 200 requests/s per pair. Each pair of gateways will provide access to a set of order books, to allow for horizontal scaling. The available set of order books per gateway might change depending on the distribution of throughput per order book. Order books belonging to the same underlying asset will always appear on the same gateway to ensure the atomicity of MMP and implied matching. See below for an example order book layout of the gateways.

API Keys

Starbase uses its own API keys, separate from standard Deribit API keys and created in the Starbase section of the Account Panel. A standard Deribit API key cannot authenticate to a Starbase gateway. Create and assign a Member first, then follow Creating a Starbase API Key for key scopes and the rest of the setup flow. Each API key can establish exactly one connection to each gateway. For example, if there are 5 gateway pairs, one API key can be used to establish 10 connections. This ensures a clear audit trail for messages to help both Deribit and the client to debug and eliminates the need for gateways to communicate with each other. Trying to establish a second connection with the same key to the same gateway will result in a disconnection of the first connection.

Connecting to multiple gateways

Connection Rules:
  • Clients can have only one connection per gateway instance per API key
  • Clients can use the same API key on every gateway
This means you can connect to different gateway instances using the same API credentials, but you cannot maintain multiple simultaneous connections to the same gateway instance with the same credentials. Event Scoping: An SBE connection receives events about orders sent by the API key on that gateway:
  • Orders submitted on Gateway A with API Key X generate events on the Gateway A connection using API Key X
  • Orders submitted on Gateway B with API Key X generate events on the Gateway B connection using API Key X
  • When an amend for that order is sent from the other gateway, AmendOrderResponse is delivered on both connections. The two copies share clientOrderId, orderId, and correlationId. A cancel sent from the other gateway delivers CancelOrderResponse on the cancelling connection and an unsolicited OrdersCanceled on the submitting connection (schema version 17 or later). Fills stay on the gateway that submitted the order. See Cross-session acknowledgements
  • Orders submitted with API Key A do not generate events on connections established with API Key B
This is done to ensure many API Keys can be given out to a single Portfolio without Portfolio-level bottlenecks becoming an issue. For a consolidated view of all activity on a single Portfolio, the FIX Drop Copy API is available. Standard Deribit WebSocket APIs (e.g. private/get_user_trades_by_instrument) work for trades placed through Starbase, but private/get_open_orders* and private order subscriptions do not return open Starbase orders. Use the Starbase REST order snapshot, FIX Drop Copy, or an SBE session to see open order state.