Nice for the contractor who gets the easy money, not nice for those missing out.
That sounds to me like the "instamine" whiners complaining about missing out on cheap coins. The brilliance of the governance system is that it can dynamically adjust to economic factors. A "good deal" will not stay a good for very long! How long did 40% masternode return last? not long, because more people invested and started taking advantage of it. And what was the benefit? A huge increase in user base, exchange rate, network security, efficiency, etc. If masternodes paid in USD, it would be to the detriment of Dash. Why should it be otherwise for budgets?
We obviously want to incentivise people to hold and use the currency. Any so-called inequities due to price appreciation are GOOD for the Dash economy, because they will attract more high quality proposals to compete for funds. They'll try to lock in those "good deals" and then their hard work will really pay off if their Dash payouts suddenly become more valuable. Then, the next round of proposers will try to do the same. All the while, Dash will keep growing and garner all manner of innovation on the backs of service providers competing to make it better and increase their ROI.
Pay in Dash, renegotiate often based on exchange rates.
And where does the frequency of renegotiation end? Are you going to advocate daily superblock budget payouts versus months? Hourly? Does the proposal owner need to be joined at the hip with his contractor, arguing about price all day? You can't have it both ways. There already is renegotiation built into the budget system directly. It's called voting. As Evan already pointed out, someone has to take the risk. Having Dash itself take the risk versus the service providers is parasitic in nature and a recipe for disaster.
That is right, Bridgewater, thanks for your insight. Is nice to see other people that can see the powerful network effects paying in Dash creates.
Paying in Dash is fine. Agreeing to a 3 month cotnract with a volatile currency is not. There are plenty of work arounds to this issue. For example; resubmit the amount you need to fulfill the invioce they send over and propose it to the network and get them paid. Just don't put the network on the hook for any volatility in the meantime, we are trying to maximize the usage of the funds after all, right?
edit: My point is we can pay them ahead of time and avoid any of these issues. Calculate the market value of dash at the time the invoice is submitted and note it. Pay them XXXXX amount of USD in Dash. They got paid in Dash, we took zero risk, everyone is happy.
What you’re failing to understand is the network is on the hook for volatility either way. USD solves this issue when the price goes up, but what happens when the price goes down?
I’ve been working on the V2 of the budget system for the last few days and I’m neck deep in code, this whole ordeal showed up at a good time actually. I think I have a pretty good understanding of where we need to go and basically the network needs to be able to promise a vendor to pay them for an extended period of time in Dash or USD. To do this I want to implement a new type of proposal, that is called a contract. This would also have some new thresholds so that this doesn't get abused:
- Month-to-month proposals: Requiring 10% support from the network
- Multi-month proposals: Requires 10% support of the network
- 3-month contracts: Requires 20% network support
- 6-month contracts: Requires 33% network support
- 12-month contracts: Requires 51% network support
Proposals can be voted down at any time, whereas contracts have a voting window which is no less than 30 days long. Contracts should be very carefully considered by the network because they are much more dangerous and expose us to a liability and market risk no matter how they are denominated.
USD valuations would also be created via quorum and an average price over a period of 7 days would be used to stop people from attacking the implementation. (e.g. if you dump 10000 coins right before the budget is finalized, you could drop the price by 10% and get 10% more coins as a result, right? To stop this we’ll use quorum based averages).
So assuming this technology exists and we can denominate in Dash or USD, we need to have an entirely different conversation about when to use Dash and when to use USD.
To figure out which denomination is better, let’s consider some examples
250 DASH Proposal - At time of submission we agree to pay $1000 USD in Dash.
$1000 USD Proposal - At time of submission we agree to pay $1000 USD.
UP - Let’s say Dash goes up 100%. 250 DASH Proposal is now worth $2000 and takes the same amount of Dash from the budget.
$1000 USD Proposal is now worth $1000 and
takes 50% the amount of Dash from the budgetDOWN - Let’s say Dash goes down 50%250 DASH Proposal is now worth $500 and takes the same amount of Dash from the budget.
$1000 USD Proposal is now worth $1000 and
takes 200% the amount of Dash from the budgetLet’s say we only utilize USD based contracts in the system and in one 6 month period we have obligations for $33,000 per month. At $4.20 per Dash, we should have $33,692 dollars available per month, so that seems reasonable. Let’s say the price goes down 50%, now our budget is $16846.20. Now we have a problem, we’ve promised more money than the system can create in a month.
Option A: If the price falls, we don’t pay out the contracts. In this case we’ve made a contract and burned the bridge with a contractor doing ongoing work. This makes our network unusable long term.
Option B: The proposal system could create unpredictable inflation based on the promises the network is making for USD based contracts.
Option C: We allocate in Dash to avoid all of these issues and don’t support USD based contracts at all.
Option D: We give the foundation a budget to take Dash and convert it to fiat, then it keeps the fiat in a bank account. The contractors would contract with our foundation directly and this bank account would serve as a volatility buffer.
Option E: We allocate only X% of the budgets according to the historical volatility of the currency. This can be calculated by taking two standard deviations from the average price history for a long period of time, then figuring out a high and low price threshold. However, this will still result in contractors getting burned once in a while.
Paging TokNormal and BabyGiraffe
