bgdlabs.eth

[ARFC] Aave DAO <> BGD Labs. Phase 6 & Project E

Voting ended about 2 months agoSucceeded

Simple Summary

Present to the Aave DAO a proposal for BGD to renew our involvement as a development and security coordinator services provider (previous finished 1st October 2025), together with a new contribution direction: (codename) Project E.

Motivation

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. The start date is when the previous engagement ended, 1st October 2025.

BUDGET: 2’200’000 in stablecoins and 3’000 AAVE, 60% paid up-front and 40% streamed during the 6-month engagement.

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 can be found HERE.

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, some of them using Aave technology as a base, while others not

Regarding those Project E projects using Aave technology as 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?

A more detailed version of the terms can be found HERE, but the following is a summary of its substance.

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.
The Aave DAO is free to backport changes from Project E systems base on Aave technology to its own insfrastructure.

FAQ

And FAQ can be found on the associated forum post HERE

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

If this proposal is approved here on Snapshot, proceed with AIP for the component requiring transferring the budget for the services to be provided by BGD Labs.

Off-Chain Vote

For881.92K AAVE100%

Against0.22 AAVE0%

Abstain0.04 AAVE0%

Download mobile app to vote

Discussion

[ARFC] Aave DAO <> BGD Labs. Phase 6 & Project E

Timeline

Oct 27, 2025Proposal created
Oct 28, 2025Proposal vote started
Oct 31, 2025Proposal vote ended
Oct 31, 2025Proposal updated

Loading proposal...

Simple Summary

Motivation

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.

BUDGET: 2’200’000 in stablecoins and 3’000 AAVE, 60% paid up-front and 40% streamed during the 6-month engagement.

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 can be found HERE.

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, some of them using Aave technology as a base, while others not

Regarding those Project E projects using Aave technology as 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?

A more detailed version of the terms can be found HERE, but the following is a summary of its substance.

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.
The Aave DAO is free to backport changes from Project E systems base on Aave technology to its own insfrastructure.

FAQ

And FAQ can be found on the associated forum post HERE

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

If this proposal is approved here on Snapshot, proceed with AIP for the component requiring transferring the budget for the services to be provided by BGD Labs.