64 lines
5.1 KiB
Markdown
64 lines
5.1 KiB
Markdown
BSIP: 0026
|
|
Title: Refund Order Creation Fee in Originally Paid Asset on Cancel
|
|
Authors: Abit More <https://github.com/abitmore>
|
|
Status: Draft
|
|
Type: Protocol
|
|
Created: 2017-10-16
|
|
Discussion: https://bitsharestalk.org/index.php/topic,25153.0.html
|
|
Replaces: 0002
|
|
Worker: TBD
|
|
|
|
# Abstract
|
|
|
|
When a user placing an new order, fee can be paid with another asset but not only BTS. Currently, when the order is cancelled and if not partially filled already, an amount of BTS will be refunded to the user. This BSIP proposes refunding in the originally paid assets but not always BTS.
|
|
|
|
# Motivation
|
|
|
|
Make the asset system easier to use and less vulnerable.
|
|
|
|
# Rational
|
|
|
|
With the asset fee pool feature, asset holders don't need to hold BTS to pay transaction fees. However, after the "Refund Create Order Fees on Cancel" feature introduced in [Graphene issue #445](https://github.com/cryptonomex/graphene/issues/445) as well as [BSIP #2](https://github.com/bitshares/bsips/blob/master/bsip-0002.md), due to the (inappropriate) design / implementation, fee pools often get drained by 3rd-party bots unexpectedly, which renders the fee pool feature hard to use / less useful. This BSIP proposes a protocol change to prevent fee pool draining from happening, while still keeping a similar "Refund Create Order Fees on Cancel" feature in the system. It brings following benefits:
|
|
* If a user created an order with fees paid in one asset, it's more acceptable for her to be refunded in same asset when the order is cancelled.
|
|
* If the same asset paid is refunded, exploiters/bots will be unable to drain the fee pools.
|
|
|
|
# Specifications
|
|
|
|
## Current Design and Implementation
|
|
|
|
Always refund fee in the form of CORE asset (BTS), even if fee was paid with another asset.
|
|
|
|
* When a new order is created, if fees are paid in an asset other than BTS, that fees will be added to the asset's `accumulated_fees` field right away, in the same time some BTS will be deducted from the fee pool according to the asset's CER then be put into the `deferred_fee` field of the new created `limit_order_object`.
|
|
* When the order got filled or partially filled, the BTS in `deferred_fee` field will be directed to referral program.
|
|
* If the order be cancelled manually before partially filled, the BTS in `deferred_fee` field will be sent to the owner's balance.
|
|
* If the order be cancelled automatically due to expiration or too small to fill, a cancellation fee will be deducted from `deferred_fee` but capped by the remaining amount, then the cancellation fee (if any) will be redirected to referral program, the yet remaining amount (if any) in `deferred_fee` will be sent to the order owner's balance.
|
|
|
|
## Proposed Changes
|
|
|
|
Always refund fee in the form of paid asset.
|
|
|
|
* When a new order is created, if fees are paid in an asset other than BTS, store the fees to the new order's `deferred_paid_fee` field (a new field) but not add it to the asset's `accumulated_fees` field right away, in the same time deduct some BTS from the fee pool according to the asset's CER and put it into the `deferred_fee` field of the new created `limit_order_object`. Say, the order owes the system some fees in BTS and owe the asset issuer some fees in that asset.
|
|
* When the order got filled or partially filled, redirect the BTS in `deferred_fee` field to referral program, at the same time send the assets in `deferred_paid_fee` field to the asset's `accumulated_fees` field.
|
|
* If the order be cancelled manually before partially filled, send the BTS in `deferred_fee` field to the asset's fee pool, and send the assets in `deferred_paid_fee` field to the owner's balance.
|
|
* If the order be cancelled automatically due to expiration or too small to fill, deduct a cancellation fee from `deferred_fee` but capped by the remaining amount, then redirect the cancellation fee (if any) to referral program; if the cancellation fee is positive, deduct an amount equals to `round_up(cancellation_fee_in_bts * deferred_paid_fee / deferred_fee_before_deduct)` of assets from `deferred_paid_fee` but capped by the remaining amount then send it to the asset's `accumulated_fees` field; then send the yet remaining amount (if any) in `deferred_fee` to the fee pool, send the yet remaining amount (if any) in `deferred_paid_fee` to the order owner's balance.
|
|
|
|
|
|
# Discussion
|
|
|
|
When creating an asset, with current design, the issuer is forced to put half of creation fee into the new asset's fee pool. But not all people like this feature. It's better if the fee pool filling is optional when creating a new asset.
|
|
|
|
Asset issuers may want a dedicated operation to get out some BTS from the fee pool, for example when accidentally filled too much BTS into the pool. This is discussed in [bitshares-core issue #188](https://github.com/bitshares/bitshares-core/issues/188). If this BSIP is implemented, asset issuers will be no longer able to get out the BTS from the fee pool by cancelling an order.
|
|
|
|
# Summary for Shareholders
|
|
|
|
[to be added]
|
|
|
|
# Copyright
|
|
|
|
This document is placed in the public domain.
|
|
|
|
# See Also
|
|
|
|
* https://github.com/cryptonomex/graphene/issues/445
|
|
* https://github.com/bitshares/bitshares-core/issues/188
|
|
* https://bitsharestalk.org/index.php/topic,25153.0.html
|