Replies: 16 comments 19 replies
-
|
Thanks for putting all this together. It is nice to see the progress Bisq is making towards repaying the security incident victims, and good to know that it's profit in terms of BSQ issued / burnt is healthy. I think a comptroller role would be a great addition to Bisq. I have thought for a while that Bisq could do with a Finance Director role which I guess is pretty much along the same lines of what you propose. I think useful elements of the role would be:
I think for this role to be successful their needs to be an agreed vision for Bisq. Then conversions can take place on how best to achieve it. For example:
I would be happy to take help get this role started. However, I have no formal financial qualifications. I do run a business that was in need of a financial director and decided to educate myself on some aspects of the role as I was too tight to pay for the fees involved for having a financial director for a couple of days a month!! I do now now buy in this service so have a bit of experience of what is involved when you receive professional advice. |
Beta Was this translation helpful? Give feedback.
-
|
@cbeams Here are a few screenshots (or run the PR #5156):
From what I can see we get about 10k BSQ burned per month. Here are the 2 addresses used by the BM: We would need to grab the tx data and bring it into a speadsheet/chart to see how much BTC fees we received over certain time periods.
So if the BTC fee numbers above are more or less correct, it would mean we have earned in average 14k USD with BTC fee and 10K USD with BSQ fees. BTC fees from traders would have been the double so 28k. The ration BTC fee to BSQ fee would be 26% BSQ fee and 74% BTC fee. The opposite as our goal. From your number of the victims data we get: 496 USD/ day -> 1 months: 14880 USD/month Good thing is that trend of the last 4 months is pretty strong increasing from 7000 BSQ in Oct to 21500 BSQ in Jan: |
Beta Was this translation helpful? Give feedback.
-
|
Another important metric is the tradde volume. It was 53M USD in 2020. I will add to the chart an update for the numbers in the text fields according to the timeline filter so we can get total numbers for the given period as well. |
Beta Was this translation helpful? Give feedback.
-
|
FYI some numbers on BSQ fees from the last 4 cycles. BSQ rates are taken from the proposals of the subsequent cycle.
(should go without saying, but BSQ trading fees denominated in BTC are approximate since BSQ/BTC rate is an average) My opinion is there should be a good foundation of data available first. @chimp1984's work looks like it will go a long way in helping. In addition to the overall numbers, my initial concept included details on what exactly issuance went toward and how it affected trade volume over time. I think that's a critical part of any analysis of Bisq finances. It's not particularly difficult to get some of this data, but it's tedious to put it all together, consistently, in a way that makes it informative. Whoever takes on this role will have this issue. The remaining tasks to automate reporting (as discussed last year) and make the information we have useful are largely technical and beyond my ability. Therefore I think a better use of time would be to get whatever resources are needed to complete a dashboard integrated with mempool.space as proposed in project 41 done. |
Beta Was this translation helpful? Give feedback.
-
|
This is all great. @pazza83, wonderful to hear you'd be up for getting this new role started. Here are my thoughts on how to do it minimally and manageably:
I think a lot of the value is in helping us to frame things correctly. How should we think about the DAO's financials? How do we turn raw data about trading fees, BSQ supply, etc, into enlightening and actionable information? Getting everybody (users, contributors, stakeholders) on the same page about these things will be really powerful. So practically speaking, I'd suggest working toward consensus on those first key metrics here in this conversation, then post a proposal to create the new role, including initial rights and duties, bonding requirements (if any), a task list of stuff that will need to be done, e.g. creating a role issue, wiki doc and GH team for the role, and then just go for it implementing accounting and reporting on those metrics in whatever way makes the most sense. Once this kind of foundation in place, the role could be handed off to someone with even more domain experience to refine it, take it to the next level, etc. A lot of the value in this initial phase is just getting the ball rolling and establishing things, pushing past initial inertia, and you've proven very good at that, @pazza83, so certainly have my vote if you'd like to do it. So, to everyone: what do you think the most important 3–5 accounting / financial metrics would be? For me, the first would be a single, USD-denominated monthly revenue number. Basically the number I was trying to get at in my original post that started this discussion. The Bisq DAO's "top line", if you will. We would naturally want to be able to drill down from that top line number to see details on how much of it is coming from BTC trading fees, BSQ trading fees, etc, but it would be so helpful to have a single, simple, rolled up number we can trust that tells us how much revenue Bisq is bringing in. Of course, it follows that the second most important number would be our bottom line, showing how much (if any) is left over after expenses (including BTC victim repayments, BSQ issuance, etc). I think it's a very interesting challenge to figure out how to make sense of all this. It's anything but "boring, run of the mill accounting" when considering all the nuances of the Bisq DAO and the various unprecedented ways in which this organization runs. |
Beta Was this translation helpful? Give feedback.
-
|
Btw in my chart I use always the average USD value of the selected time interval (e.g. day/week/month/year) for converting btc or bsq values to USD. |
Beta Was this translation helpful? Give feedback.
-
The 0.8% trade fee makes sense. I think it would be good to choose a denomination for Bisq's unit of account. My preference would be to primarily account for things in BTC. Growth in trade volume / revenue could then be measured in terms of BTC. Fiat could then be applied secondarily to the figures to give comparisons.
I agree, that this will be a job that would be better if automated. I wonder if doing this manually first could help to guide the process as to what information is important to display. I think there are potentially a number of ways to account for the financial aspects of the DAO and it would be good to consolidate a standard way to account for the financials and them implement this into any future automation.
I agree, I think keeping things simple would be best.
Understood thanks for explaining the distinction between roles. I do think there does need to be some discussion about finances and strategy to achieve agreed objectives, hopefully when the DAO financials are regularly updated it will allow for this discussion to occur.
Agreed
Sounds good to me. I think prior to making a proposal I would like to have a go at creating some accounts. I think the process of creating them would help me answer the following:
I agree it would be good to agree some key metrics in this thread to ensure the data gathered is of use.
Sounds good. Happy to get started and then pass over to someone with more financial prowess than myself.
I agree it top line revenue should be included as a metric. However, I think revenue should be BTC-denominated for the reasons:
I think this is the most important metric. Turnover is vanity profit is sanity but cash is king. With regards cash is king. A third metric to measure is cash flow. Essentially each month is Bisq expecting to burn less or more BSQ than it is issuing.
Yes, I think it would be really interesting, the tokenomics involved are fascinating. I think I would like to apply standard accounting techniques to Bisq and see how far they get me and then see what needs adjusting to make something that works for Bisq. |
Beta Was this translation helpful? Give feedback.
-
Profit / loss statement (measured in BTC) Looking back over a given time period, month, quarter, year. Did Bisq make BTC or lose BTC over the given period. Balance sheet (measured in BTC) The sum of the DAO's assets BSQ, minus and liabilities (eg outstanding security incident repayments), plus any debtors (eg confirmed future donations). Cashflow forecasts (measured in BTC) Looking forward over a given time period, month, quarter, year. Does Bisq expect to make BTC or lose BTC over the given period. BSQ/BTC All things being equal, if Bisq is successful* BSQ will rise in comparison to BTC as it increases it's market share. *success is subjective, but in my definition I would measure success as the above (all things being equal). Things not being equal could be:
All the above would have an impact on the BSQ/BTC price, but may or may not impact the balance sheet (health of the DAO). |
Beta Was this translation helpful? Give feedback.
-
|
@pazza83, in general your comments and plans above sound good to me. Please speak up if there's anything you need along the way. One difference, however, is that I think it's pretty important to continue denominating Bisq's finances in USD, for the same reasons that we currently denominate compensation requests in USD. Like it or not, USD simply is the global unit of account, and if we don't denominate in it, then we end up forcing everyone interacting with the DAO to continually do these kinds of conversions in their heads. I would love to see reporting on all key numbers done in BTC as well as USD, but I don't see how we can escape the need for and practical utility of denominating in USD so long as BTC continues to experience anything like its current levels of volatility. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I think I might need help finding where to pull all the data from. Happy to reach out for assistance as and when needed. Happy to provide accounts in both USD and BTC. |
Beta Was this translation helpful? Give feedback.
-
|
@cbeams wrote
@pazza83 wrote:
In general, I think these are fine suggestions. One way to make sure we land on the most useful set of initial metrics would be to express requirements for them as questions that different types of BSQ users need to be able to answer, e.g.:
These are just a sketch, the first few things that come to mind, but you get the idea: these requirements are expressed strictly as what information people need to know, and they avoid specifying exactly how to provide it. The latter is important, but the former is most important. If we're clear about the what, the how will more easily follow. This approach would allow us to validate that the metrics we're implementing are the right ones by completing the following sentence:
As some readers will know, Agile development teams formulate these kind of requirements in a similar way, called user stories that are structured like this:
Applying this structure to our domain, we might have a user story like this:
We could then propose a particular metric or set of metrics that meet that requirement and go about implementing it. It may often be the case that the "standard" accounting techniques like balance sheets and cash flow statements etc, are the best way to meet these requirements, but it's worth remembering that there's no particular way that we are forced to do our reporting. We shouldn't reinvent any wheels, but we are also free to structure this information in whichever ways we think will actually be most useful to current and potential BSQ users. In any case, I don't mean to add any fluff or unnecessary process here. It's just important that we focus on what truly matters, and most of us (myself included) aren't deeply familiar with accounting and corporate financials, so it can be easy to lose the plot talking about the different kinds of reports and metrics. Framing things first in terms of real world use cases should help ensure we deliver financial reporting that's actually useful. So, to everyone: think about your own relationship to BSQ and Bisq DAO financials in general. What are the real-world questions you need answers to? What are your "BSQ user stories"? |
Beta Was this translation helpful? Give feedback.
-
|
I want to comment on some of the proposed financial statements. Bisq is a very different beast from typical legacy organizations, and trying to squeeze out typical legacy financial statements from DAO numbers doesn't make sense to me. Balance sheetI'm not sure Bisq can have a balance sheet. How can such a thing be constructed? The project has no assets and no liabilities. Typically you get an equity value (book value) by subtracting liabilities from assets. The market's take on this book value of equity is what you see reflected in stock prices as market value of equity (aka market capitalization). Bisq's liabilities are not liabilities in the traditional sense—they are merely a summation of repayments that the DAO has collectively promised to pay out of future revenues. Typically, liabilities are legally-enforceable liens on assets, but this isn't the case with Bisq since it has no assets. This makes repayments expenses, not liabilities, which makes them income statement items (like all baseline Bisq finance metrics; more on this below). So Bisq is in a bit of a weird spot because it cannot have a book value of equity. But it can (and does) have a market value of its "equity"—market capitalization. I put "equity" in quotes because Bisq's market capitalization is really just a summation of the market value of all BSQ held by sovereign individuals, like shares of stock. But unlike shares of stock, BSQ tokens signify value for their owners, not the originating entity. The market value of the Bisq project itself is indeterminate, but the total value of all BSQ (what we call market capitalization) is a good proxy for the value of its software, network, community, etc. These are the only semblances of assets in Bisq land—but notice how these items are all intangible and not fit for systematic valuation. Cash flow statementA balance sheet is a snapshot of a company's assets and liabilities at a point in time, and a cash flow statement explains the difference between snapshots. So logically speaking if Bisq cannot have a balance sheet, it cannot have cash flow statements either. More intuitively—measuring cash flow only makes sense if it's possible to go broke. Bisq cannot go broke, as in, it cannot ever run out of cash. It has no cash and infinite cash at the same time. Sure the DAO can become unsustainable, in that the market can decide to value BSQ so low that the DAO can no longer sustain itself, but this is not a black-and-white determination that any financial statement can make. It's a decision the market will make if/when it wants to. Therefore having a cash flow statement doesn't make sense to me either. Income statementThis is the only legacy financial statement that makes any sense to maintain, and really, the main one from which all other metrics should flow. Bisq issues BSQ every cycle and it burns BSQ every cycle. This fits well within the profit/loss paradigm. The fact that Bisq financial metrics can only be tracked in this manner—as value coming in and value going out—should not be surprising. After all Bisq is just software, and the whole point of the DAO is to avoid value from sitting at any intermediary points at any stage during the transfer from consumer to producer. Tracking the quantity and flow of resources in such intermediary points is what balance sheets and cash flow statements fundamentally do, which is another way of understanding why they don't make sense to have here. Measuring issuance and burn on a per-cycle basis also makes it possible to analyze activity in relation to trading activity, governance, and work done (i.e., exact contributions and improvements). Profit and loss can be forecasted, of course, so such statements can be backward-looking and forward-looking. Time framesCycles seem like the only reasonable time frame for profit/loss analysis because issuance is done on a per-cycle basis. Anything else would result in inconsistent data. You can of course do months and quarters and years in terms of groups of cycles. ClosingI think many of the ideas in this thread are great, but if we're going to use certain terms, I want to make sure it's clear what the meaning of those terms are and what they mean in the context of this project. Base metrics must be understood properly in order to create second-order metrics and any further analyses. |
Beta Was this translation helpful? Give feedback.
-
I understand your concerns. I am not sure if legacy financial statements are the best way, I think they are likely not the best way. My idea was to use them as a starting point. Hopefully by doing it in a traditional way first it will demonstrate what aspects are and are not suitable. Legacy financial statements would be the starting point not the anticipated end result.
I see the balance sheet as being made up mostly of the value of the DAO's BSQ. I see BSQ as assets of the DAO. All BSQ holders are effectively share holders of the DAO. Liabilities would be, for example, outstanding funds owed to security incident victims.
I agree.
The amount owed might not be legally enforceable but I still consider it a liability. I do not think the enforceability or un-enforceability of something makes it any less of a liability when accounting for it. There is a commitment to pay the funds back, therefore, there is a liability.
I agree with all this apart from the last part about the intangibility of assets making it not fit for valuation. I think any valuation of Bisq is subjective, I agree the market cap is a good proxy for it.
I disagree with this. When you talk below about the DAO becoming unsustainable to me this is effectively the same thing as the DAO becoming broke.
In the current set up, if income dried up, and BSQ where to go to zero, regardless of the total amount of BSQ, the DAO would effectively be broke. In this situation the DAO would be reliant on contributors giving there time voluntarily, in exchange for a future IOU, or contributing their own funds to grow Bisq. I imagine this was similar to what happened when Bisq was being established; contributors gave up their time, skill and expertise without any initial compensation, or even guarantee of any future compensation. Bisq was effectively bootstrapped.
I think having a cashflow statement will help show the direction Bisq is heading. It the DAO becoming more sustainable (positive cashflow) or less sustainable (negative cashflow). I agree that the term 'cashflow' is not really suited for this. But effectively I am in this instance defining cash as BSQ denominated by USD and/or BTC. Therefore, maybe cashflow would be better describes as a DAO flow?
Here I think it is important to distinguish between Bisq as software and the DAO as the benefactories of the software. I see Bisq as not having value and the DAO having value, but I accept this is subjective. My thoughts, not fully formulated yet, to value the DAO as applied to a traditional financials would be summarized by seeing the DAO as the shareholders of the organization. Shares are represented by BSQ. Shareholders are the benefactor's of any profits generated by the DAO, and at the same time, they are also risking the value of their shareholdings for any losses incurred by DAO. The situation would not be too dissimilar from a public listed company that every month (DAO cycle) it made a profit it bought back it's own shares to increase shareholder value (burning more BSQ than issued), and every month it made a loss it issued more shares (burning less BSQ than issued).
Agreed.
Yes I agree that clear meaning of words are important, especially when stakeholders are coming from different locations. I think establishing a lexicon could be done alongside establishing accounts. |
Beta Was this translation helpful? Give feedback.
-
|
I think a core idea that needs to be pondered very hard is whether or not the Bisq DAO is an entity with assets. I firmly think it is not...isn't this the whole point of Bisq? And of the DAO? Giving it a balance sheet effectively tells the world that Bisq is really an unregistered corporate organization and that the DAO software is just a technicality. Not only does this put the whole project in a danger zone from a regulatory standpoint, but it entirely disregards the massive innovation of the DAO that makes it possible to rid an operation of intermediate points between producer and consumer. Therefore I strongly disagree that BSQ tokens are assets of the Bisq DAO. BSQ tokens are assets of their individual owners. The DAO has zero control over any BSQ (aside from bonded BSQ, which can be regarded as a special case) so how can BSQ be assets of the DAO? That's not too different from saying block rewards are assets of Bitcoin...they're not, since Bitcoin is just software which cannot have a balance sheet, and block rewards belong to miners. If there are no assets, the concept of a balance sheet breaks down, and there can be no liabilities, which also means there cannot be a cash flow statement either. It's just a logical progression. It's all tied together. Of course one can try to draw parallels and create pseudo versions of these statements, but I think this is a problematic approach that sends a misguided message to the very people you're trying to inform. These are my opinions. But as someone who has done financial modelling professionally, my stance is pretty strong.
Right, but this is a determination the market will make on its own. Early last year the BSQ price went down to ~20 cents at one point, but DAO financials were not that bad. Similarly, it's not clear to me that BSQ should be at 200 cents right now. The market will do what it wants to do. The fate of the Bisq DAO is firmly in the hands of the market. It is impossible for any financial statements or metrics to predict it. When a company reaches 0 cash, it's broke. There's only 1 way. But Bisq can theoretically "go broke" with revenues at any level.
As mentioned above, income is an important factor but ultimately not a key determinant of BSQ price. It's entirely about investor sentiment. Metrics can influence this sentiment, but they cannot predict it.
I think better terms are just revenue and expenses. I don't think it makes sense to draw a distinction between revenue and income and cashflow in Bisq. There is no debt, there is no depreciation, etc.
This goes back to my first point above. The DAO itself cannot have any value. Maybe it would be better to play around with some of the ideas you have on your own and see what you come up with before we discuss this any more. It's possible that will help some things become clearer (in either direction, or maybe a new direction!). In any case, I strongly recommend revisiting the concept of the DAO as an entity with assets. I don't like it at all. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @m52go thanks for explaining your perspective. I will have a think of your question about whether or not the Bisq DAO is an entity with assets? I think the answer will likely depend on how one defines 'entity' and 'assets'. Currently, I think that the DAO is something that has value. Whether this makes it an entity with assets is open to interpretation. With regards your point about putting things in the danger zone I have also wondered about this in the past. Bisq is very transparent with its figures; trade volume, market cap, growth reports etc. I think this transparency could potentially make Bisq a target in the future. However I think the transparency is also important for Bisq's growth, user confidence and engagement. I see it as a bit of double edge sword but something that is vital to maintain... and develop. I am happy to have go at the financials and then discuss some more. As well as the points you raise above I think it would be good to agree the purpose of doing any accounting, or a comptroller role, or even if any, or one, is needed. Also, as mentioned I have no professional experience in this area. As you have more experience in this are I would be happy to do it jointly with you, or separately and compare models? |
Beta Was this translation helpful? Give feedback.
-
|
I agree that we have to take care to not create too much parallels to normal corporate models as the DAO is just too different.
I also see a liability as legally enforcable, which is not the case in the DAO. If the DAO stakeholders decide tomorrow to not pay back the victims they might ruin the DAOs reputation and by that the market value of BSQ but they can do that if the majority of stakeholders wants to. Same with paying contributors. The incentives to act fair and to fulfill social contracts is based on repuation and game-theoretical concepts (e.g. the DAO is vulnerable to a majority attack but they would destroy their own investment by doing that). I think the main goal should be to get clear numbers of the revenue and expenses. This is the main metric for the DAO economy. Success metrics like trend for number of trades, volume, fees, number of users, etc. would be nice to have as well. But one should keep in mind that those financial metrics will not be sufficient to evaluate the DAO or even BSQ. Beside that we should not forget the "intrinsic" value of BSQ in form of the underlying BTC satoshis, which have a considerable value with the high BTC price (4M BSQ = 4 BTC = 200k USD). This is one of the limitations of BSQ, in case BTC grows by factor 100 and BSQ not, then the underlying value of the BTC satoshis are getting too expensive to serve as carrier. Though that would be an indication of failure if BSQ cannot partizipate on the success of BTC. |
Beta Was this translation helpful? Give feedback.
-
|
We can talk about metrics and models all day long but the main issue, as I said in my very first comment above, is implementation. The practical process of collecting, manipulating, and reporting this data is a critical consideration that should not be overlooked. I do some of this work on a regular basis already, so let me give you an idea of how it works right now. Currently done on regular basis:
In order to compose meaningful public reports on DAO financials, we would also need to:
It would be nice to:
Is the suggestion in this thread to expand this rickety error-prone workflow, build a public front end on top of it (whether spreadsheet or website or whatever), and then assign someone to manually keep it all updated every month? Notice that a chunk of automation still needs to be implemented even if reporting is to be done by hand...so automation, in this case, is not something that can be left for later. As a result, this more of a technical endeavor than an accounting one. @pazza83 I would love to work with you on this but I would not love to work on a process that's becoming increasingly tedious, inefficient, and unmaintainable. |
Beta Was this translation helpful? Give feedback.
-
|
I am not sure if that fits well into the discussion thread but I think it would be good to share all the details about trade fee and burned BSQ as it was a bit chaotic in the past and its quite complex. Initially we used the same donation (receiver) address for the BTC trade fees and for the trade fund from the delayed payout tx (DPT). Now that is separated. Trade fees in BTC can be sent to following addresses:
The funds from the old burningmen is sent from time to time to the new BM. To refund the victims from the security incident we added a field to the filter message where the address and the ratio of the loss is defined. Here are the addresses and after the Once that is refunded the filter will be updated to leave the @burningman3 as only receiver. If a user pays the trade fee in BTC the first output of the maker fee tx or taker fee tx is the fee payment and the receiver address must be one listed above. Also the min. BTC fee must match the one defined in DAO param (default and current 5000 sat). If the fee is paid in BSQ the first output is usually the BSQ change output (could be also the case that there is none if the BSQ input was exactly the fee or the change would be below dust. To verify such a trade fee tx one can lookup the first output in the BSQ explorer. If it is not found there then lookup the inputs in the BSQ explorer. If also not found it was not a BSQ fee tx. The tx has to be confirmed before the BSQ explorer recognizes it. To calculate the revenue is a bit complex specially for historical data as we did not had separated fee and DPT funds. Another issue is that the reimbursement requests have not been used initially (was part of compensation requests) and then only partially as the limit of the DAO parameter was low and it required a few cycles to increase that limit. In the new charts I added historical data from the DAO requests to correct that distribution. The BSQ burning via I think the best way to extract the BTC fee value is by using the received funds over a certain time perion at @burningman3's receiver addresses. It would be good if one could provide a script with API requests for each relevant time period (e.g. received BTC per month). Another option is to add that to the app via an API call so all tx data gets into the charts and one can zoom in or filter any time period (with shipping historical data so the API requests don't get too heavy). Best would be to have all the available addresses in a multi-series chart (also the victims addresses), so one can see quickly if there would be any anomality and the frequency and volume sent to the outdated addresses. A further complication is which currency is used and which exchange rates. In the new charts I added USD values to all relevant data and used the average Bisq BTC/USD rate from the same time period for conversion. Another related data is the fee adjustment (via DAO voting). Not sure if that add much value but it could be helpful to see how the % value of the trade fees and the distribution of BSQ and BTC fees have developed over time. |
Beta Was this translation helpful? Give feedback.
-
|
I fear there has not been any progress on that topic. It is still basically impossible to find out how much fees in BSQ and in BTC Bisq earns and if it is in the right proportion to the trade volume. Is there anyone who is willing to take that task as priority and gets that solved in a committed time scope? I think to track the BTC fees should not be too hard. Make a script to track all inputs on all donation addresses (it is now separated for fee and refund agent cases). BSQ fees are also available either via BSQ explorer or Bisq app charts. Trade volume as well. Those 3 sources combined should give a good picture how much fees are paid over time. As trade volume is volatile it would be good to have different time scales (day/week/month). Also denomination should be in BSQ/BTC/USD so BTC/USD and BSQ/BTC volatility can be addressed. |
Beta Was this translation helpful? Give feedback.
-
|
I did some rough numbers and seems the earlier assumption that BSQ fee payment is very low (25%) seems to be wrong. We had about 11k BSQ (from Bisq app) for June 2021 -> about 15k USD fees in bsq -> 3 750 000 usd volume with 0.4% fee (0.05% maker + 0.35% taker fee) If those numbers are more or less correct 60% of fees are paid in bsq, so thats much better than earlier estimations (i guess those ignored the diff. fee% of bsq and btc fees). |
Beta Was this translation helpful? Give feedback.
-
|
60% of trading fee value paid in BSQ makes much more sense, since most of the trading fees must come from heavy users like XMR traders. For trades over 0.1BTC the difference for regular trading which pays trading fees in BTC and BSQ is huge. |
Beta Was this translation helpful? Give feedback.
-
|
Following discussion earlier in the year. I prepared some financials based on standard accounting practices. Please note I don't have a background in finance. Here are copies of what I produced for the fiscal year 20/21 (01.04.20 - 31.03.21) Originally I included the total market cap of BSQ as an asset for the DAO, but based on negative feedback from @cbeams and @m52go on accounting this way I removed it in the above accounts. My observations My observations from doing the accounts are:
Answering questions for contributors, investors, and traders When sharing with @cbeams he felt the accounts did not answer the question posed here: #5171 (comment)
I agree these accounts do not answer the above questions. I think the answers to many of these questions can be found in Bisq. Maybe the information is best displayed in an automated way. Happy to hear any comments / questions. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @chimp1984 thanks for the additional info.
Is it possible to change this so when DAO is not synced or deactivated just the two addresses below would be used?
I think this address also receives trade fees. For example two recent ones:
Maybe I am mistaken and they are for something else but they do not look like normal delayed payout transactions.
I agree this is just getting trade fees. |
Beta Was this translation helpful? Give feedback.
-
If all the BTC trade fees sent to As we can already measure BSQ fees, then this would achieve what you are looking for: "I would prefer to focus on the most simple which has not been resolved since 2 years: How much fees do we earn and how is BSQ/BTC ratio of that."
If all the BTC deposit payouts sent to This would for calculations of the difference between what is donated by the deposit payout and what is reimbursed by refund agent. This would be useful information especially since refund agent has started applying arbitration fees. Essentially a donation to the DAO from unresponsive traders. The above would work on the assumption that:
|
Beta Was this translation helpful? Give feedback.
-
No, the default address cannot be changed as that would be a hardfork.
Yes, looks like a fee payment. Might be some edge cases (filter not received,...).
Yes agree. Maybe @jmacxx has some headroom for implementing it?
Yes I think those assumptions are basically right, but there will be some smaller amounts to the old addresses and as you mentioned there might be some fees sent to the del. payout receiver address. But I think the ratio of those are very small so they should not distort the overall number. I looked in the past into the issue why the other addresses are still used and did not found a clear reason. My assumption is that it happens with a out dated DAO state of the user, so the last valid address was used. The default address is used when the user has deactivated the DAO but from my recent tests the app is not working if the DAO is deactivated, so that should not be the case as well at least if users use recent versions, which is enforced by last hard fork. So no clear idea why there are still fees sent to those addresses... |
Beta Was this translation helpful? Give feedback.
-
|
@chimp1984 thanks for the info. I will try and put together the figures for Cycle 26 or the month of July, whichever is easier, with the info above. |
Beta Was this translation helpful? Give feedback.
-
Profit and loss report for July/Cycle 26I have completed the profit and loss report for July/Cycle 26 please see link for full figures here: Summary for July 2021Here is a quick summary of the information:
The percentage of fees paid in BSQ was: 23.64% I think profits where low as a result of decreased trading volumes. Bisq has been pretty quite and centralized exchanges also reported decreased volumes in July. Addition commentsThere are lots of ways this can be improved but for now just wanted to present the info as simple as possible to see if this is what the community would benefit from. |
Beta Was this translation helpful? Give feedback.
-
|
I have made a proposal for a new Comptroller role |
Beta Was this translation helpful? Give feedback.
-
|
Comptroller role has been created. Reports will be issued on a monthly cycle. |
Beta Was this translation helpful? Give feedback.
-
I just took a few minutes to run some rough numbers on BTC trading fees based on our victim repayments so far. The exercise evolved into a more general attempt to calculate total monthly revenues. This is all really rough, and BSQ trading fee revenues are missing entirely, but perhaps this could be the start of tracking these numbers more rigorously in the future. Please follow along if you're interested, and please speak up if you'd like to help formalize the accounting here (this could become its own dedicated role under the DAO).
This is from the security incident victim repayment report I posted 5 days ago (2021-02-03) at bisq-network/projects#31 (comment):
And this is the same report, run today (2021-02-08):
Summary: Once victim repayments are complete, probably sometime between June and October, we'll have somewhere in the range of 14–22K USD worth of BTC liquidity come back online every month for the burning man to use in buying up BSQ. That's another couple full-time dev salaries!
Ok, so that's how much of BTC trade fee revenues are tied up in victim repayments. Now, let's look at the last few months' worth of the burning man's BSQ purchases. I'm doing this as a way of calculating the rest of our BTC trade fee revenues.
These numbers are from the BM's most recent trade history csv posted at bisq-network/roles#80 (comment), covering all BSQ purchases made between 2020-11-08 through 2021-01-24.
I've dumped these numbers into a google sheet at at https://docs.google.com/spreadsheets/d/1E91nPKhkencv119n79ea2r4gEHQ4Qt4m23Y0En-FX9I/edit?usp=sharing.
From that sheet, here's a quick chart showing how much BTC the burning man spent during each (Sunday 3p CET) trading window during that date range:
Also from that sheet:
So (and this number is really rough, probably too high), there is 105K USD worth of BTC already being used to buy up BSQ every month.
If we add these numbers up:
BTC revenue freed up after victim repayments are complete: 14-22K USD
BTC revenue already being spent per month on BSQ: ~105K USD
That puts us at around 120K USD worth of BTC per month available for BSQ purchases once victim repayments are complete later this year.
The only major piece of revenue information not calculated here is our current monthly BSQ revenues in USD terms. If someone could add that into the mix (however roughly), it would be appreciated.
I threw the above together in 45 minutes or so. So don't trust any of it as particularly well-thought out or accurate. Thoughts and feedback are most welcome.
If anyone wants to take on the kind of comptroller role the DAO needs, please know that you'll need to be highly independent and self-motivated. Take a look at @pazza83's recent Payment Method Maintainer cycle reports (like this one) to get a sense of what it looks like to really take ownership of a role. If you're up for this kind of responsibility and you love running the numbers, please speak up!
Beta Was this translation helpful? Give feedback.
All reactions