I had the good blessing of catching another conversation in the crypto and cola show this time hosted by @peaceandmoney. I suspect that for some of the community members of Hive these type of virtual gatherings are not only informative, which is a given, but also therapeutic, which may actually be more important at the moment.
Discussing the current state of the market was, of course, the main agenda, but eventually the conversation landed again on the infamous DHF--The way we fund development and growth for our dear blockchain.
I did however attempt to share what I think might be a parallel to solution to the conversations we keep on having about our DHF, and even though I think my idea fell on infertile ground (ptsd of a kind more on this later), I feel like attempting to write it out in a post with the hopes of polishing it a bit more. If a good conversations sparks from this, I will know I'm not chasing shadows after all.

Identifying shortcomings
The constant issue we all seem to have with our beloved DHF, is that we truly have no way of making sure these funds get used properly, efficiently. As things are today, we only know how much a project is getting from the funds, but don't really know if any work is being done.
A system to track, if you will, the progress of a proposal has not been implemented as of yet. And, as hard as I may try, I'm having a hard time coming up with a pragmatic way of implementing one.
It was not me who said it first, I'm sure, but these funds are not truly investments for development, since we can't measure ROI on them, but more like grants.
Because of this fact we've seen over the years what we can only describe as waste, fraud and abuse. It would seem like we could use some DOGE over here these days.
At any rate, there's a whole different conversation to be hard regarding how we fund development directly, and I'm willing to accept I don't have a good idea to share on this front, at least not with tweaks to our current system.
That being said, what I shared on today's hangout, what I intend to share here, is not precisely about the DHF, but something that could co-exist along side it.
At the expense of triggering people's PTSD, allow me to remember Steemit Inc, and little ol @ned.
Steemit Inc and Delegations
Maybe someone can clarify my suspicion, but I think the way Steemit did things evolved naturally. I really don't think there is a version of the white paper that lays out how Steemit Inc was to incentivize development. But, those of us who have been around long enough probably remember it quite well.
Sometimes it was one post, sometimes a few, but a project developed on Steem sought it's funding by appealing to Steemit Inc and gaining a healthy delegation from them.
Say what you will of projects like @dmania or @dlike, but their creators did quite well for themselves with those launches. But the main point I'm trying to make is that they had to do the work first, before seeing a single token come their way.
Also, they had to constantly be sharing updates, promoting engagement for their projects, because they all knew that if their efforts fell flat, the delegation would vanish into thin air in a second.
We are not privy to the conversations in the now infamous slack, but I'm sure that staying in good grace of @ned was part of everyone's routine.
All this said, I'm not advocating for a @ned of sorts to make this important decisions. Suggesting such a thing would be antithetical to what we are trying to do. My intention is only to point out an alternative to funding from the DHF as we are currently doing.
Democratic Delegations
What if we are all @ned, what if we had a way to implement a delegation system alongside DHF. What could be the downside to such a thing?
The way I see it, we would effectively have a way to "try out" a project idea, by reducing the cost risk for us. Does that make any sense?
Picture this.
@edicted and I decide to launch a game on Hive, and work for months on a minimal viable product. It's a fighting game, stick figures that move comically attempting to behead each other.
Think "Fight Club" with an element of gambling. Fighters put HBD in the pot, and the winner of the fight takes the money minus the tiny percentage of the house.
Just like it was the case with Splinterlands, Hive is used to record the fights, workout the payouts, etc. While the animation and game itself runs on a separate server.
The initial investment for this project would then be on us, on "the developers" the "entrepreneurs", but if we get enough momentum, enough users engaging with our little game, it stands to reason that applying for a delegation to help both with RC's and costs would make sense.
The proper use of this delegation would be clearly verifiable for anyone who would want to check.
- Are we actively working on engagement?
- Are we constantly updating the game, improving it
- Are we posting updates, road maps, changes, concerns, issues?
Do you see where I'm going with this?
It would also stand to reason that if the project went dormant, if engagement dropped off, the people voting on the "Democratic Delegation" would unvote it, and if support dropped beyond a certain percentage, that would trigger the undelegation of the hive power.
Is this perfect?
Of course not and it can be abused. Let's not forget the whole @dlive debacle. But, I submit to you it's a lot harder to abuse it than the grants we are currently giving out.
Also, and this is important, not all projects requesting delegations for growth have to be gargantuan in size. I’m sure there are plenty of project ideas one can come up with, ideas that would possibly aid in user engagement here or even attract more people to our blockchain.
It’s easy for me to imagine a community project like the ones we once had here acquiring a small (when being compared to DHF costs, that is) delegation to curate its members' efforts. This was precisely how projects like @c-squared, @qurator and yes even @helpie came about.
Conclusion
Of course I would need an experienced voice to address this, but I suspect the implementation of this is not that complicated– not really. And I think I’ve made a strong case for the reduction of cost risk if such a system was an alternative to the grants we are handing out.
I would love to hear from actual developers (not me, long retired) on this very subject, to calculate the time cost of adding this feature into an upcoming fork.
Please, feel free to disagree with me. Please poke holes in the idea, because in the end good ideas survive scrutiny.
Thanks for reading my friends
MenO