TL;DR
Present to the community a proposal for a follow-up Aave <> BGD engagement for development services.
Context. Aave <> BGD Phase I
May 9th 2022 marked the start of a 15-month initial Aave <> Bored Ghosts Developing engagement (which lasted until this past 9th August 2023), for development on the Aave ecosystem and all the different items surrounding it.
Back then, the Aave ecosystem was in an operational point of inflection:
- There were multiple “monolithic” items that required both heavy expertise and execution.
- Codebases/interaction flows required deep expertise, even for small updates.
- The quality of tooling should be improved by an order of magnitude to keep the scaling rhythm of the DAO: it was not up to the required standards of quality for a system/brand like Aave.
- The was no way of checking governance proposals, apart from complex manual reviews.
- Lack of frameworks and community procedures.
Our Phase I focused on something very specific: closing all technical debt, together with keeping a good rhythm of innovation.
For that, BGD grew a team with deep knowledge of Aave (high and low level) and delivered several items, both covering the initial scope and pivoting when required.
A good overview of all the projects can be seen on our 365 days update.
From our perspective, we think these 15 months have been quite productive, and we have definitely provided value to the community. Sometimes “public” value, sometimes the “boring” technical one that sets a substrate of quality for the years to come.
Let’s talk about the next phase.
P.S. The items already started in the context of the previous engagement will be finished, even if the final delivery will happen after the end of it. This will obviously bear no extra cost for the DAO.
This includes the following:
- The new version of stkABPT, with AAVE and wstETH, already approved by the community.
- Aave Governance v3, a.DI and Aave Robot, until activation via governance proposal of all of them.
- Aave v3 network reports in progress: Polygon zkEVM and zkSync.
- Base and BNB deployments, and activation.
- Evaluation of the Owl candidates for Aave Forest.
- Present to the community a more comprehensive description of projects created (and already in use) during Phase I.
- A past security schedule overview, and a plan for the community on it going forward.
Aave <> BGD Phase II. The vision
There is no doubt that the ecosystem is pretty different now compared with how it was back on May 2022: Aave is engaged with multiple service providers, there have been 200+ on-chain proposals since then (compared with ~70 before), there are multiple frameworks (both off and on-chain) on how to handle DAO-related flows, and a good part of all “legacy” technical items is closed.
We believe our new engagement should be aligned with how the ecosystem evolved.
In our vision, BGD’s role on Aave should be reduced to the minimum necessary for the sake of progressive decentralization, keeping our involvement on those tasks on which 1) we don’t think any replacement will have the required skills, 2) immediate onboarding of other entities would be more costly to the DAO (with big uncertainty).
Collaboration principles on a DAO like Aave
From our time contributing to the ecosystem, we think the following considerations are important going forward:
-
Collaborative environment but segmented. Development projects should be led by development contributors, and each by a single party.
Collaboration can materialize by doing mutual code reviews (between development contributors), or by supporting non-purely-technical contributors (e.g. risk providers). But design decisions should be solely the responsibility of the project lead (e.g. BGD on our scope).
The DAO should be really confident in the skills of the contributors and the overlap with others, before approving the engagements, to avoid any operational inefficiency.
-
Strict evaluation of conflict of interest by the DAO. Any type or perception of conflict of interest should be carefully evaluated with the DAO before taking engagement decisions. From our side, we have a really strong compromise on not collaborating with any direct competitor of Aave during our engagement. But at the same time, we will not share any strategic information (for Aave) regarding development with anybody that we perceive as having a conflict of interest. So we hardly encourage entities to fully disclose any potential conflict of interest before future engagements, together with the DAO mandatorily asking for disclosure and strategy about it of the candidate.
-
Innovation vs disclosure. The conflict between strategic innovation on development and openness is a challenge. Disclosing too early to the community certain projects or improvements can hurt the DAO itself strategically.
This is partially why we don’t think that improvements included in the scope (e.g. Aave v3) can be disclosed while still requiring research.This is a pretty complicated matter, that we will try to address holistically during this Phase II.
This vision reflects in practice in Phase II by:
- Reducing duration of scope, from 15 months to 6 months.
- Reducing scope itself, with less monolithic projects.
- Reducing proportionally the budget.
Aave <> BGD Phase II. The scope
The new scope of contribution is more precise than before, with the open part limited to certain individual items. The focus is on development and procedures around it: software design and implementation, technical leadership for security initiatives and quality assurance, and development support to partners and contributors.
Different from Phase I, the delivery of items on the scope is only conditional to the Aave DAO not pivoting in the projects themselves, so the SURE and BEST EFFORT followed before is not really applicable: everything can be considered SURE.
If any extra project would appear on the development side, we will present separate scope and budget, in case of the community asks us to execute it (doesn’t need to be like that).
Scope
-
Development
- Maintain and improve all the Aave developer-experience tooling introduced in Phase I, including aave-address-book, aave-proposals, aave-helpers, and many others, present in the BGD Github org.
- Iterate over Aave Seatbelt, making it fully compatible with Aave Governance v3, generalize it more for upcoming networks with Aave instances, and introduce new ideas to improve governance assurance.
- Lead the development of new items involving changes in the Safety Module. More specifically, those already pre-approved by the community.
- Create aggregated workflows, by re-organizing repositories (protocol, tooling from BGD, etc). At the moment, there are a lot of developer resources scattered around, properly organizing them requires further work.
- Development of the killswitch component approved by the community.
- Maintain and iterate over the upcoming Aave Governance v3, a.DI and Robot systems, including:
- Deployment of new voting machines
- Support the community on assessment of new bridges, and enabling them via proposals.
- Fix any potential problem found.
- Maintain the new governance user interface.
- Study technical ways of increasing voting participation.
- Batch a series of improvements for Aave v3, into an Aave v3.1 version: this will include an improvement of the liquidation mechanism, and potentially some periphery components. In addition, any bug fixing (Aave v2 and v3) would be included.
- Support and advice on deprecation of Aave v2, involving any (reasonable) development. Items included on the Aave v3 part of the scope could potentially be applied on v2.
- Lead the deployment of 3 new deployment candidates (EVM), apart from the 2 pending network analyses (zkEVM, zkSync), if fully approved by the community.
Extra networks will be evaluated case-by-case.
-
Development liaison for security, and quality assurance.
- Plan and coordinate all security resources for any development project of the community., both those executed by BGD and not. This includes also the evaluation of what should be reviewed, the parties involved in it, and asking for a budget to the DAO whenever required.
If a major project not executed by BGD appears, we will support it in a best-effort manner. - Onboard Certora on governance proposal reviews. We think it is important to have additional expert parties involved in the governance proposals verification process, and healthier for decentralization.
We believe Certora, after years of collaboration in the ecosystem, is one of the only entities trustable for the task, if we support them with a light onboarding.
This will mean that what previously was done by BGD on the on-chain stage will be taken over by Certora (and included on their upcoming renewal), and is not included/billed in this scope. - Act as the main reviewer of submissions on the upcoming Immunefi bug bounty program, pre-approved by the community HERE, respecting the SLA requirements.
- Keep doing Aave governance proposals’ reviews, on the pre-on-chain stage. We will review all the “operational” projects as they appear (listings, parameters updates), but the timing on ad-hoc bigger projects appearing from other contributors will depend on the project itself.
- Provide network analysis for 3 new deployment candidates (if applicable), together with tackling the whole deployment and activation technical procedure.
Extra network analysis will be budgeted independently. - Execute an initial iteration of the proposed Aave Forest. At the moment (Phase I) we are finishing the evaluation of an initial set of Owls, but coordination and acting as a technical entity associated “natively” with Aave will be necessary.
- Plan and coordinate all security resources for any development project of the community., both those executed by BGD and not. This includes also the evaluation of what should be reviewed, the parties involved in it, and asking for a budget to the DAO whenever required.
-
Development support for contributors/partners
- Support any entity improving the Aave DAO documentation on all technical information.
- Act as technical point of contact for external partners and contributors of the DAO.
Duration
6 months duration, from the execution of the on-chain governance proposal acting as the agreement between the Aave DAO and BGD Labs.
Budget
1’900’000 USD in stablecoins and 6’000 AAVE, 60% paid upfront and the rest over a stream of 6 months.
Evaluation Metrics
From our experience in Phase I, in a development engagement with DAOs like this, the following metrics are good measures of performance:
- Provable participation and/or delivery of the projects described in the scope.
- Direct or indirect participation in projects of other fields of contribution.
- Perceived improvements in operations of the Aave due to our participation in them.
- Feedback from other contributors and partners.
- Projects’ transparency in this governance forum.
- Aave-related activity on the organization’s GitHub.
Next steps
- This post acts as ARFC (Aave-Request-for-Comments), for the community to show/not support the proposal, together with asking any questions about it.
- Wednesday 16th we will create the Snapshot vote following the standard procedure of the community.
- If the Snapshot has a positive outcome, we will escalate to an on-chain AIP, releasing the requesting funds, creating streams, and in general, acting as a binding agreement between the Aave DAO and BGD Labs for the services to be provided.
