• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Problems with Budget System / Possible Solutions

David

Well-known member
It's amazing to see how our budget system has developed since Evan originally proposed the idea. Initially only the Core Team submitted proposals, all of which passed without much controversy or fanfare. Recently, however, we have seen individual community members make proposals and have them approved, which is an important step in the evolution of our project. It's good to see innovation coming from the community rather than simply being developed in a "top-down" fashion from the Core Team.

Problems

However, the budget system has a few weaknesses that has caused/is causing/will cause problems. Namely:

1) Unused budget funds are "burned," resulting in money that could have been used to fund Dash development being wasted. Although theoretically "working as intended," this is inefficient and results in unintended consequences.

TanteStefana has eloquently argued in the BCT thread that the system is basically in debt right now, using future budgets to pay for existing projects. Not only that, but popular and highly useful proposals are getting numerous no votes out of the fear that approving them will result in unused budget Dash which will simply be burned.

2) Many service providers require legally-binding contracts to be signed, obligating the signer to pay future costs. A lawyer may be needed, for instance, and will not work unless he receives both a retainer and a legally-binding promise to pay for any additional charges which exceed the retainer. At present, the budget system is unable to handle such contracts. Any proposal can be voted down at any time, or a competing proposal can be voted up higher, resulting in future installments of the already approved proposal not getting paid.

Right now, either a human or other legal entity (e.g. the foundation) must be legally responsible for any such contracts. DACs such as Dash are not yet recognized by the law. When Evan, Daniel, or the foundation sign a contract based on a proposal which has passed, and the network for any reason withdraws funding (or simply pays more popular proposals before the contracted one), our developers or foundation are responsible for any unpaid bills. Eventually, these people/entities will stop taking this risk if they have to be worried about the reliability of reimbursement. Then if Dash needs a lawyer (or any other professional service), how will we hire one?

Possible Fixes

Any solutions to these issues are hampered in two ways: a) the possibility of unintended consequences, and b) the fact that some community members don't see these as being problematic, but rather "working as intended."

With as much respect as possible to both those difficulties, I would propose that the developers and community consider possible improvements. Possibilities include:

1) Unused budget Dash not being created, but being "remembered" by the network. In a month where 500 Dash would have otherwise been burnt, this Dash is in fact not created. But if the next month the budget goes over by 250 Dash, that amount is paid because the network "remembers" that 500 Dash was not created the previous month.

2) Some type of system needs to be developed to handle short-term contracts. Perhaps a system could be developed where for certain proposals (those involving legal contracts and requiring installment payments) you had one period to vote, say 30 days, and after that no more votes would be accepted, and no votes could be changed.

My suggestions are quite possibly flawed and could themselves result in unintended consequences. But I'm hoping they will be a starting point for some discussion.
 
1) Unused budget Dash not being created, but being "remembered" by the network. In a month where 500 Dash would have otherwise been burnt, this Dash is in fact not created. But if the next month the budget goes over by 250 Dash, that amount is paid because the network "remembers" that 500 Dash was not created the previous month.

2) Some type of system needs to be developed to handle short-term contracts. Perhaps a system could be developed where for certain proposals (those involving legal contracts and requiring installment payments) you had one period to vote, say 30 days, and after that no more votes would be accepted, and no votes could be changed.

1. This is a really good idea! I like it much better than our catchall idea (catching excess funding using a series of proposals).
2. I was thinking of exacting this as well, although with a couple modifications to stop some possible exploits. Proposals will have no expiration period and a minimum of 10% support to make it into a budget. Contracts will have a 30 day voting window and a 33% support threshold to be added as a priority item in the budget (contracts will always be paid first).
 
1. This is a really good idea! I like it much better than our catchall idea (catching excess funding using a series of proposals).
2. I was thinking of exacting this as well, although with a couple modifications to stop some possible exploits. Proposals will have no expiration period and a minimum of 10% support to make it into a budget. Contracts will have a 30 day voting window and a 33% support threshold to be added as a priority item in the budget (contracts will always be paid first).

Can we just not deal with 3+ month contracts? The price can change soooo much in that time period and we'd be on the hook for overpaying our contractor at that point, legally.
 
I think proposal budgets should be pegged to USD. The volatility of Dash makes things weird when it comes to budgets. I guess this could be coded in somehow, just use an index price from say coinmaketcap or something.
 
I think proposal budgets should be pegged to USD. The volatitliy of Dash makes things weird when it comes to budgets. I guess this could be coded in somehow, just use an index price from say coinmaketcap or something.

Thank you. Everyone keeps calling me a fucking troll and its getting annoying. This is common sense.

If you are paying a contractor for MULTIPLE months, pay them in a more fixed amount AKA USD.

Projects can be paid out in Dash as well as single vote items. Why are we adding risk to the network?
 
Can we just not deal with 3+ month contracts? The price can change soooo much in that time period and we'd be on the hook for overpaying our contractor at that point, legally.

Certain industries aren't really suited for one-off work and tend to be based on short-term contracts. If we had enough budget space to pay for the entire contract up front that would be great, but for some of the larger items, we don't.
 
Certain industries aren't really suited for one-off work and tend to be based on short-term contracts. If we had enough budget space to pay for the entire contract up front that would be great, but for some of the larger items, we don't.

So maybe we should wait until we do have the funds instead of jumping the gun? I just feel like giving out a large % chunk of the budget is a bad idea.
 
So maybe we should wait until we do have the funds instead of jumping the gun? I just feel like giving out a large % chunk of the budget is a bad idea.

Right now the system doesn't allow us to carry over unspent money from previous months, which is what I propose changing. If/when this happens, then paying for stuff in a lump sum will be feasible.
 
Right now the system doesn't allow us to carry over unspent money from previous months, which is what I propose changing. If/when this happens, then paying for stuff in a lump sum will be feasible.

See now we are getting somewhere. I like the general direction in which this conversation is headed. i can get on board with a carry-over mechanism. Just not a "slush" fund.
 
I think proposal budgets should be pegged to USD. The volatility of Dash makes things weird when it comes to budgets. I guess this could be coded in somehow, just use an index price from say coinmaketcap or something.

I only see one problem with this. For example, when a proposal is submitted with a chunky piece of the pie (like dash.org), to get it in Fiat without risking possible devaluation/erosion, you need to convert ASAP. That creates an immediate non-sale flag in the exchanges.

a) people in the know will remove their buy orders as they predict foreseeable price drop.
b) side effect is a post sell-off pump/buy-in

This will create an even more volatile market. Which is great for traders, but bad for business.

.
 
yidakee

Nothing is perfect but let's take the case of Terpin PR which is an ongoing arrangement. What if price of Dash would suddenly drop to half of what is is now. That could certainly happen. What then? Vice-versa would leave projects with excess funding which can be misallocated.

I see this is as a much bigger issue.
 
I only see one problem with this. For example, when a proposal is submitted with a chunky piece of the pie (like dash.org), to get it in Fiat without risking possible devaluation/erosion, you need to convert ASAP. That creates an immediate non-sale flag in the exchanges.

a) people in the know will remove their buy orders as they predict foreseeable price drop.
b) side effect is a post sell-off pump/buy-in

This will create an even more volatile market. Which is great for traders, but bad for business.

.

yidakee
OK those are fair points.

But we need to set a standard one way or the other.

Maybe the solution is just, lets wait for big ticket items that take up 30%+ of the budget per item? Break the budget down into smaller projects and go from there, eventually we can spend big like the big boys, but right now it's risky imo.

yidakee

Nothing is perfect but let's take the case of Terpin PR which is an ongoing arrangement. What if price of Dash would suddenly drop to half of what is is now. That could certainly happen. What then? Vice-versa would leave projects with excess funding which can be misallocated.

I see this is as a much bigger issue.

InTheWoods
Agreed. We are acting to big for our britches and people are going to see an opportunity there to rip the community off left and right.

Smaller budget proposals seem to be where the solution might start.


1. This is a really good idea! I like it much better than our catchall idea (catching excess funding using a series of proposals).
2. I was thinking of exacting this as well, although with a couple modifications to stop some possible exploits. Proposals will have no expiration period and a minimum of 10% support to make it into a budget. Contracts will have a 30 day voting window and a 33% support threshold to be added as a priority item in the budget (contracts will always be paid first).

eduffield
Why can't we add in a rule that no single item takes up a certain percentage of the budget as well? Seems unfair to be forcing everything off the table because of 1 item. ANd this will surely happen in the future with more "big ticket" items like the Terpin stuff & the Bitcoin Island resort business meeting thing.

Couldn't we just keep chugging along as we currently are? Why is everyone getting so impatient we are willing to just throw funds at things to see if they stick? Without any ROI expectations? Stats? Analytics?
 
Last edited by a moderator:
I only see one problem with this. For example, when a proposal is submitted with a chunky piece of the pie (like dash.org), to get it in Fiat without risking possible devaluation/erosion, you need to convert ASAP. That creates an immediate non-sale flag in the exchanges.

a) people in the know will remove their buy orders as they predict foreseeable price drop.
b) side effect is a post sell-off pump/buy-in

This will create an even more volatile market. Which is great for traders, but bad for business.

.

This is ameliorated by the fact that the Core Team actually sells the Dash via over the counter exchanges. No Dash actually gets sold on the open market.

yidakee

Nothing is perfect but let's take the case of Terpin PR which is an ongoing arrangement. What if price of Dash would suddenly drop to half of what is is now. That could certainly happen. What then? Vice-versa would leave projects with excess funding which can be misallocated.

I see this is as a much bigger issue.

What would happen is Michael Terpin would say "Oh damn, that sucks." Remember--we paid them in Dash because that's what they requested; if the price drops then that's on them.

Agreed. We are acting to big for our britches and people are going to see an opportunity there to rip the community off left and right.

That's why you have to use reputable, established service providers. Michael Terpin isn't going to ruin his reputation in order to take a few thousand dollars from us. Moe isn't going to ruin his reputation by taking our registration fees for BTCMiami and denying us entry, etc. Definitely a concern though if dealing with less established players.
 
I love your two ideas David.
1. How long (if there is a limit) do you think the network will/should remember the unpaid Dash from superblock? (forever? or fix a limit?)
2. This is good to avoid breaking contracts and make Dash look un-profesional.
I think that long time period contracts will have more difficulties to be voted In from MN owners. But once it's accepted, no down voted possible.
Hmmm writing this make me think it can be dangerous...
 
This is ameliorated by the fact that the Core Team actually sells the Dash via over the counter exchanges. No Dash actually gets sold on the open market.



What would happen is Michael Terpin would say "Oh damn, that sucks." Remember--we paid them in Dash because that's what they requested; if the price drops then that's on them.
Well that's not a problem of course when the person is fine with getting paid in Dash but what would have happened in the case of the Soda Machine or the Vendor Machine project? All those expenses were paid/would have been paid in fiat not Dash.
 
I love your two ideas David.
1. How long (if there is a limit) do you think the network will/should remember the unpaid Dash from superblock? (forever? or fix a limit?)
2. This is good to avoid breaking contracts and make Dash look un-profesional.
I think that long time period contracts will have more difficulties to be voted In from MN owners. But once it's accepted, no down voted possible.
Hmmm writing this make me think it can be dangerous...

This is why we must talk about it instead of just let people make these decisions for us. We are a decentralized community after all, no?
 
Well that's not a problem of course when the person is fine with getting paid in Dash but what would have happened in the case of the Soda Machine or the Vendor Machine project? All those expenses were paid/would have been paid in fiat not Dash.

That would have been messy, which is part of the reason I don't generally like long-duration projects.
 
That would have been messy, which is part of the reason I don't generally like long-duration projects.

So short term single projects would work better you are saying?

Why are we arguing again? I've been saying this over and over and over.
 
I love your two ideas David.
1. How long (if there is a limit) do you think the network will/should remember the unpaid Dash from superblock? (forever? or fix a limit?)
2. This is good to avoid breaking contracts and make Dash look un-profesional.
I think that long time period contracts will have more difficulties to be voted In from MN owners. But once it's accepted, no down voted possible.
Hmmm writing this make me think it can be dangerous...

That's a good question. My first thought is "forever" but that could be problematic if the unallocated amount grows extremely large. Then we might just start spending money because we have so much of it available. Maybe a rolling 365 day period? If unallocated money isn't allocated within a year, it is burned forever?

The short-term contract idea is a little more tricky. I agree with Evan--it would definitely need to have a larger threshold in order to prevent abuse. At the same time, we do this kind of thing in the real world all the time. Once you elect a president, you don't get to go back and change your vote no matter how good or bad he is.
 
xpost (sorta) from btctalk.

Scenarios;

1) Price depreciates
a) proposer either pays from his pocket and hopes for a future reimbursement with a new proposal
b) proposer does not cover from his pocket, leaving the contractor hanging.
b-1) proposer burns the coins because he could not get full funding (or donates to Foundation)

2) Price appreciates
a) proposer payes contractor, burns the rest ( or donates to the Foundation)

There is only problem with 1a) and 1b)

How about using the OTC to buffer the volatility factor? Shouldn't cause much stress to it unless it's a super huge budged, in which case, if voted positively, then that means it's big enough for the trouble.

.
 
Last edited by a moderator:
Back
Top