From 69ac9dc0676ab0ef496ac26cb321aa8d14277a0b Mon Sep 17 00:00:00 2001 From: abitmore Date: Fri, 16 Feb 2018 09:51:51 +0000 Subject: [PATCH 01/23] Add BSIP 30 --- README.md | 1 + bsip-0030.md | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 72 insertions(+) create mode 100644 bsip-0030.md diff --git a/README.md b/README.md index f6de885..ebbe8bf 100644 --- a/README.md +++ b/README.md @@ -37,3 +37,4 @@ Number | Title | [27](bsip-0027.md) | Asset Issuer Reclaim Fee Pool Funds | Abit More | Protocol | Accepted [28](bsip-0028.md) | Worker Proposal Improvements | Bill Butler | Protocol | Draft [29](bsip-0029.md) | Asset issue change to require owner authority | Fabian Schuh | Protocol | Draft +[30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Draft diff --git a/bsip-0030.md b/bsip-0030.md new file mode 100644 index 0000000..da2ae43 --- /dev/null +++ b/bsip-0030.md @@ -0,0 +1,71 @@ + BSIP: 0030 + Title: Always Allow Increasing Collateral Ratio If Debt Not Increased + Author: Abit More + Status: Draft + Type: Protocol + Created: 2018-02-16 + Discussion: https://github.com/bitshares/bitshares-core/issues/583, + https://github.com/bitshares/bitshares-core/issues/672 + Replaces: - + Worker: To be done + +# Abstract + +Currently, when a short position's collateral ratio is below MCR (a parameter +in price feed: `maintenance_collateral_ratio`) but is not completely filled +immediately due to a lack of enough volume on the opposite side of the market, +it will hang in the market and be waiting for being margin called. + +The owner then can adjust the order's collateral ratio **only if** +* to close the position, or +* the new collateral ratio is above MCR, or +* the call order get completely filled (margin called) immediately. + +While this prevents shorters from maliciously reducing collateral ratio (to +increase possibility of black swan event), it also prevents shorters from +slightly increasing collateral ratio (to decrease possibility of black swan +event). + +This BSIP proposes a mechanism to improve this situation. + +# Motivation + +Make the exchange system more user-friendly. + +# Rational + +The ecosystem would get benefit if shorters are allowed to reduce risks to +themselves while reducing risks to the system at same time. + +Current rules are a bit too strict, which can be loosed to: + +A shorter can adjust the position's collateral ratio **only if** +* to close the position, or +* the new collateral ratio is above MCR, or +* the call order get completely filled (margin called) immediately, or +* **the new ratio is higher than old ratio and debt is not increased** + +# Specifications + +In `do_apply()` function of `call_order_update_evaluator` class, if +finally found the call order still in margin call territory, +* don't throw an exception if `call_obj->collateralization()` is reduced, and +* require `delta_debt` of `call_order_update_operation` to be non-positive. + +# Discussion + +[to be added if any] + +# Summary for Shareholders + +[to be added if any] + +# Copyright + +This document is placed in the public domain. + +# See Also + +* https://github.com/bitshares/bitshares-core/issues/583 +* https://github.com/bitshares/bitshares-core/issues/672 +* https://bitsharestalk.org/index.php?topic=25926.0 From a38836001cb551304f8cf566b37dcf173445463d Mon Sep 17 00:00:00 2001 From: abitmore Date: Fri, 16 Feb 2018 22:01:13 +0000 Subject: [PATCH 02/23] Add BSIP 31 --- bsip-0031.md | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 bsip-0031.md diff --git a/bsip-0031.md b/bsip-0031.md new file mode 100644 index 0000000..55a5b70 --- /dev/null +++ b/bsip-0031.md @@ -0,0 +1,65 @@ + BSIP: 0031 + Title: Update Short Position's Margin Call Price After Partially Called Or Settled + Author: Abit More + Status: Draft + Type: Protocol + Created: 2018-02-16 + Discussion: https://github.com/bitshares/bitshares-core/issues/343, + https://github.com/bitshares/bitshares-core/issues/649 + Replaces: - + Worker: To be done + +# Abstract + +Currently, when a short position get partially called or settled, the call +price won't change, that said, even if its actual collateral ratio is higher +than others, higher than minimum required, it will still be selling collateral +at a low price, taking precedence over other short positions. + +This behavior is causing several issues: +* it's somehow unfair, thus brought bad experience to shorters, and +* it prevents black swan event from being triggered in time when needed, + because the collateral ratio of the 2nd even overall short positions may + be too low but not being checked, thus risks the pegging system. + +This BSIP proposes a mechanism to improve this situation. + +# Motivation + +Make the exchange system more user-friendly. + +# Rational + +To attract more users, the system should be fair, should be well balanced. + +It's common sense that short positions with least collateral ratio should +get margin called first. This can be achieved if always update the margin +call price after every fill. + +# Specifications + +In `fill_order( const call_order_object& ...)` function of `database` class, +update `call_price` field of `call_order_object` after debt or collateral +changed to a non-zero value. + +In addtion, after `call_price` get updated, the iterators initialized with +`by_price` index may be invalidated, so need to review / revise involved code, +E.G. `check_call_orders(...)` function of `database` class. + +# Discussion + +[to be added if any] + +# Summary for Shareholders + +[to be added if any] + +# Copyright + +This document is placed in the public domain. + +# See Also + +* https://github.com/bitshares/bitshares-core/issues/343 +* https://github.com/bitshares/bitshares-core/issues/649 +* https://bitsharestalk.org/index.php?topic=25926.0 From 8bc2a40e469c667fa7156d5b95e443edd61a480e Mon Sep 17 00:00:00 2001 From: abitmore Date: Fri, 16 Feb 2018 22:48:21 +0000 Subject: [PATCH 03/23] Add BSIP 32 --- bsip-0032.md | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 bsip-0032.md diff --git a/bsip-0032.md b/bsip-0032.md new file mode 100644 index 0000000..26a8432 --- /dev/null +++ b/bsip-0032.md @@ -0,0 +1,69 @@ + BSIP: 0032 + Title: Always Match Orders At Maker Price + Author: Abit More + Status: Draft + Type: Protocol + Created: 2018-02-16 + Discussion: https://github.com/bitshares/bitshares-core/issues/338 + Replaces: - + Worker: To be done + +# Abstract + +Currently, under most circumstances, when matching two orders, the maker price +will be used. That said, the order that is placed earlier sets a price, +another order that is placed later accepts the price, thus a match, two orders +pay to each other at that price. For example, if one person (A) placed a limit +order to sell 100 BTS at 0.1 USD per BTS, another person (B) then placed a new +limit order to buy 100 BTS at 0.105 USD per BTS, the two orders will match at +0.1 USD per BTS, so A will pay 100 BTS and get 10 USD, B will pay 10 USD and +get 100 BTS. + +However, when matching a taker limit order with a maker margin call order, +the taker price is being used. For example, if trader A's margin call order is +selling 100 BTS at no less than 0.1 USD per BTS, then trader B placed an order +that buys 100 BTS at 0.105 USD per BTS, the two order will match at 0.105 USD +per BTS, so A will pay 100 BTS and get 10.5 USD, B will pay 10.5 USD and get +100 BTS. + +This BSIP proposes a mechanism to change this behavior: always match orders +at maker price. + +# Motivation + +Make the exchange system more user-friendly. + +# Rational + +To attract more users, the system should be fair. + +It's common sense that orders should be matched at maker price. + +# Specifications + +There is a parameter in price feed named MSSR, which stands for "maximum short +squeeze ratio". Maker price of margin call orders is MSSP, which stands for +"maximum short squeeze price", is calculated as `feed_price / ( 100% + MSSR )`. +Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per +collateral". + +Matching between a limit order and a call order is done in +`check_call_orders(...)` function of `database` class, price of limit order +is always used. It need to be changed to use MSSP when the call order is maker. + +# Discussion + +[to be added if any] + +# Summary for Shareholders + +[to be added if any] + +# Copyright + +This document is placed in the public domain. + +# See Also + +* https://github.com/bitshares/bitshares-core/issues/338 +* https://bitsharestalk.org/index.php?topic=25926.0 From 2723cc73b6b1cfd3ef06eeb0f440dd7267688a58 Mon Sep 17 00:00:00 2001 From: abitmore Date: Fri, 16 Feb 2018 23:41:39 +0000 Subject: [PATCH 04/23] bsip32: add when to check for black swan event --- bsip-0032.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/bsip-0032.md b/bsip-0032.md index 26a8432..d87b9d7 100644 --- a/bsip-0032.md +++ b/bsip-0032.md @@ -51,6 +51,29 @@ Matching between a limit order and a call order is done in `check_call_orders(...)` function of `database` class, price of limit order is always used. It need to be changed to use MSSP when the call order is maker. +Currently a black swan event will occur when the call order with least +collateral ratio is going to be matched below 100% collateral ratio price +(name it CRP). Because the call order will be matched with incoming limit order +at limit order's price (taker price), +which can be higher or lower than CRP, so even if MSSP is +below CRP, an incoming taker limit order may or may not trigger a black swan. +So it makes sense to check if a black swan event will occur every time when a +limit order is created. + +After the behavior changed to always match at maker price, when MSSP is below +CRP, an incoming taker limit order will always trigger a black swan event. +So it makes sense to trigger the black swan event when MSSP is below CRP rather +than waiting for an incoming limit order. That means it's no longer needed to +check for black swan event when a limit order is created. Since checking for +black swan event is somehow expensive, we'll gain a side benefit on performance +with the change. + +When triggering a black swan event when MSSP is below CRP, sometimes the short +position with least collateral ratio may still have more than 100% collateral +ratio. In this case, the global settlement price is CRP but not the actual +collateral ratio of the short position with least collateral ratio. +This is current behavior, it's fair, no need to change. + # Discussion [to be added if any] From 7f291d9b0622f10c7224243497026a43d16677bb Mon Sep 17 00:00:00 2001 From: abitmore Date: Sat, 17 Feb 2018 00:02:11 +0000 Subject: [PATCH 05/23] bsip32: minor wording change. --- bsip-0032.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0032.md b/bsip-0032.md index d87b9d7..1b7938f 100644 --- a/bsip-0032.md +++ b/bsip-0032.md @@ -26,7 +26,7 @@ that buys 100 BTS at 0.105 USD per BTS, the two order will match at 0.105 USD per BTS, so A will pay 100 BTS and get 10.5 USD, B will pay 10.5 USD and get 100 BTS. -This BSIP proposes a mechanism to change this behavior: always match orders +This BSIP proposes a mechanism to change this behavior to: always match orders at maker price. # Motivation From c6dbe1880e0250212729339977de0d54077d8bc6 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sat, 17 Feb 2018 00:33:15 +0000 Subject: [PATCH 06/23] Add BSIP 33 --- bsip-0033.md | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 bsip-0033.md diff --git a/bsip-0033.md b/bsip-0033.md new file mode 100644 index 0000000..4b44795 --- /dev/null +++ b/bsip-0033.md @@ -0,0 +1,82 @@ + BSIP: 0033 + Title: Maker Orders With Better Prices Take Precedence + Author: Abit More + Status: Draft + Type: Protocol + Created: 2018-02-17 + Discussion: https://github.com/bitshares/bitshares-core/issues/625 + Replaces: - + Worker: To be done + +# Abstract + +Currently, when matching taker limit orders with maker limit orders, the maker +limit orders with better prices will always be matched first. + +For example, if trader A has a limit order selling 100 BTS at +0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, +which means B's limit order has a better price for the opposite side to buy. +Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, B's +limit order will take precedence, A's limit order won't be matched. + +However, when there are margin call orders in the market which have met the +requirements that to be matched, they always take precedence over limit orders +on the same side, no matter whether the limit orders provided better price. + +For example, if trader A's margin call order is selling 100 BTS at no less than +0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, +which means B's limit order has a better price for the opposite side to buy. +Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's +margin call order will take precedence, B's limit order won't be matched. That +means C is forced to "buy high" when have chance to "buy low". + +This BSIP proposes a mechanism to change this behavior to: always match taker +orders with maker orders with better prices first. + +# Motivation + +Make the exchange system more user-friendly. + +# Rational + +To attract more users, the system should be fair. + +It's common sense that, in a continuous trading market, new orders should be +matched with the orders on the opposite side which offerred best prices first. + +# Specifications + +There is a parameter in price feed named MSSR, which stands for "maximum short +squeeze ratio". Maker price of margin call orders is MSSP, which stands for +"maximum short squeeze price", is calculated as `feed_price / ( 100% + MSSR )`. +Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per +collateral". + +New limit order is being processed in `apply_order(...)` function of `database` +class. + +Currently, in the function, firstly call orders will be checked and matched. +After that, limit orders on the opposite side will be checked and matched. + +Need to change the logic to: +* match the new limit order with limit orders on the opposite side whose price + is below MSSP first, +* if the new order is still there, match it with call orders, +* if the new order is still there, match it with rest limit orders. + +# Discussion + +[to be added if any] + +# Summary for Shareholders + +[to be added if any] + +# Copyright + +This document is placed in the public domain. + +# See Also + +* https://github.com/bitshares/bitshares-core/issues/625 +* https://bitsharestalk.org/index.php?topic=25926.0 From 7480447b88c9d1bfdbb3b345e74cb743edd66bb3 Mon Sep 17 00:00:00 2001 From: Abit Date: Sat, 17 Feb 2018 22:35:53 +0100 Subject: [PATCH 07/23] bsip32: wording change about MSSP and 100CRP --- bsip-0032.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/bsip-0032.md b/bsip-0032.md index 1b7938f..1c2f3c9 100644 --- a/bsip-0032.md +++ b/bsip-0032.md @@ -43,7 +43,7 @@ It's common sense that orders should be matched at maker price. There is a parameter in price feed named MSSR, which stands for "maximum short squeeze ratio". Maker price of margin call orders is MSSP, which stands for -"maximum short squeeze price", is calculated as `feed_price / ( 100% + MSSR )`. +"maximum short squeeze price", is calculated as `feed_price / MSSR`. Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per collateral". @@ -53,24 +53,25 @@ is always used. It need to be changed to use MSSP when the call order is maker. Currently a black swan event will occur when the call order with least collateral ratio is going to be matched below 100% collateral ratio price -(name it CRP). Because the call order will be matched with incoming limit order -at limit order's price (taker price), -which can be higher or lower than CRP, so even if MSSP is -below CRP, an incoming taker limit order may or may not trigger a black swan. +(name it `100CRP`). Because the call order will be matched with incoming limit +order at limit order's price (taker price), +which can be higher or lower than 100CRP, so even if MSSP is below 100CRP, +an incoming taker limit order may or may not trigger a black swan. So it makes sense to check if a black swan event will occur every time when a limit order is created. After the behavior changed to always match at maker price, when MSSP is below -CRP, an incoming taker limit order will always trigger a black swan event. -So it makes sense to trigger the black swan event when MSSP is below CRP rather -than waiting for an incoming limit order. That means it's no longer needed to -check for black swan event when a limit order is created. Since checking for -black swan event is somehow expensive, we'll gain a side benefit on performance -with the change. +100CRP, an incoming taker limit order will always trigger a black swan event. +So it makes sense to trigger the black swan event when MSSP is below 100CRP +rather than waiting for an incoming limit order. That means it's no longer +needed to check for black swan event when a limit order is created. +Since checking for black swan event is somehow expensive, we'll gain a side +benefit on performance with the change. -When triggering a black swan event when MSSP is below CRP, sometimes the short +When triggering a black swan event when MSSP is below 100CRP, +sometimes the short position with least collateral ratio may still have more than 100% collateral -ratio. In this case, the global settlement price is CRP but not the actual +ratio. In this case, the global settlement price is 100CRP but not the actual collateral ratio of the short position with least collateral ratio. This is current behavior, it's fair, no need to change. From 97ed0755552d8b505f5318d11453c1431a82b14a Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 10:13:18 +0000 Subject: [PATCH 08/23] bsip33: add text about processing taker call order --- bsip-0033.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/bsip-0033.md b/bsip-0033.md index 4b44795..f1218e5 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -33,6 +33,11 @@ means C is forced to "buy high" when have chance to "buy low". This BSIP proposes a mechanism to change this behavior to: always match taker orders with maker orders with better prices first. +This BSIP also sets a principle for dealing with [bitshares-core +issue #453](https://github.com/bitshares/bitshares-core/issues/453). +In that issue, it's described that sometimes a taker margin call order may be +matched with a maker limit order which is not on the top of the order book. + # Motivation Make the exchange system more user-friendly. @@ -46,6 +51,8 @@ matched with the orders on the opposite side which offerred best prices first. # Specifications +## Matching a taker limit order + There is a parameter in price feed named MSSR, which stands for "maximum short squeeze ratio". Maker price of margin call orders is MSSP, which stands for "maximum short squeeze price", is calculated as `feed_price / ( 100% + MSSR )`. @@ -64,6 +71,23 @@ Need to change the logic to: * if the new order is still there, match it with call orders, * if the new order is still there, match it with rest limit orders. +## Matching taker margin call orders + +For [bitshares-core +issue #453](https://github.com/bitshares/bitshares-core/issues/453), +in `check_call_orders(...)` function of `database` class, +iterator `limit_itr` will move forward when variable `filled_limit` is `true`. +`filled_limit` will be set to `true` when a limit order get completely filled. +However, since `filled_limit` is declared out of the `while` block, +it doesn't get reset to `false` after `limit_itr` moved forward. That means +after the first limit order get completedly filled, `filled_limit` will always +be `true`, so `limit_itr` will always move forward no matter whether *current* +limit order got completedly filled, so a taker call order may match +with a limit order that is not on the top of the order book. + +To fix this, need to change the code to make sure `limit_itr` always references +the limit order on the top of the order book. + # Discussion [to be added if any] From 6878d6461f7ccfd3c93d87c6bd6da53996c6ee85 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 10:22:35 +0000 Subject: [PATCH 09/23] bsip33: add link to bitshares-core issue No. 453 --- bsip-0033.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index f1218e5..096fbaa 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -4,7 +4,8 @@ Status: Draft Type: Protocol Created: 2018-02-17 - Discussion: https://github.com/bitshares/bitshares-core/issues/625 + Discussion: https://github.com/bitshares/bitshares-core/issues/625, + https://github.com/bitshares/bitshares-core/issues/453 Replaces: - Worker: To be done @@ -103,4 +104,5 @@ This document is placed in the public domain. # See Also * https://github.com/bitshares/bitshares-core/issues/625 +* https://github.com/bitshares/bitshares-core/issues/453 * https://bitsharestalk.org/index.php?topic=25926.0 From b57ab2139924fff7920fd5bcc0cdbcb982c8762f Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 11:03:20 +0000 Subject: [PATCH 10/23] bsip33: minor wording change --- bsip-0033.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index 096fbaa..c56adea 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -87,7 +87,7 @@ limit order got completedly filled, so a taker call order may match with a limit order that is not on the top of the order book. To fix this, need to change the code to make sure `limit_itr` always references -the limit order on the top of the order book. +the limit order on the top of the order book when dereferencing. # Discussion From 6579c464c20c5463af9ad9895dd9b82be08312cd Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 12:43:43 +0000 Subject: [PATCH 11/23] bsip33: minor wording change --- bsip-0033.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index c56adea..a2dff50 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -31,7 +31,7 @@ Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's margin call order will take precedence, B's limit order won't be matched. That means C is forced to "buy high" when have chance to "buy low". -This BSIP proposes a mechanism to change this behavior to: always match taker +This BSIP proposes a new behavior: always match taker orders with maker orders with better prices first. This BSIP also sets a principle for dealing with [bitshares-core From c8be764e1f74edef6104d03459219dece2b789c9 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 12:45:22 +0000 Subject: [PATCH 12/23] bsip32: minor wording change --- bsip-0032.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bsip-0032.md b/bsip-0032.md index 1c2f3c9..40ea3d5 100644 --- a/bsip-0032.md +++ b/bsip-0032.md @@ -26,8 +26,7 @@ that buys 100 BTS at 0.105 USD per BTS, the two order will match at 0.105 USD per BTS, so A will pay 100 BTS and get 10.5 USD, B will pay 10.5 USD and get 100 BTS. -This BSIP proposes a mechanism to change this behavior to: always match orders -at maker price. +This BSIP proposes a new behavior: always match orders at maker price. # Motivation From 2255360034ad7e04f976604bc576413688444df5 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 13:22:19 +0000 Subject: [PATCH 13/23] bsip30: fix typo --- bsip-0030.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0030.md b/bsip-0030.md index da2ae43..11340d0 100644 --- a/bsip-0030.md +++ b/bsip-0030.md @@ -32,7 +32,7 @@ This BSIP proposes a mechanism to improve this situation. Make the exchange system more user-friendly. -# Rational +# Rationale The ecosystem would get benefit if shorters are allowed to reduce risks to themselves while reducing risks to the system at same time. From f350d86af9ce7c4c078301a7342ed4ec768c081f Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 13:23:02 +0000 Subject: [PATCH 14/23] bsip31: fix typo --- bsip-0031.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0031.md b/bsip-0031.md index 55a5b70..e4fe09a 100644 --- a/bsip-0031.md +++ b/bsip-0031.md @@ -28,7 +28,7 @@ This BSIP proposes a mechanism to improve this situation. Make the exchange system more user-friendly. -# Rational +# Rationale To attract more users, the system should be fair, should be well balanced. From dcaa2e88915d86ce36b7be7ae0b1a2444da25dd6 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 13:23:39 +0000 Subject: [PATCH 15/23] bsip32: fix typo --- bsip-0032.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0032.md b/bsip-0032.md index 40ea3d5..1dc87a6 100644 --- a/bsip-0032.md +++ b/bsip-0032.md @@ -32,7 +32,7 @@ This BSIP proposes a new behavior: always match orders at maker price. Make the exchange system more user-friendly. -# Rational +# Rationale To attract more users, the system should be fair. From 09a6529d66cca31699923e5e76af2e2e066cc356 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 13:24:32 +0000 Subject: [PATCH 16/23] bsip33: fix typo --- bsip-0033.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index a2dff50..06d5409 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -43,7 +43,7 @@ matched with a maker limit order which is not on the top of the order book. Make the exchange system more user-friendly. -# Rational +# Rationale To attract more users, the system should be fair. From f086fdfd373441266322467137052d6cd00060e8 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 15:17:25 +0000 Subject: [PATCH 17/23] Add BSIP 34 --- bsip-0034.md | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 bsip-0034.md diff --git a/bsip-0034.md b/bsip-0034.md new file mode 100644 index 0000000..444a381 --- /dev/null +++ b/bsip-0034.md @@ -0,0 +1,97 @@ + BSIP: 0034 + Title: Always Trigger Margin Call When Call Price Above Or At Price Feed + Author: Abit More + Status: Draft + Type: Protocol + Created: 2018-02-18 + Discussion: https://github.com/bitshares/bitshares-core/issues/606 + Replaces: - + Worker: To be done + +# Abstract + +To avoid ambiguity, in this article, all prices are in terms of +`debt asset / collateral asset`, aka how much debt asset per collateral +asset. A bid is an order to buy collateral asset with debt asset. + +Generally, a short position may be margin called when its collateral ratio is +below or equal to maintenance collateral ratio (MCR). + +However, to calculate collateral ratio, a fair collateral price is needed. + +In BitShares, there are two data sources can be used to decide the fair +collateral price: +* the internal market +* the price feeds + +Currently, both data sources are used. Specifically, collateral price is decided +as the higher one between the highest bid price on the internal market and the +median price feed. That said, when a short position's collateral ratio has +fallen to below or equal to MCR according to median price feed (in this case, +call price of the short position is above or equal to median price feed), if +there is a bid on the market with high price, the short position won't be margin +called. + +This mechanism has led to certain confusion and anger among market participants. +* there are often orders with overlapping price on the book but didn't fill +* there are often short positions selling collaterals with low prices, but + traders are unable to buy at those prices +* it often causes borrowers to sell collaterals at a low price when have chances + to sell at higher price +* market manipulators / arbitrage traders have more chances to force borrowers + to sell collaterals at lower price + +This BSIP proposes a new behavior to improve the situation: derive the fair +collateral price only from price feeds. + +# Motivation + +Make the exchange system easier to understand and more user-friendly. + +# Rationale + +Since price feeds are provided by a set of chosen producers, the median price +feed is usually considered trustworthy. On the other hand, instant market +price is not as reliable, especially for the markets with poor depth, so it's +a rather limited supplement for calculating collateral price. Depth of internal +markets could be greatly improved in the future, however price feed producers +can always adjust their algorithm to include internal market data. + +At this moment, changing the rule to only use median price feed will clear away +the confusion the end users may have, while still keeping the derived collateral +price fair to an extent. + +After this change is done, placing a new limit order will no longer trigger a +margin call, cancelling a limit order or expiring a limit order will no longer +trigger a margin call as well, that means we don't need to check for new margin +calls nor black swan events in those scenarios, so we'll gain a side benefit on +performance. + +# Specifications + +In `check_call_orders(...)` function of `database` class, when matching a call +order with a limit order, there is a check: +`if( match_price > ~call_itr->call_price )`, when the result is `true`, +processing will be ended and `margin_called` will be returned. +Need to skip the check and the following `return` action. + +In `do_apply(...)` function of `limit_order_cancel_evaluator` class, and +similar code blocks after a limit order object is removed, no longer need to +call `check_call_orders(...)` function of `database` class. + +# Discussion + +[to be added if any] + +# Summary for Shareholders + +[to be added if any] + +# Copyright + +This document is placed in the public domain. + +# See Also + +* https://github.com/bitshares/bitshares-core/issues/606 +* https://bitsharestalk.org/index.php?topic=25926.0 From 219b3089b469610d69b06b23f347a828a89b1e18 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 19:28:56 +0000 Subject: [PATCH 18/23] Update readme for BSIP 31 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index ebbe8bf..4d10615 100644 --- a/README.md +++ b/README.md @@ -38,3 +38,4 @@ Number | Title | [28](bsip-0028.md) | Worker Proposal Improvements | Bill Butler | Protocol | Draft [29](bsip-0029.md) | Asset issue change to require owner authority | Fabian Schuh | Protocol | Draft [30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Draft +[31](bsip-0031.md) | Update Short Position's Margin Call Price After Partially Called Or Settled | Abit More | Protocol | Draft From b5e469742a90ea1713aee9e5fe5eb854821b9ea9 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 20:12:46 +0000 Subject: [PATCH 19/23] Update README.md for BSIP 32 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 4d10615..1558fe5 100644 --- a/README.md +++ b/README.md @@ -39,3 +39,4 @@ Number | Title | [29](bsip-0029.md) | Asset issue change to require owner authority | Fabian Schuh | Protocol | Draft [30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Draft [31](bsip-0031.md) | Update Short Position's Margin Call Price After Partially Called Or Settled | Abit More | Protocol | Draft +[32](bsip-0032.md) | Always Match Orders At Maker Price | Abit More | Protocol | Draft From 21f3d15cbcf9ae563c1b13211d9450b016247131 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 21:19:57 +0000 Subject: [PATCH 20/23] bsip32: text reorganization --- bsip-0032.md | 52 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/bsip-0032.md b/bsip-0032.md index 1dc87a6..61b1025 100644 --- a/bsip-0032.md +++ b/bsip-0032.md @@ -11,34 +11,41 @@ # Abstract Currently, under most circumstances, when matching two orders, the maker price -will be used. That said, the order that is placed earlier sets a price, -another order that is placed later accepts the price, thus a match, two orders -pay to each other at that price. For example, if one person (A) placed a limit +will be used to calculate how much each order will pay and receive. +However, when matching a taker limit order with a maker margin call order, +the taker price is being used. + +This BSIP proposes a principle: always match orders at maker price. + +# Motivation + +Generally, the order that is placed earlier (the maker) sets a price, +another order that is placed later (the taker) accepts the price, thus a match, +two orders pay to each other at that price. + +Take the pure limit order matching mechanism in BitShares as an example: +If one person (A) placed a limit order to sell 100 BTS at 0.1 USD per BTS, another person (B) then placed a new limit order to buy 100 BTS at 0.105 USD per BTS, the two orders will match at 0.1 USD per BTS, so A will pay 100 BTS and get 10 USD, B will pay 10 USD and get 100 BTS. -However, when matching a taker limit order with a maker margin call order, -the taker price is being used. For example, if trader A's margin call order is +However, in BitShares, when matching a taker limit order with a maker margin +call order, the taker price is being used. +For example, if trader A's margin call order is selling 100 BTS at no less than 0.1 USD per BTS, then trader B placed an order that buys 100 BTS at 0.105 USD per BTS, the two order will match at 0.105 USD per BTS, so A will pay 100 BTS and get 10.5 USD, B will pay 10.5 USD and get 100 BTS. -This BSIP proposes a new behavior: always match orders at maker price. - -# Motivation - -Make the exchange system more user-friendly. +While not strictly a bug, this behavior is unexpected and irritating for users. # Rationale -To attract more users, the system should be fair. - -It's common sense that orders should be matched at maker price. - -# Specifications +Matching orders at the maker price, with margin calls being inlined in the +order book, is an easy to understand rule and matches user expectations, +see [bitshares-core +issue #338](https://github.com/bitshares/bitshares-core/issues/338). There is a parameter in price feed named MSSR, which stands for "maximum short squeeze ratio". Maker price of margin call orders is MSSP, which stands for @@ -46,10 +53,6 @@ squeeze ratio". Maker price of margin call orders is MSSP, which stands for Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per collateral". -Matching between a limit order and a call order is done in -`check_call_orders(...)` function of `database` class, price of limit order -is always used. It need to be changed to use MSSP when the call order is maker. - Currently a black swan event will occur when the call order with least collateral ratio is going to be matched below 100% collateral ratio price (name it `100CRP`). Because the call order will be matched with incoming limit @@ -67,6 +70,12 @@ needed to check for black swan event when a limit order is created. Since checking for black swan event is somehow expensive, we'll gain a side benefit on performance with the change. +# Specifications + +Matching between a limit order and a call order is done in +`check_call_orders(...)` function of `database` class, price of limit order +is always used. It need to be changed to use MSSP when the call order is maker. + When triggering a black swan event when MSSP is below 100CRP, sometimes the short position with least collateral ratio may still have more than 100% collateral @@ -76,7 +85,10 @@ This is current behavior, it's fair, no need to change. # Discussion -[to be added if any] +It might seem unfair on the shorter to match at MSSP even if the incoming order +specifies a better price. However, in a rationally acting market users will not, +in the presence of margin calls, create limit orders below the MSSP. +Effectively the new rule doesn't change this situation. # Summary for Shareholders From f22084690073f8631803be2d5c93ff30c9f5b71e Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 21:56:55 +0000 Subject: [PATCH 21/23] bsip34: wording change and text reorganization --- bsip-0034.md | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/bsip-0034.md b/bsip-0034.md index 444a381..1635b38 100644 --- a/bsip-0034.md +++ b/bsip-0034.md @@ -10,6 +10,19 @@ # Abstract +Currently, in BitShares, a short position may be margin called only when both +two requirements are met: +* call price is above or equal to median price feed +* no limit order on the book is buying collateral with price higher than the + short position's call price + +This behavior has led to certain confusion and anger among market participants. + +This BSIP proposes a new behavior to improve the situation: drop the second +requirement, trigger margin call when the first requirement is met. + +# Motivation + To avoid ambiguity, in this article, all prices are in terms of `debt asset / collateral asset`, aka how much debt asset per collateral asset. A bid is an order to buy collateral asset with debt asset. @@ -41,21 +54,15 @@ This mechanism has led to certain confusion and anger among market participants. * market manipulators / arbitrage traders have more chances to force borrowers to sell collaterals at lower price -This BSIP proposes a new behavior to improve the situation: derive the fair -collateral price only from price feeds. - -# Motivation - -Make the exchange system easier to understand and more user-friendly. +This BSIP effectively proposes a new behavior: derive the fair collateral price +only from price feeds. # Rationale Since price feeds are provided by a set of chosen producers, the median price feed is usually considered trustworthy. On the other hand, instant market price is not as reliable, especially for the markets with poor depth, so it's -a rather limited supplement for calculating collateral price. Depth of internal -markets could be greatly improved in the future, however price feed producers -can always adjust their algorithm to include internal market data. +a rather limited supplement for calculating collateral price. At this moment, changing the rule to only use median price feed will clear away the confusion the end users may have, while still keeping the derived collateral From 27e1975b2843bd3ea9a9a95785bba5da51e27ba4 Mon Sep 17 00:00:00 2001 From: abitmore Date: Mon, 19 Feb 2018 10:53:41 +0000 Subject: [PATCH 22/23] bsip33: text reorganization --- bsip-0033.md | 84 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 56 insertions(+), 28 deletions(-) diff --git a/bsip-0033.md b/bsip-0033.md index 06d5409..4fe4e4b 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -11,7 +11,16 @@ # Abstract -Currently, when matching taker limit orders with maker limit orders, the maker +Currently, in BitShares, under certian circumstances, a taker order may be +matched with a maker order which is not "on the top" of the order book. +This behavior is unexpected and irritating for users. + +This BSIP proposes a principle: always match taker orders with maker orders +with the best prices (aka on the top of the order book) first. + +# Motivation + +As expected, when matching taker limit orders with maker limit orders, the maker limit orders with better prices will always be matched first. For example, if trader A has a limit order selling 100 BTS at @@ -20,46 +29,62 @@ which means B's limit order has a better price for the opposite side to buy. Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, B's limit order will take precedence, A's limit order won't be matched. -However, when there are margin call orders in the market which have met the -requirements that to be matched, they always take precedence over limit orders -on the same side, no matter whether the limit orders provided better price. +However, when there are (maker) margin call orders in the market which have met +the requirements that to be matched (able to be margin called), they always +take precedence over the (maker) limit orders on the same side, no matter +whether the limit orders provided better price. For example, if trader A's margin call order is selling 100 BTS at no less than 0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, which means B's limit order has a better price for the opposite side to buy. Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's margin call order will take precedence, B's limit order won't be matched. That -means C is forced to "buy high" when have chance to "buy low". +means C is forced to "buy high" when have chance to "buy low", which is +unexpected. -This BSIP proposes a new behavior: always match taker -orders with maker orders with better prices first. +Users have been confused by this behavior, as discussed in [bitshares-core +issue #625](https://github.com/bitshares/bitshares-core/issues/625) and other +threads. -This BSIP also sets a principle for dealing with [bitshares-core -issue #453](https://github.com/bitshares/bitshares-core/issues/453). -In that issue, it's described that sometimes a taker margin call order may be -matched with a maker limit order which is not on the top of the order book. - -# Motivation - -Make the exchange system more user-friendly. +Another scenario is described in [Bitshares-core +issue #453](https://github.com/bitshares/bitshares-core/issues/453) +that sometimes a taker margin call order may be matched with a maker limit order +which is not on the top of the order book. This can be seen as a bug. # Rationale -To attract more users, the system should be fair. +Always matching taker order (e.g. a buy) with a maker order which offered best +price (aka lowest ask), is a simpler rule which most users would understand +easily. + +There is a parameter in price feed named MSSR, which stands for "maximum short +squeeze ratio". Maker price of margin call orders is MSSP, which stands for +"maximum short squeeze price", is calculated as `feed_price / MSSR`. +Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per +collateral". + +That said, the price that margin call orders are offering is MSSP. The prices +those limit orders are offering are the limit prices. + +When placing a limit (e.g. buy) order with a price beyond the lowest sell, +the order is expected to "walk the book", matching each order on the opposite +side in turn, at that order's price, until the new limit order is completely +filled, or there is no more sell order matching its price. + +To meet the expectation, +* firstly, we need to match the limit buy order with the limit sell orders + whose prices are lower than MSSP and prices can match the new order; +* then, if the new limit buy order hasn't been completely filled, match it with + the margin calls if MSSP can match the new order's price; +* then, if the new limit buy order still hasn't been completely filled, match it + with the rest sell orders until it's completely filled or no more sell order + matching its price -It's common sense that, in a continuous trading market, new orders should be -matched with the orders on the opposite side which offerred best prices first. # Specifications ## Matching a taker limit order -There is a parameter in price feed named MSSR, which stands for "maximum short -squeeze ratio". Maker price of margin call orders is MSSP, which stands for -"maximum short squeeze price", is calculated as `feed_price / ( 100% + MSSR )`. -Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per -collateral". - New limit order is being processed in `apply_order(...)` function of `database` class. @@ -67,10 +92,13 @@ Currently, in the function, firstly call orders will be checked and matched. After that, limit orders on the opposite side will be checked and matched. Need to change the logic to: -* match the new limit order with limit orders on the opposite side whose price - is below MSSP first, -* if the new order is still there, match it with call orders, -* if the new order is still there, match it with rest limit orders. +1. firstly, sort the limit orders on the opposite by `price`, best price first, + end at MSSP; check them one by one, calls `match(...)` function until the + return value is not `2` which means the new order is completely filled; +2. if reach the end (MSSP), which means the new order is still unfilled, + call `check_call_orders(..)` function or an equivalent; +3. check if `new_order_object` still exist, if yes, redo step one but set the + maximum possible price of the market as end price. ## Matching taker margin call orders From ece1658e000d7b611ca0152ce02c49b80fa898d6 Mon Sep 17 00:00:00 2001 From: Fabian Schuh Date: Thu, 22 Feb 2018 12:22:59 +0100 Subject: [PATCH 23/23] Update Readme --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 1558fe5..9e50470 100644 --- a/README.md +++ b/README.md @@ -40,3 +40,5 @@ Number | Title | [30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Draft [31](bsip-0031.md) | Update Short Position's Margin Call Price After Partially Called Or Settled | Abit More | Protocol | Draft [32](bsip-0032.md) | Always Match Orders At Maker Price | Abit More | Protocol | Draft +[33](bsip-0033.md) | Maker Orders With Better Prices Take Precedence | Abit More | Protocol | Draft +[34](bsip-0034.md) | Always Trigger Margin Call When Call Price Above Or At Price Feed | Abit More | Protocol | Draft