Introduction
Considering the upcoming Aave v4 release at the end of the year and the position of Aave v3.X (v3.5) as market leader, we think it can be very valuable for the community to understand our point of view on Aave v3.X’s future, and the relation with v4.
In this post, we touch on the following topics:
- A recap of the Aave v3.X status and infrastructure, as necessary context.
- Our view of Aave v3.X as a completely separate product to v4, with v4 NOT being a replacement of v3, or even a product continuation.
- How do we see Aave v3.X realistically changing going forward, specifically in terms of upgrades.
Aave v3.X: 2025 status-quo
While the Aave v3 base “v3” label and part of the original codebase remain associated with the production system, as of 2025, Aave v3 is totally different compared to how it was at its inception in early 2022.
In addition, the periphery (smart contracts, tools, off-chain infrastructure by different parties) has radically expanded, too.
Last but arguably as important, the DAO has created from scratch management procedures that have been proven successful by the market, positioning the Aave DAO as the lead decentralised entity on DeFi.
As a reduced summary, all the following have changed:
- The core codebase itself is very different than at the beginning, still keeping part of the original principles, but with almost everything else pretty different, for example:
- The internal available liquidity accounting of v3 is different, with virtual accounting (v3.1).
- The eModes model is different (v3.2).
- There is no stable rate mode anymore (v3.2).
- Bad debt is now accounted for (v3.3).
- The liquidation logic has been improved (v3.3).
- Batching of actions is possible with native multicall support (v3.4).
- The precision math of all user actions and internal components has changed (v3.5).
- The internal logic of aspects like LTV0 assets has changed.
- Price feeds are very different compared with v3.0: they have multiple layers (e.g., capping components), and @Chainlink_Labs SVR is adopted.
- The codebase of the protocol is now running on Foundry, instead of the original Hardhat setup.
- Deployment infrastructure is completely different.
- The test suite of the protocol has been radically improved, adding a fuzzing suite.
- In what concerns the peripheral infrastructure:
- The configuration of the system rarely happens directly via the PoolConfigurator core contract, but via additional middleware (ConfigEngine), focused on adding a better development experience and assurances, without changing too much the core components of the protocol.
- The so-called RiskStewards middleware is operational now, partially automating risk parameter changes to reduce governance proposals’ overhead. Part of this is the integration with Risk Oracles by @ChaosLabs.
- Treasury operations concerning v3 are partially (and constrained) delegated to smart contracts, which then entities like the AFC (Aave Finance Committee) use. This applies to bridging or swaps.
- Incentives management infrastructure has been improved radically: on-chain with more tooling for rewards admins to enable safe supply and/or borrow incentives; off-chain with the creation from scratch of Merit by ACI, enabling more flexibility of incentivization whenever supply and/or borrow granularity is not enough.
- Liquidations are progressively migrating to Chainlink SVR integration, currently already covering the majority of volume via the Aave v3 Core/Prime pools.
- Countless tools/dashboards focused on visibility have been created and maintained by the different service providers, on the risk side with @ChaosLabs or @llamarisk, treasury by @tokenlogic, our own resources on BGD, or different tooling by @aci.
- All high-level procedures of maintenance and expansion have radically changed, for example, the following:
- Aave v3 new deployments are a structured procedure, with multiple parties involved in different steps (ourselves on tech, risk, and growth). The process of activation is now fully decentralized via on-chain Governance proposals.
- Analysis of listings of assets is also highly structured, with three different parties involved in what relates to technical, quality, and risk evaluations.
- There is now a single source of truth for official Aave smart contract addresses: Aave Address Book.
- Quality assurance and security verification on proposals is certainly the best in the whole industry, with multiple steps of verification, deep visibility (e.g., Aave Seatbelt), and manual involvement (both BGD and @certora).
- It has a formal bug bounty address controlled by the DAO.
- It is in the process of Safe Harbor adherence.
- In terms of market adoption, Aave v3:
- Has become bigger than ever over the last years.
- Has been capable of onboarding continuously new asset classes (e.g., LSTs, then LRTs, assets like Pendle PTs).
- There is interest and ongoing projects on using Aave v3 for friendly forks (EtherFi, Horizon, Ink, World Liberty Finance).
- It has more integrations than ever built on its liquidity (e.g., Balancer for lending re-usage of capital).
- It is the revenue generator of the whole Aave ecosystem.
We can certainly say that as of 2025, Aave v3 has radically changed since its inception, to be what is today, one of the most solid DeFi protocols.
Aave v3.X and Aave v4
One of the touched topics on the Aave V3.4 thread was on how the release of Aave v4 can/will affect the production Aave v3, any hypothetical deprecation of Aave v3 in favour of v4, or even if the development of v3 further should be deprioritized and the system should ossify (fewer updates, focus on stability).
Our position on the relation between Aave v3.X and Aave v4 is the following:
Aave v4 is not an upgrade of Aave v3.x; they are totally separate developments and products, and should be treated by the DAO as such, not really with v4 as a product continuation or replacement of v3.
We have no reason to think that v3, being the biggest DeFi protocol, should have any type of short lifetime, and we think it is fully functional and capable of covering future use cases.
Our arguments are the following:
- Aave v3 is a production system, Aave v4 is still in (final stage) development . This first argument is self-explanatory: Aave v3 is the main product of Aave, fully in production, its revenue-generator and powering a high percentage of the whole DeFi. So, no matter the nature of Aave v4, or even when the final release of that system will be, the first priority should be v3.
- Aave v3 is NOT any type of legacy product . Aave v3 is totally functional and in continuous development and maintenance. It is not a system that requires deprecation of any type, just continuous improvements like any other production application.
- Aave v3 has countless infrastructure and procedures around it. The peripheral infrastructure of v3.X is very extensive, as described in the previous section. In addition, there are countless parties both inside and outside the DAO familiar/involved with v3.X procedures. Even assuming that v4 draws from all previous developments and learnings, replicating the same for any other system like v4 is not going to be a trivial task, and a task that is simply not defined at the moment.
Hence, it will take time, and so the independent lifecycle with v3.X. - Products in different stages and requirements: brownfield (v3.x) vs greenfield development (v4) .
Aave v3.x is a brownfield development, meaning that all design decisions and execution of improvements must take into account that it is a full production system, the biggest in DeFi. This makes every single decision 100% critical with close to zero room for mistakes, and that is what we do at BGD: define and execute an equilibrium of v3.x still fulfilling the strategic needs of the DAO, while introducing as less breaking changes as possible, and keeping the highest standards of quality and security.
Meanwhile, Aave v4 is a greenfield development, meaning built from scratch. So the flexibility on what can be done and how is total. Consequently, certain features or architectural changes can be introduced more easily than in v3, and that has effects on everything else (e.g., peripheral tooling required, maintenance strategy, etc).
Even assuming a final state of development of the new v4 system, the previous means is not even simple to directly compare both products, as they address problems from different angles. Aave v3 is a good product, and Aave v4 can be too in the future, but it needs to prove itself. - Different developers and feedback cycle . Both protocol lines are developed in practice by 2 separate teams: Aave v3.X by BGD Labs, and Aave v4 by @aavelabs; with both teams separately compensated to do their work.
Additionally, aside from the pure core development side, Aave v3.X has evolved directly from the past years of feedback and direct contributions of other SPs. While Aave v4 until very recently has been developed privately by Aave Labs. - Aave v4 replacing v3.X could potentially happen, but organically . We see a future scenario where v4 could potentially replace v3.X, but if this happens, we believe it should be organically, by its own merits.
Aave v3.X going forward
High-level protocol mutability: more upgrades, yes or no?
Aave v3 is a mutable system; we should not act like it is not. It is this mutability that allowed the introduction of Liquid eModes and now also Umbrella, both features elevating Aave to maintain a competitive edge. It is also that mutability that allowed the mitigation of attack vectors found by various whitehats.
Simply acting like the Aave system (or almost any other DeFi system) could be immutable, in our opinion, is foolish. The ecosystem steadily evolves with new assets and technology to integrate, the hosting software (blockchain networks) radically evolves, new security threats appear or change criticality over time, some features find market-fit, some others do not; there are almost endless reasons.
By not having upgradeability, the tail risk is that an unknown problem appears (e.g., the underlying hosting infrastructure changing, or simply a logic bug), and then, there is nothing to do, aside from changing the hosting infrastructure itself (forking the blockchain), or asking all users to do protective actions, which is a non-feasible solution and could potentially tarnish the reputation of Aave.
Also, by not having upgradeability, a product is self-limiting to not expand to certain features, features that, if the protocol is originally decently architected, are very frequently feasible.
For example, the majority of announced features included on v4 and currently not on v3, are feasible on v3, development effort aside.
To make this more specific for the community, let’s dive into the flashloan fee change proposed for Aave v3.4 as an example.
The change was not motivated by having any issue in production, but we know that any protocol flow with unbounded liquidity injection can bear problems. The virtual accounting mechanism introduced on v3.1 was added especially to prevent unbounded growth, but the flash loan fee management on 3.4 doubles down on that, by now simply not having any flow at all by which unbounded injection could be done.
Mutability allowed in this scenario for Aave to add more and more security defensive mechanisms in depth.
On the other hand, while most things we propose are in a sense related to security, it is also clear that some are not: Liquid eModes are a prime example of that.
The idea for liquid eModes came from both an architectural and a risk consideration.
- Architecture-wise, we believe that the concept of eModes should be more understood as some type of totally generic sub-group/categories of assets within a pool, and not only a “boost” mechanism for assets to have higher risk parameters.
This radically changes even the reasoning about the Aave protocol, as now it is completely eMode-centric. - Risk-wise, we did not like that risk providers had to maintain the same eMode parameters for multiple assets that are not necessarily alike. This became more and more of a problem as the LSTs/LRTs asset class expanded, as grouping them too much at high-risk parameters was creating a kind of “contagious” risk between them.
Therefore, the evolution to liquid eMode was the rational thing to do, both due to our understanding of how they would be overall better, and the growth of new asset classes (LST, LRT).
Once again, mutability allowed Aave v3 to stay ahead of the curve, in this case, feature-wise.
So, what do the previous high-level arguments and historic precedents tell us about doing more upgrades? In our opinion, it is clear that there should not be any type of “red line” not to do more upgrades, because they have only been net positive for Aave.
Does this mean there must be continuous upgrades of Aave v3? Not really, and over time, the frequency or content size of upgrades will naturally be reduced, as mature systems require fewer modifications. But as core developers of the system, we still think there is room for certain improvements going forward.
Are Aave v3 upgrades secure?
To give more visibility to the community on the security procedures applied to Aave v3 upgrades, they can be summarised as follows:
- Since the very first upgrade done on the v3 release line, every change has been audited by multiple external teams.
- For every single upgrade, we not only add tests for new code but also improve the existing tests and properties. For example, with v3.3, we completed a new setup of fuzzing invariant testing to complement the existing test setup.
- Certora’s formal verification properties are adapted for each upgrade.
- For each upgrade, the on-chain code & storage are diffed against the new version to preemptively detect any inconsistency before the on-chain release.
- For any breaking changes, we have internal tooling & indexing to predict potential impact. For example, even if tools like the previous sim.io (now Dune sim IDX) have limitations, they add assurances to the impact on integrations.
- For each feature introduced, we created some internal tooling to closely monitor the new parts of the system (e.g., v3.3 deficit invariants).
- Upgrade proposals themselves (the code and procedures/flows used to apply the upgrade codebase in production) are reviewed in detail by multiple parties.
- Even if difficult to quantify, it is highly possible that on BGD we spend more time in security and quality assurance of upgrades than developing the upgrade itself; and definitely way more time and resources are spent overall on coordination and execution of security measures than on pure development. This is natural and standard in highly critical software.
These measures, which are consistently improved as tooling becomes more and more mature, have helped keep Aave secure while also improving the protocol to keep a competitive edge in the ecosystem: for the last 3 years and 7 upgrades applied in up to 17 pools, there hasn’t been any major problem in the upgrades we proposed. As with everything security and development-related, the past doesn’t guarantee that nothing can happen in the future, but it gives at least an indication of how solid the upgrade procedures are on a relatively complex system like Aave.
Aave v3.X peripheral infrastructure moving forward
On the side of non-core protocol smart contracts, the case for keeping its development and improvement as it is at the moment is, in our opinion, very clear: all SPs and third-party contributors to the ecosystem have created and improved tools and procedures totally or partially targeting v3.X, so it is just natural to keep iterating on them.
Conclusions
- Aave v3.X is the biggest DeFi liquidity protocol and the main project of the Aave DAO, so we think its maintenance and improvement should be the top priority of the DAO in the foreseeable future.
- Aave v3.X and Aave v4 should be treated by the DAO as independent projects, not really understood as the continuation of the other, just different. If they converge down the line, this should just happen organically, but not forcefully. Aave v4 should NOT replace v3.X anyhow.
- Aave is a mutable system, and its mutability has only been positive historically. Hence, upgrades should continue to be proposed in a sane and responsible manner whenever adding value.
- We are fully confident in the procedures in place to execute the Aave v3.X maintenance and improvements in the safest possible manner.
- The rich peripheral infrastructure ecosystem surrounding v3 should continue evolving, aspects like price oracles optimisation, better risk measures (e.g., Risk Oracles), improved liquidations (e.g., Chainlink SVR), or all types of tools and visibility dashboards.