I believe Hive has a governance problem. The way the DHF works fails the smaller projects. Actually, I think it's pretty dysfunctional overall, but I recognise that it's how Hive is and unlikely to change without the implosion of another hard fork.
So I'm going to throw an idea out here that can hopefully be brainstormed to see if it offers a partial solution. Everything I say in this post is up for debate (I encourage it !), and it's just possible... maybe.... that it might lead to a solution.
.
What Is The Problem ?
The DHF has a number of issues which I believe are significant. They affect all proposals, but most especially the smaller ones.
The key issues I see are;
- The Return Proposal is a hard floor. It's a fixed figure based on the total vote value of those voting for it. It doesn't bear any relationship to what a proposal is asking for. It doesn't matter whether you're asking for a hundred or a million HBD, you still have to get over the threshold (currently a shade over 50 million vote value).
- There is no requirement for a business plan. Proposals aren't required to submit any kind of business plan. Some are good and do anyway, but many rely on hand-waves and the vaguest of justifications. They don't identify what success looks like in financial terms.
- It is a grant-giver, not a loan-giver. I believe that a good proposal should cover it's costs one way or another. Not always by charging direct fees (the antithesis of what Hive stands for), but there are other ways to recoup costs, whether it's through delegations, fees for specific services, slippage on transactions or whatever. The only exception should be proposals that address security issues or significantly improve Hive's core code. Everything else should be a loan.
- Whales are too influential. There, I said it. The elephant in the room. A lot of our whales are good people who bring a lot to Hive, but they also tend to mutually support each other in their proposals. It reduces the chances for relative unknowns, and opens up the opportunity for a few to pull huge amounts of market cap out of Hive.
A Possible Solution
The solution I'm looking at is a kind of "mini DHF". A fund used to specifically sponsor smaller proposals, but adopting a more business-like approach than the current "popularity contest" of DHF proposals. There's a lot of detail here which would need to be discussed and hammered out, but the bare bones look something like this....
Which Proposals Would Be Covered
The proposals I think this would work for are those which;
- Need smaller sums than the "big" proposals in Hive's main governance (say, up to 2000 HBD).
- Have a business plan which shows how they'd spend the money, what success looks like in objective terms and how they would repay the loan and over what timescale - and yes, I'm looking at a loan system, not flat-out grants as at present.
- Aren't technical code upgrades, but are more intended to grow Hive's userbase or improve the user experience - new user tools, games, things like that.
- Where the originator is prepared to put some of their own HBD or fiat in, and in a measurable way. It shows they have confidence in their plans, and that they aren't just trying to get market cap out of Hive. If their proposal succeeds then of course getting their own funds back (and then some) will be part of the plan.
How Would It Be Funded ?
For this idea to work, it would need to have a pool of HBD to lend out. In a perfect world, the HBD pool would be capital that didn't get touched and the loans to proposals would be just from interest. But I recognise it would take time to get to that !
Funding could be from a mix of sources; 1. It's cheeky but we could put a proposal in to the DHF. The argument would be that it's for a pool to be used as capital not spent (and ideally repaid over a period of time), and that it's a hugely efficient way to use DHF funds to benefit Hive as a one-off rather than the current constant drain. It leaves the DHF more free to focus on expensive coding projects. 2. Delegations of HP from Hivers. This would earn HIVE from curation which could be converted to HBD and added to the capital pool. 3. It would need to be coded (and I can see some objecting to it !), but delegation of HBD from Hivers. The interest could be split 50/50 and they'd be able to retrieve their delegated HBD in the same way as HP delegation. 4. Building up of Tribe tokens which could be swapped for HBD. 5. Actual donation of HIVE or HBD (see more about this below....) 6. A small interest element on loans given to proposals. I'm realistic, not every proposal will succeed well enough to repay the initial loan, so this acts as a kind of "insurance" and could be reviewed every (say) 6 months to ensure it covers the defaulted ones.
Which Proposals Would receive Funding ?
To determine which proposals would get loans, I'm thinking it should be a two-stage process.
The first stage would be an assessment (as objective as possible) to look at; * How realistic the business plan and requested amount are. * Whether the originator has been realistic about the timescales, difficulties, technical aspects and possible problems that might be encountered. * Are the measures of success sufficiently realistic and objective. * The likelihood that the loan would be repaid on the planned timescale.
I can see there might need to be some kind of discussion thread on each proposal, or even a committee of interested, experienced and fair-minded Hivers to look at each proposal. The end result would be a "score" assigned as objectively as possible, with proposals having to hit a threshold in order to go forward to stage two.
The second stage would be a voting process. This would be done on a monthly basis.
- It would start by identifying the funds available for the next month (i.e. the interest, earnings, donations etc received in the previous month).
- Hivers entitled to vote would be those who delegated or donated to the mini-DHF. There would need to be some maths (ideally automated with code), but the idea would be to give each person an HBD-equivalent vote value. For those who donated, the equivalent HBD would be a permanent vote value. For those delegating, there'd need to be maths to convert HP values to HBD values at the average for the month. For those delegating for part of a month, it would be pro-rata or maybe even only the amount delegated for the whole month. This would stop people diving in with a large last-minute delegation to support a mate and then immediately pulling it out. We could even time-weight long-term delegations.
- There would be (say) a week to cast votes, at the end of which the result would be tallied. The total vote value could be split as many ways as wanted, but the total for each voter would always be the same.
- Each proposals requested amount would be divided by the total of funds requested by proposals in the month. A proposal would have to get over that percentage of the vote to be funded. Thus, if a proposal asked for 1000 HBD, and the total requests for the month came to 10,000 HBD, that proposal would need 10% or more of the vote to be funded. Theoretically (I think !!) this would match successful voting to the funds available and mean there's a relationship between the amount requested and the chances of success.
At the end of it all, any denied proposal could try again the following month, but would be sent back for revision if it failed (say) four times in a row. Proposals that didn't hit the threshold in stage one could also be revised and re-submitted.
Conclusion
This turned out to be a lot longer when I wrote it down than I expected. In my head, it all seemed quick, simple and graceful. But it's actually got quite a few subtleties that hopefully act as checks and balances.
What do you think ? Which bits are good, and which bits suck ? Is it a realistic starting point for further discussion, and what have I completely forgotten to think about ? I'd love to know !