Aave <> Bored Ghosts Developing. Phase 2



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).


  • 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.
  • 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.


6 months duration, from the execution of the on-chain governance proposal acting as the agreement between the Aave DAO and BGD Labs.


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

  1. 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.
  2. Wednesday 16th we will create the Snapshot vote following the standard procedure of the community.
  3. 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.

We enthusiastically support BGD’s proposal! Certora has been working with the BGD team since its inception (and previously in Aave). We have audited and formally verified code sent to us by BGD, have contacted them for incident response, and collaborated with BGD on community verification and bug hunting competitions. We see BGD as one of the most innovative and capable teams in the DeFi space and see their future contribution as a key to the success of the AAVE protocol and its applications.


Hi, @bgdlabs .
I would like to thank BGD Labs for all the development over the 15 months on the Aave Ecosystem and are pleased to be able to renew contract.

It is recommended to contract to pay 6000 AAVE after 6 months as a performance fee.


As a service provider with 62 AIPs reviewed by BGDLabs in 2023, I can only speak highly of this service provider.

The ACI provides full support for this phase II.


We’ve had a very positive and fruitful working relationship with BGD Labs, for the Aave DAO, over the past 12 months. Their code is always a pleasure to review, and their knowledge of the Aave ecosystem is unrivaled. In addition to their technical contributions which were extensive and critical to the success of Aave, their coordination skills, in particular for security assessments, have been instrumental in ensuring the protocol’s safety.

Sigma Prime is very supportive of this proposal.

1 Like

Working with the BGD team has been a pleasure, and they have been extremely professional and attentive in every engagement we’ve had. This is true not only in areas that fall directly under their purview but also in matters that extend beyond their specific responsibilities. The BGD team are true experts, possessing invaluable experience and an intimate understanding of the protocol. They are a valuable resource in any discussion and decision-making process concerning the protocol. I specifically commend the team for being a true partner in their proactiveness and role in risk discussions in all of the major market events over the past year.

Big support for this proposal.

1 Like

I would like to extend my congratulations to BGD Labs on their 15-month service to Aave! It’s been an incredible achievement, and I look forward to seeing their evolution with their Phase II proposal.

Having had the privilege to work closely with the BGD team since the launch of Aave v1, I can attest that BGD Labs is at the forefront of their field for technical leadership , security initiatives and quality assurance and development support to partners and contributors. Their contribution was essential in developing and launching the Aave v3 protocol. On top of that, they have made countless efforts to keep iterating and refining protocol features such as the Safety Module, v2 migrations, new asset/chain deployment processes, and of course, always being quick to provide technical support for incident response or ad-hoc needs.

Their innovative approach to best security practices, such as bounty programs, the ongoing development of Aave Forest, and enabling Proof of Reserve for multichain markets to protect users from bridge risks sets a great example for security concepts in the DeFi space .

Additionally, their pioneering work with Aave Seatbelt, Chainlink Automation for the Aave Robot, and Chainlink CCIP for a.DI showcases their ability to deliver next-gen technology that continues to make Aave a market leader.

I am thrilled to offer my full support to BGD’s new proposal, as I am confident that they will continue to be instrumental in the development of Aave. BGD Labs is a massive asset to the Aave community, and I look forward to supporting their continued success!


@bgdlabs has consistently delivered value on Aave’s most important development aspects. Among their many contributions to the DAO, we would like to highlight the below to the community, which have positively moved the needle from a technical perspective:

  • Technical review of proposals covering hundreds of parameter changes to the protocol
  • Development of the Risk Steward
  • Technical risk assessment of key events such as the Shanghai upgrade and Optimism Bedrock upgrade
  • Technical collaboration on innovations such as the LST Killswitch - the first of its kind in DeFi

We appreciate when BGD weighs in publicly. They literally write the code base and have near universal respect in the community. We’d like to see and hear more from them whenever possible.

The budget of BGD Phase 1 was certainly commensurate with the value that BGD has brought to Aave, and this remains the case with Phase 2.

Gauntlet will be supporting this proposal.


Following the good feedback on this post and after some extra days to gather comments, we have published a Snapshot vote for pre-approval from the community.

Voting will start in ~24 and last for 3 days. Participate :ghost:



The Snapshot proposal has passed, with 728’000 YES votes, 1’500 ABSTAIN, and 4.1 NO, representing a 99.79% YES approval rate and a pretty high participation rate.

Thanks to all the community for the support :pray:

Early next week, we will proceed to the on-chain AIP stage.


It is clear BGD has done exceptional work – half the protocol or new features are thanks to them.

A small detail I’d like to push on is eliminating the ask for AAVE and paying the full-contract in stables or a non-native token. No issue with the ask or scope – but instead the composition of the budget.

Most service providers request AAVE or stkAAVE for “strong alignment the protocol” or to align incentives.

This already exists with BGD in a personal and professional capacity – well beyond any other service provider. As a collective they control 230,000+ AAVE or equivalent.

As an aggregate this is a significant amount of active control of the protocol.

I’m not sure this is the most sustainable route for long-term service providers for Aave which we expect and hope BGD will be. It is powerful — and hard to combat in times of disagreement.

I hope we can hold each service provider to the same standard, as shared in the Chaos’ thread here.


Thanks for the kind words and the support @fig , but some clarification regarding the AAVE component.

The inclusion of AAVE as a percentage of the budget is for 2 reasons:

  1. Exposure to AAVE long-term, given its nature of governance assets of the ecosystem. We feel it is just normal for an entity involved in the development of the ecosystem to have that exposure, even if some other community participants think differently.
  2. Currently, the stablecoins portion on the Aave Collector is something that should be treated with care, so an AAVE component reduces the impact there.

We think this is reasonable, and that is why is included in the proposal, Snapshot, and upcoming AIP.

Regarding the BGD’s AAVE governance power:

  • As a company, BGD has never participated/doesn’t participate in voting, for a matter of neutrality, given the ongoing working relation on the development section. We don’t see any problem with other entities participating, but it is our own decision to avoid any kind of conflict.
  • At the current moment, BGD categorically doesn’t control 230’000 AAVE, and as an entity doesn’t have any influence on how team members use their assets, including AAVE or any other.
1 Like

Following the timeline and the previous pre-approval on Snapshot, we have created an on-chain proposal for Aave <> BGD Phase 2.

The proposal will serve as a binding agreement for services between the Aave community and BGD Labs, proceeding with the payment plan, via direct transfers and streams creation.
All details can be found in the proposal’s specifications.

Voting will start in ~24h, participate :ghost:

1 Like

Fair enough —

I’d push back on point #1. An alternative way to look at this is like distributing equity.

Imagine if you paid an infrastructure vendor – like Oracle — every year equity in your company. Over time you would trade a service for ownership of your company with no contractual loyalty.

Nothing stops an organization from using these rights.

I’m glad it’s progressed to an AIP and hope to inform the community in the future.

P.S. This is the keyword:

BGD individual members’ influence is alive and well.


Aave governance proposal 311 has been successfully passed, which means the Aave <> BGD Labs Phase 2 engagement is now completely approved.

Thanks to the community for the support during the whole process; now it is time for us to keep delivering!

Similar to during Phase 1, we will keep updating the community whenever we progress on or release projects, with updates on multiple fronts coming really soon.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.