I share the feeling that this upgrade is somewhat less relevant compared to the previous ones which were great, and to proper evaluate if the risk reward is worth it, i will save my decision for when the code of 3.4 is publicly available, as i want to evaluate the impact on the codebase. While some of the proposed features i can imagine are relatively small and easy to implement in isolation like the multicall and the position manager, some others like rounding changes, the GHO migration and compiler version migration sound relatively challenging from a security standpoint. While i understand the position of @bgdlabs and i too see the value of upgradeability in a complex system like V3, we should also be very clear in recognizing how even one simple mistake is enough to kiss goodbye to the whole thing. This i think all contributors on Aave understand very deeply, and that’s one of the reasons why Aave has been fault proof, for the most part. Still, we had some security issues related to the stable rate mechanism that dated back to the first iteration of Aave, and nobody was able to find even with the code being live for over 5 years and after hundreds of audits and god knows how many thousands of black hats looking at the code. This is not meant to scare anyone, just to remind everyone the reality of the technology we work on - in a system with 24/7 liveliness, public code and no chance of addressing issues promptly due to governance, one mistake is all it takes. While i have full confidence in the ability of @bgdlabs of addressing changes securely and in our security SPs, i also keep strongly in mind past experiences and events affecting both us and other projects and i’d still avoid updates if not absolutely necessary. We are humans, and mistakes will happen, no matter how good we are. In any case, i am looking forward to the code to be able to take a more informed decision.
–
Note in regard to V4, as i am the main engineer behind it and i feel like i need to intervene. While V3 is great, V4 was designed and developed to address almost all of the aspects in which V3 could be stronger, from a capital efficiency, risk and security perspective. These aspects we all know them, we have been through challenges in the past years were V4 features would have helped immensely. I think this is undeniable and pretty much recognized by everyone who has been introduced to V4, including in the original governance post, recently @Certora and @StErMi (very soon also @bgdlabs and the rest of the SPs will get access) and also pretty much globally acknowledged on X, where i had a series of threads explaining V4 more in detail. Additionally, V4 offers a host of new features and the architecture allows for novel usecases and a variety of new options that on V3 are simply not doable (for example the multi spoke architecture).
Historically the process flow of releasing a new protocol iteration has been to deploy the new protocol instance, wait enough time for the system to be deemed secure, and then activate the migration procedures. Given all the benefits that V4 brings over V3, it would be in my opinion a strategic mistake and a waste of resources not to follow the same approach. This is of course a decision the DAO needs to take, i have no doubt V4 will “cannibalize” V3 anyway in the same way V3 “cannibalized” V2 given that it’s simply much better. Hopefully once @bgdlabs will get access to the code and have a full picture they will get a better view of the potential and we can start working together on new technology and novel features.
Regarding this:
Everything will be done with the goal of keeping as much as the current infrastructure compatible with V4, of course. In case components won’t be needed anymore they can just be deprecated in regard to the new protocol iteration, same way as it normally happens in any technology stack when new versions are released.