Summary
As continuation of the engagement finished 1st October, present to the Aave DAO a proposal for BGD to continue as provider of development and security coordinator services.
Motivation
Time flies in DeFi, and it has already been two and a half years since BGD started working for the Aave DAO.
During this time, the market has gone up and down, new protocols have appeared, and CEXes have fallen. But the Aave protocol remains, and, following almost any metric, it has grown.
Together with the work of other service providers, we want to believe our contribution has had an important role in both the stability of Aave (creating solid trust) and the growth itself, with tech enabling all new types of use cases while maintaining the highest standards of security.
During the last 3 engagements between BGD Labs and the Aave DAO, all pieces of the Aave infrastructure have been worked on: the Aave protocol itself with new versions and maintaining the current ones, the Aave governance, bridging infrastructure, all rails for expansion to new networks and use cases, supporting non-technical contributors to maximise their value without being blocked by tech; basically everything.
The motivation/goal of this new engagement is:
- Keep the stability and trust in the Aave technology.
- Innovate responsibly on production systems.
- Support all other non-tech contributors to the DAO, accelerating progress.
In summary, the same as before, but always striving for better.
Specification
Aave <> BGD Phase IV (continuous) scope
The scope of this Phase IV builds upon all previous phases, and as commented, is focused on continuous maintenance and development of the Aave ecosystem technical infrastructure, in combination with security coordination and support to other contributors.
More specifically, the services include the following:
-
Propose improvements on top of the current Aave v3.2 production version. This will include minimum a v3.3 and v3.4 versions, but with quite certainty, more.
Additionally, we have several other ideas to improve the core protocol, which will be unveiled to the community as soon as the feasibility research is positive.
-
BGD will take back the scope of deploying to new networks and pool instances. As commented on our Phase 3 final recap, we identified that having different entities on the deployment stage of Aave v3 creates more overhead than benefit. So we think for Phase IV it is more optimal to get the following entities involved in the activation procedures:
- BGD Labs will perform all the pre-governance proposal stages (deployment of required smart contracts, adaptation of all tooling, and development of the activation proposal itself).
- As it currently happens, Certora will review the on-chain governance proposal once submitted, in order to have redundancy.
-
Maintain Aave Governance v3 and a.DI. In this phase, the effort will be on improving the user interface owned by the Aave DAO, and on the a.DI side, increasing even more the visibility on the infrastructure (on https://adi.onaave.com/), streamlining upgrade procedures via governance proposals, and on-demand, enabling new paths and bridge providers.
Additionally, with the rollups ecosystem evolving (e.g. ZK-based), we will once again evaluate the expansion of voting to other networks, an item we removed priority on the previous engagement as the return of resources investment was not there.
-
Aave bug bounty program. After already close to 1 year of the Aave <> Immunefi bug bounty being active, we plan to make certain improvements to it. Same time, we will remain as reviewers, addressing all the submissions and the different stages until bounty payment.
-
v2 further off-boarding. At the beginning of the previous Phase 3, Aave v2 pools were still very meaningful instances of the protocol, both in size and usage. Currently, different off-boarding initiatives (both from us and other contributors) have reduced a lot the role of v2 in the ecosystem versus v3. During this engagement, we will proceed/support further proposals for off-boarding of v2, with the target being reaching a scenario where only very major assets stay (e.g. WETH, stETH, USDC, USDT), but everything else naturally gets finally migrated to v3.
-
Focus on Aave Stewards and additional infrastructure delegation. We believe the path of using what we name the Stewards pattern is most probably the future direction of Aave:
- The Aave Protocol (v3) is the base layer of smart contracts, enforcing the highest-order validations and general settlement logic. Decentralized, with only the Aave Governance having “super-admin” control.
- The protocol delegates operational/management functions to other smart contracts, the Stewards. These are highly constrained on-chain agents, that allow for faster and more optimal operations, but that can lose this power at any point if the Aave Governance decides so, and with low capacity to create any damage on the protocol.
- Currently, the Stewards are focused mainly on optimizing risk parameter updates, but we envision extending this pattern to multiple areas, for example, finance (a Finance Steward is in the advance stage by the treasury contributors).
Our role in Stewards development will involve 1) defining an approach that is scalable enough for the current and future needs of the DAO 2) developing the core Steward contracts we believe require our involvement 3) if optimal, supporting other contributors to create their own Stewards, or modifying existing ones for the needs of the DAO.
-
Umbrella support post-release. In Phase 3, we included a separate scope for the creation from scratch of Umbrella, a new version of the current Aave Safety Module. Scheduled to be released pretty soon, the project will require post-release support, mainly in the shape of:
- Supporting non-BGD contributors involved in all Umbrella operations, for example, regulation of incentives, and risk considerations like choosing correct targets.
- Improvements post-release.
- Iterating on tooling after the initial effort included with the previous Umbrella scope.
-
Aave protocol security coordinator. Same as in our previous engagement, this involves:
- Continuously evaluate technical risks for Aave.
- Address events involving any vulnerability affecting Aave. This includes also 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 Guardian.
-
Aave proposals reviews. We will review all governance proposals before they go on-chain, the same as we have been doing last year. This acts as the first layer of security and quality, minimizing any potential issue to be detected on the on-chain stage by Certora, on their line of contribution.
-
Maintenance and improvement of all tooling of the Aave ecosystem. During the previous phases, we created multiple tools and projects on the off-chain side of Aave, like Aave Address Book, the Aave Proposals repository, Aave Helpers, the Aave Config Engine and a myriad of others. During this new Phase, we will keep improving them and creating anything new needed.
-
Analysis for candidate networks to activate Aave v3. Even if the plan on the previous scope was to off-board network analysis, finally we decided to keep performing them ourselves, as the overhead of supporting another entity would not have been good resource allocation.
In this new scope, we will continue performing this analysis.
DURATION: same as with Phases II & III, 6 months: starting from the moment the previous engagement ended (1st October 2024) and lasting until 1st April 2025.
BUDGET: 2’300’000 in stablecoins and 5’000 AAVE, 50% paid up-front and 50% streamed during the 6 months engagement.
What is NOT part of both the scopes
Similar as on Phase 3, 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 and/or growth, that should be responsibility of other parties.
- We don’t do security reviews on major developments of other contributors. We offer our security advisory for minor projects solely benefiting the Aave DAO, but on bigger scopes (e.g. something like GHO), that is up to parties engaged specifically on security, like Certora. On our side, we only do a best-effort review if we deem it appropriate.
- We will provide feedback on 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 pretty strong stand in architecture and design decisions, which can create conflicts if no framework is defined.
- We only work on projects with 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 really manageable for us to support any project in pre-TEMP CHECK stage, unless we identified a clear need from our side.
- We are not running services on behalf of the DAO, we design them to be ran 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) is our own decision, outside of the scope of engagement.
- Very ad-hoc projects will depend on the pipeline of priority, and potentially will be budgeted/estimated independently, if we see they will have important implications on the scope that we need to fulfil and/or not fitting in this initial estimation. For example, any projects like Umbrella will be budgeted apart, and we don’t disclose them at the moment, due to being in feasibility research phase.
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.
We would like however to highlight again the same high-level points as on Phase 3, which we thing are very important for the ethos of the DAO:
-
Major projects IP and licensing belongs to the Aave DAO. As a service provider to a DAO like Aave, we have an obligation to 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) we create during our engagement are licensed to the Aave DAO governance smart contracts. This applies but is not limited for example to new Aave v3 version, Aave Governance v3, a.DI or others; systems that we consider highly innovative and not only improve the efficiency of Aave, but increase the overall value of the technology owned by 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 to BGD Labs.
- Our benefit from those projects is the fee we receive from the DAO for developing the software.
Even if already doing it by commercialising all the different Aave products, we believe in the near future IP and licensing commercialisation is something the DAO should put focus on, at the same time common good infrastructure is released.
-
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 on 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 compromise of always following solid security standards and procedures, to minimise any potential impact.
-
We don’t work with competitors of the Aave DAO. To do the type of work we do on Aave, the community should trust us as service provider. To avoid any type of conflict, we compromise to not work with any competitor of the Aave DAO for any type of financial gain.
Disclosures
BGD Labs has no meaningful commercial relation with entities that could create any type conflict of interest on the scopes of this proposal.
Similar as during the previous years, the majority of our focus is on core development and security services on Aave (exclusive provider): we have absolutely no engagement with any entity that could be perceived as competitor of the Aave DAO and we will not during the duration of this Phase 4.
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 October) 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.
