Resource Credits are an extremely valuable asset on Hive.
- We mint them "out of thin air".
- They are one of the original forms of yield farming.
- Without them, we should be unable to transact.
- We need a relatively high amount of Hive to make them useful.
You need a variable-cost pricing-model.
In January I wrote a post about the deflationary aspects of the RC system and how they are potentially damaging. Neither model is better or worse than the other; they are just vastly different and perhaps even diametrically opposed. We need to be aware of these differences in case any problems pop up in the future.
Not really a problem at the moment.
As they stand now, no one really gives resource credits a single thought. Anyone with enough powered up Hive simply does whatever they want to do... for free... with 3 second block times. If it aint broke don't fix it, amirite?
You need a variable-cost pricing-model.
This is the problem with RCs that people don't get.
It is a problem that POW networks have as well. Think about it this way: ETHEREUM gas fees have not increased one bit. Or rather, the Ethereum to pay for gas is the same, but the USD cost of Ethereum is x10 higher than it was two years ago, and thus we interpret that as the gas cost going up x10 even though it is exactly the same (or close) to where it was two years ago.
When yield farming bandwidth, this variable cost materializes in a different way.
In fact, it is much worse, because at the moment none of the Hive whales are actually using their bandwidth; they are either letting it go to waste or banking account tokens with them (which doesn't put any strain on the network until those accounts are actually claimed and putting data on the blockchain). This creates an entirely new multiplier we have to account for.
Think about it:
Of all the RCs that Hive actually mints, how much of those RCs are actually used to store data on the blockchain? 1%? 2%? 5%? Whatever it is, it's an extremely low number, and we should have every intention of believing that one day this will no longer be the case. This number could easily go x20, and when it does we should also expect that the cost of transactions on the blockchain will also go x20 right along with it.
It is not ridiculous to assume that not only could the price of RCs go x20 but the price of Hive itself could also go x20, which means the externally perceived price of gas on Hive would go x400 for outsiders, while the internally perceived price of gas for holders would only increase x20 (or for those who still have enough RCs to do whatever they want: would perceive zero difference... which is powerfully deflationary).
Imagine someone needing 1000 Hive Power in order to do whatever they wanted, but each Hive cost $20 to get. That's a $20k investment just to get free transactions. Anyone who thinks this is absurd and not going to happen is kidding themselves. It is guaranteed to happen as adoption increases. As we all know, these things come in hype-cycle bursts and it will not be easy to navigate the increased demand. This failure to meet demand then reverses and we get another brutal bear market for 1 or 2 years. Perhaps this is just the way of things.
Again, these problems aren't even considered by 99% of the community because if Hive goes x20 we all get rich. I'd personally have over $3M worth of Hive. Hard to complain until the crash hits and you realize that all your friends and family that aped in during peak FOMO just lost everything they put in. Oops!
Rewarding those who hold instead of those who build.
Ethereum is brutal Darwinism. One day a development team might build something there that works perfectly, and then a few years down the line gas prices have gone x20 and that business model becomes completely broken. This problem doesn't happen on Hive, because if the dev team simply has enough Hive to subsidize RC delegation they can simply hold onto that power until the end of time knowing full well they'll always have to huge bank of derivative bandwidth to draw from for free. Meanwhile, ETH is very dog eat dog; models that break due to rising variable gas cost simply get put out to pasture.
But what is the downside for Hive?
Yield farming bandwidth is a double-edged sword. What happens if the people farming and using RCs have products that are totally inferior to other projects, but it simply doesn't matter because they got here first? This is why deflation can cause stagnation. It creates a situation where those who have resource credits(grandfathered in) don't have to compete, while new talent gets turned away by the absurdly high onboarding costs.
Scaling solutions
This could be the variable that makes all these problems irrelevant. What happens if we, as a network, have the money and resources to upgrade our nodes and increase block size? What happens when our second layer solutions and HAF protocol come into play? What happens when we optimize our indexes and continue scaling up?
That all results in healthy inflation and lowered RC costs for everyone on the network. If this kind of inflation outpaces the deflation of yield farming bandwidth we will end up doing quite well for ourselves as we continue to grind forward. We might be able to get the best of both worlds.
BOLO: RC delegations
This options is going to make it much easier for whales on Hive to spend their RCs. That's great, and it's also a problem. Inflating the supply of RCs makes them worth less for everyone, and it makes the cost of operations higher across the board. At some point RCs will be worth real money and traded as such, and that's when this whole thing really gets interesting and kicks into high gear. Be On the LookOut.
Conclusion
Hive is a very reactive network. We first wait for the problem to happen and then try to solve it after it's done a bunch of damage. The ultimate expression of this was the ninjamine and the hostile takeover. Even though great damage was done, we also evolved and are much better off than we were before. Viruses and exploited attack vectors are a big part of evolution.
However, if it's obvious a problem will happen eventually, why not be proactive and work toward avoiding that scenario entirely? I believe we are doing just that with RC delegations and HAF tech and everything else, but those solutions will inevitably need to more problems we need to solve. Two steps forward, one step back. Developers have a way of never accounting for the one step back. Soon™