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.