[bisq-network/proposals] Fee model for Asset listing (#42)

Fri Oct 5 21:51:23 UTC 2018

To not mix it up with issue #41 (which is likely to find easier consensus) I will start here a proposal for possible options for fees for Asset listing on Bisq.

There have been also broader discussion in #35 but that has been rejected after longer considerations. 

## Overview
We get too many Asset listing requests and that adds some costs for Bisq contributors to review and merge those assets. Beside that assets which are not traded do not add any value to Bisq, in the opposite they cause bad reputation and usability costs (the user has to scroll through many assets to find the relevant ones, though that is a weak argument ;-)).

There are also some legal aspects we should consider: Many assets are ICO tokens and most of them are at risk to be considered as illegal securities. The SEC has expressed the opinion that exchanges which enable trading of those are violating regulatory rules. We are not lawyers and I think there is no 100% clear opinion about that but it is a fact that adding an ICO token to Bisq adds some legal risks.

Bisq's mission for censorship resistance includes that we don't want to make the decision if an asset is "good enough" or considered legal (in which jurisdiction?) to get listed or not. The DAO voting process will have a feature for removing assets from Bisq so that the stakeholders can make a collective decision here if there is broad consensus.

We also don't want to introduce an "economic censorship" by requiring high listing fees as it is the case on many centralized exchanges (> 100 000 USD in some cases).

We don't want to get spammed by too many assets. Today creating a new asset has close to zero costs and efforts. On CounterParty or Colu there are 100 000s of assets - most have zero relevance. We don't want to get spammed by those.

There have very low costs for asset issuer for adding an asset to Bisq. The requirement to make the PR (address validation) is quite low. So that alone does not work well as spam filter mechanism.  

It has to be clear also that listing an asset does not mean for the asset community that the asset becomes liquid. We see how hard it is to bootstrap markets even in the main currencies. The "coincident of wants" problem is very real. There might be other models which are better suited for the needs of niche assets like Bancor where the asset issuer need to provide some market liquidity programmatically.

## Possible solutions

### Delegate solution to future

Don't change anything and delegate the issue to later and see if it becomes a bigger problem.
Right now the required effort for review and merge is not that extreme that it require a fast solution. So to defer that to the future is a valid option. 
One issue with that is that we are in the finalization of the DAO and some features might be hard to add later if it is part of the DAO consensus protocol. If we want to use BSQ fees in future it would be good to implement that at least as prototype now.

### Simple voting
Adding other non-financial requirements which acts a "spam filter" and demonstrates that the asset has an interested community which might be using Bisq in future once it is listed. I think that is an interesting option but maybe hard to find a good solution which does not lead to getting spammed by marketing from the assets trying to gain more traction and support. Voting for asset listing as it is done on some exchanges is such a way but comes with many problems.

### Use DAO voting to list an asset
The above mentioned problems with voting could be delegated to the DAO which provides benefits over a simple webpage based voting: Manipulating the votes by bots and PR as it would be an issue for traditional webpage based user voting cannot be done with the DAO. Voting requires to hold BSQ, that causes some costs. 

The downside is it will create incentive for asset issues to try to convince the Bisq stakeholders that their asset is the "better Bitcoin". It could be maybe mitigated to make it very clear that unwanted PR on official Bisq channels is considered as spam and BSQ stakeholders should decline such assets in voting. As voting is meritocratic based the BSQ stakeholders who have earned BSQ by work will have the majority voting power, so it will be very hard for asset issues to over-power them by simply buying BSQ on the market. 

Such voting based approach could be automated in the way that any asset which got merged is deactivated by default and only if accepted by voting it will become accessible to the users. 

### Use a fee payment in BSQ
I want to discuss here one fee model which combines a few different aspects.
What if we determine the "warmup" phase where we don't check for trade activity by the fee the asset issues (or anyone who pays the fee) has paid. E.g. per 1 BSQ fee he gets 1 day of additional warmup time. We can have a default min. warmup period of e.g. 30 days which does not require a fee. After that time if there is no fee paid the asset need to have been traded sufficiently as defined in #41.If a fee was paid it will extend that period by the amount of the fee.

Alternatively and to make the implementation easier we could require a low min. fee of say 30 BSQ so the first 30 days are covered by that. Any asset issuer is able to pay 30 USD (assuming here a BSQ/USD rate of 1 BSQ = 1 USD).
The fee can be changed by DAO voting so we can adopt to BSQ price volatility. By delegating the amount of the fee to the BSQ stakeholders we remove as well burden on developers to find a fair value. 

One minor problem is that a asset issuer can get his PR merged but then never pay the fee, so the asset will get deactivated immediately. So it does not prevent that Bisq contributors spend time on review and merge. But I assume that will happen rarely and can be ignored.

#### Implementation of the fee model:
Basic idea is to have a special tx with an opReturn output where the hash of the tickerSymbol is in the data (20 bytes). So we can look up when the tx happened and check the hash. Anyone can do the fee payment.
That scheme could be more generally used for proof of burn. One can keep a pre-image of the hash and proof that he was the one who did the burning (e.g. used for reputation). With signing a nonce from the input for that tx he can additionally proof that he is was the originator of the tx once the pre-image was released publicly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/42
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20181005/cab356ef/attachment-0001.html>