Derivatives Runbook
Service Overview
Protocol Version
The Coinbase Derivatives Exchange (CDE) FIX API uses the FIX 4.4 protocol as a baseline. Refer to the official FIX 4.4 specification for additional details.
CDE also offers a custom Simple Binary Encoding (SBE) API.
Hours of Operation
Orders entered outside trading hours are rejected. Firms are encouraged to stay connected 15 minutes after the official close to receive execution reports generated from trading session closing logic (e.g., Expired reports, Done for Day).
Contact the CDE team for the current trading schedule—it resets its FIX sequences on a weekly basis. The reset schedule is configured during initial setup.
Firms are encouraged to stay connected 15 minutes after the official close.
Certification
To connect to Coinbase Derivatives Exchange, a firm must be certified. CDE provides separate environments for integration, acceptance testing, and certification. Contact the CDE team for details.
Disaster Recovery
Order Entry Gateways
Coinbase Derivatives Exchange operates two active gateways and clients can connect to either or both. All order events are sent to both gateways and are available for resend whether or not the client has an active session.
Guaranteed Delivery
Sessions on each gateway are distinct and have independent sequence numbers. Events are uniquely identified by ExecId
which guarantees that events received from dual sessions can be deduplicated.
Duplicate Requests
Order requests can be sent through either gateway, but should not be sent through both simultaneously. CDE may reject duplicate requests, but they may also result in duplicate fills.
Recovering Missed Events
If the client is disconnected with one or more pending/unacknowledged requests, the client should:
- Connect to the other gateway (if not already connected).
- Send a Last ExecId Request (35=F1) to determine the
ExecId
of the last order event sent by the trading system to the client.
If the client is missing events, where ExecId
is less than LastExecId
in Last ExecId Request (35=F1), the client can either send an Event Resend Request (35=F3), or a session-level Resend Request (35=2) message to retrieve missed events.
Having recovered all missed events, the client can safely assume that any requests for which there was no corresponding event was either not processed by the trading system or was rejected.
Sequence Number
CDE follows standard FIX protocol for sequence numbers. This dictates separate numbers for incoming and outgoing messages between the client system and Coinbase Derivatives Exchange, ensuring that all messages to and from CDE are in the correct order and recoverable.
It is the client’s responsibility to reset the inbound and outbound sequence numbers to “1” prior to the Beginning of the Week Logon, increment the inbound/outbound sequence number by one for each message, maintain sequence numbers across all sessions and issue a resend request if gaps are detected.
CDE resets sequence numbers to “1” across all gateways every Friday at 16:05 CT. See FIX Session and SBE Session for client-initiated reset instructions.
Cancel On Disconnect
A client may optionally be configured for cancel-on-disconnect orders. Cancel-on-disconnect applies to Day orders only (not GTC orders).
SBE XML API orders are implicitly cancel-on-disconnect.
If a client has cancel-on-disconnect enabled and is connected to both active gateways, and disconnects from one of them, only the orders submitted (or last replaced/modified) by the disconnected session are canceled.
Example If a client submits an order on gateway A and then updates that order on gateway B, the order is not canceled if the client disconnects from gateway A, but is canceled if the client disconnects from gateway B.
Market Data Gateways
Coinbase Derivatives Exchange also operates two active Market Data gateways and clients can connect to either or both. When logging on, clients receive a full snapshot and ongoing updates of the market book after subscribing to the market data.
Failover Responsibilities
Clients that connect to only one gateway are expected to failover to the other gateway if an issue arises with their primary gateway connection.