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.

---

---

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

If this ARFC Snapshot is 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.