When you first start trading options you can sometimes need reminding of some of the details. This is particularly true if you’re new to Bitcoin options as you are using the asset itself as collateral which changes some of the calculations. We’ve put together a cheat sheet you an use as a quick reference guide to options that covers:
If you checked the patch notes for the May 7th system upgrade you may have noticed this phrase in the list and be wondering what on earth it means. Well it’s not technically a new order type, however it is a change to how market orders react with our trading bandwidths.
The trading bandwidths
For those unfamiliar, Deribit operates with trading bandwidths in place. What this means is that there is an upper and lower price at which trades can be executed on any given instrument. For example on the Bitcoin Perpetual contract the bandwidth is currently set at mark price +/- 1.5%. So if the perpetual is trading at $5,000, the bandwidths will be $4,925 and $5,075.
What these bandwidths do is stop huge deviations away from the current price of the asset (as defined by the mark price). There are a few reasons why large wicks like that can happen:
A large trader trying to push the price around (a stop hunt for example)
An accidental fat finger
A cascade of liquidations and/or stop losses
These are usually just deviations away from the ’real’ price. If there is a genuine move in price across all exchanges, then the index will also be moving bringing the mark price and the bandwidths along with it. In this way the bandwidths are designed to only stop unnatural spikes in price.
Market orders and trading bandwidths
Market orders will attempt to fill the order at the best price possible, moving deeper and deeper into the order book until it is completely filled, not caring about the price it eventually reaches. So what happens when a market order that is attempting to fill ‘at any price’ runs into one of these bandwidths that stops orders executing outside a certain range? The market order is saying ‘I’ve run out of good prices, I’ll take any price’, and the bandwidth is saying ‘you can’t execute at this price it’s outside the allowable range’.
Previously on Deribit the market order would continue to fill right up to the bandwidth as normal, but then any remaining quantity yet to be filled would be cancelled. While this is normal behavior with a bandwidth system, it is not what most traders expect to happen with a stop loss.
As of this latest update any remaining quantity will no longer be cancelled, instead a limit order for the remaining quantity will be placed into the order book at the bandwidth limit waiting to be filled. In this way it still obeys the bandwidth rules, but is also more in line with what traders want their stop loss order to do.
The system as a whole is still protected from big price spikes and traders stops are safer as they will no longer have portions cancelled for hitting the bandwidth. Win, win!
This change was partially the result of feedback from existing Deribit users.
In the past two days, we have been experiencing technical issues that required unexpected maintenance and caused system downtime. Our system architecture is something we are very proud of, moreover, we continuously strive to offer the best trading experience and minimize downtimes altogether. However, there are situations that are out of our control. Our clients have always put a lot of trust in us, therefore, we believe in full transparency and would like to explain what caused these issues.
Yesterday we experienced a bug in Erlang itself, which could be described as a DOS vulnerability. This was caused by a bot, that (unintentionally) kept sending a series of requests to our platform in such a way, that triggered this vulnerability and brought all our web nodes down. Importantly, the master (matching engine) node was not affected.
Before we managed to locate and hotfix the bug, we experienced this situation twice. Thus, causing two downtimes in a very short period of time. We did, however, manage to restart our web-nodes in less than 10 minutes each time.
Although the bug is within Erlang itself, we have implemented a workaround in our code and have reported the bug to the Erlang team, which will fix the issue.
You can see this bug report here:
In a separate incident today, our most important web node (which is also responsible for load balancing) experienced a Linux kernel panic when handling an interruption from one of its gigabit network cards.
Please note that all other web-nodes (Hermes and Mercury) and master (Matching Engine) node were not affected. This issue was not related to the Erlang vulnerability and was a technical issue. Due to this, we had to reboot the main web-node, again causing downtime.
We are planning to implement a different type of load balancing system, which will have no single point of failure, thus mitigating the risk of this happening ever again.
We take each of these incidents very seriously, and our development team does everything it can to prevent these issues from happening again. We are grateful for your understanding and hope you enjoy trading at Deribit.