From 8bc2a40e469c667fa7156d5b95e443edd61a480e Mon Sep 17 00:00:00 2001 From: abitmore Date: Fri, 16 Feb 2018 22:48:21 +0000 Subject: [PATCH 1/8] 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 2/8] 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 3/8] 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 7480447b88c9d1bfdbb3b345e74cb743edd66bb3 Mon Sep 17 00:00:00 2001 From: Abit Date: Sat, 17 Feb 2018 22:35:53 +0100 Subject: [PATCH 4/8] 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 c8be764e1f74edef6104d03459219dece2b789c9 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 12:45:22 +0000 Subject: [PATCH 5/8] 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 dcaa2e88915d86ce36b7be7ae0b1a2444da25dd6 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 13:23:39 +0000 Subject: [PATCH 6/8] 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 b5e469742a90ea1713aee9e5fe5eb854821b9ea9 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 20:12:46 +0000 Subject: [PATCH 7/8] 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 8/8] 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