2017-11-11 11:54:17 +01:00

5.1 KiB

Raw Blame History

BSIP: 0026
Title: Refund Order Creation Fee in Originally Paid Asset on Cancel
Authors: Abit More
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 as well as BSIP #2, 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. 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.

5.1 KiB Raw Blame History