Distribute BTC trade fees to contributors

[HenrikJannsen]

Overview

This proposal is a part of a series of proposals to remove or reduce the role of the donation address receiver (Burningman).
It covers the part of the BTC trade fees only. The other part (the payout from the delayed payout transactions in case when the traders open an arbitration case) will be handled in a follow up proposal.

###TLDR
In short we want to distribute the BTC trade fee to all contributors who have been active in the past 1.5 years and the selection of the receiver is done by a weighted (by earned BSQ) probabilistic payout. The more one has worked the higher the chance to receive the traders BTC fee. This helps to remove the role fo the burningman. BSQ trade fee are not affected by that change.

Objective

Find an alternative to the current model where the Burningman (BM) is receiving the BTC trade fees, sell the BTC for BSQ and burn the BSQ so that the value goes into the DAO ecosystem.
The main motivation is to remove the role of the BM. A secondary objective is to improve the economic model of Bisq. Burning BSQ as source for value generation which should serve as base to attract contributors seems to have not worked as well as planned.

Suggested change

At the address selection for the trade fee we use the accepted compensation requests of current and past contributors. The period we go back is limited to about 1.5 years (TBD) and there is a linear decay for the weight so that older compensation requests (CR) will get a lower chance to receive the fee. After 1.5 years they will not be considered in the distribution.
The selection use an algorithm to select randomly one receiver from a weighted set, so the payout is probabilistic and should lead over time to a fair distribution based on the weights applied. As the fee payments are small and frequent this should work well.
The weight is derived from the requested BSQ amount of the contribution and the age using the linear decay over 1.5 years.
This direct distribution of the BTC fees to the contributors should increase the payments of contributors and make working on Bisq more attractive.

Details

Custom receiver address

As the BitcoinJ wallet in Bisq is not suited for massive volume of transactions we add an option in the DAO UI that the contributor can add a custom receiver address where they want to receive the trade fees. This data will be appended in the CP data. Using Bitcoin Core is recommended to not run into performance and memory issues when a lot of small transactions are received.

The additional field in the UI for adding a custom receiver address is optional. If not set we use the associated BTC address which was used for funding the compensation request transaction (second input of that transaction is a BTC input). By that the contributor will receive the BTC fees in their Bisq wallet. It is recommended to create a new Bisq app/wallet from time to time to not overload the Bisq wallet.
Past contributors have not associated a custom external BTC address, for those we use the address from the compensation request transaction.

Reduced BSQ payment

Additionally we add a toggle button so that the contributor can decide if they want to receive the requested BSQ amount as defined in the GitHub issue or if they prefer to receive a reduced BSQ amount (10% of the requested amount) and get a booster factor for their weight which results in higher payouts of the fees.

This helps that less BSQ get issued and to not cause inflationary pressure as the BTC trade fee now do not flow back into the BSQ ecosystem directly. With the suggested model only the BSQ trade fees are burned. So that amount should be in balance of the newly issued BSQ for compensation requests.

As the contributor takes more risk of uncertain future revenue from BTC trade fees and some delay as the expected amount will be reached only after a few months and not initially when the voting ends, a booster factor will compensate so that contributors who choose that model will earn more from BTC fees.

Past contributors also have not had the option to request a reduced BSQ amount so their weight will not include the booster factor.

Formula

Model 1 with full requested BSQ amount:

weight = BSQ amount * max(0, (maxAge - age) / maxAge)

Model 2 with reduced requested BSQ amount (10% of requested):

weight = (reduced) BSQ amount * 10 * max(0, (maxAge - age) / maxAge) * 2

Here the reduced BSQ amount is multiplied by 10 to have the same impact as in model 1 but then we multiply it again with 2 as a boost factor for compensating the risk and delay.

Suggested parameters:
MaxAge: 75000 76896 block (1.5 years with 144 blocks/day)
BSQ reduction: 10% of requested BSQ in GitHub issue
Boost factor: 2

All numbers are up for discussion.

Important is to understand that with that model the payment is not like now a one time payment per cycle but a stream of payments over the 1.5 years. The total payment is the sum of the initial BSQ payment + all BTC fee payments over 1.5 years.

Some rough calculations (will add later a post) suggest that contributors will receive about 200-250% more in payment with that model.

Fallback

In case a user has the DAO deactivated they fall back to either the most recent BM address or the default address set in the DAO parameter. Users who are out of sync with the DAO data might use outdated data for the fee selection but as we do not verify the peers fee payment it does not cause any problem.
It would be good if we could find a fallback which does not use the BM address or the DAO parameter address. We can postpone that question once the second part of the BM is resolved and if it turns out that this would be the only remaining task for the BM we might send the fees as donation to a project Bisq supports like Tor.

Updates

As this changes do no touch consensus the parameter used in the algorithm could be updated if needed.

Deployment

The change in the compensation request data requires a staged update process to avoid compatibility issued. We can hide the UI fields for a certain time and set an activation date after which they become visible (e.g. 1 month). 2 weeks after the release we can require a forced update via the Filter tool. This will only affect traders. DAO partizipants need to update as well, but as that is a smaller group that can be communicated via the existing channels. DAO partizipants who have not updated will not receive CR data which use the new fields and their votes might be invalid.
UPDATE: The initial plan to add new fields failed as it would cause invalid hashes for the DAO monitor. Instead we use entries in the extraMap hashmap which does not break any backward compatibility and the deployment does not require anything special.

The change has no critical change in the trade protocol. It just replaces the fee receiver selection with the new model.
At the DAO it changes the compensation request data which needs attention to not break consensus.

Revenue monitoring

The new model might make it harder for monitoring the revenue from BTC fees. But a tool could be built for tracking the received BTCs for each CR to get again a full picture of the revenue data.

Economics

As discussed above this proposal changes the economics of the DAO to some extent.

There will be less demand for BSQ from the BM as those fees now get directly distributed to the contributors. For BSQ stakeholders this might be a disadvantage due lower demand from the BM but also lower supply from contributors - so not clear if it changes much. If the intended effect plays out so that this model attracts more contributors and by that improves Bisq and bring more trade volume and by that also a higher BSQ price, a potentially negative effect should be compensated.

It can be assumed that most contributor will use the reduced BSQ model and by that the amount of newly issued BSQ will get reduced by up to 90%. The amount of BSQ fees in relation to BTC fees is about 20-30%. From the numbers of the past months it suggests that there will be more BSQ burned by fee payments than new BSQ issued by contributors.

Over the past 10 months it seems Bisq made quite some profit by relative low costs on contributor payments.
Bisq had a revenue from BTC fees of about 50k-60k BSQ while spending only 20-30k BSQ on contributors.
The deflationary effect though did not materialize in the BSQ price or liquidity, in the opposite the BSQ price has fallen over the past year from 2 USD to 0.75 USD (probably mostly related to the BTC price). In this market context earning BSQ seems to be not very attractive for contributors.

With the new model contributors will get directly the profit from the BTC fees. If this attracts more contributors and the DAO spends more this extra bonus will get reduced again but more contributors should result in higher trade volume and revenue. Contributors will feel more directly if the project works well or not.

The portion of the BSQ fee can be also tuned by increasing the discount and by that increasing the deflationary force on BSQ if there is need for that.

All in all I guess that the positive effects will be much stronger than potentially negative effects. But like with most in economics, it's guesswork and future will tell us if we have been right.

[HenrikJannsen]

Here some rough estimations how that new model would change payments based on revenue numbers from the DAO charts:

BSQ trade fees: 15k / month
BTC trade fees: 50 / month
Compensation requests: 25k / month

Those numbers are based on 3-6 months averages of the past 12 months.

Lets assume that 10 contributors earn 2500 BSQ/months and half of them use the model with full BSQ payment (model 1) and the rest the model with the reduced BSQ payment (10% of requested BSQ - model 2). We assume each contributor works each cycle over 18 months.

Lets calculate the accumulated weights of all CPs over the 1.5 year (18 cycles) period for both models:
Model 1:
weight of recent CP over 18 cycles = 2500 * 18 / 2 = 22500
accumulated weights of all 18 CPs = 22500 * 18 / 2 = 202500 [1]

Model 2:
weight of recent CP over 18 cycles = 250 * 10 * 18 / 2 * 2 = 45000
accumulated weights of all 18 CPs = 45000 * 18 / 2 = 405000 [1]

Sum of all weights of all 10 contributors over 18 cycles = 5 * 202500 + 5 * 405000 = 3037500
Sum of revenue from BTC fees 18 cycles = 50 000 USD * 18 = 900000 USD
Share of USD per unit of weight = 900000 USD / 3037500 = 0.296 USD

Model 1:
Earning per contributor in 18 cycles = 202500 * 0.296 USD = 60000 USD (3333 USD/month + 2500 BSQ)

Model 2:
Earning per contributor in 18 cycles = 405000 * 0.296 USD = 120000 USD (6666 USD/month + 250 BSQ)

Cross check:
5 contributors with model 1 get: 5 * 60000 = 300000 USD AND 2500 BSQ * 18 * 5 = 225000 BSQ
5 contributors with model 2 get: 5 * 120000 = 600000 USD AND 250 BSQ * 18 * 5 = 22500 BSQ
300000 USD + 600000 USD = 900000 USD = the revenue of 18 months.
225000 BSQ + 22500 BSQ = 247500 BSQ.
15 000 BSQ revenue from BSQ fees over 18 cycles = 270000 BSQ
So we burned more BSQ as we issued (270000 BSQ > 247500 BSQ).

Of course those numbers are very rough and I assume most will use model 2.

If all 10 contributors use model 2 the numbers would be as follows:
Share of USD per unit of weight = 900000 USD / 4050000 = 0.222 USD
Earning per contributor in 18 cycles = 405000 * 0.222 USD = 90000 USD (5000 USD/month + 250 BSQ)
45000 BSQ would be issued which would be much lower than the 270000 burned BSQ, thus creating more deflation.

I think we should set the "boost" factor to a rather high value (2 at the moment) to create enough incentive that most contributors use model 2 and the DAO issue less BSQ.

In that second case contributors will roughly get 2 times more as with the current model, assuming 1 BSQ is 1 USD.
Though at an one time CR it would take about 5 months until the equivalent to 2500 BSQ is received (first cycle 555, second cycle 524, third cycle 493, forth cycle 462,... ).

[1] The way how the accumulated weight is calculated might not be completely correct, might be missing 50% of one CP, but should not make much of a difference in total and numbers are anyway rough guessimates...

[HenrikJannsen]

Unfortunately we cannot use the BTC wallets address in case the contributor has not setup a custom receiver address.
When we derive the address from the inputs of the compensation request transactions we do not have the spending transaction which would be needed to get the output and dereive the address from that. We have though all the BSQ transactions and can use the BSQ input. By using that the trade fee arrives not in the BTC wallet but in the BSQ wallet as BTC balance. The contributor can transfer those funds to any BTC wallet. Technically there is no problem but it's not so nice to have the BSQ wallet "pulluted" with that.
We could maybe mark this balance and the transaction as trade fee transaction. But its assumed that most contributors will anyway use a dedicated address and then this does not happen anyway.

Here some screenshots how it looks like:

Here the added fields to a compensation request:

[devinbileck]

Overall, I like the idea. My biggest concern is address reuse. If we want to attract privacy concerned contributors, it may be a point of concern. Though I am not sure if there is anything that can be done, other than perhaps implementing something like BIP-47 payment codes.

[HenrikJannsen]

Overall, I like the idea. My biggest concern is address reuse. If we want to attract privacy concerned contributors, it may be a point of concern. Though I am not sure if there is anything that can be done, other than perhaps implementing something like BIP-47 payment codes.

I fear that would add too much complexity. Also it would still be easily detectable that its a fee payment as structure of the Bisq trade transactions creates a fingerprint.

[HenrikJannsen]

Here is proposal to enforce users to have the DAO activated. By that we do not need the fallback to the BM address and can remove the BM completely.

[flix1]

Distribute BTC trade fees to contributors

I totally agree with the idea of distributing fees to contributors. I am just concerned that I don't fully understand this mechanism.

In fact, now that the DAO is profitable, I believe that contributors should only be paid from what is earned each month in user fees.

My point is: what would be the simplest mechanism to automate this distribution?

[flix1]

OK... how about this. Fees are distributed among bonded roles in proportion to the size of the bond.

That way the DAO does not have to vote on individual compensation requests each cycle... Only on rejecting or accepting bonded roles.

That would mean one or two real votes each cycle... instead of 20 votes per cycle...

It can all be automated as you have the necessary addresses in the blockchain. The % can also be calculated automatically.

[flix1]

OK. I agree with most of this.

I agree with distributing fees. Agree with the 1.5 yr weighting. Agree with custom receiver address. Agree with reduced BSQ payment option. Agree with probabilistic mechanism so that fee goes direct to contributor automatically.

[DanConwayDev]

I'm coming from the perspective of a dev, new to the space and looking for a project to get involved with.

Getting compensated directly in satoshis out of transaction fees is a really attractive model. Doing it probabilisticly based on the value of the contribution tailing off overtime sounds like a good way of doing it. Perhaps there is a more privacy preserving approach than reusing addresses?

The main problem with the model is that it creates an short / medium term incentive to discourage other contributors / contributions to maximize the individuals share of the pie.

[flix1]

Hi Dan. I think that reusing addresses is a bit inevitable over the length of one cycle... but It would be trivial to change address each cycle when the compensation requests are approved by the DAO. I can imagine a more privacy-preserving option is possible using addresses generated from the same seed...

I think that the incentive to grow volume is huge compared to the incentive to fight over a fixed pie. Bisq is still a very small project and I have seen very few compensation requests denied.

For example Bisq volume is < 5% of Paxful volume. Finding a way to double Bisq volume would be extremely valuable to everyone involved and would be well compensated.

[HenrikJannsen]

I'm coming from the perspective of a dev, new to the space and looking for a project to get involved with.

Getting compensated directly in satoshis out of transaction fees is a really attractive model. Doing it probabilisticly based on the value of the contribution tailing off overtime sounds like a good way of doing it. Perhaps there is a more privacy preserving approach than reusing addresses?

Thanks for feedback. Good to see that its attractive to new contributors!

The main problem with the model is that it creates an short / medium term incentive to discourage other contributors / contributions to maximize the individuals share of the pie.

Yes in the worst case it could increase unpleasant or even hostile competion. In the best case it improves the self-management of the DAO. Bisq is largely un-managed and that comes with some problems. Atm the incentive to step in if a contributor asks for too much is low, as the costs are distributed to all BSQ stakeholders and its more abstract. With this change a contributor might feel more direct impact on their personal stake in the revenue sharing and that adds incentive to play some "management" role and take responsibility.
At the end I think it depends on the character and culture of the contributors in which direction it goes, but from the past I guess the latter problem was the bigger problem. The DAO had times where it spent too much money in unproductive ways and it took too long time to fix that. At a certain point this excessive spending had quite a negative impact on the BSQ price.
But to avoid the former aspect I think the Bisq contributors need to be careful as well so that working environment stays friendly, open and fair. I have no doubts that this can be achieved with the contributors active in Bisq.

[DanConwayDev]

@flix1 and @HenrikJannsen you both make good points about the model.

@devinbileck suggestion of using BIP-47 payment codes to avoid address reuse is a good one. Perhaps if it was optional, I have not looked at how difficult this would be to implement.

[HenrikJannsen]

Close in favor of a new proposal (will be published soon).