Skip to main content

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 — 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.
GatewayOrder Books
Gateway 1 AAll BTC_USD and BTC_USDC derivatives
Gateway 1 BAll BTC_USD and BTC_USDC derivatives
Gateway 2 AAll ETH_USD and ETH_USDC derivatives
Gateway 2 BAll ETH_USD and ETH_USDC derivatives
Gateway 3 AAll Tier 2 derivatives
Gateway 3 BAll Tier 2 derivatives
Gateway 4 AAll Tier 3 derivatives
Gateway 4 BAll Tier 3 derivatives

API Keys

Each API key can establish exactly one connection to each gateway. For example, if there are 4 gateway pairs, one API key can be used to establish 8 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 only receives events about orders sent by the API key on that gateway. This means:
  • Orders submitted on Gateway A with API Key X will only generate events on the Gateway A connection using API Key X
  • Orders submitted on Gateway B with API Key X will only generate events on the Gateway B connection using API Key X
  • Orders submitted with API Key A will not generate events on a 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, a FIX Drop Copy API will be made available.