Conditional Orders Have Arrived On Deribit

A conditional order is an order whose behaviour is conditional on what happens to another order. For example, we may have a stop loss order and a take profit order that are both only placed once a primary order has been filled. On some platforms, wrapping the primary order with these secondary orders is known as bracketing. The primary order would open a position, and the secondary orders are designed to close that position.

The stop loss order and take profit order can also be linked to each other in such a way that if one is filled, the other will automatically be cancelled.

Let’s look at where we can find conditional orders on the website, and for the examples in this lesson I will just be using the test version of the Deribit website.

Where to find conditional orders in the UI

Conditional orders are available in the UI, and via the API. In the UI they can be found in the new order form, which now includes two toggles. One for a take profit, and one for a stop loss.

The most common use for conditional orders is to set up a Take Profit (TP) and/or a Stop Loss (SL) for some primary order that will open a new position. For example, let’s say we want to buy the BTC perpetual when the price goes down to $72,200, and so we would like to place a limit order to buy at a price of $72,200. This is our primary order. Let’s also assume that once our primary order is filled, we would like to get out of the resulting long position if the price moves down to $69,000, or up to $74,000. This means we would like to place a stop loss at $69,000, and a take profit at $74,000.

However, we don’t want the SL or TP to be active until the primary order has been filled. Ideally then, we want the SL and TP to be placed automatically at the moment our long position is opened. In other words, we want the placement of the SL and TP to be conditional on the long position opening.

To further aid in the understanding of how orders can now be linked together via certain conditions, we will to introduce three new terms and their respective acronyms:

One-triggers-other (OTO)
One-cancels-other (OCO)
One-triggers-one-cancels-other (OTOCO)

One-triggers-other (OTO)

An OTO setup contains a primary order and at least one secondary order that is triggered by the primary order. For instance, imagine the BTC perpetual is currently trading at a price of around $72,000, and we want to buy $10,000 of the BTC perpetual once the price gets down to $71,900. If this primary order is filled, we would then like to place a limit order to take profit at the price level of $74,000. We can use the ‘Take profit’ section of the new order form to place this combination of orders together.

We create a limit order to buy $10,000 with a limit price of $71,900. This is the primary order, and it will sit in the order book as soon as we have sent the orders.

We then enable the ‘Take profit’ section of the order form, and enter the details for a limit order with a limit price of $74,000. This is a secondary order, and it will not be placed into the order book until the primary order has been filled. In other words, its placement is triggered by the primary order receiving a fill. Hence the name ‘one-triggers-other’. Until the primary order is filled, the secondary order will be in a ‘Queued’ state, waiting for a trigger from the primary order.

Once the primary order has been filled, leaving us with a long position in the perpetual with a position size of $10,000, the take profit order, which is a limit order to sell at $74,000, is placed into the order book.

One-cancels-other (OCO)

An OCO setup involves two orders. An OCO order will be cancelled if the order it is linked to is either filled or cancelled.

For example, if we have a take profit in the form of a limit order to sell at $74,000, and a stop loss in the form of a stop market order to sell if price decreases to $69,000, we may only want one of these orders to ever fill. Therefore it would be useful to be able to have these two orders linked to each other via OCO. If one of the orders is filled, the other one is then automatically cancelled, achieving the desired behaviour of only one order receiving a fill.

When both a stop loss and take profit order are entered at the same time via the new order form, they are automatically linked via OCO.

One-triggers-one-cancels-other (OTOCO)

Other than being a mouthful to say, an OTOCO setup combines both OTO and OCO. It contains a primary order that is linked to at least two secondary orders via OTO, and the secondary orders are also linked to each other via OCO.

The classic example of this would be the example we discussed at the beginning, which involves a primary order to buy or sell some instrument, with a take profit and stop loss as the two secondary orders. The take profit and stop loss are linked to each other via OCO.

As an example, imagine the BTC perpetual is trading at a price higher than $72,200, and we enter a limit order to buy the BTC perpetual when the price decreases to $72,200. We also add a take profit in the form of a limit order to sell at $74,000, and a stop loss in the form of a stop market order to sell at $69,000.

The limit order to buy at $72,200 is the primary order, and this is linked to the two secondary orders, the take profit and stop loss, via OTO. When we first send this combination of orders, the primary order goes straight into the order book, but the take profit and stop loss are in a queued state, waiting to be triggered by the primary order getting filled.

The take profit and stop loss are also linked to each other via OCO. So once they are placed, if one of them is filled, the other will be cancelled.

New labels – OTO, OCO, Queued

You will see some new labels in the orders tables that help to identify orders that are linked in some way to other orders. This is the combination of orders we have been discussing so far, which includes a primary limit order, and two secondary orders (one stop loss, and one take profit).

This is the classic OTOCO setup. The primary order is linked to the two secondary orders via OTO, and the two secondary orders are linked to each other via OCO. The labels help make this clear, as all of the orders display the OTO label, as each has an OTO link with another order. The two secondary orders, the SL and TP, have the OCO label, showing that they are linked to each other via OCO.

The SL and TP also currently have the Queued label. This is because those orders have not actually been placed yet; they are queued behind the primary order. Only when the primary order is filled will they be placed, and lose the Queued label.

Using conditional orders in the UI vs the API

In the Deribit website user interface, the possible combinations of conditional orders has been deliberately limited. A single TP and SL can be added per primary order. There is also some input validation, to ensure that the prices selected for the secondary orders are the ‘correct’ side of the primary order. The size of the secondary orders also always matches that of the primary order.

These limitations are there to protect UI traders from entering combinations of orders that are almost certainly bad for the trader. The API however does not have these protections in place. So it is possible to create more exotic combinations, for example more than two secondary orders per primary order. However, it is also easier to create combinations that would lead to undesirable behaviour, such as a stop loss that, due to the prices chosen, would always immediately close the position as soon as the position is opened.

Order Types

A primary order can be any of the available order types on Deribit. However, a take profit can only be one of the following:

Limit order
Take limit
Take market

And a stop loss can only be one of the following:

Trailing stop
Stop limit
Stop market

Testing

There are simply too many possibilities for us to cover every combination of orders, sizes and directions in an educational lesson. Therefore it is important for all users (via web, mobile, and API) to do some testing to make sure that the order types they plan to use in their own trading behave in the way they expect them to. This testing can be done without risking any funds at test.deribit.com. API users should pay particular attention to testing conditional orders, as there are less ‘common sense’ checks for orders sent via the API. It is assumed an API user has taken care on their end to construct the combination of orders in the way they wish.

Incremental fills

Conditional orders placed via the UI have incremental fills turned on. This is a setting that means that when the primary order receives only a partial fill, a proportional amount of the secondary orders will then be placed.

For example, imagine we have an order to buy $100 of the BTC perpetual, and a conditional TP and SL of the same size attached to this order. If $20 of the primary order is filled, then $20 of the secondary orders will then be placed. The remainder will still be waiting for the rest of the primary order to be filled.