BGD. Aave <> BGD Labs. Phase 5 recap

Development
1

phase5-recap
phase5-recap1920Ă—2296 385 KB


Summary

Recap of the 6-month continuous engagement for services between BGD Labs and the Aave DAO, starting on April 1st, 2025, and ending on September 30th, 2025.

Acting as a summary of all services and deliverables produced.



What has been done?


1. Aave protocol

The Aave v3 development continued to be one of our most critical contributions, with substantial progress on protocol evolution and new feature implementations.

We are especially happy with this workflow during this phase, with the v3.5 upgrade probably being the main item; a fairly difficult project, but internally improving the security profile of Aave v3 very substantially.

During Phase 5, the following major milestones were achieved:


Protocol Version Upgrades

  • Aave v3.4 activation. By the end of Phase 4, v3.4 development was very advanced. However, due to following a very conservative approach (splitting the upgrade into two), Aave v3.4 required certain reworking and was finally completed and activated during Phase 5.

    The upgrade focused on changing the model of GHO on Aave v3 Core to unify it with other assets, introduced different UX-oriented features to improve composability and integrations’ capability of the protocol (PositionManager, Multicall, etc), and multiple other improvements.
    A list of all features can be found HERE.

  • Aave v3.5 activation. After deciding to split the original v3.4 into two upgrades, with v3.5, we made deeper changes on the mathematical precision of the protocol through directional rounding (explicit rounding down for minting, up for burning), enhanced scaled accounting to reduce precision loss, improved flags handling, and refined allowance accounting for rebasing tokens.
    Now, the protocol is even stronger than before, precision-wise, an achievement we are particularly proud of, given the type of endeavor it undertakes to achieve this level of improvement in a production system like Aave.

    A list of all changes can be found HERE.

  • The Aave v3.X BGD’s Vision. We did a recap on the current state of Aave v3 in production, for the community to have visibility on how the system is very solid for the medium term, after all the v3.1-v3.5 upgrades.

  • In addition, during the following days, we will present to the community the ARFC for Aave v3.6.


Iterating on Aave <> Chainlink SVR

SVR (Smart Value Recapture) is a Chainlink sub-system integrated with Aave v3 that redirects non-toxic MEV from liquidations back to the DAO and users of the protocol.
Since the initial launch, SVR has been expanded, and currently is overperforming: it recaptures ~80% of the OEV, which, based on historic data of ~$50m OEV in 2024, would imply approximately $24m inflow to the Aave DAO, which highly possible would be enough to finance all Umbrella rewards, closing a feedback loop of sustainability.

In terms of our contribution:

  • We implemented an SvrOracleSteward that acts as a safeguard for Oracle changes, ensuring new feeds align with expected parameters and allowing a safe rollback if needed. It reduces operational risk and governance overhead when switching to the SVR oracle.

  • SVR Phase 2 activation on Ethereum. We expanded SVR beyond the pilot phase, adding all BTC-correlated assets on v3 Core (WBTC, cbBTC, eBTC) and all ETH-correlated assets on v3 Prime (WETH, wstETH, ezETH, rsETH), leveraging proven BTC/USD and newly introduced ETH/USD SVR feeds.

  • SVR Phase 3 implementation. Expanded the SVR by covering all ETH-correlated assets on v3 Core (WETH, wstETH, weETH, rsETH, osETH, ETHx, rETH, cbETH), as well as USDC, capitalizing on the improved Chainlink/Flashbots infrastructure and higher MEV recapture rates demonstrated in earlier phases.

Additionally, and arguably as important as the execution steps, we have closely advised Chainlink regarding the requirements for Aave on the SVR system, both on the current systems running in production and the future iterations/improvements.


Aave v2 Deprecation

  • Aave v2 non-Ethereum networks deprecation steps. We led the complete asset freezing of smaller v2 pools (Polygon and Avalanche) to reduce their sizes while maintaining non-invasive user operations (withdrawals, repayments, liquidations, and migration to v3 remain possible).

  • Aave v2 deprecation technical next phase. Advanced technical deprecation by implementing a 100% Close Factor for smoother liquidations (allowing liquidators to close entire positions instead of a 50% maximum).

  • Developed and deployed ClinicStewardV2 smart contract with constrained FUNDS_MANAGER role for systematic bad debt cleanup using Collector funds.


Whitelabel/Managed Friendly-forks Instances Development

The whitelabels’/friendly-forks workflow is new to this Phase, and required very important base work to simplify as much as possible the setup of upcoming whitelabels/friendly-forks like Ink’s.
Amongst others, this flow included:

  • All our internal preparations and planning to have a properly ordered setup and later maintenance of the instances.

  • The setup of the Aave v3 instance for the Ink Foundation, including development, activation proposal, procedure coordination, and all required ad-hoc advising to the Ink Foundation for later maintenance.

  • Permissioned Payloads Controller Contract: Different improvements on the PermissionedPayloadsController contract that will have infrastructural control on the instance: implemented access control changes, including preventing the guardian from modifying the delay before payload execution.

  • Aave Seatbelt - added support for the Permissioned Payloads Controller infrastructure and developed a CLI tool to generate reports for Whitelabel instances.

  • Aave Proposals v3: Updated the generator code to support the permissioned-payloads-controller, including the deployment scripts and related tooling.



2. Aave Umbrella

Umbrella enables users to stake aTokens to protect specific assets in Aave pools, earning rewards while accepting a slashing risk if a deficit occurs in the protected asset. Key innovations include slashing based on on-chain deficit data (rather than governance decisions), dynamic rewards via emission curves optimized for target liquidity, and improved capital efficiency for the Aave ecosystem.

At present, Umbrella’s TVL is $365M on its initial iteration, reaching the initially configured Target Liquidity levels on all assets (USDT, USDC, ETH, GHO). The current annual cost per dollar of coverage is $0.026, an 88% theoretical reduction compared to the previous Safety Module ($0.21). However, since the Legacy Safety Module remains active, the actual reduction is 43%, with an effective annual cost of $0.12 per dollar covered.

If considering total expenditure on Umbrella at the moment, it is approximately $9-10m, which, even if increased with extra networks and assets in the future, shows its sustainability when we compare with the recapture potential of SVR, also modelled to be in that order of magnitude.

  • We coordinated activation of the Aave Umbrella system.

  • Released the DAO-owned Umbrella UI interface.

  • Created a CLI generator for configuring Umbrella Rewards, allowing Finance Committee members to have a better and easier-to-use tooling.

  • We prepared Umbrella v1.1 to be shared with the DAO in the upcoming days.

Different contributors (LlamaRisk: methodology, post-launch insights and emissions update, reviews by TokenLogic, and Chaos Labs ) have published overviews of the Umbrella system until now, and how it has improved



3. Governance v3 and a.DI

Our focus remained on maintaining and improving the governance infrastructure, with particular attention to system resilience and emergency preparedness, and expansion to other networks.


Governance Infrastructure Maintenance

  • Deprecated VotingPortals removal. After new VotingPortals (proposal 273) were deployed, we cleaned up legacy governance infrastructure by removing old portals to improve system efficiency and reduce attack surface.

Fire Drill Proposals

  • We implemented comprehensive fire drill exercises to test emergency governance responses:
    • Ethereum VotingMachine fire drill. Conducted emergency preparedness testing by running a test vote directly on Ethereum instead of the usual Polygon/Avalanche to verify fallback infrastructure works.
    • Avalanche fire drill. Extended fire drill testing to Avalanche network governance systems, testing the Ethereum → Avalanche execution path.

a.DI Infrastructure

  • enabling support for Soneium, Ink, and Plasma, allowing cross‑chain governance proposals and execution on these networks.


4. Tooling


Migration of repositories to aave-dao

Governance, a.DI, a.DI deploy, and Permissions book repositories were moved to the Aave DAO organization.
Others more coupled in the ecosystem will follow, but being more of a hygiene task, whenever our capacity allows it.


Aave Generalized Risk Stewards (AGRS) Expansion

We significantly expanded the AGRS system across multiple networks, scaling automated risk management:

Additionally, a major simplification/unification of the Risk Stewards systems in collaboration with @ChaosLabs will be presented to the community soon.


Aave Robot Infrastructure

  • Robot maintenance and optimization. Performed a full maintenance update of the Aave Robot automation system, replacing outdated VotingMachine robots, registering new Stata Token reward robots, redeploying RootsConsumers, and migrating balances.

    Updated VotingChain robots and ensured continued support on networks using Chainlink Automation.


Permissions Book

  • We added Umbrella, GHO facilitators, and Permissioned Payloads Controller tables to the permissions book.

  • We migrated from ethers.js to viem, integrated the BGD toolbox, and refined decentralization tables to better distinguish multi-sig and steward roles.

  • We expanded support to Ink, Soneium, and Plasma, and enabled compatibility with friendly fork instances such as Ink.


Aave Address Book

  • Continuous maintenance.

  • Made bug fixes and improvements to the address book UI search algorithm.


Aave Seatbelt

  • Seatbelt underwent a major refactor to handle inter-proposal dependencies, simulate sequences of proposals, support pre-creation simulations (used on the permissionedPayloadsControllers), and enable simulations directly from Foundry (used for the Ink Whitelabel instance).

  • We also migrated from Tenderly forks to vnets, as forks were deprecated.


Aave Proposals

  • Updated tooling to support Whitelabel instances using Permissioned Payloads Controller infrastructure

  • Added support for seatbelt report for Whitelabel instances via proposals-repo.



5. Quality & Security

In addition to all other projects involving important security components (e.g. v3.X upgrades themselves), we continued our role as protocol security coordinators during Phase 5.


Network Technical Evaluations

We conducted comprehensive technical evaluations for candidate networks:


Bug Bounty Management

We maintained our role as primary coordinators of the Aave bug bounty program:

  • March 2025 Bounty Payout. Successfully managed and processed payments totalling $21,000 to ethical hackers and $2,100 to Immunefi for four valid security reports.

  • August 2025 Bounty Payout. Continued efficient bug bounty management with payments of $13,000 for two reports and $1,300 to Immunefi.


Protocol Security Coordination

As Aave protocol security coordinators, we handled multiple protocol safety matters:

  • SEAL Safe Harbor adoption. Coordinated with the SEAL team for SEAL’s Safe Harbor Agreement adoption, to provide legal protection and clear rules for white-hat hackers during rescue operations. Currently in final preparations for on-chain proposal.

  • fdUSD freeze and unfreezing. Participated in emergency response following temporary fdUSD depeg.

  • rsETH precautionary freezing. Implemented precautionary measures for rsETH following a bug in the contract that caused over-minting, recommending freeze, setting LTV to 0, and coordinating unfreeze after bug fix and excess token burn.


Asset Listings Technical Analysis

We conducted comprehensive technical reviews for numerous asset candidates:


Asset Pricing Model Upgrades:

  • LBTC and eBTC oracle implementations. As LBTC and eBTC turned into yield-bearing assets, we performed a technical analysis of upgraded oracles and price feed infrastructure, and implemented the necessary changes to the protocol.

Pendle PT Assets Integration:
Successfully analyzed and supported listings of multiple Pendle Principal Token assets:

  • USDe: 31JUL2025, 25SEP2025, 27NOV2025
  • sUSDe: 31JUL2025, 25SEP2025, 27NOV2025
  • eUSDe: 29MAY2025, 14AUG2025

Pricing Management and CAPOs

  • Pendle assets CAPO adapter development to implement the community-approved linear discount pricing model for PT assets.

  • CAPO Adapter Maintenance Update to update stable price cap adapters across all v2 and v3 instances to the latest version

  • To complement asset listing flows, we configured and deployed custom price adapters (e.g. CAPOs) whenever required.


Governance Proposal Reviews

We reviewed 110+ governance proposals during Phase 5, maintaining our high-quality technical review standards while supporting increased DAO velocity.



6. Miscellaneous


Strategic Policy Development

  • Friendly forks vision. Developed and published our strategic approach to Aave v3-friendly forks, outlining how to maintain quality standards, grant limited configuration rights, and ensure compatibility with the DAO.
    This complements the operational workflow itself, described in section 1.

  • Aave Asset Class Allowlist (AaCA). We identified the need for standardization of pre-listing procedures with regard to different asset classes. Then, we collaborated on the effort led by @llamarisk to set up the initial asset classes and a formalized framework to systematically analyse asset class evaluation and approval processes.


Ethereum Pectra Upgrade Analysis

Technical analysis of Ethereum Pectra upgrade impact. Provided a comprehensive analysis of how Ethereum’s upgrade affects Aave protocol operations, assessing risks and necessary adaptations.


Others (e.g. extra technical maintenance)



Conclusion

We think Phase 5 represents yet again maturation and responsible expansion for the Aave ecosystem. We think the ecosystem is now in a very optimal position across all its sub-systems, and fully prepared across layers to go forward on new directions (e.g. v4), while keeping a very solid current production base.


As usual, we thank the entire Aave community and fellow service providers who made our work possible and productive: @aci, @chaoslabs, @aavelabs, @certora, @tokenlogic, and @llamaRisk.

Also, special recognition goes to all governance participants and delegates who continue to drive thoughtful decision-making: @ezr3al, @sid_areta, @wintermutegovernance, @kene_stablelab, @0xkeyrock.eth, @ignas, @daoplomats.eth, @event_horizon, and many others who participate actively in governance discussions.

Most importantly, as always, we thank all Aave users whose trust and engagement make this work meaningful and impactful.

Just_Use_Aave.

15 Likes