Announcement of the creation of the Bored Ghosts Developing (BGD Labs) initiative to provide support on the development of the Aave ecosystem from the community, proposing an open list of tasks and budget, to participate in a time span of 15 months (5 quarters).
Since its inception, the Aave ecosystem has been growing at an impressive level from all perspectives: users, innovations brought to DeFi, security, assets locked, integrations, and contributors, amongst others.
From an Ethereum-based liquidity facility on v1, Aave has evolved into a multi-chain liquidity protocol on v3, a governance system and token, a safety mechanism, cross-chain communication tools, and other components complementing the previous ones. Part of the ecosystem is too other innovations like the Arc pool focused on institutions or the RWA pool focused on unlocking liquidity for real estate.
Currently, we have reached a quite mature point as a community. Aave is completely functional, self-sustained, and self-sovereign. The community makes all decisions on the ecosystem’s general direction (approving the next iterations of the protocol and governance), onboards contributors for different needs (e.g. Gauntlet for risk) and discusses actively all kinds of aspects affecting its future here, on the forum.
But there is still one particular field on which the community should improve and that is the support and core development of the different systems of the Aave protocol.
The numbers of the Aave protocol are in the hundreds of thousands of users, the assets involved, in the order of billions of dollars. And this is on an ever-changing landscape, with new chains appearing all the time or even completely fundamental changes to the basic mechanisms of the basic infrastructure, like Ethereum.
Aave has seen a myriad of contributors over these years, but there is still a lack of more teams with the knowledge, mission/values, and trustworthiness to take care of the core technical tasks of the ecosystem. Especially, this will become really important with the amount of innovation introduced now with Aave v3, and everything else to come around it.
We are BGD Labs (@bgdlabs on Twitter ), as the name says (Bored Ghosts Developing), a group founded by 3 Aave community members with deep technical expertise on Aave and DeFi in general.
We had an important role in creating Aave and now we believe it is time to stay in the community and help with our skills.
We and our credentials are:
- Ernesto Boado (@eboado on forum, @eboadom on Twitter). DeFi developer and Aave community member. Previously, I was acting as CTO at the Aave Genesis Team, being one of the initial team members since pre-Aave times. I participated in the design, architecture, and implementation of pretty much all the developments of the Aave ecosystem, with a specific focus on high-level design and economics, implementation, and management. Lately, I’m working on multiple Aave proposals (Aave Governance V3, Aave <> Starknet, oracles optimization, Safety Module migrations, …) and exploring plenty of others with other community members.
- Emilio Frangella (@emilio on forum, @The3D_ on Twitter). DeFi developer and Aave community member. One of the initial members of the Aave Genesis Team since pre-Aave times. Participated in the design, architecture, and implementation of pretty much all the developments of the Aave ecosystem, with a specific focus on both high-level and low-level design and implementation of smart contracts and DeFi economics. Lately, Emilio led the development of Aave V3, before its handover to the community, in parallel with participating in multiple community proposals and discussions.
- Andrey Kozlov (@Andyko on forum, @andy_koz). DeFi developer and Aave community member. Previously, Head of Backend/Frontend at the Aave Genesis Team, and also one of the initial members since pre-Aave times. Participated in the design, architecture, and implementation of pretty much all the developments of the Aave ecosystem, especially on all front-end and back-end components, with participation on the smart contracts side too. Lately, mainly been involved in some community proposals.
Roles assumed in the past apart, we are a group of technical contributors. We had an important role in the inception and evolution of Aave and, because of that, we feel that we should be involved in helping the community on the aspects we are able to.
The mission of BGD Labs can be summarised on the following:
- Compromise first . Being in the DeFi community since the beginning, one of the problematic aspects around it and DAOs, in general, is the lack of compromise. We don’t believe that is inherent to decentralization, so we compromise on the tackled tasks, doesn’t matter if the counter-party is a DAO or not.
- Security before pace . Aave has moved really fast in the past and should keep doing the same in the future. But it is important to highlight that pace was always secondary versus the security of what was delivered on the ecosystem. As the size and complexity of Aave grow, this order of priority needs to be kept, and that is our mentality.
- Expertise and openness . At the moment, it is not realistic to do core development of a system like Aave without expertise. At the same time that we participate with ours, we welcome other capable individuals to contribute as well and plan to help them, whether with BGC or as community members.
- Responsible freedom . We as members of BGD are the professionals we are because we had enough freedom in the past to come up with ideas we believe introduced innovation on the field. But with only freedom and no responsibility and organization, Aave would not be what it is at the moment. BGD will have a responsible approach when tackling all the tasks, but still, exercise the freedom to come up with new ideas or different approaches that we believe would improve the Aave ecosystem.
- Aave first . We compromise to work with the Aave community, and given the nature of this work, we believe there is a conflict of interest to work with similar protocols. So BGD Labs will not work with any other protocol considered in any level competitor of Aave.
- Open code for the Aave community . We believe in the creation of common goods, so all the code created by BGD Labs in relation to specific tasks on Aave will be open and owned by the Aave DAO itself, whenever possible.
At the moment, there are several aspects that need one-time and continuous development support on Aave.
On the following list, we present the ones that we believe BGD can help with. We divide them into these 2 classes:
- SURE . BGD will tackle the task, and uncertainties apart (community not approving, model not really defined, etc), will compromise to complete it.
- BEST EFFORT . BGD will participate in the task, potentially completing it too, but usually, the scope is too broad or undefined at the moment to compromise to a level of completion at the moment.
|Maintenance of Aave V2 contracts until migration to V3||SURE||Aave V3’s objective is to expand the protocol to new chains and rollups since day 0, with “fresh” deployments of the smart contracts and the infrastructure. However, the Ethereum V2 pool will need to be migrated to V3 (as already contemplated on the V3 proposal by @emilio ), and given the size of V2, there will still be technical supervision needs until that happens. In addition, until liquidity migrates naturally to V3, there is also V2 deployments on Avalanche and Polygon. Until that migration happens (and after), BGD will support technically the current V2 deployments.|
|Migrating V2 markets to V3||SURE||As a consequence of the previous point, BGD will support the technical migration of the V2 deployments to V3, as needed.|
|Technical support on listing of new assets||BEST EFFORT||Part of a liquidity protocol like Aave is the ongoing evaluation and listing of new assets into the pool. We observed and experienced that only a really small minority of external teams are capable of going through the technicalities of listing an asset on Aave without technical support. BGD will help will this, including all listing across all networks where Aave is/will be present. This will become specially important with V3, as its features “incentivise” new listings of assets.|
|Create and improve tooling to monitor governance proposals and their general correctness||SURE||Decentralized and open governance has its challenges, one of them being the correctness of the executable code of proposals (payloads). BGD compromises to continuously monitor submitted proposals to the Governance, together with the development of automated and open tools to reduce the risks as much as possible.|
|Migration of ABPT Balancer pool to Balancer v2||SURE||The ABPT Safety Module component is still running on Balancer V1, which is not anymore the updated version of the Balancer pools. BGD compromises to tackle this migration.|
|Technical support on deployments for new chains||BEST EFFORT||Aave’s multi-chain strategy is clearly targeting future expansion. Multiple teams submit proposals on this forum to get approval from the community to deploy Aave on their associated network. But as expected, usually those teams don’t have the Aave-specific expertise to manage an end-to-end deployment, and Aave community members need to help. BGD will support these external teams on the deployments as much as possible.|
|Implementation and deployment of Aave Governance V3||SURE||As presented here, it is quite probable that the Aave Governance system will evolve in the following months. This will take an important end-to-end technical effort, and BGD compromises to tackle it.|
|Technical assistance and implementation if the community creates a new iteration of the AAVE tokenomics||SURE||Tokenonomics are usually an ever-evolving field on DeFi, and no exception to it is AAVE and all its flavors. Lately, there has been some discussion in the community about introducing improved levers on the AAVE mechanisms, complementary with other parallel developments like the V3 of protocol and governance, or new models for the Safety Module. Even if being an early stage discussion, BGD compromises to technically assist on the decisions of the community concerning tokenomics, naturally evaluating the effort once the vision is outlined.|
|Technical support and implementation to close LEND-to-AAVE migration, if approved by the community||SURE||Currently, there are still some LEND funds still now migrated to AAVE. Given the time passed since the migration, the community has discussed recovering the non-migrated LEND funds (most probably lost) to be placed for better use on the Aave ecosystem. BGD will assist in the implementation and execution of this.|
|Technical maintenance and improvement of the Aave liquidity protocol UI||SURE||At the moment, it is possible to access the Aave protocol from multiple points: UIs, smart contracts’ integrations, crypto wallets, custodians, etc. One of these access points is the open-sourced Aave UI hosted in a decentralized way on IPFS here. BGD will participate in the maintenance of the decentralized Aave UI.|
|Technical maintenance and improvement of the Aave safety module UI||SURE||With the upcoming improvement of the Aave decentralized UI consequence of Aave V3, it is quite probable that the section dedicated to the Safety Module will need to be re-evaluated and improved in the future. In addition, new models of Safety Module could be included. BGD compromises to participate in the development of this UI component.|
|Technical maintenance and improvement of the Aave governance UI||SURE||Decentralized governance is still in its really early times, so its evolution is constant. Aave is no exception to that and even considering that there are multiple points to participate in its governance system (discussions here on the forum, Snapshot, governance aggregators), the community can expect changes affecting UI and off-chain infrastructure in the near future. BGD compromises to participate in this development.|
|Managing deprecation of Aave V1||SURE||With the upcoming V3, it is pretty clear that V1 should be completely deprecated, as it is clearly suboptimal compared first with V2 and V3. BGD compromises to support the community on the technical aspects of this deprecation.|
|Technical support for teams developing products on the ecosystem, depending on capacity||BEST EFFORT||Supporting technically the development of some Aave initiatives, we believe we will have an obligation with the community as a whole to pass our knowledge to everybody else. Because of that, BGD will try to support as much as possible other teams developing products connected with the ecosystem.|
|Point of contact for security disclosures and action||SURE||On open DeFi protocols, there are from time to time security disclosures of potential technicals problems. Given our experience in the past, BGD will act as a point of contact for security disclosures concerning the Aave ecosystem and will take action on them.|
|Rescue locked funds send directly to contracts of the Aave ecosystem||SURE||As discussed here, since the inception of the protocol, some users have miss-sent and “locked” tokens to different smart contract addresses of the ecosystem, in some cases, recoverable. BGD will help on this, under the limitations of complexity or even feasibility depending on the contract with tokens locked.|
|Explore and propose to the community integrations of the ecosystem with other protocols||BEST EFFORT||For Aave to continue evolving, it is fundamental to keep up with new developments happening on other protocols around, and potential technical/economical synergies. BGD compromises to explore new models in this regard, proposing to the community for feedback as much as possible.|
|Research new features and improvements from V3||BEST EFFORT||BGD will think forward after the V3 deployment, trying to come up with new features and improvements to it, and propose them to the community.|
|Technical support on community initiatives related to the DAO treasury strategies||BEST EFFORT||Being a technical supporter of the protocol, it is outside of the scope to implement the more economic aspects of DAO treasury strategies, but BGD compromises to give support to other teams helping on that.|
|Coordination with other parties contributing to Aave||SURE||Progressively, we are seeing different initiatives of independent groups providing services to the Aave ecosystem (e.g. Gauntlet, Certora). In addition, there are long-time partnerships with other teams (e.g. Chainlink). BGD will keep communication channels and relations with these parties, in order to move the ecosystem forward.|
Our proposed compensation model from the Aave DAO to BGD Labs is based on 2 principles:
- Fixed cost for the DAO. We will be providing technical services to the DAO, so we don’t think there should be any mechanism changing the compensation depending on aspects that we consider out of the control of the community, for example, prices, or revenue of the protocol. Still, we are mindful of what is an amount that the DAO can cover at the current moment, without doing an estimation of what can happen in the future.
- Exposure only to stablecoins and AAVE. Any operative initiative needs to cover operative costs, and stablecoins are perfectly suitable for that. In parallel, apart from contributors, we are firm believers in the AAVE ecosystem, so we are prepared to receive part of the compensation in governance power (AAVE).
At the moment, the Aave treasury holds the following distribution of funds, both in general across the different networks, and specifically for stablecoins. In addition, the AAVE treasury contains 1’843’000 AAVE, which is currently being distributed mainly on liquidity mining for both the protocol and the Safety Module.
Considering the previous numbers, we request a total over 15 months of $8’000’000 in a basket of DAI, USDC, and USDT; together with 21’000 AAVE.
Even if we believe that the allocation of stablecoins should not impact in a meaningful way the treasury giving its growth over time, we propose a payment schedule of 40% at the start of the engagement ($3’200’000 in stablecoins and 8’400 AAVE) and the rest ($4’800’000 in stablecoins and 12’600 AAVE) as a stream extended for the 15 months of engagement.
Given that payment schedule, the impact on the Aave treasury at the start of the collaboration will be 7% of the current protocol treasury (non-AAVE) and 0.4% of the AAVE treasury; which we think the treasury can absorb really well, given the importance of the tasks.
- The duration of the engagement will be of 15 months (5 quarters) from the moment the first on-chain proposal is approved .
- BGD will tackle all SURE items on the task list and participate in all BEST EFFORT but is not possible to predict if all of them will be complete, as in multiple cases, decisions by the community are a pre-requirement, or the task itself has an open scope.
- BGD will have the freedom to come up with other developments to the Aave ecosystem if new needs appear during the engagement.
- The budget for external audits on the different developments is not included in the one of this proposal. At the moment, the Aave community already has a continuous engagement with Certora and the needs of the extra audit will be evaluated case-by-case on the list of tasks. It will be BGD responsibility to coordinate with security parties already engaging with the DAO and look for other security needs. In parallel, it will be the responsibility of the DAO to cover the cost of those needs.
- Deployment expenses during the completion of the tasks (e.g. deployment of smart contracts, creation of on-chain proposals, and other types of transactions required for integration on the ecosystem) will be covered by BGD. Subscription-based payments can be potentially covered temporarily by BGD, but the DAO should find a model to pay its own subscriptions. BGD will help set up that model.
In order to simplify the KPIs of this collaboration, we propose a system of 3 types of scores on each metric: Exceptional > Good > Failure .
Tasks completed . The clearest quantitative metric, but at the same time given the nature of the collaboration, is not the most representative, as in multiple cases the community should take certain decisions as pre-requisite.
- Exceptional : Having completed all “legacy” tasks (migrations, deprecation, tokens rescue), plus a new iteration of the governance, plus at least 2 useful tools for the community. Extra tasks non-expected or where the community needs to coordinate before implementation will compensate one of the previous (e.g. support on asset listings, tokenomics, development help for other ecosystem’s participants).
- Good : Having completed at least 2 legacy tasks, plus a new iteration of the governance, plus 1 useful tool for the community.
- Failure : anything below the Good level.
Participation in tasks . Evaluating general involvement and development/support efforts across the Aave ecosystem and most specifically on the pending tasks defined.
- Exceptional : Provable participation on ALL the tasks defined, both SURE and BEST EFFORT.
- Good : Provable participation on at least 75% of ALL the tasks defined.
- Failure : anything below the Good level.
In addition to the previous metrics, it will be important to consider at the end of the engagement other aspects not so quantifiable, like how many good processes BGD had helped create on the community, how good have been the collaborations with external entities connected to the ecosystem (e.g. Chainlink), reaction on incidents (e.g. security) and general availability and participation for Aave-related events.
We believe this evaluation should be the central feedback point of the collaboration at the end of the engagement, for the Aave community to decide about extension or any optional bonuses.
Ideally, we would like to start working on all the different aspects as soon as possible, but knowing the timing and requirement of the community, we think the following is the best timeline to follow:
Discussion about the collaboration here on the forum, to understand how is accepted by the community. An open meeting (e.g. Spaces) will be organized for BGD to explain in detail the proposal and the community to ask questions to the members.
Creation of a Snapshot vote, lasting for 6 days.
If YES on 2), creation of on-chain vote.
If YES on 3) project kick-off.