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?


Source

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.

H2
H3
H4
3 columns
2 columns
1 column
17 Comments
Ecency