Skip to content

Commit ddc4677

Browse files
authored
Merge pull request bitshares#253 from abitmore/bsip86
BSIP 86: Share market fees to the network
2 parents 41ca9ef + eb7729a commit ddc4677

File tree

1 file changed

+121
-0
lines changed

1 file changed

+121
-0
lines changed

bsip-0086.md

Lines changed: 121 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,121 @@
1+
BSIP: 0086
2+
Title: Share market fees to the network
3+
Author: Abit More <https://github.com/abitmore>
4+
Status: Draft
5+
Type: Accepted
6+
Created: 2019-11-29
7+
Discussion: https://github.com/bitshares/bsips/issues/194
8+
Worker: TBD
9+
10+
# Abstract
11+
12+
This BSIP proposes a protocol change: Every time a trade is executed (limit order is filled) and
13+
if there are market fees generated, a portion of the market fees goes to the network.
14+
15+
Example: The network percent of market fees is set to 50%, and 0.2% of trading volume is the set as market fee.
16+
Then 0.1% of trading volume goes to the network.
17+
18+
# Motivation
19+
20+
The network needs more tools to generate income to support its development.
21+
22+
# Rationale
23+
24+
A major activity in the network is trading assets. The asset owners make
25+
profits in the form of market trading fees. Currently, the main tools for the
26+
network to generate income from asset trading activities are order creation
27+
fee and order cancellation fee. It seems reasonable that the asset owners
28+
share some profits (a part of market fees) to the network to support its
29+
development.
30+
31+
The cut of market fees can go to committee-account's vesting balances.
32+
As a supporting measure, committee-account should be exempted from
33+
white-listing restrictions, so that it is able to claim the vesting balances
34+
and sell them for core token or other tokens to pay for development later.
35+
36+
# Specifications
37+
38+
## Protocol upgrade
39+
40+
A time will need to be scheduled for applying the change. In this document,
41+
terms "before the protocol upgrade", "at the protocol upgrade" and "after
42+
the protocol upgrade" may or may not be used to indicate things happen before
43+
the scheduled time, at the scheduled time and after the scheduled time.
44+
45+
## New global parameter
46+
47+
Add a new global parameter `market_fee_network_percent` which can be updated
48+
by the committee only after the protocol upgrade.
49+
Initial value of that parameter is `0%`.
50+
Valid range of that parameter is `[0%, 100%]`.
51+
52+
## When processing market fees
53+
54+
After the protocol upgrade, when splitting a non-zero market fee, firstly
55+
split `amount * market_fee_network_percent` (round down) to committee-account,
56+
then process the remainder as before. The amount split to committee-account
57+
should go to the vesting balance object whose type is `market_fee_sharing`.
58+
59+
## When checking asset authorities
60+
61+
After the protocol upgrade, when checking authorities (E.G. white-lists) of an
62+
asset on an account, if the account is committee-account, let it pass.
63+
64+
# Discussion
65+
66+
* Other than [the "coin-days as market fees" proposal](
67+
https://github.com/bitshares/bsips/issues/191) which applies
68+
a discount to market fees to benefit core token holders directly, this BSIP
69+
seeks for a mechanism to increase the network's income and benefit core token
70+
holders indirectly.
71+
72+
* Adjusting the fee schedule and network percent in the referral program is
73+
another option to increase the network's income, and is probably sufficient
74+
for funding development.
75+
76+
* In the original design, the purpose of market fees is to reward asset
77+
issuers for their work (e.g. gateway providers, or businesses built around
78+
PMs), while operation fees (`limit_order_create/cancel` in particular) reward
79+
the network for performing its work. The separation of market/operation fees
80+
matches the separation of roles. Changing this may damage existing businesses.
81+
Thus this BSIP could be a bad idea from this perspective. Also note that the
82+
network can profit from market fees by setting them on committee-owned tokens.
83+
84+
* This would be another motivation for businesses building on top of BitShares
85+
to get involved in the parameter governance process. The percentage can be
86+
`0` if it is more appropriate.
87+
88+
* Asset owners can specify a zero market fee percentage to get around the fee
89+
sharing, while still profiting by setting a higher deposit/withdrawal fee.
90+
It is uncommon nowadays probably because it is less convenient or attractive
91+
for their customers.
92+
93+
* Another strategy is to charge a network market fee globally, independent of
94+
what the asset owner decides. It essentially removes the option to not set
95+
a fee from asset owners, which kills some freedom and would hinder non-profit
96+
use of the platform.
97+
98+
* It is possible that committee-account would accumulate a lot of tokens with no
99+
value and tokens which are unable or hard to be used to pay for development.
100+
It is a side effect. Hopefully there will be quite some usable tokens.
101+
The committee will have to do some work to manage the tokens anyway.
102+
103+
* The committee will be accumulating tokens which could potentially be used or
104+
not used for any purpose. In other words, this BSIP as currently written does
105+
not stipulate how those tokens will or will not be used by the committee.
106+
107+
# Non-Technical Summary
108+
109+
This BSIP adds a tool for the committee to impose a fee on market trading
110+
fees for all assets which enabled market trading fee, thus it can increase income
111+
for the network to support its development. It may
112+
hinder businesses relying on market fees if the committee-decided fee is high.
113+
The committee may need some efforts to decide on an appropriate value of the parameter and manage the income.
114+
115+
# Copyright
116+
117+
This document is placed in the public domain.
118+
119+
# See Also
120+
121+
* https://github.com/bitshares/bsips/issues/194

0 commit comments

Comments
 (0)