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

bsip33: add text about processing taker call order

Browse source
This commit is contained in:
abitmore 2018-02-18 10:13:18 +00:00
parent c6dbe1880e
commit 97ed075555
1 changed files with 24 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
bsip-0033.md
View file

@ -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]