Simple summary
Present to the Aave DAO a proposal for BGD to renew our involvement as a development and security coordinator services provider, together with a new contribution direction: (codename) Project E.
Context
During the last months, it has become evident that the DAO is in a pretty different stage than it was before, amongst others:
- Arguably, for the first time, all sub-systems of Aave are in a very advanced stage of maturity: the liquidity protocol, governance, safety module (Umbrella), the GHO stablecoins, and cross-chain communication. We want to believe this is partially due to our contribution to them.
- Since our initial proposal of Aave <> BGD Labs, even as a technical contributor, we have advocated for budget sustainability (e.g., projects like Umbrella are testimony to it).
The ecosystem is economically better than ever, with growing (+$140m estimated) yearly revenue, and high-profit margins even if continuously investing in growth. It is easy to make the case for the Aave DAO to be the most sustainable decentralised DeFi system out there, at scale. - From discussions in this forum last months, in what concerns the liquidity protocol product, the focus of the DAO will tend to be progressively towards the upcoming v4 version by @AaveLabs. v3 will remain fully functional and performant for the foreseeable future, but we understand the priority will not be improving it radically anymore.
- The organisation of the DAO and its contributors seems to be evolving, in kind of an inflection point (e.g., topics proposed discussed HERE). This directly affects our contribution line to the DAO, being a service provider until now, touching almost all components of it during the last 3 and a half years.
After having completed our previous engagement for services now on 1st October (recap HERE), we now present a two-sided follow-up proposal adapted to the current state of the DAO and BGD Labs:
- A similar component on previous renewals focused on maintenance and continuous development of different components of the Aave ecosystem.
- Introducing to the community Project E, a different line of product by BGD Labs, but highly related to Aave.
Specification
Part 1. Aave <> BGD Phase 6 continuous scope
Our proposed scope of services includes the following:
-
Development/activation of any Aave v3 upgrade during the engagement duration. In addition to finishing development and security procedures on the proposed v3.6, we will activate that version in production if governance approves. Additionally, even if Aave v3 should not have many more big-scope upgrades, we will develop any upgrade we think is required during this period, e.g., if any security-related issues arise.
-
More expansions of Aave to new networks. Even if the community has been more selective during the past months regarding new networks to host Aave, precisely at the end of our Phase 5, one of them has shown tremendous success: Aave v3 Plasma. We believe the role of service providers like us working on this expansion behind the scenes to meet pretty tight timelines while maximising quality is in good part to blame for this success.
During this new Phase 6, we will continue working on expansion to new networks, some of which are already in the works.
-
Friendly forks support. During Phase 5, we defined, executed, and coordinated extensive procedures for friendly forks requiring high support from the DAO to configure and run their instance. One of them (Ink) will enter its final phase pretty soon, and then our role will be that of technical coordinator from the Aave DAO: supporting the usage of the infrastructure of the DAO, upgrades, proposals, and any required ad-hoc advice.
Additionally, we will have the capacity to support via this flow one extra friendly fork requiring similar terms to Inkâs. -
Umbrella expansion. During the previous Phase 5, we have developed Umbrella v1.1, to be presented to the community in the following days. During this upcoming Phase 6, we will prepare and activate this new version in production if governance approves.
Additionally, now that Umbrella is consistently on Target Liquidity for the initial assets, we will proceed with the expansion of the system to other networks. -
a.DI improvements. We will work on some improvements on a.DI (Aave Delivery Infrastructure), in this case, focused on having extra security and reliability.
-
Technical components of v2 off-boarding. During Phase 5, we have progressed to the final phase of Aave v2 deprecation, with all assets soon to be frozen, and other technical changes (e.g., changing Close Factor to 100%) also performed.
During Phase 6, we will support the DAO with the rest of the steps deprecating v2, to reduce the number of versions running in parallel once v4 is in production with v3. -
Technical analysis of assets to be listed on Aave. During Phase 5, we kept improving the asset analysis flow, not only in content, but also, for example, doing ad-hoc analysis on cross-chain versions of the same asset, something more common lately for listings.
Additionally, we initiated new quality flows like the AAcA (Aave Asset Class List), directly related to assetsâ analysis.
During Phase 6, we will continue working on this side of the asset onboarding stream.
-
Support risk teams from the technical side. We will support risk teams using the technical infrastructure to do risk changes, mainly via the risk stewards flow (manual, automated).
As commented on the Phase 5 recap, we have already prepared a technical revamp/simplification of the risk stewards, so during Phase 6, we will activate it and migrate all the previous components via a maintenance proposal.
Additionally, we will support risk teams in any reasonable technical requirement oriented to risk.
-
Governance proposals reviews. Similar to previous scopes, we will keep reviewing governance proposals before they go on-chain, a flow that gives a lot of value to the community, by:
- Reviewing all proposals by other SPs before they are created on-chain. This gives a very high assurance that everything being voted on is secure and of quality.
- Simplifying the review of on-chain reviewers (Certora), allowing them to focus on the most critical aspects during the limited voting period.
- We have a very important presence, also advising other contributors on how to better organise proposals, not only pure code review.
-
Continuously improve DAOâs tooling. Similar to any other previous phases, we will keep improving the different tooling of the DAO: aave proposals, helpers, Aave Seatbelt, address book, permissions book, and all others.
-
Iterate on the SVR direction. During Phase 6, we expect SVR to expand to new networks, and we will support both the DAO (execution-wise) and Chainlink (advising from the Aave DAO perspective) during the process.
-
Aave protocol security coordinator (bug bounty, Safe Harbor, ad-hoc initiatives). During Phase 6, we will act as reviewers on the Aave bug bounty program in the same projects as until now, and in addition, we will present to the community a different bug bounty framework, streamlining/optimizing all procedures.
We will also act as technical contact from the DAO side for the Safe Harbor agreement in relation to all projects we are involved.
-
Participate in the planning of any potential v3 off-boarding strategy. If the DAO approves any off-boarding plan of v3 in favour of v4 in the future, we can support by advising the DAO on what, in our opinion, is a responsible way of doing it, without disturbing operations of the DAO.
DURATION: given that the Aave v3 lifetime is not clear at the moment, the duration of the scope for services is still the same as previous scopes, 6 months, but with an extra longer stream component to not have any interruption of services afterwards, but that can be cut unilaterally by any of the parties (DAO/BGD Labs) at any point.
BUDGET: 2â200â000 in stablecoins and 3â000 AAVE, 60% paid up-front and 40% streamed during the 6-month engagement.
Additionally, a stream of the stablecoins component proportion (2â200â000/6 = 366â666/month) will keep open after the 6-month mark, for us to continue our continuous services until any of the parties (Aave DAO, ourselves) decides they are not required anymore, or terms would need to be changed. This is related to the uncertainty regarding how long Aave v3 will be running in production.
We have reduced the budget (approximately 10%) from previous scopes, as the changes on the v3 side are expected to be less frequent/sizeable by default. If this would not be the case, we would propose a separate budget correction.
What is NOT part of the scope
Similar to previous phases, we want to be explicit on what is not included in our line of contribution:
-
We are a technical provider of the community; we donât do any type of business development/or growth, which should be the responsibility of other parties.
-
We donât do formal security reviews on major developments of other contributors. We offer our security advisory for projects solely benefiting the Aave DAO, but on bigger scopes (e.g., Aave v4), that is up to parties engaged specifically on security, like Certora or other external third parties.
-
We will only provide best-effort feedback on the design of projects that we donât lead, but it is not our responsibility to make any type of design decisions or move them to production, unless we think it is reasonable for us to do so.
E.g., in a case like sGHO on our previous Phase 5, we spent more resources reviewing again and again a project that was compensated to another service provider, which we would have done ourselves from scratch. And that is detrimental for both the DAO and ourselves.
-
We only work on projects with a 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 manageable for us to support any project in the pre-TEMP CHECK stage, unless we identify a clear need from our side.
-
This scope includes EVM-only contributions. Any non-EVM ad-hoc requirement would need to be evaluated aside, as it is not our core expertise and would affect the delivery of all items in scope.
-
We are not running services on behalf of the DAO; we design them to be run 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 or Umbrellaâs) is our own decision, outside of the scope of engagement.
-
We donât produce centralised backend services for the DAO.
-
We prepare the existing technical infrastructure (e.g, Aave v3 instances) for a system fully controlled by the Aave DAO, or if following a friendly fork framework, whenever the configuration is not totally custom (e.g., main pool dynamics heavily changed, major custom code components and flows).
A full explanation of our approach to friendly forks is HERE. -
We only build user interfaces for the DAO on those projects that we believe are simply not complete without that part of the infrastructure. For example, we think a project like Umbrella requires the DAO to own a UI, no matter who then runs it. Similar applies to the Aave Governance v3 UI.
But for any additional cases, we reserve the right to decide if any interface infrastructure is produced for the DAO or is exclusive property of BGD Labs, whether those using Aave smart contracts or not.
Terms of Service
A formal Terms and Conditions document for the engagement for services between the Aave DAO and BGD Labs will be found in the proposal to be voted on by the community.
However, we would like to highlight again the same high-level points as in the previous phases:
-
Major projectsâ IP and licensing belong to the Aave DAO. The core software (e.g., all on-chain smart contracts to be used by the DAO in production after governance proposals) we create during our continuous engagement are licensed to the Aave DAO governance smart contracts, both using the BUSL approach as on Aave v3 Origin, or more open source licenses if we think expanding the usage of Aave peripheral technology only helps 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 BGD Labs.
- Our benefit from those projects is the fee we receive from the DAO for developing the software.
-
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 in 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 commitment to always following solid security standards and procedures, to minimise any potential impact.
-
We compromise to not work with competitors of Aave on any core business that could hurt the DAO. We are an independent company with potentially our own projects outside of this scope, but given our involvement, especially in the core Aave v3 protocol, we agree not to provide services to any competitor of Aave (other DeFi lending protocols) in core smart contracts development or security during these 6 months in scope.
Part 2. Introducing Project E
Project E (codename) is a suite of DeFi products to be created and owned by BGD Labs, partially using Aave technology as a base.
This will include, amongst others:
- One or multiple Aave v3 instances, exploring different use cases and configurations (e.g., types of assets listed, like RWAs, or other more DeFi exotic assets) that are not suitable for Aave DAO instances. Same as other cases like Horizon, this will require customisation on top by BGD.
- In the future, and depending on how Aave Labs proposes a model of usage of v4, potentially Aave v4 spokes will be curated/customised/controlled by BGD Labs.
What is the rationale of Project E?
- The strength of BGD Labs is being independent, regardless of whether it historically only contributed to the Aave DAO.
We see Project E as a suite of future products owned by BGD Labs, meaning keeping full independence from anybody else. This allows us to have pure creative freedom, while (more details later), giving back to the DAO. - By having full control of our own instance/s, similar to other cases like Horizon, we can cover extra use cases and configurations, while the Aave DAO benefits from technology adoption.
- We really believe Aave technology is top quality, so it is just natural for us to use it in the Project E suite of projects as one of the bases. In practice, this means we propose getting permission from the DAO to use the active version of Aave v3 (v3.5 or v3.6 if approved), akin to other projects like Horizon or Inkâs instance, but also other formats like being whitelisted to customise/curate/run spokes on the upcoming v4 model, or maybe using the Aave Umbrella codebase.
What are the terms?
Aave DAO â Project E
- Project E gets permission to use the current Aave technology as a base of its products, for example, licensing on the Aave v3 codebase.
- Project E carries no cost to the DAO: no type of upfront payment/stream from the DAO to BGD Labs, no incentives, no security expenditures, no required participation from service providers to the DAO; zero.
The point is that BGD Labs compensates the Aave DAO with revenue sharing for using the technology and/or participating in its dynamics (e.g., v4 spokes); not the DAO paying BGD Labs for doing it.
Aave DAO â Project E
- For the lifetime of any Project E system using as a base core Aave DAO contracts (or using Aave DAO infrastructure, like e.g., v4 spokes), 55% of all the on-chain revenue generated by that system goes back to the Aave DAO; 45% to Project E.
In what concerns the usage of future v4 infrastructure in the future, we are glad to abide by any to-be-defined terms by the community in the future, for entities running spokes or other models, as long as those terms are fair and equalitarian for everybody. - For the sake of clarity and given the community opposition in the past, no product of the Project E suite using base Aave DAO technology (e.g., v3 codebase, running/curating a v4 spoke, etc) will have any new token like AAVE associated with it.
FAQ
We are glad to answer any questions from the community. But the following is an additional attempt at an FAQ for more specific topics that may arise regarding Project E.
â Is the continuous scope very different from previous content-wise?
All of our scopes are different content-wise in a good percentage, and the same happens with this proposed Phase 6. However, aside from projects being slightly different (e.g., more focused on the quality and security side), the goal is always for the community to just feel that âAave just worksâ, no matter the complexity under the hood.
â In which network/s /s will Project E projects be developed?
In short, we donât know. We have different ideas, some that can potentially shine on Ethereum, some others on other L1s and/or L2s. But as we previously commented, there will be a lot of exploration to do in Project E in the following months.
â Is Project E the same as Horizon by Aave Labs?
No. Same as with Horizon, we plan to partially explore RWAs within Project E, and use Aave technology (v3, v4 spokes, etc), but Project E is fundamentally different from Horizon. To start with, it is a more open scope than Horizon, not really focusing mainly on RWAs.
â Project E will be all about smart contract systems?
Not really. It will definitely be in good part based on smart contracts, but not completely.
â Is Project E a new DeFi protocol competing with Aave?
No, Project E is not even a protocol by itself; it is an open development initiative of our own, whose products will unfold during the following months.
Within that initiative, our mission is not to create a protocol to compete with Aave, but the opposite. We really believe in the potential of current Aave technology owned by the DAO, and we are willing to pay with a majority revenue share to the DAO on any product using that technology.
â Now, plainly, financially, why is this beneficial for the DAO?
There are multiple components to this:
- Directly, the benefits are clear: 55% of the revenue produced by Aave-based products goes back to the DAO, and in exchange, the DAO doesnât cover any type of development cost, incentives, services, or security coverage; BGD Labs incurs the cost of those.
It means that there is no type of downside to the DAO. - Indirectly, BGD Labs will, in the best-case scenario, open other business lines for the DAO to take revenue from allowing the use of its technology as a base, expanding that technology adoption even more, on products âpowered by Aaveâ.
The benefits of this are arguably as important as the direct ones, especially if they come at zero cost.
â Why not just keep developing the same as until now on the DAO?
During the last months, we have found the situation around v3.X versions relatively problematic in relation to our ethos: our independence of criteria and relatively freedom (within sanity) have historically allowed us to do the best possible job for the DAO.
We fully understand, from the point of view of the community, of potentially focusing on other strategic directions like v4 and de-prioritizing v3.X incremental changes. But at the same time, we think that our role in v4 is to be very different than v3: we think Aave Labs (the developer of v4) should be the main maintainer and developer of v4, and our contribution to it makes more sense in a business line like potentially running spokes or other aspects on top of v4.
â Why is BGD Labs controlling the projects in Project E?
We believe we are at a clear inflection point for BGD Labs as a company, and also in our role on the Aave DAO.
On the latter, we think the Aave DAO needs us in a maintenance, security, and quality role; still doing development, but just to make what is already good even better.
In the first, we think it is the moment for BGD Labs to take full ownership of a product, compared with before, when our full focus has been on the Aave DAO scope.
This is nothing really new in the community: all other service providers are not fully exclusive to the Aave DAO and/or run their own independent business lines separated from the DAO.
â Will BGD Labs start working as a service provider to other lending protocols?
No. As we commented in our terms of service section, while we have a compensated continuous engagement for services with the Aave DAO, we will not provide services to any other lending protocol.
â Why doesnât BGD Labs propose a long-term engagement with some type of revenue sharing on Aave DAO instances?
One of the proposals of ACI in the Aave State of the Union governance post is to redefine service providersâ compensation, including revenue sharing or other variable models. We see the rationale of this for growth contributors, but in the case of technical/security contributors like us, we donât really see any reason because:
- Development and security work donât necessarily correlate with revenue growth, only indirectly.
- In our opinion, it creates misaligned incentives, especially on the side of quality control of our contribution (e.g., network analysis, assets onboarding analysis, advising risk providers on recommendations, etc).
Disclosures
BGD Labs has no meaningful commercial relation with entities that could create any type of conflict of interest within the scope of this proposal.
Next steps
- After discussion in this thread by the community, proceed to the ARFC Snapshot stage.
- If approved on Snapshot, proceed with AIP for the component requiring transferring the budget for the services to be provided by BGD Labs.