This calendar year has seen the value of one Dash begin at $11 and skyrocket to as high as $407. Even more dramatic have been the past two “Saturday Surges.” On Saturday, August 19 the value of Dash went from $225 to $290, and the following Saturday, August 26, it went from $315 to $407. Clearly, price volatility is currently the norm for Dash (as it is for many cryptocurrencies).
With the rapid increase in the value of Dash, some in the community have noted that there is now “extra money” being distributed in various Dash Budget System (DBS) proposals. For example, one current proposal requests 2,000 Dash to fund a TV “road trip” by Max Keiser and Stephen Baldwin. At the time the proposal was made, this was worth approximately $500,000. However, with the most recent rise in Dash’s value, 2,000 Dash is now worth over $700,000. This has led to two complaints. First, some community members argued that it’s inappropriate for the proposals owners to receive so much “extra money,” with some even stating that the funds should be paid back in some fashion. Second, in order to prevent such situations in the future, others called for Dash Budget Proposals to be denominated in fiat instead of Dash.
Here’s why concerns to denominate proposals in fiat and to take action to prevent “extra money” being distributed are misplaced.
Denominated in Fiat?
Why shouldn’t Budget Proposals be denominated in fiat?
First, this would wreak havoc on determining the overall monthly budget. If proposals are denominated in fiat, then should the total allocated be in fiat or Dash? If fiat, then the amount of Dash to be generated each cycle could fluctuate wildly with the price changes. And if the total is denominated in fiat, what should the monthly limit be? $2 million, $20 million, $200 million? Should it be determined by the value of Dash at the beginning of a proposal cycle, and if so, what does that mean for multi-cycle proposals? If the total is to be denominated in Dash, but proposals are denominated in fiat, then the total amount available will be unknown until the day the cycle ends, making it difficult for proposal owners to know how much is available to them.
Second, which fiat should be chosen? U.S. Dollars? What happens if another fiat currency radically changes in value with respect to the Dollar—does the Budget System have to take that into consideration? A proposal winner could still receive “extra money” or “less money,” even if the Budget System were tethered to one particular fiat currency.
Finally, basing the Dash Budget System on fiat encourages the use of fiat for vendor payments by proposal owners. Yet Dash’s end goal is to be “digital cash,” not just a store of value. If the Dash Budget System won’t denominate items in Dash, why would any merchant? By denominating in Dash, proposals owners are pushed to encourage their vendors to accept Dash instead of fiat, thus expanding the usage of Dash in the economy.
Keeping the Dash Budget System denominated in Dash does mean accepting significant price fluctuations. What happens when the price of Dash fluctuates radically within the life of a proposal? What should be done about “extra money” or “lost money?”
Nothing.
The Problem of “Extra Money”
Everyone’s familiar with the old saying, “A rising tide lifts all boats.” If the value of Dash increases, everyone wins. The proposal owner receives more purchasing power, and just as importantly, so do all Dash owners. The value of Dash rising doesn’t create “extra money” that is somehow taken away from existing Dash owners. It just allows all Dash owners—including the proposal owner—to buy more things with Dash. The proposal owner could use that extra purchasing power to improve his project, or he could hold it for future work, or he could donate it to a worthy cause, or he could buy a boat with it. As long as he fulfills the obligations of his proposal, no one loses in this scenario (and the boat seller now wins as well).
In addition, currently the Dash Budget System doesn’t even get close to allocating the maximum amount of Dash each cycle. Thus, the “extra money” is also not taking away from other potential projects that might have been approved. In the history of the Dash Budget System, only a handful of proposals received enough “yes” votes but didn’t get approved due to maxing out the cycle’s budget. Perhaps one day Dash will encounter that problem, but it is likely a long way off.
Further, if the Dash community somehow coerces proposal owners to pay back “extra money” much greater problems would arise. How much should they return? Who should they return it to? How is it enforced? What if the payments they need to make are months in the future, and the value of Dash decreases before then? Forcing a payback also discourages people from submitting larger proposals, or encourages them to submit them at the last minute in order to minimize encountering price fluctuations.
Yes, Virginia, Dash’s Value Can Go Down
What if the value of Dash dramatically declines during a cycle? In this scenario a proposal might pass but fail in execution due to a lack of funds. This is more serious than the “extra money” problem, which isn’t really a problem at all. In the price decline scenario, there is a built-in solution: create a new proposal in the next cycle asking for the needed funds. If the Masternode owners voted for the proposal in the first place, it is highly likely they will vote to make up “lost money” due to a price decline.
If the new add-on proposal doesn’t pass, then the Masternode owners decided to treat the previous proposal as a sunk cost and move on. Businesses do this all the time.
Debate is Healthy…If It Can Be Resolved
Ultimately, the proposal owner—and the Masternode owners—accept the risk/reward possibility associated with Dash’s price moves. Over time, as Dash is used more and more as digital cash, then this price volatility will decrease. Any band-aid fixes now will only create new problems, and will delay the day when Dash is more universally accepted.
When working with a new innovate technology like the Dash Budget System, debates like this are sure to arise, and they are healthy. After all, that is how systems improve and grow. Fortunately, the debate regarding how to denominate and manage Budget Proposals can be resolved using the very system being debated. Unlike the Bitcoin community which could debate such an issue on Reddit or Slack or other online forums until they are blue in the face, the Dash community can simply put this issue to a vote and let the Masternode owners decide.
Maybe MN’s could start requiring additions for any extra money. For example we could of requested that the extra $200,000 in Dash gets donated to people Max and Stacey meet on their trip.
Agreed – raising awareness and building on what Amanda started.
Yep price variability plans would be nice.
If the cost of goods is paid in $dollars then the Equivelent value should be given in $dash at time of payout. E.g. if I request $100,000 then I get the Dash Equivelent at payout. It’s my risk after that to hold the Dash or exchange it for $. In other words, until the payout day the Dash is the asset of the network and so should be the benefits. Giving extra Dash that is not needed for the proposal can have the proposal owner indeed hold it and buy a yacht in $ and essentially dumping the Dash.
Until having Dash accepted as direct payment for goods and services rendered, it shouldn’t be given away without a tie back in the proposal to give away extra in resized goods value to charity, or expand services, or return it to a foundation of our choosing.
Getting Dash accepted as a wide currency is not going to be via giving extra away to service providers but rather via integrating more services.
Finally, If Dash is absolutely requested then we should enforce proof of payment to 3rd party service provider in Dash. This then aligns everyone interest.
How to ensure the above, including delivery of services, should be governed by a legal structure owner by the MN owners in the future to ensure recourse to the proposal owner. Today, we operate in good faith and hope for the best – whilst this is noble, it opens the network to potential abuse and wasted resources.
There is a cost to managing such a system like you describe. It could be manageable at first while things are still small, but it could become large and costly quickly. This would be a cost to the network as a whole since it would also have to be part of the dash budget. I say if the budget can afford the dash in question, then give it in dash. The network really isn’t losing anything. Management of those funds and success of the proposal is still on the head of the project owner or head. If exchange rates create an additional amount of funds in fiat, then I guess good on them. No international business ever complains when exchange rates give them a bonus, and unless overly extreme they don’t complain about the short falls. It is a part of working with exchange rates and doing international business. I think in this respect dash proposals are essentially no different.
At the end of the day… it is not a loss for the dash network at all. They had those dash and agreed to use it as long as it was within the amount of dash in the budget. Exchange rates are on the head of the users of the dash they receive.
This is an area of interest to me, I have had two successful proposals during the meteoric rise in price. There is a limit to what can be achieved within the scope of my proposals by increasing spending. I can deliver everything I outlined in the proposal and expand in areas where extra expenditure makes sense, but I’m not going to invent work that I can’t justify in terms of the original scope.
So for example with the Circus City proposal the wallet install related give away can reach more people and I can hire additional help desk staff if needed for peak times. Radiolab is even more simple as I can purchase additional advertising time.
Of course the Dash budget can and should only be denominated in Dash on a protocol level, with the budget within the proposal also being in Dash and the national fiat currency if applicable.
I think that proposal owners should focus all of their efforts on delivering the stated objectives of the proposal. This is what the network has agreed to and voted upon and it could very well be that creating ad-hoc extra will detract from delivering this.
Having stretch goals to cover increases in value seems counter intuitive, if these things are worth doing them include them in the original proposal and just ask for more Dash in the first place. If they aren’t part of the original proposal then a judgement has been made that they aren’t worth funding in the first place, so why add them as a bonus?
The current proposal system helps create an incredibly loyal and motivated, decentralised workforce for Dash: proposal owners who risk their own wealth to create proposals become ambassadors for Dash beyond the limited term of their proposals. By rewarding well thought out risk taking by proposal owners Dash can completely change lives, I’ve gone from being interested and inspired to seeing myself as a life long advocate for Dash.
It is important to think about how a system creates incentives for success: if a project is successful and that generates an increase in price then the proposal owner has a huge incentive to create another proposal and now has additional resources to do that. In this way everyone’s incentives are aligned: proposals are clear in scope and delivery, MNOs have certainty about what is being offered and proposal owners have every incentive to succeed.
I firmly agree that proposals should be mainly denominated in Dash and payouts remain in dash amounts as agreed to. However including information as to the current exchange rate and the amount of fiat intended to be used in which ever fiat the proposal owner prefers is not a bad data point to add. If anything it could make follow up proposals needing extra dash because of a negative outcomes of the dash to fiat rate easier to explain and accept, and more likely to get followup yes votes.
So keep the system as it is now… always in dash. However, part of the proposal information should include the current exchange rate for desired fiat (if any), and total amount of that fiat desired (again, if any). All this becomes is extra info that can serve as a data point, and perhaps a point of comparison.
My 2 cents.
I agree with Eric. There are two kinds of managers — those who hire people they trust and then delegate, and those who micromanage. In my experience, the former are more effective. Setting up a formal system to micromanage any excess funds seems to me like too much central control.
Maybe this debate can be decided if it’s given to some economists to study further. I believe we have the funds to contract a couple of well known researchers / econmists to advise on this subject.