An interesting idea! I think something like this would be well served by an executive summary, as I had to dig quite far to find the meat of the proposal.
To summarize, as I understand it:
- Say I have 1,000 HBD in savings (generating 200 HBD/year @ 20%)
- I could, with this feature, delegate 50% of that to X number of projects, people, or systems
- Thereby sending ~8.3HBD/month or 100HBD/year to these things automatically
At the end of the day, whether or not such a system impacts demand or the tokenomic realities of HBD come down section 8.2—risk of low adoption. For me at least. You need a reason for this to exist, and the proposal focuses on this in Section 5.
I'm finding that section a little thin on 🔥 BURNING 🔥 needs for this feature. There are plenty of 'hey, interesting' pieces. But no real problems that need fixing IMO. A huge issue with many crypto projects is: "developing a solution then going hunting for a problem." Successfully product development (web3 or otherwise) nearly always starts the other way around.
The counter, of course, is "Heyyyy I'm innovatin' over 'ere!"
If it's not a mountain of dev work to rig up something like this (and I imagine a bolt-on solution could be dev'd independent of tinkering around with the core Hive code), then it may indeed be better to enable the feature and let people play with it.
In that vein, the things that got me thinking include:
- Reliable subscription models make sense. If I ask for a user to pay 5 HIVE/month for service, there's a decent chance that that subscriber will run out of HIVE for a number of reasons. Rather, my application could require a minimum HBD delegation amount. This stabilizes income for service provider and makes it less likely that the user will "run out" (they have to forcibly "unplug" / undelegate). You could also build in contract that force a 7-day undelegation to allow the provider time to adjust to changes in their subscription base income.
- Employment and proof of funds is also a solid use case, for many of the same reasons above.
I appreciate the time and effort it took to put all this together! Very interested to see what other Hiveans, especially those with some weigh/dev chops, have to say :)
!PIZZA
Thanks a lot for your feedback and for taking the time to read the whole thing! You got that right indeed! I figured the 6K+ words could be overwhelming for some readers, so I tried to keep it "brief", but at the same time, I know there is a limit to the total amount of words that I could write in an article, and didn't want to risk a 2 part or exclude information.
The reason why you had to go through all before getting to the meat is that I think it's important to understand the existing features that Hive already has (from my POV), so in a scenario when my thought process is based on incorrectness, the meat would need adjustments as well. For example, I completely forgot about the burning mechanism and added way too much salt to the meat.
I actually started thinking about this "solution" months ago because I was brainstorming for a business that would like to offer monthly pay in crypto to its employees, and with all the rug pulls going on I thought employees are more at risk in the crypto space than employers, while employers would state the other. The challenge/problem was: how can an employee prove to be trustless, and guarantees employees there are enough liquid assets available to guarantee to pay for work in an anonymous space that's based on trustless transactions? Solution: Delegating HBD to an employee both guarantees pay for the employee, as well as guaranteeing that there are enough liquid funds available in the company. The problem: a transparent feature like that doesn't exist.
I'm not entirely sure or enthusiastic about a burning mechanism implemented in the feature, because this could also give long-term unnecessary problems if Hive becomes deflationary. I did think of allocating 0.1 - 0.5% to the DHF instead, as the DHF needs to grow IMO to further protect, secure, and stabilize the network. I believe that those properties should be community choices.
I'm pretty sure people would love using such a feature, especially people who have never used Hive before. Think about next-generation projects that fund start-ups with delegation, without people losing their buying power.