Important
This release was postponed from 05.11.2026 to 10.11.2026.
⚠️ Expected downtime: 45 minutes
Client impact: Maintenance 9 AM UTC - The system will be down for around 45 minutes. Client systems will not be able to communicate with Deribit during this time.
AWS connectivity maintenance: During the maintenance window, we will also carry out network maintenance on our AWS connectivity. Clients connecting through AWS should expect connection errors and timeouts between AWS and LD4 during this period.
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. Instead, each delayed trade is added to the 24-hour
volume8 hours after it was executed and remains included for the following 24 hours. All other trades are counted in real time, as before. 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.
Self-match prevention across Starbase Members
On Starbase, self-match prevention applies within a Member. Orders from different Members can match each other, even when the Members belong to the same main account. Deribit can now extend self-match prevention across all Members of the same main account.
-
The setting is enabled by Deribit on request. It applies to the main account and all of its subaccounts, and cannot be changed in the account settings or through the API.
-
When it is enabled and self-match prevention is active, orders from different Members of the same main account do not match each other. This applies to orders submitted through the Starbase APIs, the WebSocket API, the FIX API and the UI. Your self-match prevention mode still decides which order is cancelled.
-
The setting is mainly relevant to accounts with more than one Member, such as brokers with multiple Members.
Also from this release, when Account level Self Match prevention is enabled, orders submitted through the WebSocket API, FIX API or UI no longer match Starbase API orders from the same Member. See Self Match Prevention in the upcoming Starbase API documentation.
Starbase Market Data
Delayed block trade publication. The market data SBE schema has been updated to version 2 (semanticVersion remains 1.0). The change is additive and backwards compatible. The new fields are at the end of the message, with no repeating groups. The updated schema is available as the testnet market data XML. The production XML will be updated at release.
-
BlockTrade(33): newpadding2(int16) andexecutionTimestamp(TimestampNanos, optional) fields at the end of the message. The message body grows from 78 to 88 bytes, andmessageLengthin the message header from96to104. Clients that usemessageLengthto step to the next message need no change. -
TradeFlags: newwasDelayedchoice (bit 3). Set onBlockTrademessages for qualifying Block RFQ trades published after a delay. On those printsexecutionTimestampis the execution time andtransactTimein the message header is the publication time. On all other block tradeswasDelayedis0andexecutionTimestampis null. -
The message header
versionfield is2on all market data messages.
Delayed block trades are not published on the incremental channel at execution. The eligibility rules and delay are the same as for the JSON-RPC API; see the JSON-RPC API Changelog.
Decoding new fields. Decode market data with the published SBE schema and use messageLength in the message header to find the next message. Do not hard-code message sizes. Fields added at the end of a message keep every existing field at its offset, so a decoder built from an older schema reads the known fields and skips the extra bytes.
See Block Trade and Delayed block trades.
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.
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.
New self_trading_extended_across_members field in account summaries
When called with extended set to true, private/get_account_summary and private/get_account_summaries return a new self_trading_extended_across_members field alongside self_trading_extended_to_subaccounts. It is true when self-match prevention is extended across Starbase Members. Like the other self-trading fields, it is only returned while self-match prevention is active.