BGD. Leaving Aave

[bgdlabs]

Simple summary

We would like to inform the community with sufficient time in advance that, once our current engagement for services with the Aave DAO will conclude on April 1st, 2026, we will not be seeking a renewal and will cease our contribution to Aave.

In this post, we aim to transparently explain our reasons for taking this decision and how we plan to make our offboarding as seamless as possible for the DAO.

After 4 years, why leave Aave?

An Aave DAO <> BGD retrospective

BGD Labs was created in early 2022 to build in the DeFi/web3 ecosystem. Since then, we have been almost exclusively focused on our contribution to Aave: any technical sub-system of Aave that the community knows about, BGD Labs was leading its development, or at least participating/collaborating with other entities in it. That includes Aave v3, the “crown jewel” of Aave, that we have been (and are) continuously improving and expanding.

In our original 2022 proposal, we already disclosed our values and way of working: we believed in an organisationally-decentralised Aave ecosystem, one we thought we could be an important participant in. And the community saw our value, approving our initial scope, supporting us in our subsequent renewals, and, even more importantly, doubling down on the idea of organisational decentralisation, with more and more external/independent entities becoming Aave DAO Service Providers.

Back in 2022, on the Aave product side, we saw huge deficiencies that required addressing. But over time, almost all of them have been solved:

• The Aave liquidity protocol (v3) is in a very solid and future-proof state, requiring progressively smaller scale improvements.
• The Aave governance infrastructure just works, and can be used for perpetuity without any changes.
• All negative effects of the initial AAVE Safety Module have been removed, and we introduced a mechanism (Umbrella) to capture all positive effects of coverage.
• There are extensive operative procedures on “how to do things” on Aave, some created by us, some by others.
• Aave has not really stagnated; if anything, the total opposite, growing continuously within the DeFi ecosystem.

The current asymmetric organisational scenario

While the previous points to a potential bright future on the Aave <> BGD collaboration, unfortunately, the organisational scenario of the DAO has, during recent times, started to change radically. More precisely, as the broad Aave community knows, there is an ongoing alignment discussion due to Aave Labs pivoting from a role of an independent company building multiple products (Aave ones, non-Aave ones; prev. Avara Labs), to be a more central contributor on the Aave ecosystem with v4 and other proposed products.

While this pivot is totally legitimate and potentially positive to overall Aave, we believe the way of addressing it has been badly executed: Aave Labs believes that the whole Aave DAO and contributors should pivot in the direction they believe in, without sufficient consideration of existing contributors’ expertise.

While the DAO has built mechanisms to address this type of scenario, Aave Labs has a very strong position due to external factors: control of the brand and communication channels of “Aave”, and important voting power to actually influence major Aave DAO votes. We find those external factors very difficult to overcome while avoiding centralisation.

The unnatural disregard for the current products

A product of the previous organisational asymmetry is an underlying approach/vision that we believe is totally unnatural regarding Aave v3 and v4. Since, relatively early on the development of Aave v4 by Aave Labs, we started observing in communications a pretty big divergence on the why of Aave v4.
While initially our understanding was that Aave v4 would be a complement of a very mature and successful v3, over time, Aave Labs started to create what we think is a very aggressive of implicit criticism of Aave v3, to promote the new features of v4.

As we said and demonstrated multiple times in the past, we have never been opposed to the idea of Aave Labs contributing with a v4 version addressing different markets that potentially v3 would have more trouble with. But there are aspects on the way of doing it, that we don’t find reasonable:

• Promote v4 by implicit/explicit criticism of v3. No matter the virtues of v4, we have always found it very irresponsible to run a campaign for a new Aave sub-system by taking an adversarial position against not only the current production Aave system, but one that is the vast dominant of the DeFi lending market, even with running white-labels running on it. Especially because it is even debatable for a good part of the features how good the intended usage is, hence its existence on v4.

• Zero collaboration around v4 and v3 feedback. v4 is a product solely and exclusively developed by Aave Labs. And that means that the only exercises of collaboration have always been in pretty public terms: Aave Labs invites people to give feedback one-way, or “build on top”/”improve the system”, meaning:

  • They never asked if v3 could cover (or even was already) partially or totally v4 introduced features. Or if some of them would even be desired for other contributors potentially using them in the future.
  • Collaboration is in terms of Aave Labs having a scope and hefty budget for development, and everybody else advising them “for the sake of collaboration”.

  That approach is part of the problem. We, BGD, aside from having these past months plenty of work on the production systems of Aave, have never had any type of incentives to collaborate on v4. Because that work means contributing unpaid advisory to a separately funded initiative that was developed without broader contributor input.

• Total adversarial behaviour towards improving v3. Back in 2025, we published a document in this forum to give assurance to the community on Aave v3 being a strong system having pretty decent lifetime and improvement room, HERE.

  Unfortunately, instead of being a discussion regarding the maturity of Aave, the discussion degenerated in categoric criticism by management representatives of Aave Labs on continuing to improve v3, while trying to push on everybody to turn the focus on their v4; which months later, is not released yet. Together with highly subjective questioning of security risks on upgrades; very unreasonable to us considering that those upgrade procedures will be be required on v4, at least partially.

• Disregarding v3 and defining a deprecation timeline for it, while v4 is not even live. Aave Labs proposes, amongst plenty of other things, a deprecation timeline for v3 on their latest post, HERE. While starting with a call for action of not being too “aggressive” on the deprecation, the proposed steps couldn’t be more aggressive:

  1. On the initial step (now before the imminent v4 release), they propose to (obviously) keep doing maintenance and patches to v3, but already stop working on improving it: It also makes sense to pause any new features for V3 if this framework is passed.
  2. (Now too) This second step seems just a reiteration of the first, while v4 is not in production, and to orient all work of service providers to v4 V4 becomes the primary technology layer for expansion and innovation. This is already unreasonable, with active work streams to be deviated to v4 before it’s live, and not focusing too much on actually production Aave.
     But also, the idea of one entity simply telling everybody else to innovate exclusively on a system solely created by them is, precisely anti-innovation.
  3. Finally, (immediately after v4 launch for 8-12 months), basically deprecate v3, by V3 parameters should be gradually adjusted to encourage migration, following the same approach used in past version transitions. Which means making v3 parametrisation worse in order for v4 to “shine”. We believe even proposing this on the main revenue-maker & fully functional engine of Aave, is borderline outrageous; to hurt users with worse parameterisation in order for them to migrate to v4, not even a year before the new system is released

While all previous points that BGD should just keep contributing on the v3 side exclusively, the situation created makes it nonsensical to us: every time we think/will think about improving v3, there will be some type of implicit/explicit artificial constraint. We are not really interested in being in that position, as we think it is a waste of our potential.

---

In summary, we stop contributing because the environment no longer aligns with how we operate and where we see our value.

What happens until 1st April and forward?

As a general summary, we will try to make our off-boarding process as seamless as possible. And even if we will publish different documentation before the end of our engagement regarding the different projects, the following is a high-level overview of the path forward.

BGD’s current scope

On the side of our current scope, nothing changes until the 1st of April.

We have several contribution areas with ongoing projects (Aave v3, Umbrella, new chain expansions, assets’ onboarding, SVR, security), that we will continue moving forward until the end date of our scope.
For those with a finite development lifetime (e.g., a chain expansion, which finishes once activated; or an Aave v3 upgrade, which finishes once applied in production), we will either finish them before 1st April, or we will leave them in properly documented shape for other entities to carry on.

For projects of a more continuous nature, we will document the high-level work that is done, for the community to engage with some other entity to cover them, if desired.

Something important for the community to get assurance on. As we commented before in this post, we firmly believe the infrastructural components of Aave (e.g., Aave v3) are in a very mature stage, and we don’t envision any problem with them. That means that even if no improvements would happen, all other contributors should be able to keep moving products forward without any core change, no matter if slightly less optimally.

BGD-led projects’ future maintenance

For the project involving codebases, we have always tried to move them to the aave-dao Github organisation as soon as released, or when mature enough to do so without friction to contributors and integrators. This also means having appropriate documentation on what they contain, or how to use/improve them. For those, we think anybody with enough technical expertise and knowledge about Aave can be a future candidate to maintain them.

For other projects not really dependent on a codebase (e.g., governance reviews, evaluation of bug submissions, quality assessment of chains or assets, etc.), we believe they can be covered by new entities, no matter if qualitatively different from BGD Labs.

In any case, for all our standing projects, before our scope ends, we will publish guidelines for minimal maintenance requirements that can be used by the community to select other providers.

Future innovation on Aave by BGD

In what regards innovation on current and new systems that BGD could produce in the future, there is not really any direct off-boarding path.

However, we encourage the community to take seriously infrastructural innovation of the type BGD Labs has been contributing to Aave. We believe that in a quite broad ecosystem like Aave, continuous improvement and creation of user-facing and under-the-hood infrastructure is one of the main reasons for the success of the Aave DAO products during the last few years. When somebody asks, “how can Aave manage safely so many instances, products, and parameters?”, the answer is very simple: because there is a lot of work behind the scenes on all layers.

Transitional security retainer

As our role in security aspects is very critical and we don’t want our off-boarding to affect the protocol anyhow, we propose to the community a 2-month retainer model post-April, while the community organizes itself to handle a replacement of BGD Labs.

The model is the following:

• BGD Labs will be available for any security incident handling (e.g., reported to Immunefi) regarding the Aave v3/v3 protocols, Aave Governance, and Umbrella sub-systems.
• The duration will be from April 1st 2026, until June 1st 2026.
• Retainer cost of total $200’000 for the 2-months duration.

This security retainer will be proposed to the community as a standalone governance proposal, obviously, totally optional for the community to approve/not.

Next steps

• Our current ongoing scope continues without any disruption.
• During the following weeks, we will publish additional off-boarding materials of different projects where BGD is involved.
• In parallel, we will prepare an ARFC for the security retainer post-April.

[Tor_GAINS]

Really sad to see one of the OG DAO SPs stepping away, largely as a result of the Aave Labs shenanigans.

Thank you for all the hard work, dedication, and consistency you’ve brought to the DAO over the years.

[Ari]

@bgdlabs

We believe that in a quite broad ecosystem like Aave, continuous improvement and creation of user-facing and under-the-hood infrastructure is one of the main reasons for the success of the Aave DAO products during the last few years. When somebody asks, “how can Aave manage safely so many instances, products, and parameters?”, the answer is very simple: because there is a lot of work behind the scenes on all layers.

One idea that resonated strongly with me while reading this is that mature systems are defined less by how they react to incidents than by how effectively they make many of them never occur at all. High performers don’t merely recover faster from failures.. they invest in the layers of tooling, process, and architecture that quietly prevent entire classes of problems from emerging in the first place

This is why it can be so easily underestimated. Much of the work that enabled Aave v3 to scale across multiple instances, markets and risk profiles wasn’t user-facing.. and wasn’t meant to be. Its success is precisely that most users never had to think about it

Imho it’s only a matter of time before the DAO begins to feel the friction of losing this kind of compounding, forward-looking capacity. Mainly because the velocity and depth of innovation that v3 enabled was the product of sustained, anticipatory work.. not reactive iteration

Thank you @bgdlabs for the rigor, the long-term mindset and the infrastructure that made Aave feel stable while continuing to evolve. A large part of that value will only become visible in hindsight, which is often the mark of work done exceptionally well. Keen to see what’s next

[JosueMpia]

Ah what a sad read… What to say…

Thank you @bgdlabs for everything, Umbrella, the v3.6 upgrade, the Risk Steward mechanism, governance tooling, years of protocol maintenance and security work. The rigor and consistency you brought was unmatched. One of the most dependable contributors this ecosystem has ever had.

My most vocal take in this governance has always been v3 until 2030. We need an explicit, written commitment that v3 won’t be pushed toward deprecation in a way that pressures DAO members and users without consensus. I genuinely love v4, but I can’t in good conscience vote for it until there’s a formal agreement on v3 deprecation timelines, readiness criteria, security standards, and continuity obligations for v3. That has to come before any v4 mainnet launch.

If independent contributors feel sidelined by DAO-level centralization, maybe the answer is just structural clarity inside the DAO. Because this feels bigger than one team leaving.

I will wait for @AaveLabs response on this and go from there.

[Sisyphos]

BGD’s contribution to Aave over the past four years is undeniable. A huge portion of what today “just works” is the result of your engineering standards and infrastructural mindset behind it.

As someone that had the privilege to work closely with you, it’s genuinely bittersweet to see you step away. The rigor, long-term thinking, and production discipline you brought materially raised the bar for the entire ecosystem. Your absence will be felt across multiple layers of the protocol.

Transitions like this are never trivial, but the foundation you leave behind is strong. It’s also a pity that Aave v4 won’t get to directly benefit from your skills and experience. Thank you for the work and for handling the off-boarding with professionalism. Wishing you the best ahead.

[DTBAEE]

The shamelessness and greed of AAVE Labs and Stani led to all of this. The DAO should unite; it’s time to expel AAVE Labs and Stani. When AAVE Labs and Stani were fully engaged in developing Lens, it was BGD Labs who contributed version V3, allowing AAVE to continue developing to this day. Now that Lens has failed, AAVE Labs and Stani are greedily trying to squeeze every last penny out of the DAO—how utterly shameless!

We must expel AAVE Labs and Stani, otherwise they will only continue to harm everyone in the ecosystem.

[EzR3aL]

A day for the DAO to be remembered.
BGDLabs was crucial for the success of the protocol and governance.

There isn’t much else to say except much respect for the whole team and a big thank you.

[A_J]

Thanks BDG Labs. OG is always remembered and so will you.

Thanks for your contribution towards making AAVE multi billy.

[stani]

Reading Ernesto’s post this morning was difficult. For four years, BGD has played an important role in Aave V3’s technical development, and it is fair to say that Aave V3 would not be what it is today without their contributions. That Aave V3 has lasted this long in an ever changing industry is a testament to their dedication and craft. I am grateful for their work.

On a personal level, this is the end of a long chapter. I still remember hiring Ernesto back in 2018, right after the EthLend ICO. We were a small team with a big vision, and that spirit of collaboration is what made Aave what it is.

I respect BGD’s decision, though I am sad to see them go. The DeFi ecosystem is better for having a team like BGD in it and I hope they continue to build and make contributions to the industry.

For the Aave DAO, my (and Aave Labs) commitment remains the same. We will work with BGD as needed to facilitate a smooth transition during this period. I am in favor of their continued security and maintenance of the protocol after April.

Thank you, Ernesto and the entire BGD team, for everything you have contributed to Aave. I wish you the absolute best and hope we’ll cross paths again in the future.

Stani

[Gross]

​I just saw the news on X about BGD Labs leaving. This isn’t just a team departing; it’s a glaring indictment of failed governance and the collapse of the Aave ecosystem’s core ethos. The relentless ambition of Stani and Aave Labs to monopolize power and extract value is, unfortunately, consuming this project from the inside out.

​Let’s drop the political correctness: What we are witnessing right now is the Aave brand being held hostage, and a massive ~$51M sum being demanded from the DAO under the vague guise of a “Foundation” transition. While every other Service Provider operates with on-chain evidence, transparent reporting, and concrete ROI; Labs has zero audits and zero accountability reports for the $31.9M they’ve already received. Furthermore, attempting to cover up this lack of transparency by creating a false consensus through newly registered shill accounts on X and the forum is highly unethical. This behavior is exactly what alienated your most valuable partners and the community.

​My proposal is very clear and straightforward: If Aave Labs insists on indirectly extracting funds from the DAO, holding the brand rights hostage, and attempting to siphon value for years to come, the solution is simple. The Aave DAO should completely buy out Aave Labs (and all its IP/brand rights). If everything has a price, the DAO should pay it once, take full control, and rid itself of Labs’ never-ending cycle of extortion for good.

​I’ve said this before: If there is gangrene in a limb, you must cut it off in time. Otherwise, the infection takes over the whole body. The departure of BGD Labs is the ultimate proof of how much this gangrene has already damaged the ecosystem.

​Stani and Labs: History won’t remember how you started this journey; it will remember how you finish it. You have the choice to leave a legendary legacy as DeFi visionaries, or to be remembered as a cautionary tale of greed founders who destroyed their own ecosystem and drove away their best talent. Everyone sees through the game behind the “Foundation” mask. The choice is yours, but the DAO is finally awake.

[ApuMallku]

@stani

For the Aave DAO, my (and Aave Labs) commitment remains the same.

Your commitment to Aave has become a commitment to cannibalizing its value. This failure is 100% on your inability to lead. Aave is losing, regardless of the narrative you try to spin.

[DTBAEE]

AAVE’s current predicament is entirely your and AAVE Labs’ doing. Get out of AAVE! Your greed has hurt everyone.

[aviggiano]

As a security researcher and protocol developer, it’s been great to follow BGD Labs’ strong approach to secure protocol development. I hope these best practices continue to be upheld by the new service provider.

[lahes2ga]

No wonder $AAVE is one of the biggest losers in the last 24hours today on CMC. The first thing that came to my mind after reading this is Marc Zeller quote from the great engine room debate where he wrote this: “If the system stops being fair, and stops rewarding merit, the outcome is predictable. Talent will exit, quietly at first, then all at once.” Crazy to think it was just 2 months ago on Dec 23, 2025.

Thanks for the work fellas and best of luck in the future.

[_LP17]

It is with genuine sadness that I read this announcement.
I took some time before responding because the implications of this kind of departure are not trivial.

For many of us, @bgdlabs has been one of the foundational technical pillars of the DAO. You built and maintained what is today the core engine of Aave. V3 is not just a functional system — it is the primary revenue driver of the protocol and the backbone of Aave’s dominance in DeFi lending.

So I want to ask directly:

Is there truly no room for negotiation that would allow BGD to remain within the DAO under a clarified framework vis-à-vis @AaveLabs ?

Objectively, seeing a historical and critical provider leave is a very bearish signal for AAVE and for the broader ecosystem. Even if the technology is mature, losing a key infrastructure contributor weakens perceptions of stability and organizational balance.

I also believe it must be said: when a major service provider exits citing organizational misalignment and governance tensions, Aave Labs has a responsibility to reflect on that. A mature DAO cannot operate under a perceived trajectory of increasing centralization, even if the strategic pivot itself may be legitimate.

A solution must be explored.
Perhaps a clearer separation of responsibility between V3 and V4.
Perhaps an explicit neutrality commitment around V3.
Perhaps a structured mediation process between Labs and major service providers.

Allowing BGD to leave without a serious attempt at compromise would, in my opinion, be a significant strategic mistake.

Regardless, thank you and congratulations for the immense work delivered over the past four years. Your impact on Aave is undeniable and will remain part of its foundation.

[Millesimillia]

Responding to the previous post by @_LP17: Great comment! I did also not know what to say. You summarized it very well. Challenges are always the best opportunity to find better solutions. Why not making this solution finding process explicit/transparent. That would undoubtedly foster trust. Warm regards, Samuel

[joshuacheong]

On behalf of the Mantle team, we want to extend our sincere thanks to BGD Labs for their outstanding contributions to the Aave ecosystem and, in particular, for their direct support in the successful launch of Aave V3 on Mantle Network.

BGD Labs played a key role in ensuring the Mantle deployment met the highest standards of protocol security, reliability, and performance. Their deep technical expertise, clear communication, and disciplined engineering approach were instrumental in delivering a smooth and robust Aave V3 launch on Mantle, giving both users and builders strong confidence from day one.

Beyond execution, the team consistently demonstrated a long‑term mindset around protocol safety and maintainability, which is critical when bringing core DeFi infrastructure to new networks. Working with BGD Labs was a professional and constructive experience, and their impact on Mantle’s DeFi stack is tangible.

Transitions like this are never simple, especially when they involve teams that have contributed at such a foundational level. We wish the entire BGD Labs team continued success in what comes next and look forward to seeing their influence continue across the ecosystem.

Looking forward I remain extremely optimistic to the future of Aave in this transition.

[SaucyBlock]

Really sad to see BGDLabs leaving Aave. Your incredible technical leadership on projects like Umbrella, CAPO, and the multi-chain rollout made “Just Use Aave” more than just a slogan—it made it a reality.

Thank you for your incredible contribution. Wishing the team great success in your next chapter!

[Tor_GAINS]

Here are the latest words from AAVE Labs regarding the V3:

We have heard the feedback about the transition from Aave V3 to Aave V4. While we think it is important for the DAO to align strategically behind V4 as part of this proposal, the timeline is up for discussion. We will remove the timeline from the proposal and adjust the section accordingly.

Aave V3 is a battle-tested protocol, and it will continue to operate as a core part of the ecosystem for as long as the DAO decides it should.

• No changes to risk parameters, incentives, or capital efficiency are planned that would materially alter user behavior on V3.

• Existing incentive programs and planning around V3 markets will not be affected. Governance retains full discretion here.

If a V3 market serves a particular chain or ecosystem well, the DAO has the authority to keep it running indefinitely.

Could this change the decision of BGD Labs, or is it set in stone?

[bgdlabs]

To answer your question @_LP17 and @Tor_GAINS, our decision has already been taken.

Regarding the clarification you point out @Tor_GAINS about v3, we think it is a reflection of the type of conflicts that continuously arise, where something we believe very detrimental ecosystem/product-wise is proposed, then after very important backlash, is walked back.

Unfortunately, that has been continuous for a long time, and for us, it means wasted time and unpredictability, so our final decision.