Aave <> Bored Ghosts Developing. Phase 3



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.


It goes without saying that the contribution of BGD labs to the growth and stability of the Aave DAO has been unmatched. Excited to see this move forward


I’m in complete support of the proposal.

The scope of work will bring meaningful improvements to the protocol and given their track record I have no doubt they will be able to deliver with their usual competency and long-term, security first approach.

It’s been a pleasure to have worked with BGD for the last 4 years and I can only recommend them as one of the most competent and experienced technical team the DeFi space has.

1 Like

I don’t think there is much needed to say. Bgdlabs did an incredible job in the past. They always acted fast and reliable and have always been great when you needed something technical being explained in a simple manner.

Absolutely supportive and the asked amounts are fair for this kind of quality and very curios about Code A.


Certora is thrilled and in full support of phase 3!
From our perspective, BGD has been outstanding over the past two years. Their professionalism, innovation and experience, along with their clear vision for the protocol, have been an engine for the growth of Aave.
We’ve witnessed firsthand the amount of effort and attention to detail that BGD is putting into every aspect of its work, and it’s second to none. As SPs, we can attest that BGD is always available to support us on a highly technical level, e.g. on AIP reviews, and that they consistently take every concern and question we come up with in full seriousness.

We’re waiting to see the new safety module design and collaborate on it once it’s ready.


From day one (and a bit earlier) it has been an honor and a privilege working alongside & with Bgd Labs.

We have no remarks nor reservations on this proposal (other than non-compliance to our governance framework), and we’re excited to continue our journey with the BGD chads.


Over the years, Bored Ghosts have been instrumental in enriching the Aave ecosystem, continuously driving innovation in the DeFi space. Their involvement since day 1, gives them unparalleled expertise in Aave’s codebase, which positions them uniquely to further enhance and evolve the protocol.

I am deeply appreciative of Bored Ghosts’ hard work and dedication & wholeheartedly support their ongoing contributions. Looking forward to seeing how their continued efforts will shape the future of Aave.


Great to see a new proposal from @bgdlabs for the next chapter. Been amazing to follow the work so far.

Few points from my side

  • There was mention of tooling and improvements to existing pieces of infrastructure. We’ve seen that great set of tooling can help a lot the protocol to thrive. Something to mention here is that its worth considering that any new tooling would create maintenance surface in the future and would be good to plan how these tools could be maintained long-term.
  • "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.” Regarding this point, what does it exactly mean that its outside of the scope of engagement? Given previously mentioned that the Aave DAO “owns” the interface?
  • The proposal includes new strategy for new network onboardings, would be also great to think about a strategy for network offboardings if the DAO decides so (i.e. low ROI of a network) as well.
  • Regarding MixBytes potential proposal would be great to include some previous work that MixBytes have done for BGD to help the community to further assess their proposal.
  • For the Aave Safety Module, would the timeline to complete the product the same as the scope of the engagement (6 months)?
  • Regarding the compensations, its seems that they are upfront heavy, which is not necessarily an issue especially if it helps BGD to be better positioned to fulfil the scope.
  • Regarding the stablecoins element, highly recommend to include substantial GHO allocation.

Overall excited about the proposal, and also the fact that it potentially will bring two new valuable contributors into the DAO (MixBytes and Catapulta).


Thanks for the support @stani, and to answer some your questions:

In any project of our engagement where an user interface can be pretty important (e.g. if none exists on release), we create it, and the code is 1) licensed to the Aave DAO 2) deployed in some decentralised medium like IPFS and 3) designed to be ran and hosted by any participant or contributor of the DAO, in order to get maximum decentralisation.

Then, in some cases we host that interface if we see value to the community and no associated risk/conflict of interest for us (like on governance v3), but we want to clarify that in some others we would not host/run: for example, hypothetically we could create the codebase of some type of arbitrage bot within our engagement, license it to the Aave DAO, but not run it ourselves.

Generally we want to work on better off-boarding procedures, which could be applied to any Aave instances, v2 and v3.

We expect Mixbytes to present their credentials on the proposal, but apart from their participation in the past auditing Aave v2, with us Mixbytes has worked on reviewing the new voting token implementations for Aave Governance v3 ( AAVE report , stkAAVE report , aAAVE report ) and currently they are reviewing the upcoming Aave v3.1 that we will propose to the community.

We expect full completion on the 6 months mark, but definitely some components will be ready before, as the release will almost 100% be in multiple steps.

We can definitely study the possibility of introducing a GHO component on the final AIP.


After 1 week on this forum and positive feedback from the community, we have published an ARFC Snapshot for pre-approval of BGD <> Aave Phase 3, with voting starting in 24 hours.

Participate :ghost:


BGD has been instrumental to Aave’s success and we are glad to see a proposal to take Aave to the next level.

Given the input above, the following outlines a payment methodology that is aligned with existing requirements:

  • Scope 1
    • The 60% portion to be paid upfront in stable coins is to be paid in USDT from Aave v2 - 960k aUSDT.
    • The remaining stable coins (40%) are to be streamed in GHO - 640k GHO.
  • Scope 2
    • The 40% portion to be paid upfront in stable coins is to be paid in USDC from Aave v3 - 760k aEthUSDC.
    • The remaining stable coins (60%) are to be remunerated in USDC from Aave v3 - 1,140k aEthUSDC.

Please let us know if you would like to suggest something different.

To accommodate the supply of GHO for Scope 1, an additional 640k USDC from Aave v2 will be swapped to GHO within Part B of this Aave Funding Proposal.

1 Like

Full support of this proposal

Have worked alongside the Bored Ghosts Labs team and it is clear their impact and contributions in the Aave ecosystem goes without saying.


Following the positive outcome of the ARFC Snapshot with 405’000 YES votes and only 27 NO, we have created the on-chain AIP that, if approved, will kickstart the engagement for services.

Vote will start in 24 hours, participate :ghost: