Budget System v2 - Irrevocable multi-month contracts

ericsammons

ericsammons

Well-known member
Masternode Owner/Operator
A few weeks ago eduffield submitted a proposal to allow for multi-month contracts in the Budget System. The thread he introduced the proposal in (here) got a bit derailed by the whole PR/Terpin project, but I really feel like there wasn't any in-depth discussion of the changes Evan proposed to the Budget System to allow multi-month contracts (or if there was, it was lost in the PR kerfuffle).

The biggest concern that I and many others had regarding the proposal was the lack of a "back-out" mechanism to end a multi-month contract early. This came to mind again when I was recently watching Evan's video on the Dash Governance System:


In that video Evan says the following (starting at 3:41):
For example, lets say a proposal to make a decentralized exchange was submitted to the network. And it looked great and the Masternodes funded it, and every month they're getting a payment. And then, two months in, the progress stops and something looks wrong about this proposal and it looks like the developers have stopped working on it. Where they said...they promised to work on it and they're just not making progress. The Masternodes can actually change their vote at any given time and they will bump this proposal off of the budget, so that it's no longer funded.
Click to expand...

As you can see, when the Budget System was first introduced, the fact that Masternodes could end multi-month proposals early was seen as a feature, not a bug. Now I agree that having the ability to create multi-month contracts within the Budget System is a good thing, and should be added. But I am still concerned that there seems to be no "back-out" clause in Evan's new proposal, and I haven't really heard any response to that concern (that has been voiced by quite a few people). I would love to hear an explanation why there is no "back-out" clause in this proposal, so I can understand it better.

And please, please, please, don't let this thread get derailed by a discussion of PR! That is a completely unrelated topic that can be discussed ad nauseum elsewhere on this forum.
 
Eric, this is a great point.

I also see that that having the same threshold to get a budget approved and unapproved is a problem with contracts. You want a significant amount of voters to change their mind to defund a project. I suggest this below example only for a contract with a fixed length. We would still have the month to month like we have now too - basically voted in each month.

For example:
Approval
You have a 20% yes vote difference requirement(=700 more yes than no votes) to get a proposal funded.
1500 yes / 800 no gets funded.

To defund a project
You have 20% no vote difference requirement(=700 more no than yes votes) to get a proposal unfunded.
800 yes / 1500 no gets unfunded
 
That's what I'm thinking too, Solarminer.

Evan proposed the following for approving multi-month 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.
Click to expand...

I think these thresholds for passage are very reasonable. But I would propose something very similar to cancel a multi-month contract, perhaps like the following:
  • If less than 3 months remain on a contract, cancellation must be voted on by at least 20% of the network.
  • If less than 6 months (and more than 3) remain on a contract, cancellation must be voted on by at least 33% of the network.
  • If less than 12 months (and more than 6) remain on a contract, cancellation must be voted on by at least 51% of the network.
Once these minimum voting thresholds are met, contracts will be considered “cancelled” if at least 76% of the votes cast are “no” votes.

So you can see cancelling a multi-month contract would be quite difficult, as it should be. For really the only reason to do so would be in cases of fraud, complete incompetence, or the death of the other party. This would allow vendors to enter into multi-month contracts with the Dash network with confidence, yet also with the realization that their contract could be cancelled if they really drop the ball.
 
Eric, I don't know that we can generate a high % of votes. I think about half the masternodes don't vote, so to sway a 51% no vote(1785 more no votes than yes votes) will be unreasonable. Maybe 30% is a better number. I don't think it matters if the contract is 1 day old or 2 years old. If it something happens, a certain % should be able to vote it out. We are not trying to protect the vendor - we are trying to gauge the approval of the masternode voters. The key is that the threshold is high enough so that it is a consensus with a large number of voting masternodes.

Or maybe we use the same amount of yes votes that started the contract to set the amount of negative votes to cancel it. It could get pretty complicated on setting this up. Same with the changing % of votes based on age of contract.
 
You might be right, Solarminer.

I'm not hung up on the exact percentages, but I think the following should be true:
  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.
Probably everyone would agree with #1 & #2, but I think #3 is important as well. When you enter into a good faith contract, you can't just cancel it because you have soured a little on it. Even if the relationship strains (which often happens between clients and vendors in the life of a contract), it shouldn't be easy to just back out. And since it is harder to approve such a contract in the first place, they will only be approved if they have been truly vetted (hopefully).

I would argue that it should be only in cases of extreme situations that an approved contract can be cancelled. Also, by making it harder to cancel, it would make MN owners pause before easily approving such a binding contract.
 
ericsammons said:
You might be right, Solarminer.

I'm not hung up on the exact percentages, but I think the following should be true:
  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.
Probably everyone would agree with #1 & #2, but I think #3 is important as well. When you enter into a good faith contract, you can't just cancel it because you have soured a little on it. Even if the relationship strains (which often happens between clients and vendors in the life of a contract), it shouldn't be easy to just back out. And since it is harder to approve such a contract in the first place, they will only be approved if they have been truly vetted (hopefully).

I would argue that it should be only in cases of extreme situations that an approved contract can be cancelled. Also, by making it harder to cancel, it would make MN owners pause before easily approving such a binding contract.
Click to expand...

I like your reasoning. For #3. When you say harder, let's be clear. If you have 20% yes(700 votes more yes) to approve, then you want 30% no(1050 votes more no) to cancel. And maybe instead of saying harder we phrase it with a larger masternode consensus. Really what we are looking for is the accuracy of the decision.

Likewise, The exact % to me are not that critical. As long as we are within reasonable limits of voting history and we meet the 3 rules.
 
Solarminer said:
I like your reasoning. For #3. When you say harder, let's be clear. If you have 20% yes(700 votes more yes) to approve, then you want 30% no(1050 votes more no) to cancel. And maybe instead of saying harder we phrase it with a larger masternode consensus. Really what we are looking for is the accuracy of the decision.

Likewise, The exact % to me are not that critical. As long as we are within reasonable limits of voting history and we meet the 3 rules.
Click to expand...

Yes, that's exactly what I mean.
 
About canceling the multi-month proposal, there definitely needs to be a buffer of greater than 1 vote from when it gets approved and then getting de-funded the next month. I'm trying to think of a way to pick those numbers without being totally arbitrary?

There was also the issue of a budget being bumped due to over-allocation, which needs addressing.
 
Another question that I'm interested in is, who signs contracts for Dash? Evan, the Foundation or somebody else? If a contract is signed, are masternode operators made aware of all the details in the contract so they can decide if the contract should be signed or not? How would litigations took place if it came to it. I think it is not unreasonable to assume that at some point an disagreement will arise between the contractor and Dash community represented by masternodes' operators. How can be the network sued for not keeping the payments coming?
 
AnarchicCluster said:
Another question that I'm interested in is, who signs contracts for Dash? Evan, the Foundation or somebody else? If a contract is signed, are masternode operators made aware of all the details in the contract so they can decide if the contract should be signed or not? How would litigations took place if it came to it. I think it is not unreasonable to assume that at some point an disagreement will arise between the contractor and Dash community represented by masternodes' operators. How can be the network sued for not keeping the payments coming?
Click to expand...

I think any legally binding contracts need to be written such that they are contingent upon the DASH network's budget approval, in order to protect the DASH representative from legal action if the network defunds something. The contract needs to be entered into with that understanding, which contractors should be okay with as long as the other terms of the contract are clear and they are confident that the network will not decide to shoot itself in the foot by reneging on such a contract without a good reason. Making it more difficult to refund a contract is one way to increase that confidence.
 
AnarchicCluster said:
Another question that I'm interested in is, who signs contracts for Dash? Evan, the Foundation or somebody else? If a contract is signed, are masternode operators made aware of all the details in the contract so they can decide if the contract should be signed or not? How would litigations took place if it came to it. I think it is not unreasonable to assume that at some point an disagreement will arise between the contractor and Dash community represented by masternodes' operators. How can be the network sued for not keeping the payments coming?
Click to expand...
TroyDASH said:
I think any legally binding contracts need to be written such that they are contingent upon the DASH network's budget approval, in order to protect the DASH representative from legal action if the network defunds something. The contract needs to be entered into with that understanding, which contractors should be okay with as long as the other terms of the contract are clear and they are confident that the network will not decide to shoot itself in the foot by reneging on such a contract without a good reason. Making it more difficult to refund a contract is one way to increase that confidence.
Click to expand...

I don't think we need to have signed contracts*. The proposal submitted and approved will work as the contract, binding the parts. And this must always be very clear, to any interested contractor, since the begining: how does DASH budget system works, what are our rules, what are the risks, demands, etc.

Instead of a representative, or the Foundation, signing anything on behalf of the DASH network, what we need here is the stability of the network decisions.

This "stability" may very well come from tweaking the number of votes demands and votation rules (BUT, we must never lose the power to vote down proposals, if we decide it is the best solution). This stability will certainly have to come from the "maturity" of the Masternode owners, and the "seriousness" of their decisions.

* We do not need any other signed contract, because:
  • If the proposal owner (contractor) does not act in accordance with his duties as approved, the network will have a specific procedure for a reasoned cancelation;
  • If DASH's decisions are unreasonable, moved by emotions with irresponsible and unjustified breeches of the agreements (proposal approval terms) it will be as TroyDASH already said, the network will be shooting itself in the foot by reneging on such a contract without a good reason. It will be terrible for DASH's image if the decisions are reckless - it may become harder for us to find serious proposers, and if they come, they will be certainly more expensive, in order to cover the risks of dealing with non serious decision makers (in the DASH system).
Not having an extra layer of a signed contract seems to be the safer solution, in order to assure the total independence of the DASH network to make the decisions they need to take, without the need to depend on State-owned Judicial Authorities.

Now, I still want to know how it will be if there is an alredy running "contract" (and the contractor has been fulfilling his duties) but a better proposal is made, for the same "service" but with much better terms: how will it be solved? Renegotiation with the already working contractor? Vote down the old proposal and substitute it with the new? This is a situation I have in my mind.

Another: If two simlar (or even identical) proposals are voted and approved (by different Masternode groups) both with the same objectives, but run by different people... I believe it is possible to happen: What can be done in such situation? The quorums must be so as to avoid this stalemate.
 
kot said:
What about the other side? What about the possibility to cancel the contract by the external vendor?
Click to expand...

Good question: there must be a "fast track" cancellation procedure, to halt payments in case the contractor abandons or decides to cancel the execution of his contract.

Of course, the parts will always have freedom of contractual termination or rescission*. That's why ongoing payments must meet the pace of the execution of the works, so as to avoid overpayments (or underpayments).

* I say that the parts should be free to decide for ending the contractual bind, because that's a way to avoid having to resort to judicial claims (depending on State decisions does not fit well in our situation, it seems to me).

But although sometimes it may become hard to avoid possible disadvantageous situations, our decisions must always be as best as possible, in terms of analysing the details of each proposal, its risks, pros and cons, planning well its execution demands, preventing problems, and aiming for a successful fulfillment.

Anyway, the decision to terminate a contract will surelly reflect on one's reputation. If it was an unfair decision, it will bring future consequences. So let's work hard, so that unfair decisions will not be caused by DASH decisions.
 
ericsammons said:
A few weeks ago eduffield submitted a proposal to allow for multi-month contracts in the Budget System. The thread he introduced the proposal in (here) got a bit derailed by the whole PR/Terpin project, but I really feel like there wasn't any in-depth discussion of the changes Evan proposed to the Budget System to allow multi-month contracts (or if there was, it was lost in the PR kerfuffle).

The biggest concern that I and many others had regarding the proposal was the lack of a "back-out" mechanism to end a multi-month contract early. This came to mind again when I was recently watching Evan's video on the Dash Governance System:


In that video Evan says the following (starting at 3:41):


As you can see, when the Budget System was first introduced, the fact that Masternodes could end multi-month proposals early was seen as a feature, not a bug. Now I agree that having the ability to create multi-month contracts within the Budget System is a good thing, and should be added. But I am still concerned that there seems to be no "back-out" clause in Evan's new proposal, and I haven't really heard any response to that concern (that has been voiced by quite a few people). I would love to hear an explanation why there is no "back-out" clause in this proposal, so I can understand it better.

And please, please, please, don't let this thread get derailed by a discussion of PR! That is a completely unrelated topic that can be discussed ad nauseum elsewhere on this forum.
Click to expand...

Hey Eric, you should checkout eProcurement and eSourcing systems which are very similar to what the budget system is trying to achieve at an organizational level e.g.

.

Most of them work as reverse auctions and they decouple proposing from supplying and allowing suppliers to bid against proposals and negotia. Then in relation to multi-month contracts, they are milestone based. All of this could be 'votified' for Dash of course.

I know Evan has been looking into the eProcurement side, I don't know the details of what's coming up but I think the strategy is to build DGBB up slowly though so the foundation is right for the long term.
 
Last edited by a moderator:
...and on the Enterprise side there are systems like SAP Ariba:


One difference to Dash is that in these eProcurement systems purchasing is limited to the supply chain i.e. goods and services used by the organization whereas DGBB covers every part of the organizations purchasing including the human resources like management and development etc.
 
kot said:
What about the other side? What about the possibility to cancel the contract by the external vendor?
Click to expand...

Then obviously the MN owners would have to activate SkyNet and destroy them. :)

But seriously, that is a good point. I would think that is another argument for a cancellation mechanism in the protocol itself. If it was announced that a vendor cancelled their contract, then the MN owners could all vote to cancel the contract on Dash's end to stop payments. Without a cancellation mechanism, they would just keep getting paid regardless for the duration of the contract.
 
ericsammons said:
Then obviously the MN owners would have to activate SkyNet and destroy them. :)

But seriously, that is a good point. I would think that is another argument for a cancellation mechanism in the protocol itself. If it was announced that a vendor cancelled their contract, then the MN owners could all vote to cancel the contract on Dash's end to stop payments. Without a cancellation mechanism, they would just keep getting paid regardless for the duration of the contract.
Click to expand...

Sure.

There must not be irrevocable contracts.
 
Not only this in my opinion.
In case of working with an external vendor (as a legal entity) there must be a paper contract signed in parallel (by our legal representative e.g. foundation).
In case of any conflict or legal debate blockchain contract means nothing to court in any legal system as far as I know. Consequences of not having of the normal contract could be very painful.
 
Last edited by a moderator:
kot said:
Not only this in my opinion.
In case of working with an external vendor (as a legal entity) there must be a paper contract sign in parallel (by our legal representative e.g. foundation).
In case of any conflict or legal debate blockchain contract means nothing to court in any legal system as far as I know. Consequences of not having of the normal contract could be very painful.
Click to expand...

Right. And it needs to say in the contract something along the lines of that if the Masternodes defund something then the contract is void. With the understanding that the protocol makes (will make) it more difficult to be able to defund something and that the network is motivated to act in good faith to protect its reputation.
 
You must log in or register to reply here.
Back
Top