⚠️ Expected downtime: 15 - 30 minutes
Client impact: Maintenance 9 AM UTC - The system will be down for around 15 - 30 minutes. Client systems will not be able to communicate with Deribit during this time.
Key Changes
Delayed publication for large Block RFQ trades
Deribit is implementing a new Block RFQ feature for very large trades, which allows anyone executing a Block RFQ trade above a certain size to have the trade data for this trade only published into the public data feeds after a delay.
What problem is this feature attempting to solve?
For very large trades, some clients execute in several tranches to allow market makers to absorb the large flows. When these tranches hit the tape instantly, this can lead to front running of the next few tranches, leading to worse execution due to the information leaked from the first tranche. By delaying the publication of the trade data, this gives the trader an opportunity to execute their whole trade before any information is available publicly.
As an example of similar solutions, under MiFID II, the European Securities and Markets Authority (ESMA) attempts to tackle this same problem with their Large In Scale (LIS) rules.
Which trades qualify?
-
Delayed publication is enabled by Deribit on request. Once enabled, it applies to the account and all of its subaccounts.
-
A Block RFQ trade qualifies if the taker or any of the makers has delayed publication enabled.
-
Each Block RFQ trade (tranche) must meet the minimum size for its settlement currency, shown in the table below. Block RFQ trades below this minimum size are always published immediately. Only derivative legs count towards the minimum, and their amounts are added up per settlement currency. For USDC-settled instruments, the size is measured as notional in USDC.
-
When you request delayed publication, Deribit will require that the total size of the overall trade, across all of its tranches within one settlement cycle (between two daily settlements at 08:00 UTC), is at least 3 times the minimum size. This reflects the purpose of the feature, the avoidance of front running, and ensures that the majority of volume is still reported in real time.
-
Trades executed within 1 hour of the next settlement are not delayed and are published immediately.
|
Settlement currency |
Minimum size per Block RFQ trade |
Minimum total size within one settlement cycle |
|---|---|---|
|
BTC |
1,000 BTC |
3,000 BTC |
|
ETH |
10,000 ETH |
30,000 ETH |
|
USDC |
10,000,000 USDC notional |
30,000,000 USDC notional |
These rules are also described in the private/accept_block_rfq API documentation.
What will change on Deribit?
For qualifying Block RFQ trades, the following changes will apply:
-
There will be a delay applied between the execution of a qualifying trade that has opted in, and the reporting of that trade in the public data feeds.
-
The length of the delay will default to 8 hours. However, there is a hard cap: a trade will be reported no later than 1 hour before daily settlement (08:00 UTC). This effectively makes the delay time equal to
MIN(8 hours, time_until_daily_settlement - 1 hour). Trades are published within about a minute of their scheduled publication time. -
Until it is published, the trade is not shown in:
-
public/get_last_trades_by_instrument,public/get_last_trades_by_instrument_and_time,public/get_last_trades_by_currencyandpublic/get_last_trades_by_currency_and_time -
The
trades.{instrument_name}.{interval}andtrades.{kind}.{currency}.{interval}channels -
FIX market data
-
The Block RFQ trade tape:
public/get_block_rfq_tradesand theblock_rfq.trades.{currency}channel
-
-
When it is published, the trade keeps its original execution timestamp and
trade_seq, so it is added to the trade history out of sequence:-
Subscribers to the
trades.*channels receive the trade at publication time, so it can arrive out of sequence. -
Public trade queries for a past time or sequence range can return additional trades once delayed trades in that range are published.
-
-
A delayed trade never updates the instrument's last price, tick direction, or 24-hour high, low and price change, even after it is published.
-
While delayed trades are hidden, public trade queries can return fewer results than the requested
count. -
The taker and makers see the trade in their own trade history immediately, with a new
block_delayedfield showing when it will be published (see API below).
These changes are designed to give traders executing large orders more time to complete their trades before the related trade information becomes publicly available.
What changes in public market data?
Alongside delayed publication, the following changes apply to public market data:
-
Open interest: open interest in public market data, for example in
public/ticker, theticker.{instrument_name}.{interval}channel,public/get_book_summary_by_instrumentandpublic/get_book_summary_by_currency, is now reported with an 8-hour delay: it shows the open interest as of 8 hours ago. This applies to all futures and options instruments, whether or not any trades were delayed. Real-time open interest is no longer available through the API. -
24-hour volume: delayed trades are not added to 24-hour statistics as soon as they happen. The
volumestatistic now combines real-time volume over the last 24 hours with delayed trade volume over a 24-hour window that ends 8 hours ago. The new breakdown fields are listed under API below. -
Chart data: block trades, including Block RFQ trades, no longer add to volume in
public/get_tradingview_chart_dataand thechart.trades.{instrument_name}.{resolution}channel. As before, they do not affect chart prices.
What will not change on Deribit?
Despite the delayed publication, the following aspects of trading and risk management remain unchanged:
-
The trades are still executed immediately.
-
Margin requirements and equity are also still updated in real time. The delay does not apply to anything risk related, only to when the trade data is available publicly.
-
All trades are still eventually reported on the public data feeds.
-
This delayed data publication feature is only available for qualifying Block RFQ trades. It does not apply to on-screen trades, liquidation trades or block trades executed outside Block RFQ.
In short, the feature only changes how and when trade data becomes public; execution, risk management, and eventual trade reporting remain unaffected.
API
New block_delayed field on trades
Trades with delayed publication include a new block_delayed field: the time the trade is published to public data feeds, in milliseconds since the UNIX epoch.
-
The taker and makers see the field immediately: the taker in the trades returned by
private/accept_block_rfq, and all counterparties in their user trades, for example inprivate/get_user_trades_by_currency,private/get_user_trades_by_instrumentand theuser.trades.{kind}.{currency}.{interval}anduser.trades.{instrument_name}.{interval}channels. -
Once the trade is published, the field is also included in public trades, for example in
public/get_last_trades_by_instrumentand thetrades.{instrument_name}.{interval}channel.
Real-time and delayed volume breakdown in 24-hour statistics
New fields split 24-hour volume into real-time and delayed volume: volume_realtime and volume_delayed, plus volume_realtime_usd, volume_delayed_usd, volume_realtime_notional and volume_delayed_notional alongside the existing volume_usd and volume_notional fields where those are returned. volume equals volume_realtime plus volume_delayed. volume_realtime covers all other trades over the last 24 hours. volume_delayed covers delayed Block RFQ trades executed between 32 and 8 hours ago, that is, over a 24-hour window that ends 8 hours ago.
The fields are returned in the stats object of public/ticker and the ticker.{instrument_name}.{interval} channel, and in public/get_book_summary_by_instrument and public/get_book_summary_by_currency.
Timestamp filtering added to delivery prices endpoint
Added optional start_timestamp and end_timestamp filters to public/get_delivery_prices, making it easier to query historical delivery price data for specific periods. Both bounds are inclusive and are matched against the UTC calendar date of each delivery.