1. Deribit Support
  2. Exchange
  3. Releases
  4. 2026 Releases

11 August 2026

  • Updated

⚠️ Expected downtime: 15 - 30 minutes

Client impact: The system will be down for around 15 - 30 minutes. Client systems will not be able to communicate with Deribit during this time.

Starbase release

Deribit will complete its roll-out of a new matching engine, Starbase, on August 11th.

Due to Starbase, Deribit can and will list many new instruments in the coming weeks, while increased technical performance will lead to better liquidity. See the insights article for more information and the Starbase API documentation for technical details. Unless a member wants to utilize any of the new APIs, that member is unaffected by this change.

Key Starbase Changes

The following changes will take effect on August 11th, alongside the Starbase order entry gateway go-live. Several FIX Drop Copy changes are already available on testnet for verification ahead of the production cutover.

(Breaking) Starbase FIX Drop Copy Identifier Format

Starbase FIX Drop Copy will emit the same numeric exchange identifiers used by the SBE Order Entry gateway, the REST API, and the Websocket starbase_match_id field. Encoded string forms such as 1dggemhx-2-0 will no longer be used; the equivalent value is sent as a decimal integer string (for example 204986164241768448).

This lets clients reconcile fills across FIX Drop Copy, SBE, REST (private/get_user_trades_by_currency_and_time), and Websocket user trades without a proprietary decoder.

Affected fields:

  • TradeCaptureReport (35=AE): TradeReportID (571), ExecID (17), TrdMatchID (880)

  • Fill ExecutionReports: TrdMatchID (880)

  • MmpGroupId (8001)

These changes are already live on testnet. Clients should confirm parsers treat these tags as numeric IDs and that TrdMatchID (880) matches SBE matchId and Websocket/REST starbase_match_id.

FIX Drop Copy Replay and Account Fields

TradeCaptureReportRequest (35=AD) will be supported for replaying non-order-book trades (block trades, position moves), as documented on FIX Drop Copy. The message is currently documented but not implemented, so requests receive no response.

EventResendRequest (35=F3) will replay fill ExecutionReports only. Today F3 also resends TradeCaptureReports in the requested interval; from August 11th, use AD to replay Trade Capture Reports.

Account (1) and Parties (453) will be restored on ExecutionReport and TradeCaptureReport, so Drop Copy sessions covering multiple subaccounts under a Member can identify which subaccount a trade belongs to.

TradeCaptureReportRequestAck, msgType='AQ' will be sent out at the end of a successful replay or if the replay request is rejected (similar to EventResendComplete or EventResendReject for F3 messages).

HYPE_USDC Multicast Channel Correction

HYPE_USDC is classified as Tier 2 on Starbase, but its market data is currently published on the RWA and pre-IPO perpetuals channels (224.0.12.206 / 224.0.12.207 and the corresponding B-side feeds).

On August 11th it will move to the Tier 2 channels. Clients consuming HYPE from the RWA / pre-IPO feeds should update their subscriptions before the cutover. See Multicast Channels and Underlying Tiers.

Affiliate and partner payouts at trade time

From August 11th, affiliate and partner balances are credited instantly when the trade happens, replacing the previous model where payouts were accumulated and credited once per day (around 8:05).

This aligns fee crediting with the debiting of fees or the crediting of maker rebates, which is already applied immediately post-trade.

API changes

  • Unaggregated (.raw) market data — All unaggregated market data subscriptions, identified by the .raw postfix, will be aggregated on a 1 millisecond basis due to a different treatment in the integration between the current multicast, Websocket and FIX market data APIs and Starbase.

    • 1 millisecond is below the median latency of any non-Starbase market data feed and as such no major degradation in performance is expected.

  • Order objects — new starbase_client_order_id field: client order id for orders submitted directly to Starbase via direct access; not returned for orders placed through the Deribit API. Combo legs inherit the parent combo order’s client order id.

  • User trade objects — new starbase_order_id and starbase_client_order_id fields: present only for trades matched in Starbase. starbase_client_order_id reflects your own order (maker or taker side); for self-trades it is the taker order’s client order id.

  • starbase_order_id on orders is present for orders placed in Starbase; combo leg orders expose the parent combo order’s Starbase order id.

  • Combo trade legs carry the full set of Starbase fields (starbase_match_id, starbase_order_id, starbase_client_order_id, starbase_timestamp) when matched in Starbase.

    • starbase_last_update_timestamp is also available on combo leg order updates.

  • private/get_transaction_log: trade entries executed in Starbase include starbase_match_id, starbase_order_id, and starbase_timestamp.

  • Instrument objects returned by public/get_instruments and public/get_instrument include two additional fields:

    • product_group — product group classification of the instrument’s base currency (BTC, ETH, TIER_2, TIER_3); determines gateway and multicast channel assignment. See Underlying Tiers.

    • index_id — numeric identifier of the price index used by the instrument (shared by instruments with the same price_index).