The Aave v3.X BGD’s Vision

[bgdlabs]

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

@stani

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.

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.

@stani

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.

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.

@stani

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.

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.

@stani

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.

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.

@stani

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.

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.

@stani

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.

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.

@stani

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.

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.

@stani

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.

@stani

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.

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.