Re: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency
I think that in order to get more efficiency from the budget system we need to do one or more of the following things:
a) Lessen the time factor--There is a real sense of urgency, in that we have only one month (at most) to plan and make proposals to the network before the funds or irretrievably "lost" for future development.
b) Given that any unallocated funds are lost forever (by simply not being created), we have a situation in which there is essentially zero cost for failure. If a proposal doesn't work out, then so what? The funds would have been lost anyway. The flip side is that almost any proposal with even the slightest chance of bringing value to the ecosystem is worthwhile, from a strict cost-benefit analysis. Take the latest proposal to integrate with a major exchange: that's just over 2,000 DASH or $30,000 USD. Not spending that money would effectively increase the value of all DASH in existence by half a cent, which is infinitesimal.
c) Communication must be improved. The creation of the new subforum is an excellent start.
My suggestion is to allow the network to "bank" any unspent funds so that they can be used at a later time by worthy projects. This has several advantages:
1) There's an incentive for saving. Today's unused funds will likely be worth quite a bit more in the future, due to price appreciation. This month's proposals, therefore, essentially have to compete against the possibility of even better proposals in the future. We don't want to fund marginal projects today, since that takes money away from potentially better projects in the future.
2) It eliminates the time factor, since there's no longer a hurry to spend funds before we lose them (i.e. before the month's superblocks are created). That gives more time to craft better proposals, more time for communication, and greater ability to hold contractors accountable (since there's no rush to approve expenditures).
3) It alters the cost-benefit analysis, because now the cost of disapproving a proposal is lower and the cost of approving a proposal is higher, since the funds if unused would be available for future projects.
P.S. It is vitally important that masternode owners realize there is risk in everything, and that it is up to them to assess the risk. There have been, and will continue to be, budget proposals that simply don't work out very well. That's simply how the world works--there are no guarantees in anything. All we can do is assess the risk and make the best possible decision with the information we have. If something doesn't work out, we learn from it and use that knowledge later. Failure is to be expected; if we never fail, it's because we never aspired.
a) Lessen the time factor--There is a real sense of urgency, in that we have only one month (at most) to plan and make proposals to the network before the funds or irretrievably "lost" for future development.
b) Given that any unallocated funds are lost forever (by simply not being created), we have a situation in which there is essentially zero cost for failure. If a proposal doesn't work out, then so what? The funds would have been lost anyway. The flip side is that almost any proposal with even the slightest chance of bringing value to the ecosystem is worthwhile, from a strict cost-benefit analysis. Take the latest proposal to integrate with a major exchange: that's just over 2,000 DASH or $30,000 USD. Not spending that money would effectively increase the value of all DASH in existence by half a cent, which is infinitesimal.
c) Communication must be improved. The creation of the new subforum is an excellent start.
My suggestion is to allow the network to "bank" any unspent funds so that they can be used at a later time by worthy projects. This has several advantages:
1) There's an incentive for saving. Today's unused funds will likely be worth quite a bit more in the future, due to price appreciation. This month's proposals, therefore, essentially have to compete against the possibility of even better proposals in the future. We don't want to fund marginal projects today, since that takes money away from potentially better projects in the future.
2) It eliminates the time factor, since there's no longer a hurry to spend funds before we lose them (i.e. before the month's superblocks are created). That gives more time to craft better proposals, more time for communication, and greater ability to hold contractors accountable (since there's no rush to approve expenditures).
3) It alters the cost-benefit analysis, because now the cost of disapproving a proposal is lower and the cost of approving a proposal is higher, since the funds if unused would be available for future projects.
P.S. It is vitally important that masternode owners realize there is risk in everything, and that it is up to them to assess the risk. There have been, and will continue to be, budget proposals that simply don't work out very well. That's simply how the world works--there are no guarantees in anything. All we can do is assess the risk and make the best possible decision with the information we have. If something doesn't work out, we learn from it and use that knowledge later. Failure is to be expected; if we never fail, it's because we never aspired.
Couple of VERY important points you bring up on this that I've never understood and never agreed on...why can't the funds be "banked"
This urgency to spend the funds before they are "burned" is ridiculous. This should be addressed...unless there is some compelling technical reason as to why we can't do this, this requirement should be removed.And second back to my original point...and one you touch on here...we need a very clear way to assess the performance of the budget system. Certainly we are all grown ups here(well most are here...
lol ) and can assess risk using our own criteria. The problem is that the information to make this kind judgement of system is incomplete and not readily available. This is quite problematic. So to recap...2 things need to be addressed, we should be advocating the removal of the time limit on spending the funds in a limit time frame and 2 creating a portal to which not only masternode operators but the community at large can gauge the performance of our system.