Implement budgeting and improve reporting

[m52go]

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

Bisq's current contribution dynamic is a free-for-all with almost no constraints and almost no analysis.

This worked well while the contributor group was relatively small, since the work required roughly matched with the labor supply—people could do almost whatever they wanted and it was sufficiently productive.

But as the project has grown and matured, imbalances have emerged:

• certain functions are under-allotted (work required exceeds that available from the labor supply)
• certain functions are over-allotted (labor supply exceeds that of work required)

What is the correct allocation for each function? What is an acceptable level of overall spending for a cycle? Was the drastic inflation in the last cycle warranted? No one knows, because the project lacks micro-level goals/budgeting and macro-level analysis.

This proposal suggests an approach to accomplish this with the following aims:

• maintain the decentralized spirit of the Bisq contribution model
• adapt existing processes people are already accustomed to (e.g., compensation requests and monthly role reports)
• avoid using third-party infrastructure and dependencies that probably aren't a good fit for Bisq anyway (e.g., project management tools)
• avoid the hell that is middle-management and paper-pushing (avoid busywork and crap incentive structures)

It was inspired in part by julianknutsen's proposal from earlier and conversations with other contributors.

Concept

I suggest the following:

1. Establish network-level budgets and goals, and update every cycle.

• What is the maximum amount of BSQ the network should issue in the next cycle, based on how much BSQ was burned in the last cycle? Trading volume is too volatile to make projections so these figures probably need to be backward-looking for now.
• What are the overall goals of the project in the near-term, mid-term, and long-term? These may not change a whole lot from cycle to cycle, but project-wide goals should be clearly stated and easy to find.

2. Establish per-function budgets and goals, and update every cycle.

• What is the maximum amount of BSQ the network should issue for each function in the next cycle, as a percentage of (1)?
• what are the most pressing tasks within this function?

3. Aggregate past contributions, per cycle, separated by function, to show spending over time.

• Would be great to connect spending data (inputs) with practical results (i.e., outputs like software downloads, trade volume, etc) to determine ROI...but that's a much more complicated task that will need more thought and time to implement.

All this information should be collected and visualized for contributors and maintainers to refer to whenever needed, so that:

• maintainers can better route energy to critical work, or discourage energy going into less-critical work
• contributors can determine how to be helpful quickly without guesswork
• stakeholders have a basis for rejecting requests to compensate non-critical work
• the whole network can better control inflation

Implementation

I don't think we need dramatic change to implement this. The following suggestions might seem janky, but we don't need a solution that's scalable to 1000 active contributors...just one that works for a couple dozen active contributors and role owners. There's no need to overengineer or overthink it.

The basic idea involves establishing budgets through quick meetings every cycle, standardizing compensation requests and role reports so they can be parsed, and aggregating all data on a single page for convenient access.

Concretely:

1. Establish "stewards" for major Bisq functions. These would be unofficial roles filled by people who can best represent the interests of each significant function. So there could be one for the website, one for infrastructure, maybe two for development, etc. If more than one person is capable of filling this role, they could take turns. This "role" would have no real authority aside from participating in (2).

No additional work...just pick someone.

2. Hold meetings every cycle so stewards can establish budgets and allocations. Stewards should determine maximum BSQ issuance for the upcoming cycle, set allocations for their functions, and adjust project goals as necessary. Only stewards would participate but anyone could watch. These numbers could go into a simple JSON file that lives somewhere in the Bisq GitHub repository so it can be accessed by (5).

Should not take more than 30 minutes per cycle.

3. Standardize compensation request format. So that they can be parsed and aggregated programatically for detailed issuance information over time. Everyone making a compensation request already separates their items by function, so this isn't a big leap. A linter could alert people of malformed requests.

No additional work...just require a more uniform format for what we're already doing.

4. Standardize role report format and add budget/goal information. So that they can be parsed and aggregated programatically for per-function analysis over time. Budget information would come from (2). Role owner would specify goals. As for analysis, how did the function do in the last cycle relative to previous goals and budget? Overspend? Underspend? Was it productive?

Again, this is more about applying a uniform format. Good role reports already do most of this.

5. Collect and visualize information from (2), (3), and (4). With all issuance data and role reporting in standardized format, we could aggregate all project/function budget targets, project/function goals, reports, and analysis onto a single page every cycle. Perhaps it could be the new bisq.network/stats page.

Write a script and design a new web page.

Results

1. By looking at one page, anyone could see how the network did relative to its targets in the past, and what its targets are for the future. New contributors could see all the major functional goals on one page, get an idea of where the highest-priority needs are, and see what the corresponding budget for them are.

2. Role reports will allow existing contributors and stakeholders to better see if the function is living up to its goals and budgets, giving them better grounds for replacing under-performing role-owners. Right now there isn't much of a basis to get rid of someone other than prolonged absence or malicious activity. That might become a problem.

The practical ongoing work required to make this happen is almost nothing: just one quick meeting per cycle, and a little more effort into writing role reports.

Ancillary Results

1. I think having budgets and goals for major functions determined and re-evaluated on a regular basis could give the project the slight nudge of leadership it needs to prevent stagnation without establishing "bosses". They could serve as a form of rudimentary management in place of human managers.

2. Having budgets would help pave the path for work with non-obvious, non-immediate results. Creating thoughtful blog posts and social content, for example, or even providing support—these are jobs that take a lot of time but don't have obvious results in the short-term. They're not compensated well (or at all) by the existing compensation conventions. We'd have to fine-tune the process to discourage complacency, but that's a separate challenge and a separate discussion.

[MwithM]

This is a very difficult task for a DAO, but a very important one.

I am not able to imagine the details of the whole process, but I'm open to changes that I think are mandatory.

Regarding this:

What is the maximum amount of BSQ the network should issue in the next cycle, based on how much BSQ was burned in the last cycle? Trading volume is too volatile to make projections so these figures probably need to be backward-looking for now.

I would consider the possibility of not taking into account burned BSQ (which can be seen as a kind of revenue) and create a certain fixed (or at least, rigid) amount of BSQ in a certain period. This way all DAO participants would know from advance what is the maximum rate of inflation to expect, even if it's a high one at the beginning. I like this feature for BTC (demand doesn't matter, the creation of coins is fixed) and I think it would be good for BSQ too.
Another possibility is to calulate total BSQ burned in the last 4 cycles and not exceed this amount divided by 4 on the next cycle, in a similar way we are calculating BSQ/USD rate for compensation requests. Reading again the proposal, I guess this option, or a similar one, is what @m52go means by backward looking.
A mix of both options, the first for long term and second for short makes sense too.

I believe that keeping a low inflation rate is the best for Bisq. It could look like this way we are limiting possible growth of the project, but it's the best way of making it long term sustainable from the beginning and for BSQ, something valuable that contributors don't sell as soon as they earn.

[chimp1984]

Thanks @m52go for the proposal! I agree to all your points.

Looking at the BSQ market we are declining on a dangerous path where negative feedback can become an existential threat. Lower BSQ/USD rate means higher compensation amounts, which means higher inflation and with that lower incentive to hold BSQ as investment. We have to avoid further decline on that path.

Here are the numbers of the past 4 cycles:
Cycle 6 is 1.00 USD
Cycle 7 is 0.79 USD
Cycle 8 is 0.81 USD
Cycle 9 is 0.67 USD

How can we get out of that negative cycle?

• Cutting costs
• Increasing trade volume and with that revenue

I would like to discuss an additional idea to what @m52go has brought up above:
Freezing expenses to a minimum until we have a more solid management with clear targets and checks if expenses are justified. This cut would not be applied to already done work (but pending compensation), only to new work.
Those who are motived to make Bisq successful will have a strong incentive to get that management problem solved as soon as possible. I fear otherwise the process to get back on track might take too long.

Before looking how we can cut expenses lets look first to the numbers of the last cycle.

Here is an overview of our costs from cyle 8 by category (some requests contained mixed categories, I tried to find out which was the dominant one and used that in the assignment):

Techincal:

Development: 86862
Infrastructure (seed nodes,...): 6800
Testing: 4539.51
SUM: 98201.51

Communications:

Translations: 9864.27
Communications: 8517
Webpage: 1300
SUM: 19681.27

Support:

Mediation: 5200
Burningman (not perfect category here...): 1000
SUM: 6200

Refund agent: 27210 (the refund agent must be excluded as the reimbursement is equivalent to the burned BSQ from trades ending up in arbitration, so its zero sum ignoring volatility risk)

Here is an attempt to find our minimum required expenses to keep operation of Bisq healthy and to be able to grow trade volume (requires investment).

Min. costs infrastructure:

(using 100 BSQ for a heavy node and 20 BSQ for a light node, not sure if that is too low)
8 Seed nodes: 800
12 BTC nodes: 1200
5 Price nodes: 100
3 BSQ explorer: 300
1 notification relay: 20
1 market server: 100
SUM: 2520

Min. costs development:

Release: 3000 (for shipping most recent data we need a release at least every 4-6 weeks)
Release testing: 1000 (if no new features are released test effort should be low)
Bugfixing: 5000 (investment to bring support costs down and user experience up)
SUM: 9000

Min. costs support:

2 Mediators: 10000 (1 mediator did not made his request this cycle) - to get down the costs we need to improve support and fix bugs
Burningman: 1000
3 Support agents: 6000 (we have to improve here, so no cuts but investment)
SUM: 17000

Min. costs communications:

Webpage: 1000 (minimum which directly helps with management and growth)
Get the word out to increasse volume: 5000 (we have to improve here, so no cuts but investment, but we have to ensure quality and strategy is correct)
SUM: 6000

Min. costs translations:

I would suggest to make a complete stop on translation expenses for the time until the revenue is back on track.

Total costs: 34520

This is still way above the current revenue which is roughly 12000 USD assuming 0.4% trade fee for the 422 BTC volume of the past 4 weeks. To get a more correct number should be an investment for improving our management tools.

[m52go]

I agree with the general idea of the budget above. We need hard (harsh?) caps. Numbers above are a good starting point...maybe exact numbers are best left to a discussion.

As a general comment, growth is what's going to get us out of this pickle—there's no way around it—so we need to get serious about it. We've been brainstorming growth strategies over the past couple of weeks, and as it turns out, a couple of promising growth-minded contributors have dropped by recently, so I'm hoping to start implementing in early January.

[ghost]

A few comments:

Min costs support:

Mediators should write a report about what their cases were such that the problems can be eliminated or minimised. If remaining cases are simple then their compensation should be in line with the effort. The new reporting feature will help in this regard: bisq-network/bisq#3788

Support agents should do the same. We risk to land in support hell also, which is extremely expensive. Bisq must absolutely minimise the need for support.

Presumably the expense for support and mediation can be decreased quite a bit in the near future.

Min costs communication:

One has to be careful here. So far all marketing has been a failure. Essentially nobody is trading yen, RMB, and so on despite bounties, meetups and translations. The only exception is BRL which was started by one person.
The effort should be put on understanding why nobody is using Bisq and improving that. I only know of programmers who can use Bisq and they have to help their non-programming friends to use it. Some of them trade for their friends. I doubt Bisq will survive without an improved UX. Maybe if all other exchanges are regulated to death (and that may happen).

[RiccardoMasutti]

I would suggest to make a complete stop on translation expenses for the time until the revenue is back on track.

I disagree on taking away budget from languages. The most important thing in my opinion are translations.
Since it affects me directly, does this apply even if my proposal has already been accepted? #151

Would be great to connect spending data (inputs) with practical results (i.e., outputs like software downloads, trade volume, etc) to determine ROI...but that's a much more complicated task that will need more thought and time to implement.

This is easy to implement with Matomo. For example, if an Italian user enters the Italian version of the site, we can create a goal and track an event if he downloads the software.

[wiz]

@chimp1984 One minor note on the infrastructure budget, we need to increase the cost of price nodes to $100/month each because BitcoinAverage just raised their prices to $60/month and the node will cost $40/month to run

[chimp1984]

@wiz Ah ok. My numbers are just starting points for discussion.... Node operators need to give feedback what are realistic numbers.

[m52go]

Another possibility is to calulate total BSQ burned in the last 4 cycles and not exceed this amount divided by 4 on the next cycle, in a similar way we are calculating BSQ/USD rate for compensation requests. Reading again the proposal, I guess this option, or a similar one, is what @m52go means by backward looking.

@MwithM yes this is what I had in mind, but I was only thinking of the short-term (i.e., use last cycle's burn to predict next cycle's issuance). Your suggestion about using an average might be better.

---

I suggest we aim to get basic elements of this proposal figured out and implemented before the end of Cycle 9 in case any proposals need to be made, so that they can be implemented at the start of Cycle 10.

Cycle 9 will end in about 2 weeks from now, and Cycle 10 will begin in about 3 weeks from now.

Maybe we can have a call next week to discuss the basic mechanism proposed here, budget numbers, and any other concerns.

[MwithM]

I think that this is one of the priorities for Bisq now, so I agree with the call.

Also, it would be nice if we published Compensation Requests for Cycle 9 as WIP soon, to estimate how many BSQ are going to be issued this cycle.

[chimp1984]

I suggest to communicate clearly that we will be more restrictive with accepting compensation requests to avoid disappointments from wrong expectations. I at least will only accept requests which are in areas absolutely needed and which are 100% clear that added value justifies the requested amount.

[flix1]

Consider the above hypothetical budget for a conservative growth scenario...

At some point in the life of a startup you need to decide to prioritize financial breakeven. However it can be a mistake to do so before critical mass is reached. There is a minimum revenue below which it makes no sense to even have a business model. I would suggest that anything lower than $100.000 /day volume (= $12.000 /month revenue) is not viable as anything other than a personal not-for-profit project.

So before we even think about budgeting we should be worrying about how to reach that minimum viable volume.

Once we achieve that minimum critical mass everything follows logically... if you have $12k monthly revenue it's pretty easy to budget... (eg: $8k dev, $2k maintenance, $2k support). You basically have a role for budget manager for each basic area... budget managers are the ones who approve bounties, proposals. DAO votes on appointment/removal of those managers.

Or if you want to give the DAO a bigger role, you can have the DAO itself set the total budget (vote on a proposal) then approve individual compensation requests based on the pre-approved monthly guidelines without budget managers.

Whatever we do KEEP IT SIMPLE. We don't need a bureaucracy to allocate a startups worth of salaries and expenses.

[flix1]

The easiest, fastest way to achieve $200k daily volume would probably be to attract a handful of altcoin OTC whales. If we could replicate XMR/BTC volumes with a couple of the other top 10 altcoins we would be there already.

Just look at the volumes that LTC or USDT do on other exchanges and imagine if Bisq could capture even 1% of that.

...

1% of USDT volume alone would be 310.000.000 daily! Even if we clean up the stats and use only verified volume from fee-charging exchanges, we are still talking of millions in daily volume.

I have always advocated for Bisq to be focused on Bitcoin-fiat exchange... but I don't see why we can't just add USDT, improve conditions for XMR users, etc..

[flix1]

I should mention that there are 2 basic approaches to budgeting in a startup:

A- "We need to spend X" + "We have Y capital" --> "We have Z months of runway"
B- "We generate X in monthly revenue" --> "We can spend X"

Normally startups have 2-3 years of method A and when (if) they have sustainable revenue generation they transition to B.

For Bisq, even if in theory there is no limit to runway because it pays in BSQ, in fact there is. BSQ inflation could lead to a downward spiral.

I would suggest that 2020 is the year for this transition to breakeven and living within our means. However it doesn't have to be January 2020.... the transition can be gradual over 6 months. Just having an announced plan to limit BSQ inflation by June 2020 will bring much stability to the market.

[MwithM]

I completely agree with your last comment.
The other two were a little off topic as they were focusing more on growth-revenue, which is the other side of spending.

[flix1]

2019 Bisq trading volumes totalled $102M. That is an average of $8.5 million/month. At 0.4% fees that would mean a monthly revenue of $34k.

I think that if we work with a monthly budget of $50-60k per month in 2020, Bisq could reach breakeven by June/July. If we want to be on the safe side we could limit BSQ issuance to $40k monthly for the next 6 months. That would send a strong signal to everyone that the DAO is serious about limiting inflation and being profitable.

[wiz]

@m52go based on the discussion here, do you have a draft budget on how to spend $50K/month?

[beingindot]

If we have problems with runway, we have to put efforts for growth (everyone agrees here).

Meanwhile we can split compensation into two parts

1. spendable (which we can spend in the market)
2. non spendable (immediately we can not spend, but once bisq gets runway or in some agreed point we can make it spendable - much like equity)
   much like PR, one authorized person have to split requested compensation amount as 1 and 2 as per budget. (everyone may need to accept here)

Not sure whether possible in DAO or not.
Just my thought here. Please ignore if it's missing some obvious reason.

[ghost]

@flix1 Maybe you can tell us how "The easiest, fastest way to achieve $200k daily volume would probably be to attract a handful of altcoin OTC whales." can be done.

[m52go]

@beingindot that's an interesting idea. If I understand you correctly, maybe we can achieve something similar by simply deferring a request into the future. That is, if someone is willing to do work that the network agrees is important right now, but there is no budget for it, the compensation request for it is deferred until there is room in the budget to compensate it.

Perhaps we can track those in compensation requests and then do 1-time payouts (at the end of a year, for example) if the network effect is acceptable (i.e., if we end the year having burned 100,000 more than expected, than a <100,000 dividend to cover deferred compensation requests might be acceptable).

So before we even think about budgeting we should be worrying about how to reach that minimum viable volume.

Yes we are in the final stages of working out growth strategies right now, will start to coordinate and execute next week. Will make a thread to collect thoughts in the growth repository shortly.

Whatever we do KEEP IT SIMPLE. We don't need a bureaucracy to allocate a startups worth of salaries and expenses.

Agree, and that's the intended spirit of this proposal. Ultimately this budget will be a guideline to help focus efforts, approve reasonable spending, and reject unreasonable spending. I think it's pretty simple. The X factor is in effectiveness of growth strategies...they will make all the difference.

[flix1]

@flix1 Maybe you can tell us how "The easiest, fastest way to achieve $200k daily volume would probably be to attract a handful of altcoin OTC whales." can be done.

@TaxD it was rightly pointed out to me that this is off-topic here. However I am very interested in having this discussion elsewhere, I think it is an important issue.

Maybe keybase growth chat?

[beingindot]

maybe we can achieve something similar by simply deferring a request into the future. That is, if someone is willing to do work that the network agrees is important right now, but there is no budget for it, the compensation request for it is deferred until there is room in the budget to compensate it.

That won't be simple because one will submit only one CR which has some imp and some not so imp in near term things. totally cant approve cause of budget / cant reject cause of impactful work.
Also what if all submitted work is important and exceeding budget.
This is all assuming if we have an insufficient budget.

[chimp1984]

@flix1 Over the past month we have been just slightly over the 100k limit, the years average benefits from a few very strong months with XMR trades in summer. I think currently with the decreasing BSQ price we are in an emergency situation and not lose too much time to get back on track. Also I had the feeling over the past months that compensation requests became often out of balance to delivered value. We should be much more critical of the value of delievered work.

[ghost]

Even excluding XMR the volume is at best steady and probably decreasing.
Any bounty or so to increase liquidity will be taken by selftraders.
The liquidity is sufficient in EUR and USD and artificial liquidity boosting will not work.
Attempts to increase volume must work for EUR and USD.

[m52go]

This initiative is being implemented, but in a different way than proposed here. See details here.