One-cancels-other could be safer

[badgerwithagun]

I plan to create a proper OCO implementation, equivalent in effective functionality to Bitfinex's:

• A stop order
• A limit order
• A job with a "flip price" equidistant between the two where it cancels one order and activates the other depending on which side of that price the market currently stands.

So, as the price approaches the target price, the job will maintain a limit order to catch a wick into it. As the price approaches the stop price, the limit order is cancelled and replaced with a proper exchange-side stop (if supported, otherwise a server side stop).

[badgerwithagun]

This is now possible since Orko now supports proper server side stops.

[badgerwithagun]

Urgency of this is now reduced since the existing OCO mechanism is more reliable (it adjusts the trade size down to match the balance) but really a proper OCO where there is permanently a live server side order would be better.

[badgerwithagun]

I've been looking at this on and off and the big problem is how to place an order and record the order id in the Orko database without the risk of a failure between the two operations, leading to Orko losing its reference to the server side order.

The the right answer is clearly to use client order ids, where Orko specifies its own order ID. It can then simply check the exchange to see if such an order is present. This is supported by Binance, but is sketchily supported by other exchanges.

I already use this in {{LImitOrderJobProcessor}} to ensure orders are placed atomically. Looks like this thing will need to do the same thing.