-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fee model for Asset listing #42
Comments
Regarding the above idea to use DAO voting: |
Very smart. |
I think the fee for listing only make sense if there is a fee before a merge happens. That way no energy is spent on review and merge of assets that never get used. To pay the fee it makes sense with a proof of burn of BSQ. That is the only way to pay to the project rather than to (a group of) individuals. To have proof of burn implemented as a concept in the DAO sounds good, it would then be a good way to pay the project as a whole for any kind of service. I'm strongly against any kind of systematic voting on listing assets before the fact. It would clog up the voting and render the DAO a lot less useful. If anything it would always be possible to create de-list proposals before an asset is listed if it's a controversial asset. |
@sqrrm Paying before merge/release is problematic as we need a date when the trial/warmup period starts and we don't want to manage that manually in the code. So the fee tx would be a good candidate but then if the asset issuer is paying the fee and the warmup period starts and it takes another 1-2 months for release we get issues here... Making a PR and get an asset listed has already some costs, so I hope that is enough to keep assets out which never pay any fee and are inavtive by default. If it happens once in a while I think we can live with it. |
Here is a more detailed version of the proposal: OverviewWe want to introduce a small fee for listing an asset. As we have seen from our past assets >90% never gets traded and the effort it causes on our side is not worth the value added to Bisq. After listing has started there is a trial period where the asset is not checked for trading activity. After that it must have been traded with a volume of at least 0.01 BTC. Those paramets can be changed as well by voting. If an asset gets delisted due inactivity it will be hidden from the UI. If anyone wants to get the asset re-listed he can pay a BSQ fee. Once paid the asset get re-activated for another trial period and then the activity check starts again. It can be de-listed again if not traded in the trial period. The trial period lenght is defined by the amount of fee paid. Initially 1 BSQ/day (144 blocks) is set. So with a 90 BSQ fee payment the trail period is 3 months. The trial period is also the time frame used to look back for trading activity. E.g. 3 months trial means the first 3 months there is no activity check, and after that there have to be a volume of 0.01 BTC reached. In case an asset gets removed by a remove asset proposal which got accepted at the DAO voting it will be delisted forever and cannot be added again. Once the delisting got triggered trade activity is not checked anymore and only fee payment for re-listing will trigger that an asset becomes visible again. With the initial parmeters the costs for re-listing is higher then the costs for making a self trade to avoid delisting, but we prefer to not disrupt the current unrestricted model too much by requiring a big amount of trades as well we don't want to set the re-listing fee too low. We also want to avoid too much discussion and friction, so we prefer to be on the very moderate side. Technical impelmentationThe 'Remove asset proposal' is already implemented as well as the code for checking for trade activity. What is missing is the fee payment and the check for the fee payment as well as the automated de-listing and option for re-listing by paying a fee again.
We will add a new feature for burning BSQ and adding a hash to the opReturn to that tx. There will be a new tx type for that (PROOF_OF_BURN_TX). The hash is created from a marker string + the ticker symbol ("listingFeeFor-"+tickerSymbol). There will be a whitelist for already added coins which will be exlcuded from that check. Thought those can be delsited duw inactivity as well and then can be re-listed by fee payment. Only the initial listing fee is not required. Default trial period for those whitlisted assets is 4 months. Once an asset is added to a new release they need to pay the listing fee, only then the asset will be visible and from that moment on the asset will start it's trial period. Here are the possible states:
|
I uploaded here a video to demonstrate the implementation: |
@ManfredKarrer I think this an ok proposal as it handles a lot of the issues that we have. Hopefully it's enough that there is a fee to be paid to deter people from frivolously creating PRs for every new asset that will never be traded. This way the amount of work to review the PRs is lessened which is to me the main purpose of the listing fee. |
Nobody is foreced to review or merge. As it happens now if nobody do that voluntarily it is simply not happening. Maybe some will start to offer payment for the reviewer to spend time on that. |
Even nobody upvoted I saw in the comments sufficient support. It is implemented already. I leave it open for reference/information. |
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.
One downside is that if we get a lot of requests we have many proposals for those assets and the more relevant proposals get a bit lost. We have about 20 new listings in some month. It also adds data which are stored forever. The DAO voting is not designed for the use case of 100s of proposals.
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.
Combine voting with fee
We could use for the initial list the voting and then to extend the "warmup phase" we can use fees.
I think a tool to get a deactivated asset re-activated again is important. Repeated voting might be one way but I think fees are easier and better here.
The text was updated successfully, but these errors were encountered: