bitshares
New BSIP: Conditional order - stop-limit, OSO, etc.
Motivation
There are multiple order types that makes trading much more convenient that are available on other exchanges and not available on BitShares. They usually are conditional and are based on the price. There are multiple examples of such order types: Stop-loss, Take profit, Stop-limit, OSO, OCO. We believe that adding this highly convenient trading tools would make BitShares much more attractive to many traders.
Abstract
A topic of Stop or conditional orders has appeared a few times in the forums and on the github.
A stop-limit order is an order to place a regular buy or sell order (also known as a "limit order") when the highest bid or lowest ask reaches a specified price, known as the "stop." This can be helpful for protecting profits or minimizing losses. Traders can create stop-limit orders with specified limit and stop prices.
Our understanding is that exposing the conditional orders to public might jeopardize trading for the the trader who put the order. Hence, the biggest challenge is to hide this kind of orders from everybody except the trader and the blockchain And we think that solving this technical challenge is quintessential for this BSIP.
Please let us know your thoughts, OpenLedger team
I like this idea, we should discuss it in more details first of all. It is something like smart contracts. So traders can configure their strategies to work automatically. It is some kind of new abstraction level with scripting different behaviors based on such variables as: price, feed_price, settlement_price, highest_bid_price, lowest_ask_price, etc ... We should also include logical and comparison operations (like AND, OR, NOT, EQUAL, NOT EQUAL, LESS, MORE, LESS or EQUAL, MORE or EQUAL, ...) for such variables so traders can add dynamically different conditions and as many as desired in the her/his list so execution of such list of conditions of the order will return TRUE or FALSE, thus means execute order or not. So traders can adjust conditions for variables and order will be executed when those conditions will be TRUE. Just my thoughts ... Need to think and research more. Also very important will be to use in such orders variable like fill_percents for traders will be very useful to set how much must be filled this order in percents, so 100% means must be fully filled, with this variable traders can control more flexible execution of the order by conditions.
Opening note: I am not against the idea. I just want to open a dialog on how to possibly mitigate some of the hurdles.
Triggering an order based on price is difficult. Brokers in the US often include disclaimers sent at least once per year that explain stop orders are on a "best effort" basis, and are not guaranteed. In a distributed system, the problems get harder.
Here is the first question. What is the price? Is it the most recent price feed? Is it the average of the price feed? Perhaps the last trade price on the Bitshares exchange? Maybe the price from another exchange?
If the price relies on other transactions, when do we rely on the price? As soon as we see it? When it appears in a block? When the block becomes irreversible? What happens when the transaction is rolled back (i.e. forks)?
These questions do not all need answers to continue, but they will eventually need answers.
imho this can be implemented also as 3rd party app.
different prices are different variables which can be used in conditional orders, the same for irreversible or not must exists such variable
Why we need to change BitShares core to integrate it ? This can be implemented as 3rd party app based on BitShares API.
Why we need to change BitShares core to integrate it ? This can be implemented as 3rd party app based on BitShares API.
The distributed nature of the BitShares network has advantages. As a 3rd party application, conditional orders would not execute if the server(s) the application was running on failed.
Hence, the biggest challenge is to hide this kind of orders from everybody except the trader and the blockchain
Did you already have ideas on that? Especially the latter?
Did you already have ideas on that? Especially the latter?
Not yet, we have just started looking into the technical stuff.
All the recent proposals are to get the feeling if it these are needed features for the community.
More sophisitcated orders are something many in the community want, I see that very often pop up in trader channels and others. But they need an abstract concept on how to hide them while still being on the blockchain, to avoid them being gamed.
Why we need to change BitShares core to integrate it ? This can be implemented as 3rd party app based on BitShares API.
Another reason, aside from server downtime, as @jmjatlanta mentioned, is premature broadcast.
In other words, in order for this to work as a 3rd-party app, it seems to me that a user would have to submit a signed order, and rely on the 3rd-party to broadcast it only when the conditions are met. (Perhaps there is another way? This is just the first to come to mind for me.) But, if the order is snooped or else accidentally broadcast too soon, it would execute under the wrong conditions. If the correct conditions were encoded within the order itself, then the user would have some protection against this.
(This brings up another question though, which is how to cancel an order of this type. What if the 3rd-party accidentally broadcasts after the user "canceled"? To solve this, one of the "conditions" in the order could be some random "cancel code" which must NOT have been broadcast and signed by the same party that signed the conditional order.)
If an off chain solution is considered, you can build a 3rd party app using the upcoming custom active authorities. Create a named key that is only allowed to sell a certain amount of an asset, but not the other way. You always have the option to revoke the custom authority, which means the 3rd party can't sign anymore if you want to cancel.
The UI has price alerts in the latest version, this could be easily expanded to a locally run stop loss.
IMHO price triggered actions should be caused by 3rd parties. With custom operation permissions, this can even be done without risking funds. Basically, what you want to do is
- execute and action,
- based on a trigger.
If you store the action and the trigger on-chain, they are there for everyone to see and abuse. If you store only the action on chain (in a proposal) and let some 3rd party do the triggering, you can have stop-limit orders and alike without any other change than custom operations (BSIP44)
We have done an investigation and, unfortunately, we have not found any ways to hide the information in the blockchain :( So at this point the idea is only valid if we decide to keep the orders open to public...
OR have a 3rd party service available that can take advantage of upcoming custome active authorities as mentioned by @sschiessl-bcp.
IMHO price triggered actions should be caused by 3rd parties. With custom operation permissions, this can even be done without risking funds. Basically, what you want to do is
- execute and action,
- based on a trigger.
If you store the action and the trigger on-chain, they are there for everyone to see and abuse. If you store only the action on chain (in a proposal) and let some 3rd party do the triggering, you can have stop-limit orders and alike without any other change than custom operations (BSIP44)
@xeroc I am not sure i understood you correctly.
Let's say e have a stop-limit order of buying 10 BTC for bitUSD , with stop-price 4000 and limit price 4100.
DO you suggest to pubish a limit order of 10 BTC for 4100 but make it a proposed transaction.
Meanwhile 3rd party would hide the trigerring stop of 4000??
In this case, people can still see the limit price and volumes.
@xeroc I am not sure i understood you correctly.
Let's say e have a stop-limit order of buying 10 BTC for bitUSD , with stop-price 4000 and limit price 4100. DO you suggest to pubish a limit order of 10 BTC for 4100 but make it a proposed transaction. Meanwhile 3rd party would hide the trigerring stop of 4000??
Correct
In this case, people can still see the limit price and volumes.
but not the price limit that triggers execution
OSO has been implemented now, we can close this issue unless you want further changes?
