[ARFC] Aave <> Bored Ghosts Developing. Phase 6


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:

  1. A similar component on previous renewals focused on maintenance and continuous development of different components of the Aave ecosystem.
  2. 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.
15 Likes

BGD’s Phase 6 scope looks very solid, and their track record shows they can deliver. The budget ($2.2M plus 3,000 AAVE) is pretty much in line with what the DAO already approved for Phase 5, I believe they asked for the same amount so it’s pretty clear how important BGD Labs is to keeping Aave running smoothly. They’ve done a lot for the protocol, from security improvements to risk management tools, and their technical guidance has been really valuable.

That said, I do wonder about bundling Project E with the renewal. Unlike Horizon, which Aave Labs proposed as a separate initiative, Project E is included with a proposal that’s basically routine.

So, is Project E just a heads-up or an actual proposal? If it’s a proposal, why not fully discuss it on its own? Bundling it like this could put the DAO in a tricky spot since questioning the whole thing might be hard. As much as I love BDG, could this set a precedent where other service providers start thinking about launching their own side projects under the DAO’s umbrella? I recall last month people had questions what service providers will do with v3 after the launch of Aave v4, is this a response to that?

Multiple “Aave-based” products (Horizon, Project E, future independent) could confuse users or investors. I don’t know man… Aave Labs is already talking about building their own additional products , and now BGD? Danm. Fortunately, looking on the bright side, as long as Project E doesn’t issue its own token, there’s no issue for me.

Anyway, as a DAO member, I’m fully in support of BGD’s renewal. Everyone is thankful for them, and all Aave service providers and delegates know how critical BGD Labs is to the ecosystem, this is reflected in others forum responses as well. BGD has consistently set the benchmark for security and protocol optimization through its proactive approach and elegantly designed implementations. My only concern when I read this was on potential conflicts of interest, lack of clear governance/oversight, and the precedent it sets for other service providers launching independent projects. anyway, I look forward to seeing whatever the future holds. Have a good day guys.

Thanks for participating in the discussion @josuempia, and we appreciate the kind words regarding our contributions.

To try to answer your question about Project E being a “heads-up” or a proposal, and the bundling of everything together.

  • Project E is both an announcement of a line of products by BGD Labs and a proposal to involve the Aave DAO in some of them, with the terms proposed.

  • Similar to what was done in the past, our engagement proposals are in terms/shape that first, we believe give value to the DAO; second, is strategically interesting for us as an independent company.

    In this case, from a very high-level standpoint, the proposal it is two-sided, but one unit: we keep supporting the core infrastructure of Aave on terms that we believe are very fair for the caliber of the contribution and our track record/expertise, and at the same time, we initiate our own Project E direction, which includes the DAO allowing us to use its technology as base, with us giving majority revenue sharing when doing that, and not asking anything from the DAO.

As extra clarification, this is not really anything new on the DAO: the majority of other contributors have had extra projects in addition to their contribution to Aave, and that is just fine. The DAO is a common area of contribution, but it doesn’t necessarily need to be a limitation for service providers to have additional business, e.g., Certora providing services to other entities, Chaos Labs collaborating with other DeFi protocols, Avara/Aave Labs having additional businesses like Horizon, etc.
We didn’t really do it in the past for multiple reasons, but at the moment, the proposal is how it makes sense for us, and we believe it is attractive and worth it to the DAO.

4 Likes

Hello,

I think the scope for phase 6 is really reflecting on how mature the protocol has become with v3 and its iterations. For the protocol to grow its now only about choosing the right assets, chains and partner, and less about feature upgrades.
Its also great to see that a SP is reducing their budget based on the expected workload. I don’t recall any other SP doing this. This is a very fair approach towards the DAO.

Project E makes me curious and im happy to see its being build around Aave and the codebase which could open a new business line for the DAO. The fee sharing agreement is also great and currently the best offer made towards the DAO.

To sum it up, the scope seems solid and makes sense, its not a revolution but an evolution of improving and adding systems that already exist.
Its great seeing BGDLabs sticking with the DAO and im very excited for whats coming in the future. BGDLabs definitely made the protocol successful from from their verticale.

Happy to support scope 6

3 Likes

Yes, overall I think the proposal makes a lot of sense, especially with BGD Labs having a future vision of building its own products and becoming more self-sustaining.

The reasoning is clear:

  • As Aave V3 and its ecosystem mature, the work will naturally shift more toward full maintenance rather than continuous feature overhauls.

  • Positioning BGD Labs to branch into product development (ramping down servicing the Aave Protocol) is a strong strategic move, giving upside and optionality beyond pure protocol maintenance.

  • The proposed fee-sharing / revenue alignment also strengthens incentives between the DAO and BGD, reducing the risk of misaligned goals.

That said, the only aspect I am not fully comfortable with is leaving an open, indefinite maintenance stream (i.e. open-ended allocation or funding). Given that the maintenance burden on Aave V3 is expected to decrease significantly over time, a perpetual open stream may risk overpaying for diminishing effort.

A more balanced approach could be to review the maintenance proposal again in 6 months, ensuring that funding and scope can be adjusted downward as maintenance demands decline and BGD ramps up its own business activities. This would reconcile the desire for long-term commitment with the reality of decreasing incremental work.

From a tokenholder perspective, one question I have is: if BGD makes changes to the licensed code base, would those changes be available for the Aave DAO as well, or only exclusively for BGD’s own products?