General
Lock account
In case of security concerns, clients can block access to their account using the link in the sign-in confirmation email should they think their account has been compromised without the need to wait for Deribit customer support. This includes disabling all API keys as well.
New FIX and WS API error when order falls outside trading bandwidth for futures & perpetual orders
This applies to when a bid is higher than the Max Buy or ask is lower than Min Sell. Previously these orders were price adjusted to the Min Sell or Max Buy. As of the date of the release these orders will receive the following error: price_too_high or price_too_low.
All trades & orders in API results will always be chronologically ordered
Before these were sorted by order/trade ID which were not necessarily in chronological order.
FIX Changes
New Order Single was upgraded to support the entire range of orders supported by Deribit.
The Deribit FIX engine now supports placing, editing, and canceling of Options (including advanced order types), Futures (simple types and algorithmic types (trigger orders)).
To place new order types, OrdType <40> ENUM was changed to:
Futures
OrdType <40>:
FIX -> Deribit's order type
1 -> Market
2 -> Limit
K -> Market Limit
4 -> Trailing Stop
If Trigger Price presents (StopPx <99> field) in New Order Single request, then OrdType <40> value would mean the following order types:
2 -> Take Limit
J -> Take Market
4 -> Stop Limit
S -> Stop Market
Options
1 -> Market;
2 -> Limit;
Order type Trailing Stop requires the presence of Trigger Offset (PegOffsetValue <211> field).
Trailing Stop, Take Limit, Take Market, Stop Limit, Stop Market order types also require the passing of Trigger (DeribitTrigger <5127> field) which might have the following values:
1 -> Mark Price;
2 -> Trade;
3 -> Index;
Handling of Order Cancel Request, Order Mass Cancel Request, Order Mass Status Request, Order Cancel Replace Request were updated to support new order types.
Multicast Changes
-
Snapshot change to mark the beginning of the snapshot (when clients would need to start buffering events). We do this by sending a snapshot_start message 200ms before we start the actual snapshot for the clients to know when they should start buffering events. Also the change adds a snapshot_end message to know when not to expect more messages in the snapshot batch.
-
Add combo_legs message to the combo snapshot and event channels. This means that for each snapshot on the combo channels, besides the combo instrument data (same as normal instrument data) we append an extra message which lists the instrument ID's and amounts of each leg of the combo. We also append this message to the instrument start event on the combo event channels. So clients don't need to rely on parsing the combo name to guess which instruments are in the combo.
-
Add combo RFQ event/message to the combo event channels.
-
Add a new channel for index prices.
The above is available in our test environment already and will be released to production on 25 January 2023.