Get a better view on the DAO revenue and expenses #306

chimp1984 · 2021-02-04T17:51:25Z

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

Currently it is very difficult to get a good idea what is the revenue of Bisq, how much is the share of BSQ fees vs. BTC fees and if the relationship of trade volume and total fees is as expected. The current charts in that area are not reflecting well the data and are too poor from features to get some real value out of them (e.g. no tooltip for data points, no naviation/zoom to time periods).

I am working on an improved chart compenent with a timeline component and a date filter so it enables to select a certain time period and make it easier to navigate through the data. I also added toggle buttons as data legend for the chart series so one can show/hide certain data series.

DAO internal data

Data sources/series:

Burned BSQ from trade fees paid in BSQ. Data source: All burned BSQ of TxType PAY_TRADE_FEE.
Burned BSQ from proof of burn transactions. Data source: All burned BSQ of TxType PROOF_OF_BURN.
BSQ issued by compensation requests. Data source: Issuance with type comp request. TODO: We had mixed earlier comp requests with reimbursements from RA as limits have been too low. We need to add static data derived from GH issues and blog cycle reports to filter out the reimbursement part. As it is only historical data and now cleanly separated we don't need to @MwithM is helping to render those data: https://docs.google.com/spreadsheets/d/1cd_jQUWRDEGy1wPeg2QxyJ1Rfo9KJ1uZi7b5pq3DzOw/edit#gid=0
BSQ issued by reimbursements requests. Data source: Issuance with type reimbursements request. TODO: Like above adjust the data with statically added data.
Burned BSQ from trade fees paid in BTC. Data source: Difference of serie 2 and serie 4. Theoretically BSQ burned via proof of burn which was not reimbursed in issuances should be the burned BSQ from BTC fees. There might be other proof of burn transactions (asset listing - I guess that can be excluded from DAO data, arbitrarely POB amounts - I guess there is not large amounts). We should cross check that data with the blockchain data from the donation addresses, but thats another complex area covered below... -> UPDATE: So far the resulting data are not very useful as the burn and reimbursement time is too far distributed to get meaningful data.
Add trade volume to see comparision of fee with volume. -> UPDATE: That would require a secondary yAxis for the USD or BTC scale and that is unfortunately not supported by JavaFX charts and would require a custom implementation which would be too much effort.
Optional we could have an aggregated serie with total fees (BSQ+BTC)
Optional: Add BSQ price as well to that chart (we have it separate but might be more interesting to see it in context to the other data)

We could also consider to split it into 2 charts: One with the fee vs comp requests and one with reimbursement and burned BSQ from proof of burn for delayed payout txs.

The chart shows all data in BSQ. We could add a feature to convert it to USD based on average BSQ and USD prices.
As a main goal is to show relationship between revenue and expenses (comp requests) I think this is achieved without the USD conversion and I will leave that out in the initial delivery from my side (as I want to limit effort on that project). But any dev is very welcome to extend that and add that later. As well as using average values instead of plain data might be useful to filter out outlies. Outlier filter for initial data, specially for the BSQ price will be still used as we have it.

Blockchain based data

We have different addresses where BTC as trade fee or BTC from delayed payout transactions (DPT) are received.
We had several burning mans [1] and we still receive funds on the old addresses. Funds to the default address is expected from users who have deactivated the DAO. Why we receive still funds on the other addresses (not much and rarely) is not 100% clear but it is likely that the DAO state of the uers got out of sync and got stuck to the result of that cycle where that BM was active. We do not send BTC fees anymore to any of the addressed defined as DAO parameter but use the data from the filter. So if we still receive funds it is either from users with very old versions (they should not be able to trade anymore but maybe they still can create offers?) or from funds from the DPT.

Default receiver address as defined in DAO param. The funds are sent from time to time for the owner of that address to the new address of the BM. https://mempool.space/de/address/1BVxNn3T12veSK6DgqwU4Hdn7QHcDDRag7
@burning2019: https://mempool.space/de/address/3EtUWqsGThPtjwUczw27YCo6EWvQdaPUyp
@burningman2: https://mempool.space/de/address/3A8Zc1XioE2HRzYfbb5P8iemCS72M6vRJV
@burningman3: He took over the old address after @burningman2 revoked. https://mempool.space/de/address/3A8Zc1XioE2HRzYfbb5P8iemCS72M6vRJV
@burningman3 for trade fee [2]: https://mempool.space/de/address/38bZBj5peYS3Husdz7AH3gEUiUbYRD951t ()
@burningman3 for DPT [2]: https://mempool.space/de/address/34VLFgtFKAtwTdZ5rengTT2g2zC99sWQLC
Refunds to victims of the security incident in 2020 [3]: 50% of BTC fees goes to the victims, the other 50% to the BM.
https://mempool.space/de/address/1EKXx73oUhHaUh8JBimtiPGgHfwNmxYKAj
https://mempool.space/de/address/1HpvvMHcoXQsX85CjTsco5ZAAMoGu2Mze9
https://mempool.space/de/address/3EfRGckBQQuk7cpU7SwatPv8kFD1vALkTU
https://mempool.space/de/address/13sxMq8mTw7CTSqgGiMPfwo6ZDsVYrHLmR
https://mempool.space/de/address/19qA2BVPoyXDfHKVMovKG7SoxGY7xrBV8c
https://mempool.space/de/address/19BNi5EpZhgBBWAt5ka7xWpJpX2ZWJEYyq

For new data we have a clear separation now from the addresses, so it should be easy to get the numbers from BTC fees and the numbers from DPT (including the old addresses which should be only DPT amounts).

The real reevenue in BTC fee includes the funds to the victims. We can use that number for estimating the BTC fees in the period when we did not had separated the receiver address as the BTC is statistically 50% split between victims and BM.

We have to connect those data with the data we get from the DAO and figure out if the results are as expected even for older data it will not be perfect it should give a good estiamtion.

Related efforts

@wiz and @soft_simon have an open project for a similar effort for the webpage [4]. This proposal does not want to compete with the more broad and detailed business report style attempt. It should be seen as the bare minimum to see the economic health of Bisq. Beside that I did not want to wait another xxx months until we get that implemented, patience is not my biggest strenghts ;-)
@ripcurlx is maintaining a reporting spreadsheet [5]

Limitation

This is pretty fresh WIP and many details are not well thought out yet. I also want to keep effort from my side limited and spend already too much time on that. So I plan do deliver only the MVP and any contributor is welcome to improve and fine tune as well to apply the new chart component to other areas. But before getting too far into details it would be good to coordinate with @wiz, @soft_simon and @ripcurlx about their plans, ideas and state of work to not duplicate efforts.