If we do a Google search on Reactive vs Proactive a certain pattern tends to emerge. Being proactive is good and being reactive is lazy or even dangerous. After all, if you're building a security system: a reactive system implies that the security has failed and been breached. Security systems should be proactive and prevent attacks before they occur. However, this is a very unbalanced bias when trying to apply the concept across a spectrum of contexts.
A billion years of evolution show us that life itself doesn't try to guess what will happen; it simply waits for the environment to change and adapts to it. Of course there are many things about evolution and adaptation that we don't understand very well.
Used to be that we thought most/all evolution stemmed from the idea of "survival of the fittest". Under this model evolution can only occur if the environmental change in question has a direct affect on survival or reproduction. Evolution could only occur if weaker genetics resulted in diminished reproduction, slowly eliminating those genes from the species' pool.
The answers are never as simple as we'd like them to be, and the more we know the more questions pop up as a result. Knowledge is a beacon of light in an infinity of darkness. As the light expands, so to does the edge of unknown. Everything beyond this edge are unknown unknowns: questions we don't even know to ask because of our lack of knowledge. There are perhaps some ways in which evolution is proactive that are currently unknown to us, but for now we are left speculating on such things.
Everyone likes to harp on the advantages of being proactive. Solve the problem before the problem ever happens! However, this strategy assumes that our game theory is 100% accurate, which is coincidentally also false 100% of the time. Even the best theory-crafters are going to be smacked around by unknown unknowns when the thing actually gets tested in reality. A good test is worth a thousand theories.
Thus, the advantages of reactivity are largely based on efficiency. If we plan for a disaster that never happens, well all the energy we put into that plan was completely wasted. Do that enough times and our actions will become drowned in a sea of unsustainability.
For example, it's not a smart idea to make a building resistant to earthquakes within an area that never has earthquakes due to lack of a Faultline. Even worse, forcing other builders to do the same with construction codes or other regulations would be a huge waste of resources across the board. Certain building materials like bricks can get outright banned in such scenarios, even if clay is logistically abundant in that area. In addition, bricks are very expensive to transport because they are so heavy and bulky and low value.
Location location location.
Of course there are many scenarios in which a reactive strategy is completely worthless. Take cryptocurrency for example. If you wait for something to go wrong with your Bitcoin wallet you're probably just going to end up having your entire account cleaned out by a thief before even realizing what happened. By in large, safety and security measures are a proactive endeavor, which is why Hive security is go good (4-tier security plus account recovery plus a layer-0 social network to smooth out off-chain problems or downvote malicious users on-chain).
Hive is actually the reason I wrote this post to begin with. The Hive network itself is a very reactive and proactive platform in a lot of different ways. For the most part we wait for problems to happen and then scramble to fix them. This can be frustrating sometimes, but also: if it's not broken, don't fix it! Crypto is one of those things that isn't supposed to be perfect. It only needs to be good enough to work.
For example, the economic incentives hardfork from back in the day was a huge change. I was very much against most of the changes being made, from free downvotes to the convergent curve and 5 minute voting to the 
Our most recent economic hardfork25 rolled back the failures and kept everything that worked. We no longer have 5 minute curation trails that can be gamed by bots (even though many bots still vote at the 5 minute mark due to old code that didn't need changing). Instead everyone gets a 50% kickback just like HiveEngine... so in a way HiveEngine also acted as a testnet for Hive by employing these mechanics; seeing what works and what doesn't. It all worked out in the end.
I'd say our biggest proactive move is to continue optimizing the chain and trying to scale up even though we don't really have high enough adoption levels to necessarily justify all the effort being put in. Then again optimizations will lower costs no matter how many users there are, so perhaps this is both a proactive and a reactive move. Best of both worlds.
There are a couple of other things I wanted to talk about as well. Like in this Taskmaster vlog from 3 days ago, he dances around the issue a little bit but doesn't outright talk about it. It's talking about Hive as an access token and adoption of our network. As demand to use the network goes up the value of RCs also goes up.
And I'd like to reiterate as I have done a dozen times already in previous posts: that RCs are a derivative asset that have value, and that value will increase.
In his vlog, Taskmaster speculates correctly that eventually delegating RCs to certain accounts will result in being rewarded with some other asset or utility. I already believe that this is the best way to solve the node API overload. We can create fullnodes that charge to be accessed, but also the charge could be something as simple and cheap as an RC delegation (which constantly recharges and pays for itself). This will be more than enough to keep those nodes from being overloaded with requests during periods of network instability.
I think the main thing we need to be thinking about when it comes to RCs is that our branding today isn't going to mesh well with the future. Every day we talk about how transactions on Hive are free, even though they aren't. We need to stop saying they are free and start saying they are yield farmed along with all of our other inflation using staked governance tokens (I guess on a marketing level that's certainly not as catchy). Still, people are going to be mad when they learn that RCs on Hive are absolutely not free when we've been telling them they are since inception. It won't be a good look, but maybe we can make it work using some cliché 'innovation'.
Another thing I worry about in terms of witnesses not being proactive enough are the "unsustainable" 20% yields on the savings accounts. Of course I've explained why they are sustainable for now, but it seems unlikely that this will always be the case.
Do we trust our witnesses to have the self-control to manipulate interest rates downwards during peak bull market FOMO? In many respects: this is the problem with Hive witnesses: we expect too much from them.
They need to be crypto devs, politicians, and professional economists all at the same time. It is perhaps the fate of all witnesses on Hive to be replaced with companies and/or sub-communities so they actually have the resources to provide all these critical roles to the network on a professional basis.
This is a tricky subject, but I'm going to guess around 15% during a bull market, and a much higher number during a bear market like 20% to 25%. 30% is the haircut, which is the number we are trying to avoid. If we don't the peg will break and the entire network loses credibility.
The problem with this is that during a bull market the bubble is just waiting to be popped. No one is going to want to pop it on purpose (unless they're insider trading around that power of knowledge... which will also almost certainly happen one of these days). If Hive goes x10-x100 no one's going to be worried about potential instability. The FOMO is simply too stronk.
The problem here with the debt ratio increasing during the bull market is sustainability problems. It's all well and good to increase the haircut even higher if we can be sure that we will bottom out at a higher level during the subsequent bear market (like 20%-30%), but if we go from 50% debt ratio to 5% during a bear market it's going to cripple our economics. Even worse, at the beginning of said bear market the debt ratio will actually go up as users get locked into the system and Hive spot price continues to go down.
Should we put effort into speculating on how things could go wrong? If so should we then takes steps to mitigate the problems that may arise? It always sounds like a good idea, until it isn't. There's only so much we can do in the planning phase, and overthinking can be a Goliath problem for builders that just ends up being a massive waste of time. Sometimes the best strategy is to simply keep building and grind out the work so it can be tested in the field sooner and refactored using real world data.
On the other side of that coin, if we fail to plan: we plan to fail. As with all things, there is a healthy balance between proactive and reactive strategy. Finding balance is difficult, but will certainly pay off in the long run should enlightenment be attained.
