2018-02-17 00:33:15 +00:00
|
|
|
BSIP: 0033
|
|
|
|
Title: Maker Orders With Better Prices Take Precedence
|
|
|
|
Author: Abit More <https://github.com/abitmore>
|
|
|
|
Status: Draft
|
|
|
|
Type: Protocol
|
|
|
|
Created: 2018-02-17
|
2018-02-18 10:22:35 +00:00
|
|
|
Discussion: https://github.com/bitshares/bitshares-core/issues/625,
|
|
|
|
https://github.com/bitshares/bitshares-core/issues/453
|
2018-02-17 00:33:15 +00:00
|
|
|
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".
|
|
|
|
|
2018-02-18 12:43:43 +00:00
|
|
|
This BSIP proposes a new behavior: always match taker
|
2018-02-17 00:33:15 +00:00
|
|
|
orders with maker orders with better prices first.
|
|
|
|
|
2018-02-18 10:13:18 +00:00
|
|
|
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.
|
|
|
|
|
2018-02-17 00:33:15 +00:00
|
|
|
# Motivation
|
|
|
|
|
|
|
|
Make the exchange system more user-friendly.
|
|
|
|
|
2018-02-18 13:24:32 +00:00
|
|
|
# Rationale
|
2018-02-17 00:33:15 +00:00
|
|
|
|
|
|
|
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
|
|
|
|
|
2018-02-18 10:13:18 +00:00
|
|
|
## Matching a taker limit order
|
|
|
|
|
2018-02-17 00:33:15 +00:00
|
|
|
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.
|
|
|
|
|
2018-02-18 10:13:18 +00:00
|
|
|
## 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
|
2018-02-18 11:03:20 +00:00
|
|
|
the limit order on the top of the order book when dereferencing.
|
2018-02-18 10:13:18 +00:00
|
|
|
|
2018-02-17 00:33:15 +00:00
|
|
|
# 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
|
2018-02-18 10:22:35 +00:00
|
|
|
* https://github.com/bitshares/bitshares-core/issues/453
|
2018-02-17 00:33:15 +00:00
|
|
|
* https://bitsharestalk.org/index.php?topic=25926.0
|