bsip35: update logic of matching limit and call
This commit is contained in:
parent
5fabc12f16
commit
dceedb9d43
1 changed files with 16 additions and 12 deletions
28
bsip-0035.md
28
bsip-0035.md
|
@ -158,16 +158,17 @@ the solutions.
|
||||||
However, when filling a small order at a less favorable price, the receiving
|
However, when filling a small order at a less favorable price, the receiving
|
||||||
amount is often rounded down to zero, thus causes the something-for-nothing
|
amount is often rounded down to zero, thus causes the something-for-nothing
|
||||||
issue. Current code tried to solve the issue by cancelling the smaller order
|
issue. Current code tried to solve the issue by cancelling the smaller order
|
||||||
when it would receive nothing, but only applied this rule in a few senarios:
|
when it would receive nothing, but only applied this rule in a few senarios
|
||||||
|
(the processed parties won't be paying something for nothing):
|
||||||
* when matching two limit orders, processed the maker
|
* when matching two limit orders, processed the maker
|
||||||
* when matching a maker limit order with a call order, processed the maker
|
|
||||||
* when matching a limit order with a call order, processed the call order
|
* when matching a limit order with a call order, processed the call order
|
||||||
* when matching a settle order with a call order, processed the call order
|
* when matching a settle order with a call order, processed the call order
|
||||||
* when globally settling, processed the call order
|
* when globally settling, processed the call order
|
||||||
|
|
||||||
Other senarios that need to be processed as well:
|
Other senarios that need to be processed as well (these to-be-processed parties
|
||||||
|
may be paying something for nothing in current system):
|
||||||
* when matching two limit orders, process the taker
|
* when matching two limit orders, process the taker
|
||||||
* when matching a taker limit order with a call order, process the taker
|
* when matching a limit order with a call order, process the limit order
|
||||||
* when matching a force settle order with a call order, process the settle order
|
* when matching a force settle order with a call order, process the settle order
|
||||||
* when globally settling, process the settlement fund
|
* when globally settling, process the settlement fund
|
||||||
|
|
||||||
|
@ -181,12 +182,15 @@ The detailed rules proposes in this BSIP (new rules highlighted):
|
||||||
* **if the smaller order would get nothing after the round-down, cancel it**
|
* **if the smaller order would get nothing after the round-down, cancel it**
|
||||||
* when matching a limit order with a call order, in favor of call order,
|
* when matching a limit order with a call order, in favor of call order,
|
||||||
round down receiving collateral amount
|
round down receiving collateral amount
|
||||||
* **if the limit order would get nothing after the round-down, cancel it**
|
* **if the call order is receiving the whole debt (so the short position
|
||||||
|
will be closed) but paying nothing, let it pay 1 Satoshi (round up);**
|
||||||
|
* **otherwise, if the limit order would get nothing after the round-down,
|
||||||
|
cancel it (it's smaller, so safe to cancel)**
|
||||||
* when matching a settle order with a call order, in favor of call order,
|
* when matching a settle order with a call order, in favor of call order,
|
||||||
round down receiving collateral amount
|
round down receiving collateral amount
|
||||||
* **if the settle order would get nothing after the round-down, give it one
|
* **if the settle order would get nothing after the round-down, give it 1
|
||||||
Satoshi (round up); after paid both side, check (and allow) if a black swan
|
Satoshi (round up); after paid both side, check if a black swan event would
|
||||||
is triggered by the round-up**
|
be triggered by the round-up, if yes, trigger it**
|
||||||
* when globally settling, in favor of call order, round down receiving
|
* when globally settling, in favor of call order, round down receiving
|
||||||
collateral amount
|
collateral amount
|
||||||
* **when the asset is not a prediction market, if a call order would pay
|
* **when the asset is not a prediction market, if a call order would pay
|
||||||
|
@ -238,14 +242,14 @@ so the order will be cancelled later.
|
||||||
|
|
||||||
In `check_call_orders(...)` function of `database` class,
|
In `check_call_orders(...)` function of `database` class,
|
||||||
after calculated `order_receives`, check if it is zero.
|
after calculated `order_receives`, check if it is zero.
|
||||||
If the answer is `true`, and the limit order is taker, skip filling and cancel
|
If the answer is `true`,
|
||||||
the limit order.
|
* if `call_receives` is equal to `call_itr->debt`, set `order_receives` to 1;
|
||||||
|
* otherwise, skip filling and cancel the limit order.
|
||||||
|
|
||||||
## When Matching A Settle Order With A Call Order
|
## When Matching A Settle Order With A Call Order
|
||||||
|
|
||||||
In `match( const call_order_object&, ... )` function of `database` class,
|
In `match( const call_order_object&, ... )` function of `database` class,
|
||||||
after calculated `call_pays`, check if it is zero.
|
after calculated `call_pays`, round up it to `1` if it is zero.
|
||||||
If the answer is `true`, round up it to `1`.
|
|
||||||
|
|
||||||
If rounded up, after filled both orders, check and allow a black swan event.
|
If rounded up, after filled both orders, check and allow a black swan event.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue