As lead architect of the first iteration of V3 and currently V4 i find this statement by @ACI incredibly offensive and honestly a little bit sad. It seems that Zeller’s favorite strategy is to throw uninformed shades at other people’s work hoping to gain cheap popularity. Unfortunately for him, it doesnt always work especially when it comes engineering where he clearly lacks any basic knowledge. I will try to educate him appropriately (again, as i was the first one teaching him basic smart contract development many years ago) and debunk this embarrassment, hopefully this way he will avoid wasting my time that could be better spent for the DAO. Let’s see what the (great) improvements implemented by BGD address, why they were needed and where they come from:
-
Virtual accounting: There has never been virtual accounting before in any iteration of Aave. This basically goes back to Aave V1
-
Stable rate removal: Stable rate was inherited from Aave V1 and is not inherent to V3.
-
Precision: The precision dynamics in V3 were inherited from Aave V2.
-
Foundry codebase and better testing: The original V3 codebase was of course a continuation of V2 that was in turn a continuation of V1. The code base was running on hardhat as when the development of V3 started, foundry was not even a thing.
The only changes that improved something that was directly introduced in V3 were liquid emodes (which improved the original eMode design, that was anyway functional and what made Aave what it is today in the first place) and LTV0 dynamics. The rest (multicall, bad debt accounting, oracles) are a result of new DAO initiatives coming in that werent even a thing when V3 was initially released.
As for GHO, the original design of the stablecoin itself is still unchanged and arguably works well. What was rengineered is the GHO integration in Aave, that was in hindsight probably not the best decision originally - but there was a reason behind it, which was attempting to give to the AAVE token more utility with the GHO discount. That made the implementation more complex and again in hindsight maybe not worth it, but we all know hindsight is always 20/20 and in any case that says nothing about the quality of the codebase. TLDR pretty much all of the improvements BGD applied are if anything symptoms of an aging protocol, with most of the adjustment needed to address decisions taken many years ago and not at all indication of bad “state and quality of codebases“ as insinuated by Zeller. In the end both V2 and V3 were holding billions before ACI was even a thing, and before any of these improvements were applied - not bad for a “non market ready” codebase.
Done with the OT, I also have some comments that i will post later on the original topic which hopefully will make for a more constructive discussion.