The Aave v3.X BGD’s Vision

Development
1

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.
25 Likes
2

First off, credit where it’s due: maintaining and evolving a system like Aave v3 is no small feat. BGD was instrumental in improving Aave v3.x almost in every dimenssion.

The plan to continue extending the v3 stack with new features, processes, and infrastructure, is imo very important. But if v4 is meant to be the next major step for Aave, shouldn’t we be channeling technical and community resources in that direction? Instead, we see a push to double down on what exists—without even acknowledging the potential costs of doing so.

Imo v3 and v4 should be seen as competitors, not complements. This isn’t just a technical fork. It’s two separate systems:

  • With separate liquidity pools

  • Competing for users, integrators, and risk teams

Every dollar that flows into a v3 market is a dollar that won’t reach v4. Every hour spent extending v3 is an hour not spent accelerating v4. Pretending they can grow in parallel ignores the zero-sum nature of liquidity and attention.

Is There a structural conflict of interest here? BGD has played a central role in the evolution of v3. But it’s also a service provider to the DAO. If BGD has the capacity to build complex extensions and infrastructure on top of v3, why aren’t they applying that same energy to contribute to v4? Or helping design a migration path? Or at the very least, outlining how the two versions can converge? That absence says a lot.

This “vision” reads less like a strategy for the protocol, and more like a strategy for BGD and others to maintain influence by keeping v3 alive indefinitely.

Yes, several providers have done meaningful work around v3. But are they now economically or politically invested in v3’s continued relevance over making v4 succesful? When incumbents rally together to defend the current architecture, it’s worth asking who benefits.

It’s time to stop treating “incremental improvement” as neutral. Every architectural choice is also a governance and strategic decision. Right now, the original post looks like we’re running two protocols, not one—competing for liquidity, and for developer mindshare.

5 Likes
3

Thanks for the contribution to the conversation @Frida, with very valuable points to discuss.

We will try to address our point of view on them below:


The plan to continue extending the v3 stack with new features, processes, and infrastructure, is imo very important. But if v4 is meant to be the next major step for Aave, shouldn’t we be channeling technical and community resources in that direction? Instead, we see a push to double down on what exists—without even acknowledging the potential costs of doing so.

There are multiple layers to the argument of Aave v4 being/not the evolution of Aave. But our position on that is not about making any type of statement that Aave v4 will never somehow deprecate v3, or that no resources should be allocated to v4. We are only saying that we and nobody knows at the current moment if/when that will happen, and that there is not really any type of need for v3 and v4 to become an exclusive selection.

More precisely, it should be obvious that the cost of maintaining the most successful product of the DAO at the moment is highly probably worth it. A product that, over time, has only widened the delta between higher revenue for the DAO, and costs not increasing substantially.


We understand the point of view of trying to analyse the implications to the DAO in this manner, but we don’t really agree with it.
v4 must organically be able to capture new market share that v3 is at the moment not currently accessing. That seems pretty obviously the main goal of a new DAO product out there in the same line as existing ones.
That makes them complementary more than some type of internal competitors.

Moreover, the v4 system is still in the final phases of development, so arguing it is any type of competitor to the production v3.X, is not reasonable.


There is quite a lot to unpack here, but:

  • v4 is an independent proposal from an independent team, not any type of joint effort by that team and current service providers from the start.
    It is up to that team to think about how the new system fits into the strategy with existing ones, not of everybody else currently working in the production systems of Aave to adapt all of those and other flows to a design that, frankly, they have not been participants in.
    E.g., we contributed Umbrella to the DAO, and it was our work to, before even starting the work, evaluate and be sure that the system was not conflicting with anything else, like the legacy Safety Module.
    v4 is slightly different, but still, there is no reason for us to, at the moment, put our energy into a system that we don’t even have full access to yet.
  • We are not saying anywhere of keeping v3 alive indefinitely, but the following:
    • v3 is and has been successful until now, so leaving everything else aside, it is not in a subordinate position with anything else.
    • v3 users need to have assurance that they will be able to use the system with maximum assurance for a long enough time. Forever? We are not defending that, but still, it seems reasonable for the interests of the DAO that stability must be guaranteed for some time.
      Even more, we don’t think the developers on v4 argued anything like the immediate deprecation of v3.
  • Our post is not even related to ourselves, BGD; it is about one of the products of our work, far from the only one. So, definitely an interpretation of its goal being some type of private interest is very far from reality.
    There are countless facts on why BGD is not trying to capture anything, but to name one, our service provider agreements are of 6 months duration, the shortest of any contributors, while arguably could be the longest. And that is on purpose to give flexibility to the DAO itself, highly possibly hurting the business interests of BGD.
  • The whole argument of non-DAO parties invested in v3 being relevant is pretty misdirected. The Aave DAO is interested in Aave products being a success, and definitely on its most successful product still being a success for the time required, no matter if other complementary systems are being built in parallel.

This actually outlines our whole post, but reversed: Aave is running 1 single (non-deprecated) protocol, not two: Aave v3.X.

3 Likes
4

Thanks for putting this forward and for the effort to outline a vision. However, I will be voting against if any such proposal is put forward. Aave V4 is the future of the protocol, and the DAO must stay aligned on this path for both strategic and practical reasons.

1. Aave V4 is the evolution of the protocol
Aave V4 is not a side branch; it is the natural continuation of the path from V1 to V2 to V3 to V4. It carries forward the same core functions as V3 but with less overhead, improved efficiency, and much greater modularity. The DAO has already recognized this by funding its development and confirming it as the protocol’s future. Splitting focus now risks fragmenting liquidity and confusing the ecosystem about Aave’s direction.

2. Migration and community alignment should follow precedent
With V1 and V2, the community aligned behind orderly migrations. V4 should be no different. If we fail to align, the result will be liquidity fragmentation, reduced DAO revenue, and negative consequences for both business development and users. The DAO’s BD arm is actively building relationships and attracting liquidity; introducing competition between V3 and V4 undermines those efforts.

3. Network effects and market positioning
Aave’s competitive advantage is built on deep liquidity and strong network effects. Fragmenting liquidity between V3 and V4 weakens this foundation and hands an advantage to competitors. From a BD and institutional perspective, a split roadmap signals indecision and makes onboarding harder. Partners want stability and clarity, not parallel versions competing for attention.

4. Upgradability at scale is a major risk
At Aave’s current scale, upgrading protocol logic directly is dangerous. Even minor errors can threaten billions in liquidity. On top of that, competitors already point to upgradability as a risk in BD conversations. Expanding V3 further through upgrades only reinforces that narrative. I will only support upgrades for essential bug patches; anything else is too dangerous.

5. DAO accountability and treasury efficiency
The DAO has already voted for V4 and funded its development. Continuing to invest in V3 beyond maintenance undermines governance credibility and wastes treasury resources. Every dollar spent on V3 is one not spent accelerating V4 adoption, integrations, and ecosystem growth. The DAO must respect its prior decisions and maximize the value of its investments.

6. V3 is not deprecated overnight
This does not mean V3 is deprecated immediately. It will remain active until liquidity migrates to V4 hubs. But strategically, the DAO must commit to building forward into V4, not sideways into V3. V3 should be safely maintained for users, while development energy goes to V4.

7. Continuing development of V3 is a distraction
If BGD introduces proposals to continue developing V3 in a way that competes with V4, I will vote against it. The DAO already paid for V4, and supporting V3 in parallel undermines that investment. Resources are better spent supporting builders and other SPs expanding V4’s modular ecosystem, which is explicitly designed to enable innovation from multiple providers.

8. Security and operational complexity
Maintaining multiple active versions increases the security surface, auditing needs, and operational complexity. Oracles, risk parameters, and liquidation systems all become harder to manage when liquidity is split. A unified focus on V4 reduces these risks and keeps Aave more resilient.

9. User and brand confidence
Users and partners expect clarity. A split roadmap creates confusion over which version is the future, undermining trust and weakening Aave’s brand as DeFi’s innovation leader. Aave has always been strongest when it moves forward decisively as one community, and that must continue with V4.

10. Time for unity around V4
Aave’s success has always come from united, orderly evolution. V4 is the next step in that journey. Its modular design will create significant opportunities for SPs, integrations, and innovation, while providing a safer and more efficient foundation. Dividing resources between V3 and V4 will only slow progress and weaken the DAO’s position.

For these reasons, I will vote against if any such proposal is put forward. The DAO has already chosen V4 as the protocol’s future, and now is the time to align, consolidate, and build together.

16 Likes
5

Hello,

im rather keeping it short, as I think the majority of people understand the ongoing path.
V3 is not going anywhere soon, its staying here as the backbone of liquidity and DeFi. It has been king because of its upgradability features which introduced liquid eModes, allowing you to max your borrow position on different assets.
VCs and other individuals as well as people delegating to me have not once mentioned a problem with this.
In my opinion software needs to be upgradable in certain areas to mitigate risk and introduce great features, while others for sure can be immutable. Both have their benefits and their trade offs.

If v3 is ever going to loose its spot as the no.1 defi protocol its because v4 has taken it, not a competitor. When this is going to happen, no one can tell, as each user has to decide if he wants to move on or stick to v3.

Ressources should and will be used in an efficient manner, all DAO SPs are experts in their vertical and won’t be wasting it. But for as long the majority of TVL is on v3, it should be maintained like right now to not put any user funds at risk. Because this is the most important feature of Aave and the most important for me as a delegate and user.

3 Likes
6

I agree with @EzR3aL. V3 will remain dominant for a while before V4 proves itself and naturally attracts liquidity.

2. Migration and community alignment should follow precedent. With V1 and V2, the community aligned behind orderly migrations. V4 should be no different.

V3’s rollout was cautious: L2 first, stress-tested, then deployment on mainnet. Only after proving itself did it replace V2. V4 deserves the same process and until it’s battle-tested, halting V3 upgrades makes little sense to me.

3. Network effects and market positioning. Aave’s competitive advantage is built on deep liquidity and strong network effects. Fragmenting liquidity between V3 and V4 weakens this foundation and hands an advantage to competitors.

Yes, liquidity fragmentation is a concern, but this isn’t V3 vs V4. The DAO already chose V4 as the future - I voted for it. Still, V3 is our current engine and we should maintain it. Yes, avoid major refactors, but keep adding features that drive growth, not only critical security patches.

9. User and brand confidence. Users and partners expect clarity. A split roadmap creates confusion over which version is the future, undermining trust and weakening Aave’s brand as DeFi’s innovation leader. Aave has always been strongest when it moves forward decisively as one community, and that must continue with V4.

There’s no split roadmap: V4 is the future, V3 is the present. V3 must stay competitive until V4 is ready to lead.

4 Likes
7

Hello,

At the @ACI we don’t even understand why there’s a debate here.

  1. V4 is several months away; this is not in any capacity a “now” topic. Service providers were informed of the v4 codebase literally only days ago.

As the elected BD service provider of this DAO, we are the main DAO arm and factually most growth come from our work and @TokenLogic exclusively for the past 3 years.

we can’t grow something that doesn’t exist yet. The statement makes no sense to us, and we have our own voice; we will use it directly and need no one to speak on our behalf.

We will continue to do what we’re paid to do, and that is growing the products currently in prod of the Aave DAO.

  1. V3 is the largest defi protocol on earth, freezing improvement and development is doing a favor to competition that won’t casually sit on a bench while v4 gets ready.

  2. This DAO and the community are very well aware of the state and quality of codebases delivered by Aave Labs in the past, V3.0, GHO, all of which required significant improvements to be market-ready. if there’s a V4 “flippening” it won’t happen realistically before the later stages of 2026. Halting improvement of the largest part of aave is simply unwise.

We are witnessing a trend of an overly defensive approach by Aave Labs to contributions from neutral and high-value added service providers, to the point of violating the neutrality doctrine and voting directly in their own interest as a company (an unprecedented and frankly unwelcomed behaviour), as seen in the Horizon vote and the current threat expressed in this thread.

We suggest moving away from a zero-sum mindset, as everyone involved benefits directly from the Aave DAO’s success in general. V3 thriving will only give better grounds for V4 to bloom when the time is right.

6 Likes
8

Thanks for participating in the discussion @stani, some comments about your points.

First and probably most important aspect: this is not any type of proposal, there is nothing to vote about. It is simply how we see the system we have developed and maintain via proposals to the DAO in the future. A vision that we believe is very necessary in an ecosystem like Aave.

Additionally, as previously noted, we are not suggesting that v3.X should be indefinitely developed, that there should be X amount of upgrades, or even that we BGD, should do any of that.
We are just saying that immediately/categorically stopping improving v3 is totally unreasonable, given the stakes and status quo, and that everything is simpler if understanding v3.X as a independent product compared with v4; nothing else.


The DAO has, of course, approved the development of v4, but there was no type of proposal to change the focus of all SPs into it, with the system not even being public, and while there are so many projects being worked on by all contributors.
In the future, that is probably a discussion to have, but that is not even the goal of our post.


v4 was designed to create liquidity fragmentation from v3 by design, by being a separate instance.
We can understand the arguments for deciding so, and that was not really even anything belonging to our vision, but:

  • Defending a position of v3 creating fragmentation from v4 is currently very far from reality. The new system that will start from scratch is v4, not v3.
  • The DAO BD arm is working, highly possibly more on growing the current Aave main product than the new one, and that is perfectly normal cc (@aci, @tokenlogic).
    Definitely, that has been the case during the past years until today, as for very obvious reasons, BD was/is focused on the most successful product and revenue-generator of the DAO; v3.X.

Similar argument as before, the case exists for exactly the opposite: not doing fragmentation with the new product, instead of being the current ~$70b v3.X instances creating the fragmentation.


We have explained how upgradeability is managed in the safest possible manner, and there is not really much to add to that. It is outside of our contribution line, but there are countless arguments to explain to partners why mutability is net positive when exercised responsibly.

This categoric approach is also very contradictory for us, as it is @AaveLabs who chose to have Horizon (an institutionally oriented instance) as an upgradeable system and the Aave DAO controlling that upgradeability.


There has not been any type of decision to not spend resources on making v3 as good as possible, and qualifying having the most solid system as “wasted treasury resources” is, at best, misdirected, at worst, dismissive not only of our work, but that of all other contributors.


BGD has a mandate to build the best system possible on v3, and again, we are not saying that v3 should be completely revamped anyhow, but just doing incremental updates whenever deemed suitable. Even more, we think that realistically, there should not be even so many changes down the line, highly possibly aligning with v4 going into production.

Of course, opposing categorically and systematically to any update is legitimate in this decentralised community, but we think far from recommended if the goal is collaboration and decentralisation.

Finally, qualifying as a “distraction” to maintain the highest quality, the biggest DeFi protocol doesn’t sound too reasonable. By that argument, the distraction is precisely not putting resources into doing the main product of the DAO as good as possible.


The reality is that v4 has been unilaterally designed and developed by @AaveLabs, without making participants other SPs on very important preliminary decisions like whether the new instance path was the best approach, upgradeability itself, future roadmap, and all other debatable aspects. But again, that is not even the topic of discussion here, as we have assumed the coordination will happen in the very last stages pre-release.

But in parallel to the work of @AaveLabs, all other SPs, including us, have been continuously improving v3.X to allow users of the protocol to make it the success it is nowadays.
So, stating now that improving the current system is somehow not going in the direction of unity is very far from reality.


11 Likes
9

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:

  1. Virtual accounting: There has never been virtual accounting before in any iteration of Aave. This basically goes back to Aave V1

  2. Stable rate removal: Stable rate was inherited from Aave V1 and is not inherent to V3.

  3. Precision: The precision dynamics in V3 were inherited from Aave V2.

  4. 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.

13 Likes
10

Honestly, watching this governance thread unfold feels like déjà vu from every DAO growing pain ever — except here we’re talking about AAVE, the protocol that literally carries the highest TVL in DeFi. I’ve been around since the LEND days, so yeah, it’s kind of painful to see the DAO slipping into what looks like a never-ending SP vs. Aave Labs “measuring contest.”

DeFi has already passed the phase where Twitter drama and forum ego battles should dictate multi-billion-dollar treasury and protocol decisions. AAVE should be setting the bar for DAO maturity, not reenacting high school cafeteria dynamics.

If everyone truly has the protocol’s best interest at heart (which I believe they do), then there are only two solutions: either everyone chills TF out (ngmi otherwise), or — more constructively — SPs and Aave Labs commit to a structured, in-person DAO retreat. A physical room, no pseudonym shields, no posturing. Just builders and stewards hashing out what the AAVE vision actually is for the next cycle.

Because let’s be real: if AAVE governance degenerates into endless he-said-she-said threads, the market will notice — and TVL can walk faster than it arrived. We’ve all seen it happen.

So yeah, let’s stop the dick contest, roll a governance offsite, and act like the protocol with the biggest balance sheet in DeFi. Wen DAO retreat?

10 Likes
11

Hello,

I think some of the previous replies speak for themselves and confirm some of my statements,

With the ACI we will remain strictly professional and maintain our focus on the job we’re paid to do since the before the first day of Aave V1 and under our current entity for the past 3 years to grow the protocol and its revenue at the benefit of the Aave DAO and the Aave token holders.

Our results speak for themselves and we don’t feel any need to participate in any form of escalation.

4 Likes
12

As the elected BD service provider of this DAO, we are the main DAO arm and factually most growth come from our work and @TokenLogic exclusively for the past 3 years.

Hello, and thanks for sharing your perspective. I want to clarify a few points, as some of the statements could be a bit misleading.

First, I personally think that ACI has done a great amount of work on the growth side. That said, saying growth has come “exclusively” from ACI and TokenLogic (who have been doing incredible work growing GHO across multiple networks) over the past three years is not the full picture. As a DAO, growth is driven collectively, anyone can and does contribute. Even Aave Labs has also supported growth in meaningful ways. For example, the recent Metamask deal in collaboration with TokenLogic started from a whiteboarding session with the Metamask team last year. This was an example where Aave Labs put the DAO first, even though the integration conflicted directly with the Aave interface experience.

There are also large institutional players like Galaxy Digital (NASDAQ: GLXY) and BTCS (NASDAQ: BTCS) that have been major borrowers with contributions from Aave Labs. ACI has done strong work on Ink/Kraken, but these relationships also show the DAO-wide effort is needed where I had to be personally involved. This is not about me or Aave Labs, but simply to underline that growth is a DAO-driven effort, where everyone who contributes, from writing code to taking meetings, is adding value, and the success should not be credited to any one entity. For the DAO to consistently win deals and integrations, it is important that all service providers contribute to the common effort, since in most cases each brings unique expertise to the table that helps close opportunities.

Regarding the comments about code quality: it is not clear what that refers to and seems very offensive even. Aave Labs has developed and delivered codebases that are still the production basis of today, of course some improvements made over time. The reality is that upgrading existing codebases with tens of billions of dollars at stake introduces significant risk. This is a key factor for decision-makers when choosing which lending protocol to partner with, and it can put Aave at a disadvantage while competitors consolidate. Personally, I am not comfortable supporting such upgrades unless its absolutely mandatory (as we’ve done before), as the consequences can be unprecedented and devastating.

This is why it is important to focus efforts on the evolutionary path to V4, while maintaining V3 in a safe and stable mode until migration is complete. In fact, V4 is flexible enough to cater to both setups at the Hub or Spoke level if the DAO truly wants that optionality and users then can decide what to opt-in.

It is unfortunate that within the DAO there is sometimes a culture where contributors feel they must be overly vocal or protective of their work so others don’t take advantage. The reality is that this should be a collective effort, not a zero-sum competition. No one is saying V3 disappears the moment V4 launches. V3 will remain live until liquidity migrates. The key shift is moving V3 into maintenance mode, especially given the high stakes, and directing development energy into V4 so it can gain lindy and become the foundation for the next phase of growth that our growth-focused service providers can then spearhead.

It is time to unite across all fronts. Aave has always been strongest when the DAO moves forward together. V4 is the future, and aligning behind it ensures we keep Aave’s leadership position while still respecting the important role V3 plays in the transition.

21 Likes
13

To continue on a more constructive discussion:

I feel that to express a thorough opinion regarding both @bgdlabs and @stani’s comments, i need more information as some details are unclear since the beginning.

  • I agree that Aave V3 is an amazing protocol and we are here today because of it, and BGD’s improvements made it even better (who ever said otherwise?). I do not agree that V4 is not to be considered an upgrade of V3 though: it is yes much different, technically speaking, but functionally it is an upgrade and a massive one as well - in the sense that improves upon the original capabilities of Aave, doesn’t drastically change them (like a different model, for example segregated liquidity pools, would). This is not an opinion but a fact, and should be universally recognized across the DAO to position V4 accordingly.
  • I agree that V3 should definitely continue to operate alongside V4 for the short to medium term, but the original post by BGD doesn’t provide a possible timeline which in my opinion creates confusion. What timeframe are we talking about here? I feel like dismissing V3 in 3 months or 6 months from the V4 release would be counterproductive and probably not possible at all, the DAO could probably begin with the standard operations that are usually enacted to facilitate protocol migration (lowering some supply caps and ltv of higher risk assets first for example) after the 6 months mark with more aggressive operations (increasing RF, decreasing LTV of safer assets) at the 1 year mark. This would be perfectly reasonable to me, and even with that i think V3 will still live on for a very long time. Which is great, because V4 being completely new will require a bit of a longer timeframe to acquire the required lindiness.
  • If the goal instead is to keep V3 alive forever and somehow make it compete with V4, then i do agree with stani - that would be a massive waste of resources and ultimately would not benefit the DAO in the long term. I am not sure that this is what BGD is proposing, probably not, but when i read the original post i can potentially interpret it that way. To be clear, i have no doubt that V4 will outcompete V3 (and again, this says nothing about the quality of V3 or the work that has been put on it, i am simply confident on V4 capabilities). Still, not redirecting to V4 the same amount of technical, BD and growth work that was done for the previous iterations would be a mistake, and definitely hamper its potential. And nobody would want that, hopefully.
  • Same though process on contract upgrades: most of the community probably knows i am not a big fan of upgrades, because no matter how good you are, there is always the potential risk, even as small as it can be, of introducing regressions that can be devastating. So the decision to upgrade or not is always a risk/reward decision: does the improvement outvalue the potential risk, even extremely low, of making a mistake? I would say for the upgrades BGD applied until now, that answer was yes - and Aave greatly benefited in general, with a more efficient and stable protocol. But if you have a newer protocol iteration running in parallel, with more capabilities right off the bat, does it make sense to keep upgrading the old one? and what’s the goal there? Potential fixes? then yes, sure. Add new features? then probably not, and that energy would be better spent on the new one. Plus, let’s say V3 stays fully functional (no migration oriented changes in risk params) for a year - how many upgrades in that timeframe are we talking about? 1? 5? 10? We need more information here.

ultimately, i am in favor of a graceful and organic transition between protocol iterations (even more graceful than the past given that V4 is completely new) which to be honest would be nothing different that what already happened in the past, but definitely against any attempt to create two separate product lines. Answers to the questions above will help me understand which one is which and orientate accordingly.

EDIT: Forgot to answer to this part

While the original design was yes proposed by Aave Labs, it was voted positively by the community. This is important - nobody is trying to force V4 on the DAO, the DAO voted and paid for it. All the debatable aspects BGD mentioned are in fact still up for debate, and will ultimately be decided by the community:

  • the deployment structure will be decided by the DAO risk managers (they have been already introduced to the codebase and will have an in depth primer on V4 risk management in the next couple of days as mentioned by the latest V4 community upgrade - so that they can start with the work accordingly).

  • Before the deployment, the DAO will vote on whether to use upgradeable or immutable contracts.

  • Future roadmap is honestly up for grabs - Aave Labs has some ideas on what to build on top of V4 already, but one of the great things of V4 is that will finally reopen the design space and give more possibilities to build on top. It would be nice if everyone would start thinking about what to build to maximize its potential.

16 Likes
14

Great points. Everyone is watching … competitors are watching… so.

15

Gm,
I think we can agree on some things here. @bgdlabs, @ACI and @Emilio have the same things in mind. Pushing Aave to greater levels.
There are on both sides a lot questions I assume.
The DAO is likely very eagerly awaiting docs. Right now it’s hard to understand how SP will work with Aave v4, even if there was a demo or code preview. In order to properly prepare a launch everyone must be able to prepare accordingly. Releasing the docs upfront to the DAO definitely makes the path clearer and easier to work on it.
As long as this path is unclear it’s likely going to continue working as it does today.

Additionally I don’t read @bgdlabs comment as there will be infinite new features, upgrades, etc for Aave V3. More like keeping the system alive, improving small things and making sure it’s always safe to use.
And again I do not think anyone wants to waste time or ressources. Nor did any SP anything like that in the past. Just look at what everyone has done and where the DAO is today.
The more we move to the release of V4, the clearer the path will be. And when it’s there hopefully every SP was able to prepare themselves and then see how the migration will work.

4 Likes
16

Thanks @Emilio for the very constructive feedback, which definitely raises some important points. We will try to address our view on them.


Our initial post section regarding the status quo regarding v3 and v4 is essential that gets interpreted as at the current moment. It means that we simply say that v3.X and v4 should be interpreted as independent development lines in the short/medium term, depending on 1) the release schedule of v4 and 2) obviously any DAO decision going forward.
For how much time do we think they should be understood as independent? We didn’t put any type of exact timeline because we believe it is simply very uncertain, with various variables, and it still depends totally on the organic growth of v4.
We don’t really see any scenario where, let’s say, after 1 year, the DAO doesn’t decide to prioritise v4 if that’s the desire. Because that would have meant that during 1 year v4 didn’t show success, or that its features didn’t fit with the market, which we have no reason to think it is the case.
Moreover, in some type of optimistic scenario, it could be that soft steps prioritising v4 instead of v3 could start way earlier, e.g., 6 months after v4 release, or any shorter timeline. Our points are more that:

  • Nobody knows the timelines at the moment, because v4 is a new system finishing development.
  • No type of aggressive migration should happen any time soon, because that would hurt Aave.

And to insist again, we are not even saying that during the whole next year the DAO should prioritise new features on v3, we actually think it probably shouldn’t.


To be more explicit on this: we are not saying that v3 should live forever, and it should compete somehow resources-wise or anyhow else, with v4.
Just that both in development stage and resources-wise, they are very independent at the moment and users of Aave should understand clearly that v3 is perfectly fine at the moment and ready for the future. Then v4, bringing new features and capabilities, is just value added.


It is not really possible to say exactly what will be proposed to be added to v3 for multiple reasons, but it is possible to give some extra light from our side:

  • We really think v3.X at the moment is very mature, and any upcoming upgrades (if not related to security patches, which none are pending) should be way more “light-weight” than almost all previous.
  • We have no intention from BGD of proposing new major features for the running v3.X. Aside from “light” changes to simplify configuration of the pool, almost everything else can be done on top of v3 if required.
    Sure, that could change if DAO decides the opposite, but that is the current status and our intention.
  • We simply can’t say the number of upcoming v3.X, as even how changes are split is not something we can predict. But we can be very pretty categorical that a scenario of having more than e.g. 3.7 or v3.8 is something we don’t imagine. And those upgrades will not be even comparable in complexity with all the pre-v3.5 ones.
    Once again, and we want to be very clear on this: nobody knows what may be needed in the future, so what we are very firm against is about setting some type of red line of the style “Aave v3.X must never go over 3.8, 3.9, or whatever”. It is just that the chances of that are probably zero.
  • We obviously need, when contributing to v3.,X a minimum vote of confidence that what we propose to add makes sense. No major change got historically proposed to Aave v3.X that didn’t have a very solid rationale behind it, in terms of security, go-to-market, etc. And really balancing complexity versus returns.
8 Likes
17

**Nice, **
I read that post yesterday and I appreciate all the clarifications here, it makes things a lot clearer how v3 and v4 should be understood in the short/medium term.

One thought I wanted to add: if we look at Uniswap’s path, v2, v3, and now v4 all co-exist and still hold billions in liquidity. Each serves different user needs and risk profiles, and the market has shown there’s room for multiple “different” versions to run in parallel for a long time. No one really sees an issue with that, Uniswap v4 has its own role and user base and it still needs time to build trust and adoption, **I imagine Aave’s path with v3 and v4 will play out in a similar way in terms of user adoption.
**
In that light:

  • Aave v3 remains stable and trusted, especially for users and integrations that prefer gradual change. Light upgrades can help keep it healthy while adoption grows.

  • Aave v4 over time will become the main focus as the ecosystem shifts toward it. Maybe by the end of 2026, v4 will really start to show its dominance, but for now Aave v3 remains essential. That’s why It would be great to see a clear proposal on when key milestones are expected and how much support is needed. For example:

    • January 2027: Maintain Aave v3 with light upgrades, no major changes.

    • Mid-2027: Begin soft unwind for v3.

    • Early 2028: Start heavily encouraging adoption of v4 for new users and features.

    • End of 2029: v4 shows meaningful TVL and ecosystem adoption, while v3 is officially deprecated.

    Having something like this would help everyone in the DAO align on expectations and timelines.

Just my 2 sense, excited to see how this plays out :rocket:

2 Likes
18

Hello,

A few thoughts after reading.

I don’t know the fact, even if it’s as you said, it only proves logically that you have been in the industry earlier than he does. If you are using this to prove that you are right and better, may I ask you the teachers’ names of Da Vinci or von Neumann or Alan Turin?

So objectively, we should follow the principal that in knowledge, there is no hierarchy; the one with true understanding should lead.

After reading the whole post, I have impression that you keep referring to things happened years ago. There is an ancient oriental proverb “ don’t live on past success, real strength shows in the present”.

2 Likes
19

This is great clarification and happy that i understood the initial post the right way. I am definitely onboard with the strategy outlined by BGDLabs and excited to see things coming to life in the next months. I also understand that given the context it’s not possible to give precise information in regard to upgrade and timelines but the scenarios provided here are more than reasonable. To be honest i believe that this was a misunderstanding since the beginning - there was never any intention, by Aave Labs, to try and push for an immediate offboarding of V3 - that would be unwise and outright dangerous - rather to coordinate for a graceful and organic migration, and give V4 the time to acquire enough Lindy while progressively shifting focus once V4 proves itself. We will do our best to improve communication and try to do things as transparently as possible while we approach the final steps towards the V4 release. Tomorrow risk primer call for risk managers is a great second step after the official code introduction, and would be nice to have as many participants as possible - i expect a nice and organic discussion around the launch configuration for V4.

11 Likes
20

The statement of Emilio is very candid and pragmatic! :+1:

Is what’s stated here the consensus opinion and conclusion inside of @AaveLabs ? :winking_face_with_tongue: for instance, my statement only represents my personal opinion.