Hard Fork 26, even before 25 has been incorporated into the blockchain, is gearing up to be a game-changer. With so many features, improvements and additions to tackle, I'd like to focus on Resource Credit Delegations, and its foundational use-case in the grand scheme of things.
RCs are the hard-cap to how many operations and transactions a single user could carry out on any layer of the HIVE blockchain, be it posting and commenting, which is what RCs are most commonly used for as of today, to continuously providing input in a video game built on upon HIVE, such as Splinterlands. Different sorts of transactions cost a different amount of RCs, and RCs recharge themselves from %0 to %100 in 5 days, sped up by staking more HIVE power.
Notice how I said, "as of today." Commenting and posting on the frontends of HIVE's balkanized social media is the most popular use case of the blockchain, but as time goes on, this almost certainly won't be the case anymore. The Play-to-earn model is becoming much more viable by the day, and HIVE provides the biggest platform upon which to build those games. DeFi is also going to become a much bigger category of application, and HIVE hosting them is an inevitability. RCs are going to become much more valuable over time.
The problem with HIVE that arises over time is the fact that RCs are extremely hot commodities, and it limits the pool of video games and DeFi applications that could be viably hosted on HIVE. Any application that requires multiple inputs from the user is going to cost them valuable RCs that take a long time to recharge to maturity.
Splinterlands sidesteps this limitation by requiring very limited input, as well as relying on randomization in the battles. But why sidestep? Why the limitation? There is a better way:
The prototypical user on HIVE is composed quintessentially of two things: Resource Credits, and Voting Power. We'll leave Voting Power out of the equation for now.
A direct, peer-to-peer RC delegation is the only way available right now. It can be visualized like so:
An RC delegation is just that, giving RC to another user without giving them voting power. But HIVE Power could produce both RCs at a much faster rate, and voting power for both of the original user and the recipient user of that delegation, like so:
But why would you delegate your RC if you could simply delegate HP instead, achieving the desired effect and much more?
The crux of the issue, and what inspired the creation of this sort of delegation to begin with, revolves around your trust of the delegatee. The delegatee, to your eyes, shows you promise and potential on account of their engagement with the community and their proliferative nature in posting such that a lack of RC is an issue on their end, but you don't trust them enough so as to give them immense voting power. This is where RC delegation becomes paramount.
The resource credits of the origin account of any community frontend could be automated and used as an RC pool which delegates to new and seasoned users. New users, after they pass through the Great Filter of onboarding, frequently run out of RCs, and get discouraged as a result from continually interacting within Hive's ecosystem. An automated delegation to that user could prevent that from happening by tracking the activity happening within a community and satisfying certain conditions such that they favor users low on HP.
Another use-case of the RC delegation system is through supporting project and dApp developers such that they could carry out much more operation-intensive transactions upon Hive, essentially speeding up development.
RC delegation, although sort of a regression from what HP delegation could provide on first glance, could prove to be a powerful tool in the hands of users in supporting newly onboarded users and project developers, possibly even encouraging the development of applications that require a substantial amount of RCs to operate than what would've been possible before.
Support the development of HF26 through this proposal!
