To encourage efficient trading strategies and incentivise behaviours that improve the executable liquidity of the market, BitMEX will be introducing some advanced trading rules that apply to all users of the platform. The first Trading Rule to be enabled is the Quote Fill Ratio Threshold.
Quote Fill Ratio
We define the Quote Fill Ratio (QFR) as the proportion of quotes filled per quotes submitted to the platform per calendar day. A quote submitted is any individual order sent to the market. A quote filled is an order that has been filled for any amount. The QFR is calculated as follows:
Quote Fill Ratio example
A market maker quotes a two-sided price on XBTUSD and submits one bulk new order request containing 4 bids and 4 asks which rest in the book at different price levels. The market maker then receives a price signal and submits a bulk amend request to change the prices of the 4 bids in the market down by one tick each.
Another market participant submits a large market buy order which lifts 3 of the asks that the market maker has resting in the book. There is no more quoting or trading for these two participants for the remainder of the day.
The market maker’s QFR for the day is calculated as follows:
- # quotes filled = 3
- # quotes submitted = 12
- QFR = 3/12 = 25%
The taker’s QFR for the day is calculated as follows:
- # quotes filled = 1
- # quotes submitted = 1
- QFR = 1/1 = 100%
Quote Fill Ratio Threshold
Accounts on the platform will need to maintain their 7 day moving average QFR above a minimum QFR threshold. Violations of this rule will result in email warnings and an eventual API ban.
Accounts making fewer than 2000 quotes per day will be exempt from this Trading Rule.
Starting 30 August 2019, the following QFR threshold will be implemented:
- Minimum QFR Threshold: 0.1% (7-day moving average)
For the introduction of this Trading Rule, the QFR threshold will initially be set very low at 0.1% to minimise impact to users. For comparison, traditional venues typically enforce QFRs in the range of 1-5%. At 0.1%, we estimate less than 0.2% of active traders will be affected based on current platform quoting activity. We may update the minimum QFR threshold and/or mechanism from time to time. Advanced notice of any changes will be published here so that users have time to adjust their trading behaviour.
From 19 August 2019 at 04:00 UTC, bulk order requests submitted through the API containing a crossed price (at least one BUY order at an equal or higher price than a SELL order) will be rejected. This functionality update is part of the ongoing simplification of our API and trading system architecture.
As a continuation of our efforts to simplify the BitMEX API, we are scaling the REST rate limiter from a 5 minute interval to a 1 minute interval.
This does not change the 1 request / second rate at which the limiter replenishes. Note that current rate limits will be prorated from 5 minutes to 1 minute. For example, a 300 requests / 5 min rate limit will translate to a 60 requests / 1 minute rate limit.
This change should not break applications that respect the X-Ratelimit-Remaining header. If the previous 300 requests / 5 minute rate limit is hardcoded into your application, you will need to update it.
The new rate limits are live on Testnet for you to demo, and will be deployed to production on 22 May 2019 at 18:45 UTC. During this production deployment, which will last about 15 minutes, users may receive inconsistent values on the X-Ratelimit-Remaining header. Otherwise, this update should be transparent to users.
As part of the ongoing simplification of our API and trading system architecture, the api-nonce header will no longer be supported starting on Tuesday 12th March 2019. BitMEX will not check for increasing nonces as part of validation. The nonce scheme will still be valid for generating signatures used to authenticate with the API. Your requests are still safe from replay attacks thanks to TLS. Please see https://www.bitmex.com/app/apiKeysUsage for more information.
Beginning on 20 February at 04:00 UTC, market orders will no longer be permitted in bulk order requests submitted through the API. This includes both orders submitted with ordType=Market and implicit market orders (orders submitted with a side but without a price). After this time, including a market order in your bulk order request will result in the entire request being rejected. This functionality update is part of the ongoing simplification of our API and trading system architecture.
As part of the ongoing simplification of our API and trading system architecture, the below order type will no longer be supported after 04:00 UTC on Friday 8th February 2019:
Orders submitted with an order type value of MarketWithLeftoverAsLimit after this time will be rejected. Furthermore, any open order of this type will be automatically cancelled shortly after the above deadline. As such, please ensure any trading strategies using these order types are appropriately updated to reflect this change.
As part of the ongoing capacity improvements to the platform, there will be a scheduled update to the Websocket API infrastructure at 16:00 UTC on 16th January.
There is no planned downtime to the trading engine for this change however please note that a momentary interruption in the deltas published on the websocket feed is expected at 16:00 UTC. Shortly after this all websocket connections will be forcibly disconnected to ensure no websocket client is left with an inconsistent view of their own orders, positions or the public order book upon reconnection. This change should otherwise be transparent to users.
As part of the ongoing simplification of our API and trading system architecture, the below order types will no longer be supported after 12:00 UTC on Saturday 10th November 2018:
- OCO: One Cancels the Other
- OTO: One Triggers the Other
- OUOA: One Updates the Other Absolute
- OUOP: One Updates the Other Proportional
Orders submitted with a contingencyType field after this time will be rejected. Furthermore, any open contingent orders will be automatically cancelled shortly after the above deadline. As such, please ensure any trading strategies using these order types are appropriately updated to reflect this change.
Orders submitted using the simpleOrderQty field will no longer be supported from 12:00 UTC on Friday 26th October 2018. Any orders submitted using the simpleOrderQty field after this time will be rejected. Any existing open orders submitted using a simpleOrderQty will automatically be cancelled shortly after the above time.
Please further note that within the coming weeks updates via the Websocket API or GET requests to the REST API for the below fields will return a null value:
- position: simpleQty, simpleCost, simpleValue, simplePnl, simplePnlPcnt
- order: simpleOrderQty, simpleLeavesQty, simpleCumQty
- execution: simpleOrderQty, simpleLeavesQty, simpleCumQty
These fields may also be removed entirely from these schemas at a future date. We will make another announcement before removing the fields entirely from the message schemas. We strongly recommend API users to update any clients that use these fields before the above deadline to avoid any disruption.
A previous version of this article detailed a rollout to CloudFlare at our edge. Due to latency and connection stability issues, CloudFlare has been removed. We are investigating long-term viability and will not re-initiate until we are sure we can satisfy our customers’ high expectations.
As part of BitMEX’s engine optimization process, breaking API changes are occasionally required. BitMEX strives to avoid imposing these whenever possible.
Please ensure you update your API clients appropriately to avoid any disruption to your trading strategies.
- The order Execution Instruction (ExecInst)
AllOrNone will be removed on 00:00 UTC Monday 14th May. Orders using
AllOrNone will be rejected.
It has come to our attention that some API consumers are using the
Close execInst as an escape valve to continue quoting one side of the market during overload conditions. This was not the intention of the exclusion – the intent was to allow full position closure, primarily for frontend users.
Close orders are now subject to load shedding if they contain a quantity. If you do intend to close your full position, please omit the
orderQty field in your order. The absence of this field, in combination with
Close, is interpreted as your full position size.
See also previous announcements on Load Shedding:
- 26 Feb 2018: https://blog.bitmex.com/api_announcement/addition-of-position-endpoints-to-load-shedding/
- 3 Dec 2017: https://blog.bitmex.com/site_announcement/update-to-system-overload-policy/
- 9 Nov 2017: https://blog.bitmex.com/api_announcement/scheduled-maintenance-november-9-2017/