bsips/bsip-0033.md

    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
    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.

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.

# 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

## 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.

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.

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

# 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