• 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

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.

As I recall, you were a major proponent of the 99-month Vendor-Experience proposal?

I personally think that contracts should be made for as short of a period of time as possible. If a vendor will do a one-off, month-to-month thing with us, then great! If they will only do a guaranteed three month engagement, then fine. But I wouldn't commit for any longer than is strictly necessary. Too much changes in this world--exchange rate not the least of all.
 
As I recall, you were a major proponent of the 99-month Vendor-Experience proposal?

When? Where?

I was a proponent of supporting the actual community members, not 'outsiders' who give no shits about Dash. I was pushing that we should show some gratitude to these people. 99 months never mattered to be because I understand it can be voted down at ANY time when competition arises.
 
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.

Forever can be problematic for the reason you give, 1 year memory seems good balanced.

Maybe enable a re-evaluation, or make a renewal period (ie: re-open vote every X months for 30 days, 1 month before the terms of the "period" contract. )
For example : a contract of 1 year with 6 months re-evaluation : if the budget pass then the contract will be paid every month, after 5th month the vote are re-open for (30 days) and will decide if this contract is renewed for his last 6 months period or not. If it pass then again the last 6 months will been paid without down vote possible..

Edit: and also we must think of a kind of "Emergency" contracts exit. In extreme case...

Edit 2: Or just accept small time frame contracts. (max 6 months) ;)
 
Last edited by a moderator:
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 respectfully disagree.

If we pay in USD, WE take the volatile risks. If we pay in DASH, the other side takes it.

Dash is what it is today because of people who BELIEVE in Dash. If a contractor doesn't believe enough in Dash to sign a contract paid in DASH it's IMO the wrong person for the job. A person with the same skills who believes in Dash will always do a better job.
 
Last edited by a moderator:
I respectfully disagree.

If we pay in USD, WE take the volatile risks. If we pay in DASH, they other side takes it.

Dash is what it is today because of people who BELIEVE in Dash. If a contractor doesn't believe enough in Dash to sign a contract paid in DASH it's IMO the wrong person for the job. A person with the same skills who believes in Dash will always do a better job.

Completely fair point.

Hence why I suggested paying upfront or in chunks of 1 month (in this case the proposal needs to be resubmitted when it becomes overfunded to fix the overfunding issue).

Wouldn't that save everyone this whole hassle? Why are we putting the network OR the contractor on the hook for any risk? Just give them the money upfront and be done with it, wala no risk. They can do as they please now, its thier money.
 
I respectfully disagree.

If we pay in USD, WE take the volatile risks. If we pay in DASH, they other side takes it.

Dash is what it is today because of people who BELIEVE in Dash. If a contractor doesn't believe enough in Dash to sign a contract paid in DASH it's IMO the wrong person for the job. A person with the same skills who believes in Dash will always do a better job.

I hear what you're saying but what about proposals where stuff needs to be purchased in fiat like the Soda Machine or the Vendor Experience. This becomes increasingly problematic when you're talking long term projects.
 
Completely fair point.

Hence why I suggested paying upfront or in chunks of 1 month (in this case the proposal needs to be resubmitted when it becomes overfunded to fix the overfunding issue).

Wouldn't that save everyone this whole hassle? Why are we putting the network OR the contractor on the hook for any risk? Just give them the money upfront and be done with it, wala no risk. They can do as they please now, its thier money.

Why don't the proposal owner make a contract that is a agreement to provide services should the proposal be funded? Then if the money comes, the proposal owner converts it into local currency and contractor can start working. After the service is completed to satisfaction, the proposal owner pays him. Everybody is happy.

What I see some people doing is counting the chickens before they hatch, and they should be more responsible.

PS: Maybe it would be nice to have an option to return (or give!) funds to the next superblock. A special address, perhaps?
 
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.
.

Something I've been thinking about with being paid wages in appreciating crypto-currencies
If we wish for the economy to grow then the value needs to be pegged to its relative value when paying people in said currency, this means the total sum of wages paid will go down
relative to the increasing value.
If this doesn't happen, growth will be restricted and there will never be enough Dash to go around. This should also be true with the budget
My fear is, if this isn't sorted out now, we go nowhere.
 
I would suggest we deal with the 5 DASH for submitted proposal as well.
Instead of Burn the coin and the rest of the unused budget. It would be better to collect those fund and redirect to a charity purpose fund.
And maybe giving those money to homeless people I guess. Or buying food for homeless people.
We can treat this as a PR as well.
 
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).

Evan, I'm glad you like these ideas. It's always great to hear from you!

I wanted to take a moment to flesh things out just a little more:

Network "Remembering" Unspent Funds

I believe that there should be a time limit on how long the network "remembers" unspent budget funds. Without a limit, we could theoretically arrive at a point one day where there are thousands of Dash built up in the unspent pool and be tempted to use them on projects that aren't overly valuable. I think we have to walk a fine line between not wasting unspent funds but preserving scarcity in budget funding so that people are incentivized to vote only for the best proposals.

I think a good balance is to have the network "remember" unspent budget funds for 12 months, on a rolling cycle. So if we have 500 Dash unallocated in May 2016, the network would allow those funds to be allocated at any point up until April 2017. Once May 2017 rolls around, the funds should be "forgotten." Also, when unspent funds are "remembered" by the network and spent in a later month, the oldest should be used first.

A final consideration is that nobody is 100% sure as to how much budget space there will be until the month is completely over. Likewise, one is never 100% sure that the vote count won't change in the last hours or minutes of a voting cycle. This makes it very difficult to decide which projects to support. One doesn't want to waste a whole bunch of budget funds by funding a "small" important project before a "big" important project, and so may vote "no" to the small project even if budget space ends up being available for it. Likewise, in a particularly tight budget cycle, a person may refrain from proposing something for fear that it would bump a bigger project and result in wasted funds. If such funds are remembered instead of burnt, these issues are mooted.

Contracts

I like the idea of having a higher threshold for "irrevocable" contracts. I would also suggest that they not be permitted to exceed a certain time period, such as three or six months. Any budget proposals for longer than that maximum length of time would be submitted as "normal" budget proposals subject to being voted down at any time.

There is probably going to be some controversy about one-time voting on contracts and then "locking" them so that they cannot be revoked. I would like to point out a few reasons why such a system should be accepted by the community:

1) There are times when a service provider requires a contract for a certain duration. Once it's approved, the network should not be allowed to breach that contract. Such a breach would have obvious consequences for Dash's reputation (who wants to deal with a contract breaker?), but could have legal consequences as well. Dash is a DAC, but DACs aren't legally recognized. That means a person (Evan, Daniel, etc.) or an entity (the Dash Foundation) must sign any contract. It is that party who would be legally liable in the event of break of contract. The last thing we need is for our lead developer or our foundation to be sued by a service provider for breach of contract!

2) The idea of voting one time and not being able to change one's vote is pretty well established in most or all democracies. In the United States, for instance, you can't go back and change your vote or "unelect" the president once he is voted into office. You're stuck with him/her for the next four years, regardless of whether you like that person's job performance or agree with that person's policies. I cannot think of very many scenarios in the real world where people have the opportunity to change their vote at any time. Usually voting is a one-time thing, until the next voting cycle opens. Using such a system in special cases within Dash should not be too much of a stretch.

3) Several people in the last week have asked why contracts can't simply be completely funded in the month they are proposed, rather than requiring recurring funding from month-to-month. This would be desirable, of course, but isn't always possible. There are times when two or more equally important (and expensive) opportunities arise, and the network would benefit most if both were passed. However, there may not be enough funds for both. Likewise, it's possible that there could be a temporary "crash" in the price of Dash which results in a much lower than normal amount of budget funds (in fiat terms) available. Also remember that a significant percentage of our budget funds are already allocated for Core Team and Public Awareness, which means that large projects could not necessarily be funded in a single budget cycle anyway.

My solution to this is psychological. In the budget proposal for a contract, the proposer should be clear not only how much the proposal will cost per month, but also the total cost of the project (all months added together). Each voter should then consider whether, if the proposal was submitted as a one-time lump sum request, they would be willing to spend that money. Just because a proposal spans multiple months does not mean voters can't evaluate it as they would a one-time expenditure.

Currency Risk

No currency is completely stable--not even the much-vaunted U.S. dollar. Currencies rise and fall with respect to other currencies all the time. Dash is no different. Yes, our fluctuations are much greater, but the concept remains the same. Some vendors will happily accept Dash, while others will insist on fiat payments.

In my opinion, the proposer should specify which currency the vendor will be paid with, whether Dash, dollars, euros, etc. If the vendor is accepting payment in Dash, then the proposer should specify the agreed-upon exchange rate. This is really only an issue with multi-month proposals.

I don't think it's right for us to force a particular currency on any vendor we are doing business with. Whether Dash or fiat, the situation can be easily managed by being up-front and fully communicative when writing a proposal. The network can then decide not only on the merits of your proposal, but (if paying in Dash) on the agreed-upon exchange rate.

We must remember that this sort of thing happens all the time in the real world. Pre-IPO companies are "valued" at a certain amount during each funding round (for instance, $1 million for a 10% stake, which represents a $10 million valuation). Likewise, multinational companies deal with exchange rate issues all the time. Most of them use currency hedges to mitigate risk, but at the present time no such thing (to my knowledge) exists with Dash. This means any vendor accepting Dash must also accept the possibility of depreciation or appreciation. The network must understand and accept these possibilities too.
 
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?

I don't think you're a troll but I think this is a bad idea, it's basically pegging our obligations in another currency. This is how a lot of emerging market countries became debt burdened to the extreme - their debts were in USD.

All of the same problems could theoretically arise, the USD could rise or fall, fucking our contracts.

I think the governance system works fine now, we can always cancel, and then renegotiate contracts on the network governance platform.

Also, maybe we should ignore the system's proclivity for risk right now?

Imagine what the dev team could do with the budget if DASH went up 100%? If it went down by 50%, we may have to cancel the contract, and set up a new one for more dash.

I like the fact our system utilizes human agents, and my only concern regarding changing how the rewards are spent is accidentally hiding risk or pegging our risk to another horse so to speak.
 
I'm trying to put all my thoughts in one place (or at least, one thread), so I'm adding everything here as I think of things.

Perverse Incentives

I'm a big fan of the book Freakanomics. The authors' thesis is that most of the things that happen in the world are at least partially the result of economic incentives/disincentives. The authors argue that even the best-designed legislation will end up failing if incentives are misaligned. Right now, in the U.S., the Affordable Care Act (aka "Obamacare") is in danger of entering a financial (not political) death spiral.

The authors of that legislation inadvertently misaligned the economic incentives; even with the penalty for not selecting healthcare, many of the young healthy people (whose premiums are needed to balance out the old sick people) are still not signing up. As a result, the risk pool is greatly increased, and insurers are losing massive amounts of money by offering insurance to participants in the A.C.A. UnitedHealthcare stated that they lost $500 million last year and expect to lose the same amount this year, because their plans were mispriced. Their response is to raise premiums, which drives even more of the "young healthy" people out of the health insurance market. Now UHC is talking about leaving Obamacare altogether, further tilting the risk pool for those who remain.

How is this relevant to Dash? Simply put, the budget system (as it exists now) contains a major perverse incentive. It's a sort of chicken-and-egg problem that's predicated on the fact that virtually nobody wants budget funds to be lost due to not having enough proposals to fill the entire budget space. I agree; I think the budget space should be filled as completely as possible every month.

But here's the rub: it's almost impossible to fill the entire budget space and still allow the community to submit budget proposals. Think about it. The only way to be sure that the entire budget space will be filled is for Evan to fill it up with Core Team budget items, which are very likely to pass. If he doesn't leave any budget space unallocated by Core Team items, then it's likely that at least some Dash will end up being unallocated and never created at the end of the budget cycle. If he doesn't leave any budget space for the community, then we lose a major avenue of innovation, a major aspect of decentralization, and an opportunity to shift budget proposals completely to the community one day.

How do you ensure that the entire budget will be used every month without filling it with Core Team proposals? How can you ensure that the community will still have space to make their own proposals, without "wasting" budget funds? You have the system "remember" uncreated funds, and allow it to create those funds at a later date as needed.
 
I like your ideas David, but just want to say that if it were up to me, I'd like to see contracts have a maximum length of 3 months, at least until Dash stabilizes price-wise, which will probably take many years. And we could lengthen the terms as Dash's price stabilizes.

Also, I don't like the idea of "irrevocable" contracts" because someone can just not perform at all , and get the funds no matter what. So if it has to be irrevocable, maybe it also has to be in a multi-sig wallet where the foundation can not sign it if the contractor doesn't perform. The funds risk sitting there forever, but at least the scammer won't get paid.

And of course, I've been wanting us to make the entire 10% of the rewards available no matter what, forever. I suspect it was a real pain to code safely though, and that's why it wasn't done. Maybe it was a time constraint? I don't know, but yes, please, I'll have some of that :)

Finally, I can see Evolution taking longer and longer to complete, LOL
 
I would suggest we deal with the 5 DASH for submitted proposal as well.
Instead of Burn the coin and the rest of the unused budget. It would be better to collect those fund and redirect to a charity purpose fund.
And maybe giving those money to homeless people I guess. Or buying food for homeless people.
We can treat this as a PR as well.

5 DASH for submitted proposal can be distributed among those who submit vote. this will increase voter participation.
 
5 DASH for submitted proposal can be distributed among those who submit vote. this will increase voter participation.
Yeah that is true.
But I would prefer people not voting if they are not sure about any proposal.
So I would simply not support incentive voting cos it is their own responsibility to vote for their best interest budget.
 
Yeah that is true.
But I would prefer people not voting if they are not sure about any proposal.
So I would simply not support incentive voting cos it is their own responsibility to vote for their best interest budget.

i think you can vote abstain, or maybe those 5 dash should be added in next budget maybe ?
 
+1 To carry over unspent budget to the next month with a limit of 1 year.
I was initially sceptic about this, thinking that it is better to leave money unspent than use it for some random crap project. But there is the 10% votes hurdle for projects and accumulating some budget will allow for a bigger project at some point.

+1 For having a special address that funds can be returned to the budget. This would also allow for people to donate to the budget system. The dash budget proposal fee should also be paid to this address. Funds sent to this address should be added to the budget pool.

-1 For having proposals in USD and the dash amount adjusted based on this. This would tie the dash governance to the old world of fiat.

I am unsure about the multi-month contracts: I'd rather have projects financed fully upfront. This will avoid the conversion rate problem. But I can see the benefits of short-term (3-6 months) contracts that could not be cancelled after it was accepted. So I think this is fine to add.
 
Back
Top