Limit security incident repayments to 50% of btc revenues

[m52go]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

When a mechanism for security incident repayments was determined in #209, two determinations were left to be made:

1. The portion of the Bisq DAO's BTC revenues used for repayments
2. Whether the amount to be repaid will be denominated in US dollars or in bitcoin

This proposal covers the first item.

Background

The filter to start repayments was put in place around 20 July 2020. Since then, almost all of Bisq's BTC fee revenue has been routed to repayments through the filter mechanism detailed in #205.

This proposal contends that a 100% allocation of BTC fees to repayments is unsustainable for the DAO and seeks to establish a 50% limit to return price stability to the BSQ market.

BTC fee revenue

With all BTC revenues being routed to repayments, very little is left for the burningman to buy BSQ, significantly reducing demand in an already fledgling market.

Unfortunately determining precise BTC trading fee revenue directly is not easy, so we must use alternate approaches.

BSQ bought by burningman relative to overall BSQ volume

BSQ bought by the burningman is a significant portion of overall BSQ volume.

Month	BSQ Traded (in BTC)	BSQ Burned
202001	9.8692	117460
202002	7.2543	30900
202003	14.5409	76600
202004	15.406	153400
202005	11.3593	121500
202006	6.2257	10600
202007	6.1513	64000

Numbers above are meant for illustrative purposes only. BSQ price has fluctuated over the past few months, BSQ burned includes BTC from arbitrated trades, and burning amounts listed above don't necessarily correspond to the time period they're listed in.

Having said that, quick back-of-napkin arithmetic suggests that the burningman can account for a sizeable portion of BSQ trading volume, often as much as half.

Number of trades using BTC to pay trading fees

We do have precise numbers for (i) total trades on the network and (ii) number of BSQ fee payments, so we can determine the (effective) number of trades using BTC to pay trade fees:

Month	# BSQ Fee Payments	# Effective BSQ Trades	# Total Trades	# Effective BTC Fee Trades
202007	2257	1129	3127	1999
202006	2221	1111	2018	908
202005	2236	1118	2851	1733
202004	2312	1156	2854	1698
202003	2992	1496	3597	2101
202002	2679	1340	2902	1563
202001	2365	1183	2393	1211

# Effective BSQ Trades = total number of BSQ trade fee payments divided by 2

A drawback of this approach is that it disregards the size of fee payments.

Approximate BTC fees from proof-of-burn and arbitrator reimbursements

I created such a chart before based on estimates but it wasn't very accurate, so I won't offer an updated one here unless requested.

Proposed Action

BTC fee revenues are a considerable portion of total network revenue. Given the importance these fees play in supporting the BSQ market, directing 100% of BTC revenues to repayments is not wise.

The filter should be modified to divert 50% of BTC fees to the donation address.

Already the BSQ market has been weakened in the past few weeks since the burningman hasn't had much BTC to buy BSQ as a result of repayments started 4 weeks ago. Zero BSQ has been burned in this cycle so far, and there's only about 0.2 BTC in the donation address right now. Unless there have been any purchases that haven't been burned yet, this is far from the amounts burningman was burning before the filter was put in place.

A weak BSQ market spells major trouble for the whole project, and jeopardizes the chances repayments are completed at any point in the future.

Considerations

Since the portion of BTC fees going to repayments is proposed to be a percentage, repayments will go up as BTC fees go up. They'll go down if BTC fees go down. None of these effects are different from the current situation.

When BTC revenues increase for a sustained period of time (or if BSQ usage increases considerably), it may be appropriate to increase this percentage through a separate proposal in the future.

[chimp1984]

Thanks for the summary. It seems we lost quite a good portion of BSQ fee trades in favor to BTC fee trades over the past months. Roughly a decrease from 50% to 33%. Even 50% is way below our target of about 80%. I think we have to adjust BSQ fee ration to give more attraction that users use BSQ for fee payment.

I would suggest instead of changing the % we spend from BTC fee revenue to reimbursements, to try to get BSQ/BTC fee ration back to our target. That would reduce the total amount we use for the reimbursement automatically.

[MwithM]

I would start repaying after a certain threshold per cycle is achieved or approve this proposal, giving strong importance to this condition:

When BTC revenues increase for a sustained period of time (or if BSQ usage increases considerably), it may be appropriate to increase this percentage through a separate proposal in the future.

This proposal would lead to changes can be implemented quickly and modified when needed. I'm ok with it.

[sqrrm]

I think routing 50% of BTC fees to the donation address is reasonable. That's in line with what was discussed when the repayment proposal was accepted.

Regarding the burning over previous months, it's not a good measure if the amounts that refundagent is refunding is included. Those amounts are not fees but get treated the same since there is no differentiation between the fee payments to the donation address and execution of delayed payout transactions to the donation address. All those funds are later used to buy and burn BSQ.

[m52go]

I would suggest instead of changing the % we spend from BTC fee revenue to reimbursements, to try to get BSQ/BTC fee ration back to our target

I agree this is important, but there are a number of other factors that could be causing this trend, with price stability probably being a top factor. No one will want to buy BSQ if its price is declining, even with a steeper trading fee discount. The BSQ economy needs to retain as much value as possible within it to have a chance at maintaining this stability.

[MwithM]

This has many upvotes and no opposition. I'd like to link a PR where this has been or is being handled before closing as approved. Could you help?

[ripcurlx]

This has many upvotes and no opposition. I'd like to link a PR where this has been or is being handled before closing as approved. Could you help?

There is no PR as this is set directly in the filter within the app.

[MwithM]

Closed as approved.

FYI, the repayment process can be followed here.