abitmore commented 5 years ago

BSIP: 0086
Title: Share market fees to the network
Author: Abit More <https://github.com/abitmore>
Status: Draft
Type: Protocol
Created: 2019-11-29
Discussion: https://github.com/bitshares/bsips/issues/194
Worker: TBD

Abstract

This BSIP proposes a protocol change: when every trade happens, if there are market fees generated, a portion (E.G. 5% or 10%) of the market fees goes to the network.

Motivation

The network needs more tools to generate income to support its development.

Rationale

A major activity in the network is trading assets. The asset owners make profits in the form of market trading fees. Currently, the main tools for the network to generate income from asset trading activities are order creation fee and order cancellation fee. It seems reasonable that the asset owners share some profits (a part of market fees) to the network to support its development.

The cut of market fees can go to committee-account's vesting balances. As a supporting measure, committee-account should be exempted from white-listing restrictions, so that it is able to claim the vesting balances and sell them for core token or other tokens to pay for development later.

Specifications

Protocol upgrade

A time will need to be scheduled for applying the change. In this document, terms "before the protocol upgrade", "at the protocol upgrade" and "after the protocol upgrade" may or may not be used to indicate things happen before the scheduled time, at the scheduled time and after the scheduled time.

New global parameter

Add a new global parameter market_fee_network_percent which can be updated by the committee only after the protocol upgrade. Initial value of that parameter is 0. Valid range of that parameter is [0, 100%].

When processing market fees

After the protocol upgrade, when splitting a non-zero market fee, firstly split amount * market_fee_network_percent (round down) to committee-account, then process the remainder as before. The amount split to committee-account should go to the vesting balance object whose type is market_fee_sharing.

When checking asset authorities

After the protocol upgrade, when checking authorities (E.G. white-lists) of an asset on an account, if the account is committee-account, let it pass.

Discussion

Other than the "coin-days as market fees" proposal which applies a discount to market fees to benefit core token holders directly, this BSIP seeks for a mechanism to increase the network's income and benefit core token holders indirectly.
Adjusting the fee schedule and network percent in the referral program is another option to increase the network's income, and is probably sufficient for funding development.
In the original design, the purpose of market fees is to reward asset issuers for their work (e.g. gateway providers, or businesses built around PMs), while operation fees (limit_order_create/cancel in particular) reward the network for performing its work. The separation of market/operation fees matches the separation of roles. Changing this may damage existing businesses. Thus this BSIP could be a bad idea from this perspective. Also note that the network can profit from market fees by setting them on committee-owned tokens.
This would be another motivation for businesses building on top of BitShares to get involved in the parameter governance process. The percentage can be 0 if it's more appropriate.
Asset owners can specify a zero market fee percentage to get around the "tax", while still profiting by setting a higher deposit/withdrawal fee. It is uncommon nowadays probably because it's less convenient or attractive for their customers.
Another strategy is to charge a network market fee globally, independent of what the asset owner decides. It essentially removes the option to not set a fee from asset owners, which kills some freedom and would hinder non-profit use of the platform.
It's possible that committe-account would accumulate a lot of tokens with no value and tokens which are unable or hard to be used to pay for development. It's a side effect. Hopefully there will be quite some usable tokens. The committee will have to do some work to manage the tokens anyway.

Non-Technical Summary

This BSIP adds a tool for the committee to impose a tax on market trading fees for all assets which enabled market trading fee, thus would potentially increase income for the network to support its development. It may probably damage businesses relying on market fees if the committee-decided tax is high. The committee may need some efforts to manage the income.

Copyright

This document is placed in the public domain.

I can understand that @bitcrab as owner of an exchange running on top of BitShares, he doesn't want to reduce income of his own exchange. But I don't understand where @pmconrad stands. Besides of the near-zero operation fees, the network can always earn more income to support funding for more workers which would add more value.

The network does earn some market fees for the network via committee-owned assets at this moment, but it doesn't mean the income is sufficient nor forever.

shulthz commented 5 years ago

Like Apple Store App, en，how much fees is suitable? not harm the owner of the exchange.

Inmortak commented 5 years ago

Hello guys,

Where can I see the current distribution and kinds of fees?

froooze commented 5 years ago

Like Apple Store App, en，how much fees is suitable? not harm the owner of the exchange.

flat 0.01% on all trades or 5-10% of the trading fees

pmconrad commented 5 years ago

But I don't understand where @pmconrad stands.

I don't have a personal interest in this subject. I have stated my reasoning above.

shulthz commented 5 years ago

Like Apple Store App, en，how much fees is suitable? not harm the owner of the exchange.

flat 0.01% on all trades or 5-10% of the trading fees

en, that's reasonable. As we only have little income now, can't support anyting.

froooze commented 5 years ago

Like Apple Store App, en，how much fees is suitable? not harm the owner of the exchange.

flat 0.01% on all trades or 5-10% of the trading fees

en, that's reasonable. As we only have little income now, can't support anyting.

I suggested some numbers, but I am not convinced this is the right thing.

shulthz commented 5 years ago

Like Apple Store App, en，how much fees is suitable? not harm the owner of the exchange.

flat 0.01% on all trades or 5-10% of the trading fees

en, that's reasonable. As we only have little income now, can't support anyting.

I suggested some numbers, but I am not convinced this is the right thing.

DEX service is not free, if want more better service, it need more reasonable income to support.

froooze commented 5 years ago

DEX service is not free, if want more better service, it need more reasonable income to support.

I agree here, but we can also increase the fee for BURN ASSET!

shulthz commented 5 years ago

DEX service is not free, if want more better service, it need more reasonable income to support.

I agree here, but we can also increase the fee for BURN ASSET!

The income should be diversified，shouldn't be single.

sschiessl-bcp commented 5 years ago

In my understanding, the purpose of market fees is to reward asset issuers for their work (e. g. gateway providers, or businesses built around PMs).

In contrast to this, operation fees (limit_order_create/cancel in particular) reward the network for performing its work. Network effort is independent from the size of an order and therefore fixes.

IMO the existing separation of market/operation fees matches the separation of roles perfectly. Changing this might damage existing businesses. I think this is a bad idea.

(Note that the network can profit from market fees by setting them on committee-owned tokens.)

I agree with the sentiment, if the expectation is met that the current network fee is sufficient to support the network or gateways contribute back to the community. History shows that most gateways are not interested in that, such that I agree that imposing a tax on their profits seems reasonable. This also goes hand in hand with the current voters sentiment that the network needs to fund its own development more outside of worker proposals.

Either way, having the option to impose a percent network fee on the market fees sounds reasonable to me, even if it blurs the distinction Peter has laid out. That parameter could still be 0. This would be another motivation for businesses building ontop of BitShares to get involved in the parameter governance process.

It might also be sufficient to adjust the fee schedule and network percent though. Either or should happen as its the voters expressed opinion at the moment IMO.

abitmore commented 4 years ago

@ryanRfox please assign a number to this. Thanks.

BTW quote from an old post in forum:

... we should also and mainly consider to have a global % trading fee that apply as basic % trading fee that every issuer owe to the network. (it could be very low, since it apply to both side of every market) (at the end of the day the platform allow the issuer to create his asset and manage all the trades, the platform gives him a trading engine, so imo make sense to have a global fee for it)

pmconrad commented 4 years ago

have a global % trading fee that apply as basic % trading fee that every issuer owe to the network

IMO that would be a stupid thing. We have per-asset configurable fees, which means every issuer can configure their assets as they wish. Applying a global fee would remove the option to not set a fee.

sschiessl-bcp commented 4 years ago

have a global % trading fee that apply as basic % trading fee that every issuer owe to the network

IMO that would be a stupid thing. We have per-asset configurable fees, which means every issuer can configure their assets as they wish. Applying a global fee would remove the option to not set a fee.

It's a strategic decision

a) Charge a network market fee cut, iff the asset owner is having a market fee which indicates for-profit use

b) Charge a network market fee globally, independent what the asset owner decides.

Discussion points:

ad a): Gateways can somewhat circumvent paying a network cut by charging a big deposit / withdraw fee and not charge a market fee. Justifiable as a tax to for-profit operations.
ad b): Impact significant, will also cause committe-account to accumulate a lot of Shitcoins. Harder to justify as a). A fee is already always present, just not a % fee.

Explain and let voters decide?

abitmore commented 4 years ago

I've updated OP with a full document. @sschiessl-bcp can we assign a BSIP number to this so that I can create a pull request to discuss the details?

sschiessl-bcp commented 4 years ago

BSIP-86 seems to be free

abitmore commented 4 years ago

Thank you @sschiessl-bcp. PR created: https://github.com/bitshares/bsips/pull/253

bitcrab commented 4 years ago

I now support this BSIP, as a gateway operator I feel it is OK to be taxed 5%-10% of the market fee.

however I am considering whether a global market_fee_network_percent is enough or we need to enable defining the percent per asset?

as under the marketing maker contest scenario, charging tax from gateway asset market fees will make it more reasonable for system to fund the contest, and it seems even more funny if system can demand a higher percent for the assets which are included in the contest funded by system?

sschiessl-bcp commented 4 years ago

I now support this BSIP, as a gateway operator I feel it is OK to be taxed 5%-10% of the market fee.

however I am considering whether a global market_fee_network_percent is enough or we need to enable defining the percent per asset?

as under the marketing maker contest scenario, charging tax from gateway asset market fees will make it more reasonable for system to fund the contest, and it seems even more funny if system can demand a higher percent for the assets which are included in the contest funded by system?

I don't think it's necessary. At the end, we want to make it more interesting for traders to participate. An asset participating in the market making contest could be required to have market fee sharing enabled to a certain percentage.

MichelSantos commented 4 years ago

The concern over what the maximum fee cannot be made on any sort of principle. Once the principle of fee sharing is accepted it is all arbitrary. But the lower the better for the asset issuer.

But every asset issuer in the future will be nervous and reluctant about introducing a new asset because even if the maximum fee is set at, for example, 25%, that asset issuer will remember this BSIP as a warning sign: "Sure, you created an asset where the maximum fee was set at 25%, but let's not kid ourselves. Someone else may come along and introduce a new BSIP which changes the maximum value to 50%. Then 75%." There can be no trust in the platform if core token holders will come along and change the rules under which they originally created the asset.

The same concern will be held by today's asset issuers. If core token holders can change the terms of the platform without the consent of the asset issuer, this is not any sort of agreement. This is a platform that can change at any moment.

Therefore, my personal non-technical recommendation is that this BSIP should not apply to existing assets without the consent of each asset issuer. How this can be achieved depends on whether the asset exists before or after this BSIP takes effect.

Existing Assets

Existing asset issuers must either opt-in or have the ability to opt-out of the effects of this BSIP. Opt-in could be accomplished either by a complete agreement, or with a partial agreement such as, "We agree to pay 60% of the fee sharing %".

Future Assets

Future assets issuers agree to sharing fees at a maximum value of X% that is defined in this BSIP. If any later BSIP is introduced to increase X% then the asset issuer will have the option to opt-in or opt-out as described above for existing assets.

I believe that this is the only fair way to treat asset issuers.

abitmore commented 4 years ago

Thanks for the comments @MichelSantos. IMHO, of course we should think about fairness, however, we also need to be fair to ourselves, a good strategy is to only give out when we afford to. The system is bleeding, the proposal is to mitigate it.

bitcrab commented 4 years ago

Therefore, my personal non-technical recommendation is that this BSIP should not apply to existing assets without the consent of each asset issuer. How this can be achieved depends on whether the asset exists before or after this BSIP takes effect.

Existing Assets

Existing asset issuers must either opt-in or have the ability to opt-out of the effects of this BSIP. Opt-in could be accomplished either by a complete agreement, or with a partial agreement such as, "We agree to pay 60% of the fee sharing %".

Future Assets

Future assets issuers agree to sharing fees at a maximum value of X% that is defined in this BSIP. If any later BSIP is introduced to increase X% then the asset issuer will have the option to opt-in or opt-out as described above for existing assets.

I believe that this is the only fair way to treat asset issuers.

I don't think this is a good idea.

for example, we have several gateways that have ****.BTC, do you think it's good that OPEN.BTC completely opt in however GDEX.BTC can select to opt out?

BTS can change at any time, if there is strong enough consensus, I don't think this is a problem.

tax is compulsory, no government can work without tax. BTS is a DAC, it need to charge enough fees for providing public service.

sschiessl-bcp commented 4 years ago

Approved

litepresence commented 4 years ago

I'm in favor of BSIP 86. VARIABLE rate fees generated from trading are a far better idea than flat rate transaction fees. This is in keeping with the way all centralized exchanges in crypto, forex, and stocks operate. By far it is the most equitable way for the chain to raise revenue. It generates a large amount of income while distributing the tax equally based on trade size.

Just as easily the exchange could increase the limit_order_create and limit_order_cancel FLAT tax... which is a detriment to free market activity and places a far heavier burden on the poor.

While I understand @MichelSantos concern about "changing the rules"; this rule applies to all and distributes the burden based on trade size meaning the percent that the poor pay is the same as the percent that the rich pay. Further, an individual asset owner has the option after this rule is instituted to adjust their market fee to make up for any loss of revenue.

Also, as market fees only apply to completed transactions which are matched on the books, this fee does not discourage the movement of orders, which result in lively order books, such as flat fees on limit order create and cancel operations would.

litepresence commented 4 years ago

This on the other hand, I find highly disappointing. Decision making in a decentralized autonomous company should - by definition - be made by a large, diverse constituency of individual voters. All to often decisions here at BitSharse are made through the acts of 3-4 proxies or other custodial voting arrangements. I think this strikes at the heart of the difference between what constitutes a Howey test "security", where investors are earning based on the decisions and "efforts of others", and what constitutes a "decentralized" entity, where investors are earning based on decisions they themselves effort to make. A BSIP is long overdue to decentralize voting in this community. It is all too easy for collusion, malfeasance, and influence peddling to occur when power is centralized as it currently is.

abitmore commented 4 years ago

A BSIP is long overdue to decentralize voting in this community.

You're free to propose one. Perhaps check BSIP 24 and #83.

froooze commented 4 years ago

A BSIP is long overdue to decentralize voting in this community.

You're free to propose one. Perhaps check BSIP 24 and #83.

BSIP 24 does only increase the problem.

shulthz commented 4 years ago

Valid range of that parameter is [0, 100%].

why is 100%，not should be [0, 1%]?

I think no one like this valid range of that parameter is [0, 100%], too dangerous for a business.

dls-cipher commented 4 years ago

Parameter is being updated to [0, 30%] for the final development. BSIP document clear fix coming in few.

Chee®s

sschiessl-bcp commented 4 years ago

Parameter is being updated to [0, 30%] for the final development. BSIP document clear fix coming in few.

Chee®s

This was explicitly discussed during review and the author decided to keep 100% value. I don't think this change can be considered implicitly approved by author or voters due to that.

Reference: https://github.com/bitshares/bsips/pull/253#discussion_r360285928

shulthz commented 4 years ago

This BSIP86 has legal risk, i suggest everyone need to consider it very carefully and seek a legal consultancy.

When BSIP86 charges the market fees from the GATEWAY.assets, the BTS system will have joint liability and must be responsible for these GATEWAY.assets, but these GATEWAY.assets were without supervision and control by the BTS system.

Gateway just likes the DApp of BTS, BTS just provides the service and takes the transaction fee of blockchain，DApp do what is not the business of BTS, but when BTS charges the market fees of GATEWAY.assets, the nature of things will become different.

bitsharescrude commented 4 years ago

Market fee sharing is a good idea, however I think it should be done on an individual basis, for example a user trading a specific asset, say GATEWAY.BTC can get a share of the market fees from this asset as his reward, the asset owner can specify a certain condition for the user to get this reward, conditions like; must be LTM, user must trade above 1BTC or user must have up to 10BTC deposit monthly, etc. It should not be a forced tax, however should this be implemented as is, asset owners should be given the complete freedom to opt in or not i.e under update asset> charge market fees> share market fee to network> default 0%> adjust to max 100%, in this way asset owners still have full autonomy and can still contribute to the network if they wish to....

bitshares / bsips

BSIP 86: Share market fees to the network #194

Abstract

Motivation

Rationale

Specifications

Protocol upgrade

New global parameter

When processing market fees

When checking asset authorities

Discussion

Non-Technical Summary

Copyright

See Also