[bisq-network/proposals] Connect traders and contributors more closely by extending the fee model (#280)

[chimp1984]

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

This proposal consists of 2 parts which are closely connected:
- Extend fee model: Users see the required funds for achieving the next milestone and can choose how much they are willing to contribute to that by paying a higher trade fee as currently.
- Add a milestone cycle where contributors commit to projects and estimate costs

### "Pay as you wish" like fee model

We change the current trade fee field to a slider which gets initially set to the estimated required fee to fund the next milestone. The user can move the slider to a min. value which can be the current fee and to a max. value of maybe the double amount of the suggested value.

Of coures there should be some link to the milestone definition and the UI should make it easy to understand that the user has here direct influence about how Bisq gets improved.

#### Example: 
Lets say the commited work for next milestone is estimated to cost 30 000 USD. Assume the revenue from the last milestone has been 15 000 USD. The average fee in % was 0.1% for maker and 0.6% for taker.
As we would need to earn 2 times on fees to be able to fund the milestone we suggest to the users to pay a maker fee of 0.2% and a taker fee of 1.2%. The maker can move the slider to 0.1% of to 0.4% and the taker can move it to 0.6% and to 2.4%. So it is up to the user how much he is willing to support the development of the next milestone. If the majority of users accept the suggested value the revenue from fees should be roughly enough to fund the milestone (if trade volume was more or less similar as past cycle). 

#### Indicate supporters
The makers average deviation from the suggested value should be shown in the offers. So if a maker always gave 50% more as suggested he gets a 50% score. If he went even higher to 100% (max) he gets a 100% score and in the other direction if he only paid the min. fee he has a score  of -100%. This score is then displayed with his offer and takers can choose to take an offer from a maker who supported Bisq or of one who did not care about future improvements. 

For the taker its a bit harder but we can show it in the trade process, so it can have a positive or negative impact on the tolerance in the trade (e.g. if taker is a bit slow with reaction maker might be more tolerant and not open a dispute too quickly if he sees that taker is a Bisq supporter by having a  good score. 

The score data is not a security feature for reputation but more a social badge like people get when they have donated to a charity. As like in such cases it cannot be really verified and it should not be over-interpreted. To make it verifiable is probably difficult specially in context of privacy protection (but have not thought about it further). Even if we think that it is not safe enough to use that "add on" feature the basic model does not depend on that and we could drop that. But I think its should help to amplify the acceptance and success chances that the funding goals is met. There is a reason why charities use that feature as well - we are social animals. 
And the hurdle to manipulate the code to fake that is too high for 99% of users to become a problem, and if one fakes it he does not create real damage. So I think the benefit out-weight the risk of abuse.

We should take a lot of care on wording and design for that feature. It is a social element and based more on emotions than other parts in Bisq. 

And in general I think we should become more aware of the social character and potential of Bisq and should emphasise such elements more in future (as trader chat has been a huge success). Trading on Bisq is a social experience very different to trading on a centralised exchange. But thats maybe a topic for a dedicated proposal....

I hope @pedromvpg can help us here to get the UI right!


### Commitment to milestones

I think some of the reasons why the productivity of Bisq is not at the level we would like to see it, are based on mis-aligned incentives:
1. Revenue from trade fees are not sufficient for paying for professional work, so contributors see it as a hobby project and with a hobby project attitude we are not able to improve Bisq to the required level to grow 
2. No incentives to take responsibility and drive things forward 

To improve that situation I suggest to make contribution to Bisq more orientated to commitments on milestones.
The fee model extension discussed above gives a better chance to get professional funding for professional work and aligns more closely contributions with the users needs.

#### Application of projects

Any contributor can make a proposal for a project or even a less clearly defined commitment (like committing to work 40/h a week for 1 month) for the next milestone which is the next planned release. Larger project have to be broken down to smaller ones to fit into a milestone.

As we have roughly a 1 months release cycle this is a good time period to make it easier for estimation and delivery. Once a proposal has been made other contributors can discuss and up/down vote it (Github is sufficient for that). If it gets rough consensus it is part of the next milestone. Once the deadline for the applications is met we sum up the estimated costs of the projects and that results in the funding goal for that milestone. At that point we calculate how much the fee need to be changed to reach that funding goal (can go up or down). In our example above we used a 100% increase, this factor is then published in the P2P network (TDB how, maybe we use the filter object) and is used for every fee payment from that moment on until the next cycles funding goal is defined.

#### Delivery

Once the milestone is over (release) we check which projects got delivered. Those which got delivered will become subject to compensation requests. For not delivered projects it need to be discussed why they failed and if they should be canceled or moved to the next cycle. If contributors over-promise and under-deliver they will lose their reputation and will have it harder in future milestones to get included. Goal is to have a high delivery rate. 

The details how to organise that have to be discussed and refined but I would suggest to keep it as light-weight as possible. It should be also very flexible to support work which is not that easy to plan (e.g. commitment to work 20 hours/week on bug fixes and performance improvements - hard to know all the details in advance). So I suggest that we start at least with as little overhead as possible and adjust on the way to improve the process over time. 

#### Mixed model

Fix costs should still have their allocated budgets (e.g. operations, support) and are paid independent of the milestone model. But I think we should reduce that to the min. costs (e.g. only pay for server hosting costs) and move maintainance costs to the milestone model to align better with improvement goals.
E.g. If a node costs 50 USD for hosting the contributor get that from the fixed allocated budget. The additional cost for maintaining the node which might be another 50 USD should be moved to milestone model and be connected to goals to be reached. E.g. If the goal is to improve qos by factor 2 operators only get paid if their nodes have reached that goal.
Such will depend a bit if its measurable, but we work on that... 
Main goal is to create the right incentives. Bisq should primarily pay for improvements, if things degrade or stay the same it shows things are wrong and by not paying for that we escalate the problem to get fixed (e.g. if a seed is too unstable and the operator does not get paid he has to pressure devs to fix that).

For support we could also split it in a min payment per case and pay the rest aligened with a reached goal. E.g. goal is to reduce support cases by 5%. If the goal is reached the mediators and refund agent get the allocated payment, if not they don't get paid extra on top of the min. payment. This should help to create the right incentives. Now the incentives are perverted as they earn more if there are more cases. Of course I know that nobody thinks that way and that they try to decrease cases but mis-aligned incentives are a real problem we need to fix. It creates for them pressure to report bugs earlier to devs to bring  number of case down. Currently that is not reflected in the payment model. 

Those suggestions for the mixed models are rough ideas and I dont have very stong opinions on those. I just think that the main problem why we have not improved more in those areas (as in many others) is because we have not set the right incentives, motivations and structures. We need more a "fix-the-problem" culture and fast escalation paths to those who can fix it if its not in the realm of the contributor.

#### What happens if revenue was not sufficient to fund the milestone?
I suggest that we reduce the payout rate in such cases. 
E.g. if we only met 80% of our funding goal each contributor only gets 80% of his estimated costs.
If that happens contributor should improve communication to users to make it more clear why they suggested work has value for users. They also should question if the direction of their work is not aligned with the needs of users? I think this is an excellent tool to bring users and contributors closer together and make it more clear that Bisq contributors work for their users. Of course there will be areas which are harder to "sell" as it requires more contextual knowledge but in general I think users understand whats good for Bisq.

#### What happens if revenue was higher as the requested funds?

A happy problem and probably no action needed here. Just a sign that the DAO works and each BSQ token gets more valuable.

#### Other contributions

Normal contributions outside of the milestone model can still be done, but I would suggest that we keep our budget limits and only fund those if budget is sufficient. 


All that is a rough idea and input and discussion very welcome!



-- 
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/280
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201114/ca0a304b/attachment-0001.html>