Skip to main content
Deribit spot instruments are matched in one of two places:
  • On the Deribit matching engine, the same engine that matches derivatives. A small number of spot instruments continue to work this way.
  • On Coinbase Exchange (CBE), where Deribit routes the order for matching. Most spot instruments are routed.
Both kinds trade through the same Deribit APIs, with the same authentication, the same sessions and the same instrument names, and both return the same order and trade objects. Routed instruments accept a narrower set of order parameters and do not serve the public trade tape, which is what the rest of this article describes. Derivatives are never affected, including derivatives on the same currency pair. A routed spot instrument does not change anything about the futures, perpetuals or options quoted in the same currencies. For the background to the routing change, see Spot trading routed to Coinbase Exchange in the Deribit knowledge base.

Telling the two apart

public/get_instrument and public/get_instruments return is_cbe_routed: true, and its alias is_csr: true, for routed spot instruments:
Both fields are omitted entirely for spot instruments matched on Deribit, and for every other instrument, so test for their presence rather than for a false value. Routed spot instruments also omit block_trade_commission, block_trade_tick_size and block_trade_min_trade_amount, because block trading is not available on them. Which pairs are routed is a configuration decision that can change, so read the flag from the instrument metadata instead of maintaining your own list. The instrument.creation.{kind}.{currency} and instrument.state.{kind}.{currency} notifications carry is_csr only; the is_cbe_routed alias is added by the two instrument methods above. On FIX there is no routing flag in the reference data. Security List(y) returns both kinds as ordinary FXSPOT entries, so identify routed instruments through the JSON-RPC methods above.

What applies to every spot instrument

These rules hold for spot regardless of where the instrument is matched, and are differences from derivatives rather than from routing:
  • good_til_day is rejected. On FIX, TimeInForce(59)=0 is rejected.
  • reduce_only is not supported, and mmp is not available. Mass quotes are derivatives-only.
  • Spot holdings are balances, not positions: private/get_positions rejects kind: "spot".

Order entry

JSON-RPC

The table compares private/buy, private/sell, private/edit and private/edit_by_label across the two venues. Cancelling works the same on both. private/cancel, private/cancel_all_by_instrument and the other cancel methods accept routed spot orders, including untriggered stop-limit orders.

FIX

The same differences apply to New Order Single(D) and Order Cancel/Replace Request(G).

Post-only

On the Deribit matching engine, a post-only order that would match on arrival has its price adjusted by one tick into the spread, unless you set reject_post_only: trueExecInst(18)=6A on FIX — in which case it is rejected instead. On a routed instrument the price is never adjusted. The order is either placed unmodified or rejected, which is why the reject flag is mandatory there: post-only without it is rejected with post_only_not_allowed (11055). An order that would match on arrival is rejected with post_only_reject (11054) on both venues.

Errors and rejections

The errors below are specific to routed instruments. On JSON-RPC they are returned in the response to the request; on FIX, rejected orders arrive as an Execution Report(8) with OrdStatus(39)=8 and the reason in Text(58). Parameters that are unavailable on spot generally, such as reduce_only and good_til_day, come back as Invalid params (-32602) on both venues rather than as one of the codes above. See Error codes for the full list. Code 11060 is also returned under its legacy message not_supported_for_csr_spot; treat the two as equivalent.
On routed instruments, fills are asynchronous. private/buy, private/sell, private/edit and private/edit_by_label — and, on FIX, the first Execution Report for the order — acknowledge the order once Coinbase has accepted it, and do not necessarily carry any fills. Subscribe to user.trades.{instrument_name}.{interval} and user.orders.{instrument_name}.{interval}, or track the subsequent Execution Reports on the FIX session, to follow execution.

Market data

Deribit only observes a match on Coinbase when one of your own orders was a party to it, so the public trade tape it could publish for a routed instrument would be incomplete. Rather than serve partial data, trade-derived methods, channels and message types are rejected for routed instruments. Order book data is unaffected, because Deribit receives the full Coinbase book. Your own fills are always complete on both venues: private/get_user_trades_by_instrument, the user.trades.* channels, and on FIX both Execution Reports and Trade Capture Report(AE), report every trade you were a party to.

Methods that return an error

For routed instruments these return not_supported_for_coinbase_routed_spot (11060): Requesting a derivative kind on a currency that happens to have a routed spot pair is unaffected, so kind: "future" still returns trades for that currency.

Subscriptions that are rejected

public/subscribe refuses these channels for routed instruments, reporting them as invalid channels rather than as error 11060: currency: "any" is rejected as well whenever any routed spot pair exists, so subscribe per currency, or per instrument, if you need spot trades for instruments matched on Deribit.

FIX market data

Bid and offer snapshots and incremental updates are fed from the full Coinbase L2 book, and Security List Request(x) and Security Status Request(e) are unaffected.

Responses that omit fields

For routed instruments, two responses drop fields instead of returning an error:

Getting the routed data from Coinbase

For the full public trade tape, candles and venue volume of a routed instrument, query Coinbase Exchange directly: