Summary
Recap of the 6-month continuous engagement for services between BGD Labs and the Aave DAO, starting on October 1st, 2024, and ending on March 31st, 2025.
Acting as a summary of all services and deliverables produced.
What has been done?
1. Aave protocol
The Aave v3 side of our contribution is highly possible the most critical one and the one with the slowest pace, as both development decisions, implementation, and security procedures are substantially more time consuming than other product lines.
During Phase 4, the following was done:
-
With v3.2 activation happening at the end of our Phase 3 engagement, the first months of Phase 4 had some minor focus on v3.2, even if not in development stage, more in the maintenance and support side, for example advising all other SPs on how to properly change procedures and proposals for the new concept of Liquid eModes.
-
Development/activation of v3.3. We developed and led v3.3 to full activation in production across all networks, with all complementary procedures and tooling adaptations required.
-
Development of v3.4 up to ARFC. We batched in a v3.4 upgrade multiple features that we didn’t want to include in v3.3, plus some extra features that we came up with after the v3.3 codebase was frozen for activation.
The code is now fairly finalised, awaiting the final pre-approval of the community and then security procedures.
-
Additionally, we have worked on several internal improvements, that could fit in future upgrades.
-
Aave <> Chainlink SVR. First, adding priority to the idea of an OEV-protection mechanism for Aave, after collaborating on the requirements and analysis stage, we collaborated with Chainlink to enable the SVR system on Aave v3, currently in its pilot phase, enabled for AAVE, LINK, tBTC, and LBTC.
-
Expansion to new networks. During this period, Aave has expanded to 3 more networks with another pretty ready for activation (Mantle), a slightly faster pace than before, but still not compromising the quality of procedures and their improvement.
Our role is all-around on the proposal side that later on the community approves, and also supervising/coordinating with other contributors. -
StataTokens v3: waTokens (wrapped aTokens). We created a new version of the non-rebasable Aave v3 aTokens, currently in use as part of the infrastructure of multiple systems like Balancer or Synthetix.
-
Aave v3 fuzzing suite. We engaged and collaborated with Enigma Dark on the creation of a fuzzing test suite for the Aave v3 protocol, this way having the codebase covered by unit/integration testing, Certora’s formal verification, and fuzzing.
-
Aave Collector improvements. First, supporting other contributors working on it (KPK, Tokenlogic), then moving the final steps until the proposal goes forward, we contributed a Collector adaptation to allow having multiple entities with funds admin role, this way opening for Finance Stewards smart contracts, with constraint/granular control on the Aave DAO treasury.
-
Aave Clinic steward. To enable the DAO to clean with its funds bad debt historically accrued on the v3 protocol, we created the Clinic Steward smart contract, a smart contract with constrained access to Collector funds and isolated permissions to clean bad debt of Aave.
Additionally, we supported the entity running the bad debt “cleanup” in all off-chain components, like sourcing all positions with bad debt, or any other operational details. -
GHO Direct Minter. To enable the expansion of GHO to Aave v3 Prime with minting capabilities by an entity associated with the DAO, we developed/proposed the GHO Direct Minter design.
2. Quality & Security
Another field of our contribution is concerning the overall quality and security procedures around Aave. That includes deep down internal security research that later on reflects on candidates’ features, decision-making, technical analysis assets listings, governance proposals reviews, bug bounty management, and multiple others.
The following is a list of everything we have worked on during this engagement:
-
Candidate network technical analysis. We did three technical analysis of candidate networks, two of them already active.
-
Governance proposal reviews. We reviewed approximately 100 governance proposals, of all types and complexity levels, from all the community contributors/Service Providers.
-
We substantially improved our internal monitoring of the protocol.
-
Aave bug bounty. We reviewed tens of Immunefi submissions and managed the resolution of the valid ones via the Request for Bounty Payout procedure:
We are glad that during these last 6 months, only six finally valid reports have been submitted, leading to an aggregated disbursement by the DAO of $82’000, plus Immunefi fees.
-
Candidate asset listings technical analysis. Aside from some others currently being worked on, during this period we have done technical analysis of multiple assets candidate for listing on Aave v3.
Something we have noticed is that as DeFi reaches maturity, the technical complexity of the assets living in DeFi increases, which led us to substantially change internal procedures and reports. For example, we always go the extra mile of not only verifying that an asset is safe for the Aave protocol, but also suggesting improvements to the teams behind the asset. This way, the Aave DAO gives very important technical value to them, and maximises the importance of an Aave listing.The following is a list of analyses we did:
Being a relatively lengthy procedure depending on the asset, we also have multiple ones started, but not yet published until ready.
-
Aave Guardian. We act as technical coordinators of the Aave Guardian, to give as much visibility for decision-making on emergency actions of the protocol.
Aside from this continuous role during all incidents during these 6 months, we also proposed to governance the migration to the current Protocol + Governance Guardians, splitting more involvement depending on the criticality to the Aave system.
3. Governance v3 and a.DI
On the Governance and a.DI side, the focus has been on maintenance and adding support to new networks, more precisely:
- Improving dependencies of a.DI off-chain repositories, for example to align upgradeability/proxy patterns to other parts of Aave.
- Governance proposals to activate required a.DI paths and governance infrastructure for new networks:
- Aave Governance v3 interface (one instance hosted on vote.onaave.com). On this side, changes have been mainly related to maintenance tasks:
- Adding support for new Aave networks.
- Prepared a Safe app for Safe users to interact with the Aave governance directly from their Safes, currently only pending approval to release.
- Bug fixing.
- Aave a.DI monitoring interface (one instance hosted on adi.onaave.com). Changes are only related to the support of new Aave networks and bug fixing.
4. Tooling
- Aave Seatbelt. The Seatbelt tool has undergone quite important improvements:
- With Tenderly depracting the Fork feature on their suite to encourage the usage of Tenderly vNets, we have migrated Aave Seatbelt to use an hybrid approach of vNets plus pure Tenderly simulations.
- Especially after the “collision” problem that appeared on proposals 263 and 264, we have changed the Seatbelt simulation flow for the following:
- Instead of simulating each payload in isolation, we now build an execution path based on the expected execution order.
- Then, we simulate the target payload on top of the executed proposals.
- We improved the backend infrastructure to improve the UX of AIP developers/contributors. The Seatbelt report will now be generated immediately after payload registration on all networks (previously, integrators had to wait up to 2 hours until the report was available).
- Misc minor improvements on the tool from feedback of Certora on their on-chain proposals review role.
- AGRS (Aave Generalised Risk Stewards).
- Improvements on the generator for manual steward updates that are suggested by Chaos Labs.
- Developed and activated the system to do fully automated caps updates on Arbitrum, consuming Edge Risk Oracles, together with rate updates of wstETH on v3 Ethereum Prime.
- Added support to update eMode configurations on the risk stewards, currently in code review stage.
- Aave Robot.
- We added support for new networks, whenever available using Chainlink Automation, and in other networks Gelato Automation.
- Additionally, we updated automations for new infrastructure like the new VotingMachines introduced on proposal 273, or new stata tokens (wrapped aTokens).
- Aave permissions list.
- Maintenance tasks, for example, to adapt to a slightly different approach now on Aave with ProxyAdmin upgradeability.
- Add support for new Aave networks.
- Mainly for usage of the Aave Guardians, we created https://permissions.onaave.com/, for quickly querying which permissions on Aave an address holds, like governance contracts or the aforementioned Guardians.
- Aave address book.
- Maintenance of the address list.
- We added a sanity test suite to prevent the addition of wrongly configured external contracts.
- Made improvements on the search algorithm of the address book UI (search.onaave.com)
- Aave proposals & aave helpers repositories.
- Aave proposals had multiple maintenance-like changes, given that it is a heavily used repository by all service providers and contributors creating Aave AIPs.
- On the Aave helpers side, we substantially improved the test suite that gets used then for any type of production simulation of Aave v3, for example, covering more paths like repayment with aToken, flash loans, or liquidations.
- Aave v3 incentives tooling. Maintained the tool used by entities configuring on-chain Aave v3 incentives (REWARDS_ADMIN).
Additionally, we added a CLI generator to simplify the operations of other service providers, following the same approach as on Aave proposals.
5. Miscellaneous
- Pendle pricing discussion. During the proposal to list Pendle PT tokens on the Aave protocol, there was quite an intense discussion in the community between different pricing models, from very static to very dynamic and middle-ground solutions.
We participated in this discussion from the technical side, to allow the community to make a more informed decision, here. - v3 incentives proposals review. We did technical reviews of all v3 incentives updates by the rewards admin role, currently held by ACI.
- Manual AGRS reviews. As technical reviewer, we verified that all risk parameters changes proposed by Chaos Labs via the manual AGRS were technically sound, and aligned with what was disclosed publicly on the Aave governance forum.
- Permissioned payloads controller. Even if not in usage yet, we developed a permissioned payloads controller smart contract, to introduce time-locked flows similar to those of the Aave on-chain governance, but for other entities that receive delegated permissions from the DAO, like configuring v3 incentives.
- Changes on ProxyAdmin usage. We modernised the ProxyAdmin pattern used across all Aave ecosystem contracts to be aligned with OZ v5.
Conclusion
Overall, we think our Phase 4 contribution can be summarised as a process of continuously improving all Aave systems, making them little by little better and better.
This continuous evolution is always matter of keeping an equilibrium on what, how and why to improve the different components; equilibrium we think we have have been mastering for the last years, across our 4 engagement Phases.
As always, we thank the whole community and its service providers for making our work easier, currently @aci, @ChaosLabs, @certora, @tokenLogic, @kpk, @aavelabs, and @llamaRisk. Not forgetting all delegates and governance participants, including but not limited to @ezr3al, @aci, @tokenlogic, @kpk, Areta (@sid_areta), @wintermutegovernance, StableLab (@Kene_StableLab), Keyrock (@0xkeyrock.eth), @ignas, @daoplomats.eth, @event_horizon.
And finally, we thank all Aave users.
Just_Use_Aave
