Summary
Present to the Aave DAO a proposal for BGD to continue as provider of development services, after Phase 1 and 2.
1. Motivation. Aave and BGD 1, 2….3
May 9th 2022, we presented Aave <> BGD Phase 1, a proposal for services to the DAO, covering a pretty extensive scope on the big majority of Aave sub-systems; development and security related.
During the following 15 months, we did or participated in dozens of projects of technical nature for the Aave DAO, and more importantly, we set precedent that a model of a fully independent company providing services to a decentralised entity can work.
September 4th 2023, we presented Aave <> BGD Phase 2, with similar type of scope as Phase 1, but with slightly different objectives in mind: the technical foundation of the Aave DAO was pretty solid from Phase 1, and possible to iterate on top of it, with a more concrete scope.
Additionally, we set ourselves as a goal to study how to introduce extra technical parties to service specific needs of the DAO, helping more on the decentralisation of the organisation, but without disturbing operations and delivery.
Also, we proposed a way shorter engagement (6 months), which we thought was more optimal for the DAO to have capacity to manoeuvre. The outcome of this work can be found HERE.
We think that our services to the DAO on both Phases had played a role on Aave staying in top of its category for years in so nascent field, and the Aave codebase being used in other products, accounting to close to 75% of total market share category.
Now we present Phase 3, continuist, but with some important changes in terms of scope.
2. Specification. Aave <> BGD Phase III. The scope
This time, we want to explicit divide our proposal in 2 different and explicit components, each one with its separate scope, budget and duration characteristics.
Scope 1. Aave technical maintenance, improvements, security coordination and tech advisory to the DAO
This scope is the continuist component historically performed by BGD for the DAO, and will be composed of the following items:
-
Maintain, improve and consolidate all the Aave tooling introduced in Phases I & II, including but not limited to Aave Address Book, Aave Helpers, Aave Proposals, Risk Stewards, Seatbelt and Killswitch.
-
Maintain and improve Aave Governance v3, a.DI and Aave Robot, together with the tooling surrounding them.
The following new items will be delivered, consequence of the research done on Phase 2:
- Extend coverage of voting networks to rollups, apart from the current Polygon PoS and Avalanche C-Chain.
- Allow voting with AAVE tokens held in non-Ethereum networks.
- Granular and generalised consensus rules for a.DI, together with different planned optimisations.
-
Propose further improvements on top of the upcoming Aave 3.1.
-
Different v3 maintenance tasks with important development requirements, including:
- Improve asset off-boarding procedures.
- Complete removal of stable debt logic.
-
Act as reviewers of Aave <> Immunefi for all current Aave ecosystem, not including GHO (Avara currently being the reviewer). Additionally, doing proper maintenance of the bug bounty program.
-
Act as security coordinator of the Aave ecosystem, including:
- Continuously evaluate potential technical risks for Aave.
- Design specific protection strategies in the event of any vulnerability affecting Aave.
- If arising, create governance proposals to mitigate any type of problem affecting Aave.
- Coordinate with the Aave Guardian for protective emergency actions.
-
Support with further technical off-boarding strategies for legacy versions of Aave (v1, v2) in a safe manner, both for the DAO and the users of the protocol.
-
Advise other contributors on which security procedures to apply for their developments, when required.
-
Evaluate new upcoming high-level technical implications/risks for the protocol, for example, new types of assets being listed.
-
Generally advise other contributors, whenever feedback from an entity expert on the Aave protocol is required. This includes but is not limited to contributors on the risk, treasury, security reviews and miscellaneous fields.
-
Review governance proposals on pre-onchain stage, not as a full security audit, but in order to verify that we don’t see any integration problem with Aave’s smart contracts and good practises.
Scope 1. Aave technical maintenance, improvements, security coordination and tech advisory to the DAO
DURATION: same as with Phase 2, 6 months, starting from proposal execution.
BUDGET: as some items are not included in the scope (more later), the budget has been reduced from Phase 2. 1’600’000 in stablecoins and 5’000 AAVE, 60% paid up-front and 40% streamed during the 6 months engagement.
What is NOT part of the scope
- 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.
- 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.
What about network analysis and deployments from Phase 1 & 2?
Same as we did on Phase 2, we think it is our duty to help the DAO growing the number of service providers engaged on technical areas. An example of it is the recent on-boarding of Certora on the task of on-chain proposal reviews.
This Phase 3 is no different, and after evaluating their competence and preliminary terms of engagement with the DAO, we would like to recommend two new contributors, who will independently present to the community their own proposals.
New networks analysis: MixBytes
Having collaborated with MixBytes for security needs in the past, we explored the possibility for them to perform a task we introduced and have been doing during the past engagements: evaluating the technical suitability of new networks for the Aave to expand there.
Even if this task requires a pretty holistic view of the Aave system, after evaluating internally the capabilities of the MixBytes team and their preliminary terms to be proposed to the DAO, we believe both are very reasonable, and consequently we endorse an engagement to be presented in the following days.
Additionally, the offer will include a review of new Aave deployed instances on the pre-activation stage, this way having 3 parties providing maximum security: ourselves, MixBytes and Certora.
We are aware that we will be required during an initial pilot phase in an advisory/evaluation role, but we think this can have a positive outcome for the decentralisation of the Aave DAO.
New networks deployment: Catapulta
Expansion of Aave v3 liquidity pools to other networks is a pretty critical task, currently involving the deployment and configuration of multiple sub-systems, in addition to other tasks like the creation and submission of activation proposals for the DAO to vote on.
During the previous 2 phases we have been tackling this task, but more importantly, we have built internally procedures and tooling that helps performing this in the safest manner.
Similar as with networks’ analysis, we think now is a good moment to engage another party to do the following:
- Once the final ARFC Snapshot for a proposal passes, do all the preparations and deployments of the Aave v3 pool in the new network.
- Create an activation proposal for the Aave DAO to vote on, following the good practises and standard procedures.
- Coordinate with all other different parties for coverage of the new network, including but not limited to: BGD for a.DI/Aave Governance v3 preparations, risk contributors to get final recommendations, security contributors for review of the proposal, user interface maintainers for them to support the new deployment.
- Manage transparent communications with the Aave DAO in this forum about the deployment process.
We think Catapulta, founded by David Racero (@kartojal ) is the perfect candidate for this task, given their deep expertise of Solidity deployment procedures (the Catapulta platform is example of it), but also given the role of the founder (David) in the past on Aave, leading the deployment operations team of Aave, until BGD took over the task.
Similar as with the new proposed contributor on network analysis, we think the terms we have preliminarily discussed with Catapulta and to be presented the following days are fair; consequently our endorsement.
Scope 2: Aave Safety Module - Code A
As commented before, we believe now the Aave DAO is in a really solid stage of their current systems, quite future-proof and ready to scale:
- Aave v3 is a solid liquidity layer, on which is possible to iterate and improve.
- Aave Governance v3 is probably the most advanced on-chain governance system in production.
- a.DI is a totally generic bridging layer, that can be used for any cross-chain communication need on the Aave ecosystem, in a secure and scalable manner.
- Aave Robot is a solid automation layer, integrated with Chainlink Automation, but flexible enough for any technology.
More in the line of innovative projects like Aave Governance v3, we propose to create a completely new system in an Aave component which requires improvement: the Aave Safety Module.
Aave Safety Module: Code A
Safety Module Code A is the major project on the innovation side of this scope, but different to previous cases, our proposed approach is different: at the moment, we will not disclose a detailed description of it, as we think this is the right strategic approach for the DAO.
However, we can say the following about Code A:
- It will change completely the dynamics of the Safety Module and its components, including stkGHO, stkAAVE and stkABPT.
- More efficient mechanism than the current.
- Improved use experience.
- Heavily improved dynamics for builders to build on top, but still batteries included.
- Affecting importantly AAVE tokenomics.
- Holistically designed, taking into account Aave v3 and GHO.
- Directly/indirectly benefiting any future project of the DAO.
We are aware this requires some trust by the community on our research and execution capabilities (which is reflected on the payment schedule), but considering that the main beneficiary will be explicitly the DAO and our history of services, we think it is acceptable.
Scope 2. Safety Module Code A
DURATION: this scope is not continuous like Scope 1, but our estimation is similar for full completion, approximately during the next 6 months to have everything fully ready and in production.
However, delivery and communications will definitely be iterative, with extensive details of Project A to be disclosed in the first 2 months, and highly probably some of its components.
BUDGET: 1’900’000 in stablecoins and 7’500 AAVE, with the following schedule:
- 40% upfront.
- 60% in a delayed payment in 4-months from now, when we estimate to be in good stage of completion.
Terms of Service
-
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 major software we have produced during our engagement have been licensed to the Aave DAO governance smart contracts. This applies but is not limited for example to 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 other models can be explorer, from our point of view, this is a pretty solid contribution model for the innovation side of the DAO.
-
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.
3. Next steps
After some days of discussion in this forum, we will proceed with an ARFC Snapshot.
If positive, we will proceed with an on-chain governance proposal that will serve as formal and binding agreement for services between the Aave DAO and BGD Labs, on the terms defined.
