Simple Summary
As a continuation of the engagement that finished on 1st April 2025, present to the Aave DAO a proposal for BGD to continue as a development and security coordinator services provider during the next 6 months.
Motivation
In our role as technical services providers of an ecosystem like the Aave DAO, the context before we request renewal ideally is very simple: Aave has remained secure and competitive in the number one spot in DeFi, while little by little improving on all aspects in which we (BGD) have been involved.
From that perspective, compared with 6 months ago:
- We think Aave v3 is more technically sound, even considering a very high starting point. v3.3 has improved the protocol, and the upcoming v3.4 will do it even more.
- The whole Aave ecosystem kept expanding to the networks.
- New types of assets have been onboarded, and procedures on this have only improved.
- A lot of groundwork has been done for an even brighter future, from all angles. Testimony of that is, for example, the activation of SVR to recapture liquidations value, or Umbrella being ready for integration with all other Aave systems.
- Service providers’ coordination has continuously improved, and the DAO is now a very efficient decentralised organisation, not sacrificing quality.
Same time, the DAO is going into very new directions, like the upcoming v4 by @AaveLabs, Umbrella having a core role in the ecosystem, or the new Aavenomics, amongst others.
Given that our objective has always been giving value to Aave in those places where we believe it is worth it, our new scope presented here naturally has evolved due to that.
Specification
Aave <> BGD Phase V scope
Our proposed scope of services includes the following:
-
Activation of v3.4 plus improvements on top. As commented on the v3.4 upgrade thread, we think that high-level everything included there is a net improvement of the protocol, even considering the final refinement of the features we are now performing post-ARFC approval.
In addition, we believe Aave v3 has big room for improvement in multiple directions that, to reduce the size of v3.4, have not been included, so we will propose those to the community in the shape of a v3.5 or more upgrades if fragmentation is required. It is important to highlight that these improvements don’t involve any full re-architecture of the system, as we agree with the upcoming v4 in the picture, that would not be too reasonable.
Same time, considering the feedback on upgradeability procedures, we will lead an effort to make them stricter and formalised, procedures that the DAO can then potentially use for any of its production/upcoming infrastructure. -
Improvement of Umbrella post-activation. The Umbrella system activation is imminent, and even though it is a very complete system, it will require improvements over time on the overall infrastructure: smart contracts, Aave DAO user interface, or better integration of it with other DAO infrastructure (e.g., compatibility with the future v4 if applicable).
We will work on all these aspects to maximise the value Umbrella brings to Aave. -
More Aave expansions to new networks. Similar to the previous years, the demand to host Aave on different networks is constant. In the same line as on our previous scopes, we will participate in the technical and quality procedures for the Aave governance to activate v3 instances on those networks.
This includes a process of continuous improvements on all layers: better/deeper network evaluations or better setup pre-activation.
-
Better off-boarding procedures for assets and networks. Historically, the Aave DAO has been focused on establishing solid procedures for the onboarding direction of new assets to be listed and new networks to be present on.
However, no matter if these procedures are exercised or not, currently there is an important lack of precise technical steps to off-board assets and networks whenever the expected KPIs by the DAO are not fulfilled.
Our role will be to better define these steps and collaborate with other contributors to move them forward by any mechanism decided. -
Technical analysis of assets to be listed on Aave. As we commented in our Phase 4 recap, one of the values we think the Aave DAO gives to the whole DeFi industry is helping to step up architectural and security standards on the assets (tokens) level, via the quality procedures they need to pass in order to get listed on Aave v3.
Also, this is a very important flow for the DAO in the future, as it is totally scalable/applicable for other upcoming systems like v4, still sharing similar principles asset-wise as v3.
Our role will remain the same as in the previous Phase 4. -
Streamlining risk management flows on the technical side. During the previous phase, the DAO has already been running in production more automated systems like the AGRS (Aave Generalised Risk Stewards), infrastructure to make the Aave on-chain ecosystem more efficient and less maintenance-heavy, which indirectly improves all other aspects of the DAO.
Our role in that has been developing the majority of that infrastructure, but also advising other contributors (e.g., treasury or risk itself) on how to better and safely expand in this direction.
We will keep doing the same, with the objective during these 6 months of having all possible systems following the constraint stewards-model, this way reducing governance proposals to only critical aspects. -
Governance proposals reviews. High-level, aside from decentralisation principles, we see governance proposals as a very strong mechanism of the DAO to achieve base security without requiring complex developments. This means that by having access control configured to the Aave Governance in new systems, that new system has very strong security by default, which later on can be made more granular, but without delaying go-to-market.
That base security is a consequence of multiple aspects, but the most important in what regards our past and proposed scope are:- We review what, in practice, are all proposals by other contributors before they are created on-chain. This gives a very high assurance that everything being voted on is secure and of quality.
- Our pre-onchain role helps the on-chain proposal reviewers (Certora) to have a way simpler job, as there has already been very important groundwork prior.
- We have a very important presence also advising other contributors on how to better organise proposals, not only pure code review. For example, how to batch aspects to propose, or high-level advice on good practices.
-
Support for the implementation steps of the AAVEnomics. During the following months, other contributors (e.g. growth and treasury) will require technical support from our side to execute different steps on the implementation of the newly approved AAVE tokenomics.
Our role here will be producing the required helper contracts and defining/reviewing procedures on each sub-step. -
Continuously improve DAO’s tooling. Since the beginning of our Phase 1, we have been developing off-chain tooling for the DAO, benefiting integrators, service providers, or users themselves. For example, this is the case of the Aave Proposals repository, Aave Address Book, Aave Seatbelt, or even the DAO-owned Governance v3 interface.
We will continue to do the same, both improving the existing infrastructure and creating new ones when deemed appropriate.
Additionally, we will make an effort to move all the tooling to the Aave DAO organisation, always trying not to disturb the operations of the DAO in the process. -
Iterate on the SVR direction. Aave <> Chainlink SVR has just been introduced, but we think it has a lot of potential for refinement from here, aside from expanding it to more assets on Ethereum or more networks.
Until now, we have supported Chainlink as the Aave tech expert party, and we will continue in this role. Additionally, once SVR is in production with more assets, there could be different synergies with other systems of Aave, and we will contribute with any smart contract required.
-
Aave protocol security coordinator. Same as in our previous engagements, this involves:
- Continuously evaluate technical risks for Aave.
- Address events involving any vulnerability affecting Aave. This also includes creating governance proposals if required.
- Act as technical support for the Aave Protocol and Governance Guardians: define and document plans of action, communicate with both of them whenever a reaction is needed, and also properly disclose to the community activity on the Guardian.
- Manage the bug bounty program (currently Aave <> Immunefi). Both operationally (as reviewers of submissions), but also structurally, if we consider, for example, a platform change could be worth it.
-
Contribute to the final steps of v2 off-boarding. Similar to what happened with v1, v2 has entered into its final deprecation stage, with its market size being approximately $300m.
We will participate in the final steps of its deprecation, which usually include changes on oracles, interest rate strategies, or even further measures like the ones applied on the v1 off-boarding Phases. -
Participate in the planning of any potential v3 off-boarding strategy. It is not clear at the moment, and we think that definitely is not a good idea during the next 6 months, but if the DAO would approve any off-boarding plan of v3 in favour of v4 in the future, we can can support the party leading v4 advising on what in our opinion is a responsible way of doing it, without disturbing operations of the DAO.
DURATION: same as with Phases II, III, and IV, 6 months: starting from the moment the previous engagement ended (1st April 2025) and lasting until 1st October 2025.
BUDGET: 2’300’000 in stablecoins and 4’000 AAVE, 50% paid up-front and 50% streamed during the 6-month engagement.
This is a slight reduction from our previous scope, as we think the community approving Aave v4 implies that changes on Aave v3 will be lighter than before, focusing on security and basic UX improvements, but without very deep re-architecturing. At the same time, Umbrella will enter into an improvement/maintenance phase, which adds to the scope.
What is NOT part of the scope
Similar to Phases 3 and 4, we want to be explicit on what is not included in our line of contribution:
-
We are a technical provider of the community, we don’t do any type of business development/or growth, which should be the responsibility of other parties.
-
We don’t do formal security reviews on major developments of other contributors. We offer our security advisory for projects solely benefiting the Aave DAO, but on bigger scopes (e.g., Aave v4), that is up to parties engaged specifically on security, like Certora or other external third parties.
-
We will provide feedback on the design of projects that we don’t lead only whenever the project is 1) of technical nature and 2) the final design is flagged as “ready” by the contributor. Given our expertise, we have a pretty strong stand on architecture and design decisions, which can create conflicts if no framework is defined.
More explicitly, we are not the developers of Aave v4 and other ad-hoc initiatives like Aave v3 on Aptos, so aside from best-effort giving high-level advice (e.g., similar as we did with GHO or cross-chain GHO) to other contributors like Aave Labs, our scope doesn’t include any involvement/obligation on those. -
We only work on projects with a TEMP CHECK Snapshot passed (e.g., reviews). With the activity on the DAO increasing day by day, unless a filtering of projects is applied, it is not manageable for us to support any project in the pre-TEMP CHECK stage, unless we identify a clear need from our side.
-
This scope includes EVM-only contributions. Any non-EVM ad-hoc requirement would need to be evaluated aside, as it is not our core expertise and would affect the delivery of all items in scope.
-
We are not running services on behalf of the DAO, we design them to be run in a decentralised manner, or by parties with the proper role to do so. Any tool we decide to run on our infrastructure (e.g., hosting of one instance of the Aave Governance v3 interface or Umbrella’s) is our own decision, outside of the scope of engagement.
-
We don’t produce centralised backend services for the DAO.
-
We prepare the existing technical infrastructure (e.g, Aave v3 instances) for a system fully controlled by the Aave DAO, or if following a friendly fork framework, whenever the configuration is not totally custom (e.g. main pool dynamics heavily changed, major custom code components and flows).
-
We only build user interfaces for the DAO on those projects that we believe are simply not complete without that part of the infrastructure. For example, we think a project like Umbrella requires the DAO to own a UI, no matter who then runs it. Similar applies for the Aave Governance v3 UI.
But for any additional cases, we reserve the right to decide if any interface infrastructure is produced for the DAO or is exclusive property of BGD Labs, both those using Aave smart contracts or not.
Terms of Service
A formal Terms and Conditions document for the engagement for services between the Aave DAO and BGD Labs can be found HERE.
However, we would like to highlight again the same high-level points as on Phases 3 and 4, which we think are very important for the ethos of the DAO:
-
Major projects’ IP and licensing belong to the Aave DAO. As a service provider to a DAO like Aave, we should defend the interests of our customer. For that reason, the core software (e.g. all on-chain smart contracts to be used by the DAO in production after governance proposals) we create during our engagement are licensed to the Aave DAO governance smart contracts, both using the BUSL approach as on Aave v3 Origin, or more open source licenses if we think expanding the usage of Aave peripheral technology only helps the DAO.
To insist on the previous fundamental implication:
- The Aave DAO is the sole owner of the intellectual property and licensing of those projects.
- It is entirely up to the DAO to decide how to use and/or commercialise them, not BGD Labs.
- Our benefit from those projects is the fee we receive from the DAO for developing the software.
-
BGD doesn’t decide what gets activated/applied in Aave. We create the software and the technical proposals to activate said software, but it is and will always be up to the DAO governance to decide if that software should be enabled in production.
-
No software is flawless, but we pursue it. Historically, no major problem has been detected in the developments we did for the DAO, but it is impossible to assure from our side that all software will be flawless. However, we have a firm commitment to always following solid security standards and procedures, to minimise any potential impact.
-
We compromise to not work with competitors of Aave on any core business that could hurt the DAO. We are an independent company with potentially our own projects outside of this scope, but given our involvement on especially in the core Aave v3 protocol, we agree not to work with any direct competitor of Aave (other DeFi lending protocols) in core smart contracts development or security during these 6 months in scope.
Disclosures
BGD Labs has no meaningful commercial relation with entities that could create any type conflict of interest on the scopes of this proposal.
Next steps
After some days in this forum for the community to comment on, we will create an ARFC Snapshot for pre-approval of the services engagement. If positive, we will proceed with an on-chain AIP.
During this period (since 1st April) where we technically have no engagement, we will simply continue doing the same work as before, without stopping any of the on-going projects/developments.
