Post
Topic
Board Announcements (Altcoins)
Re: [ANN][DASH] Dash | First Anonymous Coin | Inventor of X11, DGW, Darksend and InstantX
by
eduffield
on 03/02/2016, 17:32:19 UTC
snip
Quote

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 budget

DOWN - 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 budget

Let’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 Smiley

Evan, would it be possible to code the revised system so that contracts were paid first, always? If so, then Option E wouldn't result in contractors ever getting burned. Some one-time proposals would essentially get burned by being bumped from the payment list due to inadequate funds on occasion, but if contracts get paid first then contractors should be satisfied.

Contracts will be paid first by V2. Option E results in contracts getting burned if the price falls more than 2 standard deviations from the historical price average. I'll modify my previous example a bit to show how it can happen:

Let’s say we only utilize USD based contracts in the system and in one 6 month period we have obligations for 75% of the total budget, which amounts to $25471.50 per month. At $4.20 per Dash, we should have $33,692 dollars available per month, which will more than cover our expenses. Let’s say the price goes down 50%, now our budget can pay out a possible $16846.20. We have a deficit of $16846.20 - $25471.50, totaling -$8625.30. That's nearly $10k of work that we promised to pay that won't get paid now, thus burning bridges.