New BSIP: Call Order Options (Stop-Loss and etc)

[abitmore]

Just write some thoughts here, perhaps will make a detailed BSIP later. People who have interest can help compose as well.

After bitshares/bitshares-core#343 is fixed, call price of call orders (short positions) will be updated after every match, in favor of consistent margin call process logic and black swan detection. But some traders DO NOT want this behavior, for stop-loss purpose for example.

Here we propose some new options that traders can set onto their call positions:

• target CR: an optional collateral ratio, when the position being automatically liquidized, sell no more than required collateral until CR of the position reaches this value.
  • default: not set, which means sell as much collateral as possible (same to current behavior)
• stop-loss price: an optional price to release (sell) collateral automatically when feed_price is below it (in terms of collateral/debt), the behavior will be placing some collateral on market for sale, at the price equals to feed_price/MSSR, until target CR is reached. (Note: MSSR is a ratio greater than 1)
  • default: not set, which means will sell collateral only when CR < MCR (same to current behavior)
• take-profit price: an optional price to release (sell) collateral automatically when feed_price is above it (in terms of collateral/debt), the behavior will be placing some collateral on market for sale at the specified price to repay the whole debt (capped by debt amount).
  • default: not set, which means never take profit automatically (same to current behavior)

Assuming feed_price is in terms of debt / collateral, e.g. how much CNY per BTS

target_CR = new_collateral / ( new_debt / feed_price )
          = ( collateral - amount_to_sell ) * feed_price / ( debt - amount_to_get )
          = ( collateral - amount_to_sell ) * feed_price / ( debt - amount_to_sell * (feed_price / MSSR) )
=>
amount_to_sell = (debt * target_CR - collateral * feed_price) * MSSR / (target_CR - MSSR) / feed_price

[bitcrab]

I like these proposed logics, I believe they can help smartcoin producers to avoid risks.

[thul3]

Agree on that.Major functions which are very demanded on big exchanges.
If DEX wants to go big this is something it needs

[sunburntcat]

In my personal experience trading, stop-losses are dangerous on relatively illiquid exchanges. Even GDAX exchange has seen intense spikes due to triggered stop-loss orders and margin call events. However, automated if/then orders are an amazing improvement. For example, "if buy bitUSD at $0.96, automatically trigger sell order at $1.04." This sounds like the "take-profit" tool you describe.

[jmjatlanta]

In the US equities world, this is often split into separate orders, managed by the broker's system. The filling of a "parent order" (a.k.a. OSO or "One Sends Other"), even partially, triggers other orders, which are also interrelated.

Child orders can be set up to cancel the others if they are triggered (a.k.a. OCO (One Cancels Other) a.k.a. "Bracket Order")

Example scenario: a parent order is partially or fully filled, triggering stop and limit orders (bracket orders) to be activated with the same size, both of which will cancel the other upon their fill.

Advantages to the client: automation. They do not need to remain connected to manage the order. The plan is in the hands of the broker.

It could also be said that concepts are easy to grasp for the client, as simple orders remain simple. An order is an order. If you don't know what a stop order is, you don't have to use it. If you know what you're doing, you can get fairly complex with combinations of OCO and OSO orders.

The disadvantage is to the broker (in this case, the exchange): They are responsible for execution and the overhead of order management. But this also exists with the "all in one order" originally mentioned.

Just my $0.02

[ghost]

Can't this be implemented on a blockchain wrapper program? What are the side effects of implementing this within the DEX? Performance/security/maintainability?

[pmconrad]

stop-loss/take-profit can be implemented externally. The biggest downside of an external implementation is that it cannot make any guarantees, i. e. it can only create the required transactions and hope that they're executed in time. Another downside is that an external implementation requires hot keys.

An internal implementation would make the already complicated market engine even more complicated. The biggest downside is in fact maintainability. Performance is probably less of a problem.

[ghost]

I don't think a blockchain implementation can guarantee as well. If theres multiple orders near a stop point, and limited opposing orders to fill the stop losses, I don't think it can be guaranteed that all of them will go through at a certain price. I might be wrong though.

[pmconrad]

A blockchain can guarantee certain behaviour. It cannot guarantee that the behaviour makes the user happy. :-)

[ghost]

I just thought about a decent counterargument here. Stop loss data should not be public information since if visible it can be used by other traders as an informational advantage to trade against you. This is why, for example, exchanges like GDAX make stop-loss data private. Is this possible to implement this without revealing the information to other traders?

[jmjatlanta]

Stop-running is a wonderful (often profitable) strategy if you can guess where the stops are. Having them displayed would be great for traders who can push the market a bit.

While I'm a trader at heart, I have to agree with @pmconrad on this one. Stop orders (as well as OCO, OSO, OCA and others) should probably not be visible, nor handled by the blockchain itself. Work through a reliable "connection" that can place your "hidden" order when the conditions are right.

Even stock brokers have issues with the rules around stop orders. i.e. when is the price considered "touched"? At or below? What about bad print protection? etc.

Could hiding such orders be coded into the servers? Yes. Coders can do anything! But it would have to include very tight rules and limits on guarantees to be usable. A lot of requirements would be required. Not everyone would be happy with the result.

On a related note.. perhaps a wallet ("trading platform") with such functionality would be a business opportunity for someone.

[ghost]

On a related note.. perhaps a wallet ("trading platform") with such functionality would be a business opportunity for someone.

The wallet would have to store the user's keys if it stores the stop-loss data on its internal servers and then executes them when the conditions are met. The clients can't be expected to have their wallet open 24/7. Any way around this?

[jmjatlanta]

@arminnaderi I was thinking of a local application (remember those? :-) ) running on an always-on, always connected machine. It ain't perfect, but is an option.

[ghost]

That seems basically the same as having traders run a separate stop-loss program on their machine, pretty much what is available right now. I don't see a business opportunity here :P