Proposal “budget-system-v2“ (Completed)Back
| Title: | Budget System v2 / Transform PR |
| Owner: | eduffield |
| One-time payment: | 50 DASH (1424 USD) |
| Completed payments: | 1 totaling in 50 DASH (0 month remaining) |
| Payment start/end: | 2016-03-07 / 2016-04-21 (added on 2016-02-08) |
| Final voting deadline: | in passed |
| Votes: | 1087 Yes / 131 No / 0 Abstain |
| External information: | www.dashwhale.org/p/budget-system-v2 |
Proposal description
Hello,
I'm guessing most of the community is aware that we had a 3-month contract with Transform PR that started last month. This contract was for $6000, denominated in Dash and locked into a rate of $3.38. I believe this contract was going really well and that we were making the correct choice when we originally went with Transform PR. At the end of the first month, some vocal members of the community began lobbying to remove the Transform PR contract from the system while it was active.
I would like to post some evidence of the ongoing work that Transform was doing for us at the time the contract was voided and make some suggestions to alter the system so that we have better communication and we don't experience problems like this again in the future.
To start, I'm posting the final report from Transform PR, which shows the work they were doing. As you can see, they were the major driver of most of the media attention we were getting during the last month. They were even working with a major mainstream media outlet, Reuters, to publish a story on Dash.
December Transform PR Activity
Proposal For Next Contract
As a decentralized autonomous organization we need to be able to work with outside vendors reliably, so when the network makes a decision to fund a contract, we need to be able to support that decision in an irrevocable way. I believe the budget system failed us and it needs to be altered slightly to support this type of arrangement in the future.
Here are my suggestions for the budget system:
Proposals:
Ordinary one-time or month-to-month proposals will continue to function as they presently do; votes can be changed at any time, which will move these proposals up or down the payment queue (or even disapprove them altogether). These can be thought of as month-to-month contracts, which require ongoing review in order to keep supporting.
Contracts:
These will be an extended version of a proposal, with a minimum voting period of 30 days. During this period of time, an actual, legally binding contract between the vendor (promisor) and a network representative (promisee) should be evaluated. The promisee can be any legal entity which will act as the networks representative (legal firm, foundation, natural person, etc).
After the voting period (minimum of 30 days) has expired, any contracts which have been approved by the necessary number of votes will be paid until their expiration. Contracts, due to their legally binding nature, will be given priority for funding in the new budget system. Regular proposals will be funded by the system after funding is given to contracts.
I propose that the new contract system have a significantly higher voting threshold than ordinary proposals:
3-month contracts must be voted on by at least 20% of the masternode network.
6-month contracts must be voted on by at least 33% of the masternode network.
12-month contracts must be voted on by at least 51% of the masternode network.
Once these minimum voting thresholds are met, contracts will be considered "passed" if at least 51% of the votes cast are "yes" votes.
USD/Dash Denomination:
All contracts and proposals shall be denominated in Dash, unless the proposer is doing business directly with our foundation, which will carry a USD balance.
Eventually we wish to add native USD support to the budget system, which will allow a contractor to get an exact amount of Dash that can be converted to USD without the contractor carrying the market risk while the work is ongoing.
V12.1 - budget-system proposal
To establish network support for the above proposed, I’ve added a proposal to the system "budget-system". Please feel free to ask questions here about the proposed changes, I'll answer as many of them as possible.
I've also submitted the proposal for a payout of 50 DASH. If successful I'll be reimbursed for the creation of 10x proposal, which each cost 5 DASH a piece to submit to the network. To see all proposals that have ever been submitted you can use dash ninja, https://dashninja.pl/budgets.html.
If you support the idea and my reimbursement, please use the command ("vote-many a54a4fc99dde45b6841465c1cdb7b8f5ce4e6059c0086524ed26183f2b91f6dd yes").
What's Next?
During the time Transform PR was an active contract, they did fantastic work for us. I would really like to work with them again after we have irrevocable contracts, which will be available in 12.1. Transform PR has provided us with the plan they were going to use from March through May, which I have posted in order to give the community an idea of what our future work with them (if approved after 12.1) would look like.
Creating and fully testing a new version of the software will take about six months. The good news, however, is that while we're working on 12.1, we also have a separate development team led by Andy Freer doing work on Dash Evolution. Because of this, 12.1 shouldn't delay the release of Dash Evolution. We are right on schedule.
Best,
Evan Duffield
I'm guessing most of the community is aware that we had a 3-month contract with Transform PR that started last month. This contract was for $6000, denominated in Dash and locked into a rate of $3.38. I believe this contract was going really well and that we were making the correct choice when we originally went with Transform PR. At the end of the first month, some vocal members of the community began lobbying to remove the Transform PR contract from the system while it was active.
I would like to post some evidence of the ongoing work that Transform was doing for us at the time the contract was voided and make some suggestions to alter the system so that we have better communication and we don't experience problems like this again in the future.
To start, I'm posting the final report from Transform PR, which shows the work they were doing. As you can see, they were the major driver of most of the media attention we were getting during the last month. They were even working with a major mainstream media outlet, Reuters, to publish a story on Dash.
December Transform PR Activity
Proposal For Next Contract
As a decentralized autonomous organization we need to be able to work with outside vendors reliably, so when the network makes a decision to fund a contract, we need to be able to support that decision in an irrevocable way. I believe the budget system failed us and it needs to be altered slightly to support this type of arrangement in the future.
Here are my suggestions for the budget system:
Proposals:
Ordinary one-time or month-to-month proposals will continue to function as they presently do; votes can be changed at any time, which will move these proposals up or down the payment queue (or even disapprove them altogether). These can be thought of as month-to-month contracts, which require ongoing review in order to keep supporting.
Contracts:
These will be an extended version of a proposal, with a minimum voting period of 30 days. During this period of time, an actual, legally binding contract between the vendor (promisor) and a network representative (promisee) should be evaluated. The promisee can be any legal entity which will act as the networks representative (legal firm, foundation, natural person, etc).
After the voting period (minimum of 30 days) has expired, any contracts which have been approved by the necessary number of votes will be paid until their expiration. Contracts, due to their legally binding nature, will be given priority for funding in the new budget system. Regular proposals will be funded by the system after funding is given to contracts.
I propose that the new contract system have a significantly higher voting threshold than ordinary proposals:
3-month contracts must be voted on by at least 20% of the masternode network.
6-month contracts must be voted on by at least 33% of the masternode network.
12-month contracts must be voted on by at least 51% of the masternode network.
Once these minimum voting thresholds are met, contracts will be considered "passed" if at least 51% of the votes cast are "yes" votes.
USD/Dash Denomination:
All contracts and proposals shall be denominated in Dash, unless the proposer is doing business directly with our foundation, which will carry a USD balance.
Eventually we wish to add native USD support to the budget system, which will allow a contractor to get an exact amount of Dash that can be converted to USD without the contractor carrying the market risk while the work is ongoing.
V12.1 - budget-system proposal
To establish network support for the above proposed, I’ve added a proposal to the system "budget-system". Please feel free to ask questions here about the proposed changes, I'll answer as many of them as possible.
I've also submitted the proposal for a payout of 50 DASH. If successful I'll be reimbursed for the creation of 10x proposal, which each cost 5 DASH a piece to submit to the network. To see all proposals that have ever been submitted you can use dash ninja, https://dashninja.pl/budgets.html.
If you support the idea and my reimbursement, please use the command ("vote-many a54a4fc99dde45b6841465c1cdb7b8f5ce4e6059c0086524ed26183f2b91f6dd yes").
What's Next?
During the time Transform PR was an active contract, they did fantastic work for us. I would really like to work with them again after we have irrevocable contracts, which will be available in 12.1. Transform PR has provided us with the plan they were going to use from March through May, which I have posted in order to give the community an idea of what our future work with them (if approved after 12.1) would look like.
Creating and fully testing a new version of the software will take about six months. The good news, however, is that while we're working on 12.1, we also have a separate development team led by Andy Freer doing work on Dash Evolution. Because of this, 12.1 shouldn't delay the release of Dash Evolution. We are right on schedule.
Best,
Evan Duffield
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
https://dashtalk.org/threads/budget-system-v2-irrevocable-multi-month-contracts.8174/#post-86578
These are the three main objectives we think will make contracts work:
1. It should be harder to approve a multi-month contract than a month-to-month proposal. (Which is true with Evan's proposal).
2. It should relatively difficult to approve a multi-month contract. (Again, which is true of Evan's proposal).
3. It should be harder to cancel a multi-month contract than to approve it.
I disagree with irrevocable contracts. They limit any leverage we have with contractors. We should have a large change threshold instead. For example, 30% yes to activate a contract and 30% no to reject a contract that is already active. Also suggest we only provide 3 month contracts to start with.
No idea why this way complicated, known-to-be-problematic-before-it-was-even-created system was made in the first place...
If you're making deals based on FIAT, they payouts have to be weighed against fiat. It can easily be done dynamically because exchanges have APIs for exactly this purpose...
A half-assed band-aid on top of a half-assed system, the half-assed band-aid for which won't actually fix it, is not what we need here. The system has much deeper fundamental defects that need to be addresses, not another gadget built on top of it that will need to be re-engineered when the inevitably-needed revamp is done.
I get it. But I also understand that adding dependent code on top of something that will go away, the replacement for which can't be compatible, is a huge waste of time and effort. Lets fix the broader underlying problem instead of band-aiding only one of it's limited symptoms...
Maybe we should have a variable length budget cycle. So if we don't spend enough to use up the rewards for the next xxx blocks the vote/budget start timing changes yyy blocks sooner.
I can't see working with any vendor and expecting them to receive five hundred 0.5 dash transactions each day and expecting them to manage a bloated wallet.
Mining was never supposed to be pooled. Ever block had payment. Still does.
No one said vendors would get 500x 0.5 TXes a day. We're talking about payees of budget proposals. Not vendors...
There's only one address, so it doesn't bloat. Just a bunch of TXes to the same address. So what? Pretty sure they're going to move it to another address anyway... Or hit that handy darksend button and start mixing...
Are you drinking again? :-p
Imagine having all proposals funded by percentage, which can be voted upon, too. Accelerate one, decelerate another. All by simply adding a rate vote.Which is nothing but an add-on to a much simpler system of funding in the first place. I discussed this at length last year, but was ignored because nobody could see a use for doing ti that way.
I think you can see one now. My idea is more flexible, uses existing metrics, and simpler by far, without any of the pitfalls... We can decelerate something if something really cool comes up, instead of cancelling it altogether. We can throttle on major price changes... Even add a dynamic FIAT bind for those making proposals who wish it so... But the existing system can't scale like that because it's a complete clusterfuck that obeys none of the pre-existing rules in the system and creates it's own clunky microcosm.
If you are anticipating a project manager that is paying the vendor, then your idea works well.
but i would also like to raise the current treshold of 10% for proposals higher, to 20%
If only 700 MNs have voted, that is NOT support for a proposal...
Of course, downside is you do need masternodes to keep the second tier running, so that's a problem. But I strongly believe that people WILL vote if they are asked in this way and mn count will not drop. Benefit is a stronger more involved comunity.