Proposals with Payment on Delivery on Hive. How I would do it.
I wrote a few days ago about the DHF proposals and how they could benefit from integrating polls, which is also the basis for the follow-up idea I'm presenting in this article.
How Can a Project / Initiative Be Funded?
There is more than one way to fund a project or initiative, in general. Here are 3 simple, unmixed cases, without segregating by the destination of the funding:
1. Prefunded
This is when the project or initiative receives its funding upfront because it has clear costs to cover. It involves a certain level of trust, reputation at stake, or previous access to other fundings of the same type without any issues because there is the risk the receiver gets the funding and doesn't do their part of the deal. It also can only be offered for costs that are easily verifiable (remote verification is pretty difficult in some cases).
2. On Delivery (Milestones/End of Project)
In this case, the project's owner receives funding after certain agreed-upon stages, if the milestones are reached. Otherwise, payment may be refused or only partially released.
3. Ongoing
Here, the funding is continuously released for the duration of the project or initiative, unless it's suspended temporarily or permanently for a certain reason.
What Kind of Funding Does the DHF Support?
By design, the DHF proposal system only supports the 3rd type of funding: ongoing. Payments are made hourly to the active proposals. A proposal can drop out from being funded and be back throughout its lifetime, depending on how votes on it and the return proposal fluctuate.
Using a workaround (to which I don't disagree), prefunded initiatives with a marketing component for the Hive ecosystem are also possible using the Value Plan project. Verifying offline expenses other than locally is complicated though, even if invoices can be checked remotely.
What the DHF doesn't offer at all is funding on delivery, and I believe many would like to see that. This is what I'd like to focus on in this post. Of course, we could create and fund another major proposal for this use case, but then we end up centralizing most of the DAO funds and reducing the say of stakeholders significantly in DAO matters.
DHF Proposals with Payment on Delivery
This idea can go deeper, to separate or sub-DAOs based on the type of funding offered, but I'll just iterate with my idea on the existing DHF proposal system, to which we added polls in the previous article.
How would I see such a system?
So, previously, a DHF proposal would have been published which included a few options for stakeholders to select in a poll. The poll would have run until the proposal got the necessary votes to pass over the return proposal, after which, the parameters linked to the winning option became the parameters of the proposal.
To be able to select between the option of payment ongoing and on delivery, a new parameter would be needed, with the two values. If it's only the two options, can be boolean, and something like pay_on_delivery.
What else would we need?
The system can be built to support multi-milestone proposals, but it's simpler to just have one proposal per milestone (end of project). And then have other proposals for future milestones.
We would need an escrow account, preferably without keyholders, and controlled only by code (like @hive.fund).
If a proposal with payment on delivery is approved, instead of payments going to the specified account (project owner, etc.) hourly, they go to the escrow account.
Here's the more complicated part, I think: a proposal with payment on delivery, once approved, cannot drop out of funding. There will be a delivery check at the end. So, unvoting it below the return proposal shouldn't work. Active proposals with payment on delivery should remain active through their lifetime regardless of vote fluctuations.
When the milestone date is reached, there will be no more payments to escrow for this project. The project owner needs to write a post with proof of the milestone achieved. They can post it at any time they want, so if they are not ready, they can keep working, but for free. The post will automatically have a poll with 'yes' and 'no' options. People who previously voted for their proposal can vote on this poll, and only they, because they are the ones who expressed interest in the first phase.
So, what happens if the proposal creator doesn't deliver?
I said above there will be a poll, I didn't say for which question. This is the question: "Approve payment?" (with the options 'yes' and 'no'). Stakeholders have a week to answer, and they will be notified by the front ends about the pending poll.
If more than 2/3 (stake-weighted) says 'no', the proposal receives no funding, and the escrow funds are returned to the DAO.
If between 1/2 and 2/3 say 'no', the proposal receives 25% of the funding, and the remaining funds return to the DAO.
If between 1/3 and 1/2 say 'no', the proposal receives 60% of the funding, and the remaining funds return to the DAO.
If less than 1/3 of the stake voting says 'no', the proposal receives full funding.
There should also be a minimum stake voting for the vote to be relevant. If that threshold isn't reached, then full funding is given regardless of the results of the poll.
We need to keep in mind the voters might be biased toward the project since they voted on it, that's why the harsher cuts if there are voters rejecting payment, but these are obviously just some options and thresholds that can be discussed further.
Stakeholders have the right to change their minds within the week they have to vote. If it's an obvious money grab, they can be pointed out by others if they missed it, and it's their reputation at stake if they don't want to deny payment.
'No' can turn into a 'yes' too, if the proposal creator or someone else can clear the stakeholder's doubts.
Final Words
What are the benefits of payment on delivery on Hive from the DHF?
- the funded party doesn't need to check every day if payment still comes in and engage in politics to get the necessary votes instead of working (they might still need to do that at the end of the milestone, but not continuously)
- funding is more likely to be in full if the delivery is as expected
- the funded party is incentivized to do great work within the agreed-upon timeframe
- stakeholders who approved the proposal have total control over how much funding the proposal receives, usually depending on delivery
Want to check out my collection of posts?
It's a good way to pick what interests you.
Posted Using InLeo Alpha
There should be some sort of payment on delivery and only release of funds once milestones have been reached. Many projects probably wouldnt get funded then.
Well, that's what I try to describe here. Not sure about "many", but I believe things would be different with such a method of payment and control.
The system you describe is excellent and I want to see it become a reality. The fact that even a funded Proposal can suddenly loose funding makes DHF very unreliable. We could temporally see a smart contract based approach using multisig to secure the funds.
This will require 2 multisig accounts. One will be funded by DHF similar to @valueplan and the other one will be the escrow account.
I don't understand why would you need two multisig accounts in your approach. Why would you need a Value Plan-like account at all in this case for this type of funding on delivery? Value Plan is still useful for prefundings or for small projects that would never get funding otherwise. But in this case, one escrow account should be enough. Unless I'm missing something. After payment is approved by vote (or by not enough participation in the vote), funds are sent from escrow to the destination account (proposal creator or whoever they designate), and that can be a normal account (not multisig).
I would avoid using a multisig account and use an account with no keyholders at all instead (I believe keys are burned). @hive-fund (the DHF account) is such an account, and the distribution of funds is controlled exclusively by code, without any (number of) people having control over the account.
This would be the ideal scenario. I assume it would take some extra work for the developers. The method I suggested does not require any changes to the current code.
The first account is to receive funding from DHF the same way all the existing Proposals are funded. Let's call this Mini DAO. When a project is selected for funding, the payment will be moved to Escrow account with a memo telling what the funds are for.
We could have a regular post on the Escrow account and ask HP holders to vote (similar to ow https://peakmonsters.com/proposals work). If the votes reach the target specified, the payment happens at once. Partial or no payments mean funds get returned to Mini DAO. This 2 account model was suggested for clarity.
Anyone can easily see how much is available for funding. and projects can have a certain guarantees about their payments and transparency is presented in a user friendly way. Nobody will have to dig deep to figure out what is happening to the funds. No changes to the existing DHF code needed.
Nice food for thought for today!
Thanks.
Great ideas. I guess a very simple approach could be something like this:
The decentralized community has interest in making the payment after delivery so that the proposer, as well as other proposers, can continue to want to deliver useful things to the community. At the same time, the community can comment on the proposal and express their satisfaction or not with what has actually been delivered. So smaller milestones will probably work better (especially for new proposers) and what has been delivered can get adjusted if/as needed.
Yes, your process is simple and I like it for some cases (and I believe it was even used, apart from the poll part). The only problem I see with it is that it's often difficult to gather support when needed (even harder twice), and if we are talking about bigger payments, they can't be paid out all at once due to the daily limit for payments made from the DHF.
The daily limit is generally not an issue if payments are made regularly in an escrow account, and it is less likely, in my opinion, to do the work according to the specifications described when the proposal was made and not get paid if there is this mechanism of delivery check at the end.
I guess there is more risk to the developer with payment on delivery. If in the end the votes change, then they might have done all that work for nothing. I am curious on the maintenance and updates of the product after delivery. With the ongoing funding, it is simple, but with payment on delivery, do they need to make a new proposal once all milestones were reached?
They need to take some risks too. Otherwise, the risk is reversed. That they get paid to do nothing.
And in my opinion, the risk is minimal for developers. Think about it. Only voters on their proposals (who are supposed to have liked at least one version of their proposal) are allowed to cast a vote at the end, on allowing or denying payment. So, they are likely to have a bias toward the proposal, not against it. Only if they fail to deliver or they do it in an unserious manner their voters would likely vote 'no'.
For maintenance, server costs, etc. the best option is a viable business solution (after a while). If that doesn't apply, then yes, a proposal with an ongoing payment applies, but that should be separated from the actual development proposal, which should be with payment on delivery.
That makes sense. It is a good idea, I hope the witnesses consider it.
I think it's an interesting system and I personally think it's better than the existing system. I still think there might be a few things to consider because everyone is different in their opinions. Then again, I guess that is what the milestones should be for. People need to make a solid plan that shows it's progress in terms of milestones.
Absolutely! It's something that can be improved upon or that can offer ideas for creating something even better.
Sometimes I actually use to feel the funding of some proposal on hive is biased well I have no right to complain since I didn't know the standard been used
There is little chance of having a funding system completely unbiased. That's because people are involved, and we develop biases, even when we think we are neutral and fair.
I am not really familiar with the prefunded though. I guess I will be aware with it much more