Quote from: ddink7 on February 03, 2016, 05:23:51 PM

Quote from: eduffield on February 03, 2016, 04:07:37 PM

snip

Quote

What youre 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?

Ive been working on the V2 of the budget system for the last few days and Im 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 well 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, lets 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 - Lets 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 - Lets 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

Lets 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. Lets say the price goes down 50%, now our budget is $16846.20. Now we have a problem, weve promised more money than the system can create in a month.

Option A: If the price falls, we dont pay out the contracts. In this case weve 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 dont 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

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:

Lets 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. Lets 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.