Lamassu Integration Delay - An ominous precedent?

Status
Not open for further replies.
Macrochip

Macrochip

Active member
Dash's Governance model is without a doubt the most sustainable and technically superior method to govern the development of a cryptocurrency. However we must not close our eyes to potential weaknesses.

The recently revealed reason for the insufferable Lamassu integration delay, which boils down to a single developer with questionable motivations, is a perfect display of how the "Pay and Pray" method of budget funding is flawed. I had my concern about this the day budget proposals were introduced and it took a while but my concern finally came true: Currently we're relying on delivery of performance after an upfront payment has occurred.

What's being created when a budget proposal is accepted is nothing short of a legally binding contract. But we lack any recourses or any possibilities of a refund. Paid is paid. Delivered or not. And that's the problem. The nature of most proposals ("Code for money") makes smart contracts (at least with current technology) almost useless, too: Let's assume a contractor made a proposal to build a decentralized marketplace. He shows us some nice mockups, test code, roadmap, milestones etc. Everyone is frantic about it and Masternode operators accept the proposal to pay 200 DASH/month for 1 year to the project. The developer promises to publish every update on a public github account. Now if we had a smart contract in place, all it could check for is this: "Does he upload code within the agreed upon interval? Yes - Pay the 200 Dash | No - Withold payment". There is no method to check for the codes uniqueness (copy-paste garbage?) and usefulness to the end goal. The dev could upload anything just to get paid.

Currently the only way to check for useful code is having another human party review it. But even then, when the code is revealed to be garbage, that person couldn't stop the payments (and neither should she or anyone be able to do that).

So we need to have a discussion on how to remove the component of dependency on goodwill and trust within our governance model. Any ideas? An Evolution DApp where users vote on these updates, maybe?

Edit: Maybe I should clarify something: For some cases I mean for a solution other than voting the entire proposal down and stop payment altogether, even though my example doesn't reflect this, unfortunately. It's about paying less for receiving less. The proposal can still be good (like BTM integration), but should be foolproofed and avoid wasting resources. Other cases (like one time payments) are mostly about wasted funds with no ability to reclaim them. In any case: Payment should occur after delivery and validation of performance.
 
Last edited by a moderator:
The current governance model already supports this. If someone is untrusted / untested and with no track record, then masternodes should not approve their budget. That does not mean if someone is untested that they should never get a proposal. Those people should seek out trusted parties, such as the Dash Foundation, who can manage the proposal on their behalf.

For example, if untrusted person named Bob submits a propsoal such as "I will make awesome Software X!" they can go to the dash foundation. Dash Foundation will submit the proposal and receive the funds and act as the final gatekeeper of the funds. If Bob does not perform them Dash Foundation does not pay. They can then ask the community what to do with the funds at that point.

TLD: masternodes need to quit upvoting untested people. Instead, require trusted 3rd parties such as Dash Foundation to act as gatekeepers / escrow of funds for untested submitters.
 
xdashguy said:
The current governance model already supports this. If someone is untrusted / untested and with no track record, then masternodes should not approve their budget.

TLD: masternodes need to quit upvoting untested people. Instead, require trusted 3rd parties such as Dash Foundation to act as gatekeepers / escrow of funds for untested submitters.
Click to expand...

I agree with this. I paid DASH for a sticker from the person who made DASH Payment processor budget request. I never got any such said sticker. How can I expect this project which is currently funded to actually get build out when they can't even mail my sticker.....We need some checks and ballances... Sooner than later
 
Separating the approval of the budget and the distribution of the payment might be worth looking into. Similar to how we were discussing how we want to handle multi-month contracts in another thread. But even for a single-payout budget, because a budget approval is not a legally binding contract, it makes more sense for payments to occur after the services are rendered. However, if we implement such a thing, it needs to be difficult enough to prevent a payment that people can still have high confidence that the masternode network will act in good faith, but not so difficult that it is trivial.
 
  • Like
Reactions: daf
So something like the proposal can be approved and the coins created, but will only be unlocked after the next budget?
 
I know its hard to get ALL MNs to vote on these to begin with now but adding a second vote might be a good approach. 1st vote gives requestor confidence to keep on working their project 2nd vote gets them paid becuase they prooved they had something decent in the works and payout is approved by vote on display of work quality...
 
Miner237 said:
I know its hard to get ALL MNs to vote on these to begin with now but adding a second vote might be a good approach. 1st vote gives requestor confidence to keep on working their project 2nd vote gets them paid becuase they prooved they had something decent in the works and payout is approved by vote on display of work quality...
Click to expand...

That was pretty much my thinking with it too, one round to approve funding and a second round on completion to judge satisfaction and release the funds, something like a multisig budget. Imho it's something better done with tools to enable that kind of format and to allow voting to decide what kind of format meets with approval rather than trying to enforce hard and fast rules that may limit what kind of proposals are put forward.
 
Status
Not open for further replies.
Back
Top