agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

bsip32: text reorganization

Browse source
This commit is contained in:
abitmore 2018-02-18 21:19:57 +00:00
parent b5e469742a
commit 21f3d15cbc
1 changed files with 32 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
bsip-0032.md
View file

@ -11,34 +11,41 @@
# Abstract # Abstract
Currently, under most circumstances, when matching two orders, the maker price 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, will be used to calculate how much each order will pay and receive.
another order that is placed later accepts the price, thus a match, two orders However, when matching a taker limit order with a maker margin call order,
pay to each other at that price. For example, if one person (A) placed a limit 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 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 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 0.1 USD per BTS, so A will pay 100 BTS and get 10 USD, B will pay 10 USD and
get 100 BTS. get 100 BTS.
However, when matching a taker limit order with a maker margin call order, However, in BitShares, when matching a taker limit order with a maker margin
the taker price is being used. For example, if trader A's margin call order is 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 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 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 per BTS, so A will pay 100 BTS and get 10.5 USD, B will pay 10.5 USD and get
100 BTS. 100 BTS.
This BSIP proposes a new behavior: always match orders at maker price. While not strictly a bug, this behavior is unexpected and irritating for users.
# Motivation
Make the exchange system more user-friendly.
# Rationale # Rationale
To attract more users, the system should be fair. 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,
It's common sense that orders should be matched at maker price. see [bitshares-core
issue #338](https://github.com/bitshares/bitshares-core/issues/338).
# Specifications
There is a parameter in price feed named MSSR, which stands for "maximum short 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 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 Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per
collateral". 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 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 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 (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 Since checking for black swan event is somehow expensive, we'll gain a side
benefit on performance with the change. 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, When triggering a black swan event when MSSP is below 100CRP,
sometimes the short sometimes the short
position with least collateral ratio may still have more than 100% collateral 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 # 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 # Summary for Shareholders