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:

  1. Connect to the other gateway (if not already connected).
  2. 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.