There’s been a lot of talk lately in the Dash community about how to optimize the Dash Budget System. With a few proposals recently not delivering on their promises, Masternode owners (and Dash users in general) are rightly concerned that such failures may lead to the breakdown of the system itself. Fortunately, work is being done to improve the system, including adding escrow services to prevent fraudulent proposals.
As those improvements to the system are discussed and implemented, however, it would be good to review for Masternode owners some simple steps to take in evaluating proposals. Following these steps won’t guarantee that bad proposals won’t get through, but it can reduce the number of sketchy proposals that pass.
When evaluating a proposal, a Masternode owner is actually evaluating two distinct aspects of the submission: the proposal itself and the proposal owner(s). Let’s first review the most important of these two items: the proposal owner.
Evaluating Proposal Owners
Many people first focus on the proposal itself and the value it might bring to the Dash ecosystem. But by far the most important factor in the success of a proposal is the owner of that proposal. Someone could have a great idea, but if he can’t deliver on that promise, then the proposal is sure to fail. Two things I recommend evaluating when it comes to a proposal owner: reputation and qualifications.
Reputation is a nebulous concept that is hard to quantify. What does it mean that someone has a “good reputation?” Ultimately, it means that the person is trusted in the community. Typically, one builds a solid reputation by being a productive part of a community, building trust by helping others, and offering services that are worthwhile. For example, for years Tao of Satoshi has assisted the Dash community, with his Masternode guide and with his general advocacy for Dash. He also set up and maintained a Slack channel to benefit community communications. When he made a proposal to fund an upgrade to the Slack channel, it passed easily, mostly due to the solid reputation he had built and the value he already has provided to the community.
But reputations can be lost as well. Charlie Shrem came to the Dash community with a proposal for a Dash-branded debit card. His reputation in the Bitcoin community was strong, and based on that his proposal passed. In hindsight, that was a mistake, since although Shrem is a well-known figure in the Bitcoin community, he had no history with Dash, and had previously done nothing to further its goals. Of course, based on the failure of his project, his reputation in the Dash community is such that it’s unlikely he’ll ever be able to get another proposal passed. A reputation system isn’t fool-proof, but it does lessen the chances of systemic fraud or failures.
The other important factor for evaluating a proposal owner is her qualifications: does she have the experience and knowledge necessary to bring the project to successful completion? Anyone can have a great idea, but only some people have the ability to execute. For example, when Amanda Johnson proposed a series of Dash videos to the Masternode network, she had already been the successful host of The Daily Decrypt. It wasn’t outside her competency to create a series of helpful videos. Likewise, a proposal owner should demonstrate previous success in the arena of her proposal.
After evaluating the proposal owner, Masternodes should look carefully at the proposal itself. The proposer might be well-trusted and competent, but questions still remain: Does this project help the Dash ecosystem? Is the project plan feasible? Will it have the resources necessary to be completed as promised?
Opinions will vary as to what is most needed to help Dash succeed. Each Masternode owner will have to decide for himself if a project is worthwhile in this regard. However, Masternode owners should examine if the project plan is feasible. For example, if someone proposes to deliver a complicated, multi-step product within weeks, Masternode owners should be skeptical. Sometimes proposal owners, in their enthusiasm to sway Masternode owners, will make unrealistic promises. Better to have a realistic timeframe given than a more-impressive-sounding, but infeasible, timeframe.
Further, Masternode owners should check the budget. Some proposal owners ask for an outlandish sum, but it is just as problematic when a proposal owner doesn’t ask for enough. It’s a waste of money to allocate 50 Dash for a project that actually needs 100 to be successful. Proposal owners should give a detailed breakdown for project expenses, including realistic costs associated with each step of the project outline.
A final note: there have been some calls to reduce the 5 Dash requirement to submit a proposal. I think the recent spate of bad proposals argues against that thought. Reducing the submission fee will only lead to an increase in the number of bad proposals and will create more proposals for Masternode owners to evaluate. If anything, the submission fee might need to be increased in the future to ensure quality submissions to the network.
The Dash Budget System is still in its embryonic stages, having only been running for two years. There are still improvements to be made to the System itself and how it operates. But Masternode owners themselves should take responsibility and make improvements to how they evaluate and analyze the proposals. This won’t remove all bad projects, but it will make the overall process run more smoothly and lead to more successful projects.