Connect traders and contributors more closely by extending the fee model #280
Comments
|
Good proposal! I'm currently only aware of the critical bugs board, and issues list as source of things to work on. It would be really useful to know what bugs/new features are prioritized for upcoming releases. Currently the next release milestone is empty. Also it would be a huge plus to see Bisq move closer towards breakeven in terms of costs vs. revenue. |
You are actually very good to pick up quickly important tasks and issues! We lack on maintainance of the issue list and the projects list is also quite out of date and does not reflect well current state of priorities and needs. It would be one area where we need a contributot to be commited to clean that up and to maintain that better. I fear I cannot offer that as I have too much other stuff on my table. But if that proposal gets support you are very welcome to implement it if you are interested! |
|
Good idea. In fact, it could even be rolled-out in phases, where each phase in itself could be a worthwhile improvement, regardless of when or if the next phases are rolled out. For example:
|
|
Extended fee model I like the suggestion in principle. It has a feel of when I go to McDonalds and have the option to donate to charity :) It would good for buyers and sellers to have the option to tip Bisq at the point of sale. I am not sure how paying in BSQ in itself is beneficial for Bisq, don't the BTC fees just get spent on buying BSQ anyway. If someone wanted to tip in BSQ or BTC the benefit to Bisq would be the same? Why limit tips just to BSQ? From a personal point or view it would be great to connect traders and contributors more closely by using the fee model. As a trader I would be happy to pay more in trade fees if contributors where working on solutions which lowered miner fees. For example working to implement SegWit for trade transactions, or in future working to implement payments via the lightning network or other second layer solutions. It makes it easy to pay more in fees if you know you will pay less in total fees. Commitment to milestones I think anything that increases accountability is a positive thing. These proposal look to achieve that. I do not feel I have been around long enough to further comment. |
It was not meant to limit to BSQ.
#279 is the most promising candidate. LN does not support multisig. |
|
Not sure if the underlying problem has been defined somewhere. I assume this is all about increasing benefits in order to finance bisq's growth. I think it's a good idea to ask for support when a transaction is about to happen, seems to be a strategy that works for players in the e-commerce space in a similar manner. A superior way to increase revenues is probably one that contributes to the growth of the plattform by attracting new user groups or making things easier for existing users, so that they use bisq more often. Have you already thought about offering a kind of insurance for buyers that protects them from losses caused by fraud or bugs? There are tons of initiatives in the ETH space that might work as a model. Also I am sure that traders are willing to pay a fee for some type of notification services in case a trade opportunity opens up for them. Once again, I only did a superficial search due to time constraints, maybe this has been discussed already elsewhere. |
|
This proposal has 2 parts. About the first one, I'm not sure if a lot of users are willing to pay more trading fees, and signalling them as Bisq supporters have the already commented risk of being considered by other users as a security feature, which is not. The XMR ultra-privacy oriented user who constantly changes its onion address won't appreciate the badge, although some Bisq enthusiasts might like it. If it's easy to implement, might be a nice feature. About the second one, I second (pun intended) any effort to balance DAO's revenue and costs. |
Yes I agree those examples are not well thought out yet, I just added them to illustrate a bit the direction, but yes it will not be so easy. We also should not get caught in complicate rules but adjust our structures in a way which makes us more productive and driven by individual contributors rather than a leaders like a CEO in a traditional company. Its a challenge how we get there, but I think that idea might bring us closer towards a decentralized AND productive/efficient DAO. |
|
How about this? Mock up of phase 1 per @cd2357 :
Default setting at 2x the minimum trade fee: Maxed out at 5x the minimum trade fee: The minimum fee: |
|
@jmacxx Thanks for the fast input!!! I think we should impl. all 3 phases in one to get better impact, otherwise users might ignore it. @pedromvpg Do you have some suggestion? |
|
Lots of excellent ideas in this proposal. I agree with a lot of what's been said here. One thing I might suggest is starting with a small number of initiatives we know that fees are likely to be enough to fund (and that users would find attractive). I don't think it's realistic to have all high-priority Bisq work funded solely through fees right now. Furthermore -- from a user's perspective, opting to pay more and not seeing the initiative you wanted fully funded is discouraging. Then from a contributor's perspective, there are a number of details we need to figure out, so maybe limiting this mechanism to a small number of initiatives makes sense as we refine the social processes behind it (implement it fully, all 3 phases, but only apply it to initiatives/milestones we know can be funded). |
|
@jmacxx The mockup looks like voluntary fee increase will only apply to BSQ, it should be asked for BTC as well. Looks good. |
|
Indeed both BTC and BSQ trade fees are multiplied by the slider setting, perhaps the screenshots do not make that very clear. |
Yes I agree. Best to have a low target (maybe just 5000 USD extra) and be able to meet the target and give both contributors and supporting traders a success experience.
Absolutely. Thats why it wil be super important to be realistic with estimations and delivery. Yes, after further thinking I think its best to just make this an add-on the the normal process we have. So contributions can be done insidw our budget limited teams or if a project is candidate for this direct user support in that space. We have to be very selective and past reputation will be a factor for acceptance (e.g. its too risky that a new contributor make a projeect promise but does not fulfill it). It also should focus on projects users often request and which are easier to understand from a user perspective. Segwit was a prime example but would have been also difficult as it was a big project. |
As default is BTC and user has to toggle to BSQ I think its clear then that it applies to both. |
|
Crypto transactions & exchanges are all about, or at least an important part, low fees. For me, I don't understand, with questions:
Increased funding for Bisq is always a desired goal, of course.
As for the slider, it looks very good indeed. Perhaps it should also have notches, marking some fee levels, to guide users:
|
Why would anyone who don't care about the reasons why Bisq exist use Bisq and not enjoy the benefits from centralized exchanges? I think we have to be more aware that a P2P exchange never can compete with centralized exchanges for many reasons if the core values we represent are not valued by the user. Some reasons why we never can compete are:
There are for sure more points here but I think those 2 are not that obvious so I wanted to point them out... I think we need to focus on what makes Bisq different and become more aware of the fact that we are unique: No other real fiat dex exist after so many years. Look at Qubes: They are unique. They do not compete with attributes of other mainstream OS like MS or OSX, and even with Linux they compete in a very limited way. Qubes users know that and are committed to a higher learning curve, more hardware driver problems, etc. But they understand the unique value proposition of Qubes and share those values. Thats why they are in. Money (or low fees) is the wrong motivator: But there are quite a lot of Bisq contributors around, not in for the money but because they understand that a censorship resistant and privacy protection Bitcoin exchange is of fundamental importance for the Bitcoin ecosystem.
Sure repuation and privacy are a bit hard to combine. I think there are ways as anyone who is anonymous on communication platforms has also an ID but is not connected to his real life ID so allowing reputation based on an anonymous ID. So if the repuation is based on a dedicated private key which can be controlled by they user to change or keep when switching other IDs (like onion address) there can be build some systems where the use is in control of the balance between reputation and privacy. |
|
I share some of the negative concerns that traders care about lowering their costs and that this wouldn't provide that much value. I particularly agree with the following: I however agree with the underlying sentiment of creating an environment conducive with a better quality of contributions and contributors. And I don't have a good answer to it. |
This existed since long and had basically zero impact. |
|
@chimp1984, thank you for addressing my points. For sure competition with centralized exchanges is difficult at the moment. They provide convenience, quick transactions and flashy marketing always hiding the unpleasant stuff (not your keys, etc.). But Bisq has a very important niche as a decentralized platform with strong censorship resistance and privacy protection. As these pressures grow, more people will turn to Bisq. And keep in mind the crypto/BTC economy has not really taken off, yet. The idea of a voluntary transaction fee donation-bar, where the average user may choose to up fees from 30 to 70 cents, can do little harm on its own. May make a difference, may not. To be discovered. Here is an idea: Add simple color marker to the anonymous id Bisq face for using the fee donations, as:
|
|
I like the spirit of the proposal, and it's spurring a lot of thought on my side. I'll hold off on a more detailed write-up just now, but will say I don't think we should rush into implementing this. Getting it right will require improving how we plan and estimate and budget. This proposal can drive making those improvements. How traders use the proposed variable fee slider will measure how well we're managing our roadmap and telling our overall story. More to come, just wanted to add this quick note for now. |
|
I think the idea did not get more traction or support and can be closed. Also the revenue if Bisq has improved over the past months so the problem field has changed. |
This proposal consists of 2 parts which are closely connected:
Extended 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 the next milestone is estimated to cost 30 000 USD. Assume the revenue from the last milestone has been 15 000 USD. The average fee at the last milestone 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 deviation from the suggested value should be shown in the offer. So if a maker 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 prefer to take an offer from a maker who have supported Bisq.
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 like a social badge like people get when they have donated to a charity.
The promoted score could be verified by the peer in the trade process as then the fee tx becomes visible to the peer (though its not in his wallet as its a wallet foreign tx, so we would need a explorer lookup - which for the start at least seems to be too much of effort for that feature). A fake score could lead to a failed trade so any attempt to scam here would have very negative impact to the scammer. I think the verification can be kept out in the initial implementation as risk for abuse is low and effort for verification not justified as long we don't have a explorer lookup feature in other use cases already implemented.
UI
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. We also need to take care that this feature is not mis-interpreted as secuirty feature (e.g. reputation).
I hope @pedromvpg can help us here to get the UI right!
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....
An unrelated idea is to indicate as well if the maker has paid the fee in BSQ or BTC and give more incentive for BSQ supporters.
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 and unclear responsibilities as well as that the 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
To improve that situation I suggest to make contribution to Bisq more orientated on commitments to milestones.
A contributor who made a project commitment has full responsibility for that. If the PR does not get reviewed in time he has to pressure reviewers. So the contributor is responsible for escalating any problems on the way to succeed with their project.
This "project ownership" orientated thinking should create more clear responsibilities. Every contributor should think in their domain what are the important areas to improve, extract a project out of that and make a commitment to implement that improvement. A project can be small in scale and does not need to be as clearly defined as in the larger projects definition at https://github.com/bisq-network/projects/issues (maybe we should use a diff. term to not confuse it, like commitment?).
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 with fast escalation paths to those who can fix it if its not in the power 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 contributors should improve communication to users to make it more clear why their suggested work has value for users. They also should question if the direction of their work is 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 in such cases.
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.
We have to take care that important work which was not planned for a milestone does not get delayed by that model. So common sense and being flexible should be the key to adjust to whats best in such cases.
All that is a rough idea and input and discussion very welcome!
The text was updated successfully, but these errors were encountered: