It doesn’t make sense to vote after few days of preliminary discussions to “soft approve” something that could get turned down upon actual activation. That would be waste of DAO budgeted resources.
Because let’s be clear, the ARFC stage (not the activation even) on a proposal by an engaged service provider, on a process that has been made multiple times in the past, is also a vote of trust on our work, or the opposite.
The framing from @eboado here where the vote against unnecessary protocol upgrades is vote of trust is quite unfounded. Community members including a technical member raised the concern of protocol upgrades, which by itself is a controversial topic in DeFi and our industry widely. As I personally mentioned earlier it made sense to upgrade for V3.1 given the essential security improvements, V3.2 and V3.3. itself were justified (even though the procedure of upgrading could have been risk mitigated more by upgrading one network deployment at a time). However, the concerns are around the version V3.4. Especially since the upside is very negligible for users compared of the risk of mutating existing codebase and recompiling it. Aave is not a small protocol anymore and each time the codebase is changed, the lindy effect restarts since new code is introduced. This is not only the perception but also the reality.
This direction of frequent protocol updates is playing with fire. It’s just a question of time, a human error occurs, not when, and once it happens the consequences will be devastating given the amount of funds in the protocol (circa 30B). In fact, we should steer towards a direction to ensure maximal mitigations of unnecessary risk and single point of failures. Aave is well built brand and it can all be lost by one mistake even if we are extremely diligent as we usually are.
Whole point of decentralization is to create resilient systems where the users do not need to trust us as the developers or rely on anyone else to ensure functionality of the system. This is the right vision, otherwise Aave is just another centralized business with additional blockchain hurdles but thats not what we are here for or believe in.
I also don’t see a point of altering a codebase that is going to be deprecated overtime similar to V1 and V2 while taking unnecessary risks with limited time of development and due diligence. At this point Aave’s moat is security and we need to steer towards direction where we try to minimize any potential risk and single point of failures, including code changes. Every single line of code change can be an additional risk and should be questioned. Every single protocol upgrade needs to be questioned, the more value the protocol has the more resilient the community should be towards protocol upgrades as stakes and their consequences are increasingly high.