Aave <> Bored Ghosts Developing (BGD)

[eboado]

TL;DR

Announcement of the creation of the Bored Ghosts Developing (BGD Labs) initiative to provide support on the development of the Aave ecosystem from the community, proposing an open list of tasks and budget, to participate in a time span of 15 months (5 quarters).

The proposal

Rationale

State of the Aave ecosystem

Since its inception, the Aave ecosystem has been growing at an impressive level from all perspectives: users, innovations brought to DeFi, security, assets locked, integrations, and contributors, amongst others.

From an Ethereum-based liquidity facility on v1, Aave has evolved into a multi-chain liquidity protocol on v3, a governance system and token, a safety mechanism, cross-chain communication tools, and other components complementing the previous ones. Part of the ecosystem is too other innovations like the Arc pool focused on institutions or the RWA pool focused on unlocking liquidity for real estate.

Currently, we have reached a quite mature point as a community. Aave is completely functional, self-sustained, and self-sovereign. The community makes all decisions on the ecosystem’s general direction (approving the next iterations of the protocol and governance), onboards contributors for different needs (e.g. Gauntlet for risk) and discusses actively all kinds of aspects affecting its future here, on the forum.

But there is still one particular field on which the community should improve and that is the support and core development of the different systems of the Aave protocol.

Why a team of dedicated contributors

The numbers of the Aave protocol are in the hundreds of thousands of users, the assets involved, in the order of billions of dollars. And this is on an ever-changing landscape, with new chains appearing all the time or even completely fundamental changes to the basic mechanisms of the basic infrastructure, like Ethereum.

Aave has seen a myriad of contributors over these years, but there is still a lack of more teams with the knowledge, mission/values, and trustworthiness to take care of the core technical tasks of the ecosystem. Especially, this will become really important with the amount of innovation introduced now with Aave v3, and everything else to come around it.

Who we are

The initiative

We are BGD Labs (@bgdlabs on Twitter ), as the name says (Bored Ghosts Developing), a group founded by 3 Aave community members with deep technical expertise on Aave and DeFi in general.

We had an important role in creating Aave and now we believe it is time to stay in the community and help with our skills.

Founding members

We and our credentials are:

• Ernesto Boado (@eboado on forum, @eboadom on Twitter). DeFi developer and Aave community member. Previously, I was acting as CTO at the Aave Genesis Team, being one of the initial team members since pre-Aave times. I participated in the design, architecture, and implementation of pretty much all the developments of the Aave ecosystem, with a specific focus on high-level design and economics, implementation, and management. Lately, I’m working on multiple Aave proposals (Aave Governance V3, Aave <> Starknet, oracles optimization, Safety Module migrations, …) and exploring plenty of others with other community members.
• Emilio Frangella (@emilio on forum, @The3D_ on Twitter). DeFi developer and Aave community member. One of the initial members of the Aave Genesis Team since pre-Aave times. Participated in the design, architecture, and implementation of pretty much all the developments of the Aave ecosystem, with a specific focus on both high-level and low-level design and implementation of smart contracts and DeFi economics. Lately, Emilio led the development of Aave V3, before its handover to the community, in parallel with participating in multiple community proposals and discussions.
• Andrey Kozlov (@Andyko on forum, @andy_koz). DeFi developer and Aave community member. Previously, Head of Backend/Frontend at the Aave Genesis Team, and also one of the initial members since pre-Aave times. Participated in the design, architecture, and implementation of pretty much all the developments of the Aave ecosystem, especially on all front-end and back-end components, with participation on the smart contracts side too. Lately, mainly been involved in some community proposals.

Mission and values

Roles assumed in the past apart, we are a group of technical contributors. We had an important role in the inception and evolution of Aave and, because of that, we feel that we should be involved in helping the community on the aspects we are able to.

The mission of BGD Labs can be summarised on the following:

• Compromise first . Being in the DeFi community since the beginning, one of the problematic aspects around it and DAOs, in general, is the lack of compromise. We don’t believe that is inherent to decentralization, so we compromise on the tackled tasks, doesn’t matter if the counter-party is a DAO or not.
• Security before pace . Aave has moved really fast in the past and should keep doing the same in the future. But it is important to highlight that pace was always secondary versus the security of what was delivered on the ecosystem. As the size and complexity of Aave grow, this order of priority needs to be kept, and that is our mentality.
• Expertise and openness . At the moment, it is not realistic to do core development of a system like Aave without expertise. At the same time that we participate with ours, we welcome other capable individuals to contribute as well and plan to help them, whether with BGC or as community members.
• Responsible freedom . We as members of BGD are the professionals we are because we had enough freedom in the past to come up with ideas we believe introduced innovation on the field. But with only freedom and no responsibility and organization, Aave would not be what it is at the moment. BGD will have a responsible approach when tackling all the tasks, but still, exercise the freedom to come up with new ideas or different approaches that we believe would improve the Aave ecosystem.
• Aave first . We compromise to work with the Aave community, and given the nature of this work, we believe there is a conflict of interest to work with similar protocols. So BGD Labs will not work with any other protocol considered in any level competitor of Aave.
• Open code for the Aave community . We believe in the creation of common goods, so all the code created by BGD Labs in relation to specific tasks on Aave will be open and owned by the Aave DAO itself, whenever possible.

The project

Pending/ongoing tasks on the ecosystem

At the moment, there are several aspects that need one-time and continuous development support on Aave.

On the following list, we present the ones that we believe BGD can help with. We divide them into these 2 classes:

• SURE . BGD will tackle the task, and uncertainties apart (community not approving, model not really defined, etc), will compromise to complete it.
• BEST EFFORT . BGD will participate in the task, potentially completing it too, but usually, the scope is too broad or undefined at the moment to compromise to a level of completion at the moment.

Aave tasks

Task	Type	Description
Maintenance of Aave V2 contracts until migration to V3	SURE	Aave V3’s objective is to expand the protocol to new chains and rollups since day 0, with “fresh” deployments of the smart contracts and the infrastructure. However, the Ethereum V2 pool will need to be migrated to V3 (as already contemplated on the V3 proposal by @emilio ), and given the size of V2, there will still be technical supervision needs until that happens. In addition, until liquidity migrates naturally to V3, there is also V2 deployments on Avalanche and Polygon. Until that migration happens (and after), BGD will support technically the current V2 deployments.
Migrating V2 markets to V3	SURE	As a consequence of the previous point, BGD will support the technical migration of the V2 deployments to V3, as needed.
Technical support on listing of new assets	BEST EFFORT	Part of a liquidity protocol like Aave is the ongoing evaluation and listing of new assets into the pool. We observed and experienced that only a really small minority of external teams are capable of going through the technicalities of listing an asset on Aave without technical support. BGD will help will this, including all listing across all networks where Aave is/will be present. This will become specially important with V3, as its features “incentivise” new listings of assets.
Create and improve tooling to monitor governance proposals and their general correctness	SURE	Decentralized and open governance has its challenges, one of them being the correctness of the executable code of proposals (payloads). BGD compromises to continuously monitor submitted proposals to the Governance, together with the development of automated and open tools to reduce the risks as much as possible.
Migration of ABPT Balancer pool to Balancer v2	SURE	The ABPT Safety Module component is still running on Balancer V1, which is not anymore the updated version of the Balancer pools. BGD compromises to tackle this migration.
Technical support on deployments for new chains	BEST EFFORT	Aave’s multi-chain strategy is clearly targeting future expansion. Multiple teams submit proposals on this forum to get approval from the community to deploy Aave on their associated network. But as expected, usually those teams don’t have the Aave-specific expertise to manage an end-to-end deployment, and Aave community members need to help. BGD will support these external teams on the deployments as much as possible.
Implementation and deployment of Aave Governance V3	SURE	As presented here, it is quite probable that the Aave Governance system will evolve in the following months. This will take an important end-to-end technical effort, and BGD compromises to tackle it.
Technical assistance and implementation if the community creates a new iteration of the AAVE tokenomics	SURE	Tokenonomics are usually an ever-evolving field on DeFi, and no exception to it is AAVE and all its flavors. Lately, there has been some discussion in the community about introducing improved levers on the AAVE mechanisms, complementary with other parallel developments like the V3 of protocol and governance, or new models for the Safety Module. Even if being an early stage discussion, BGD compromises to technically assist on the decisions of the community concerning tokenomics, naturally evaluating the effort once the vision is outlined.
Technical support and implementation to close LEND-to-AAVE migration, if approved by the community	SURE	Currently, there are still some LEND funds still now migrated to AAVE. Given the time passed since the migration, the community has discussed recovering the non-migrated LEND funds (most probably lost) to be placed for better use on the Aave ecosystem. BGD will assist in the implementation and execution of this.
Technical maintenance and improvement of the Aave liquidity protocol UI	SURE	At the moment, it is possible to access the Aave protocol from multiple points: UIs, smart contracts’ integrations, crypto wallets, custodians, etc. One of these access points is the open-sourced Aave UI hosted in a decentralized way on IPFS here. BGD will participate in the maintenance of the decentralized Aave UI.
Technical maintenance and improvement of the Aave safety module UI	SURE	With the upcoming improvement of the Aave decentralized UI consequence of Aave V3, it is quite probable that the section dedicated to the Safety Module will need to be re-evaluated and improved in the future. In addition, new models of Safety Module could be included. BGD compromises to participate in the development of this UI component.
Technical maintenance and improvement of the Aave governance UI	SURE	Decentralized governance is still in its really early times, so its evolution is constant. Aave is no exception to that and even considering that there are multiple points to participate in its governance system (discussions here on the forum, Snapshot, governance aggregators), the community can expect changes affecting UI and off-chain infrastructure in the near future. BGD compromises to participate in this development.
Managing deprecation of Aave V1	SURE	With the upcoming V3, it is pretty clear that V1 should be completely deprecated, as it is clearly suboptimal compared first with V2 and V3. BGD compromises to support the community on the technical aspects of this deprecation.
Technical support for teams developing products on the ecosystem, depending on capacity	BEST EFFORT	Supporting technically the development of some Aave initiatives, we believe we will have an obligation with the community as a whole to pass our knowledge to everybody else. Because of that, BGD will try to support as much as possible other teams developing products connected with the ecosystem.
Point of contact for security disclosures and action	SURE	On open DeFi protocols, there are from time to time security disclosures of potential technicals problems. Given our experience in the past, BGD will act as a point of contact for security disclosures concerning the Aave ecosystem and will take action on them.
Rescue locked funds send directly to contracts of the Aave ecosystem	SURE	As discussed here, since the inception of the protocol, some users have miss-sent and “locked” tokens to different smart contract addresses of the ecosystem, in some cases, recoverable. BGD will help on this, under the limitations of complexity or even feasibility depending on the contract with tokens locked.
Explore and propose to the community integrations of the ecosystem with other protocols	BEST EFFORT	For Aave to continue evolving, it is fundamental to keep up with new developments happening on other protocols around, and potential technical/economical synergies. BGD compromises to explore new models in this regard, proposing to the community for feedback as much as possible.
Research new features and improvements from V3	BEST EFFORT	BGD will think forward after the V3 deployment, trying to come up with new features and improvements to it, and propose them to the community.
Technical support on community initiatives related to the DAO treasury strategies	BEST EFFORT	Being a technical supporter of the protocol, it is outside of the scope to implement the more economic aspects of DAO treasury strategies, but BGD compromises to give support to other teams helping on that.
Coordination with other parties contributing to Aave	SURE	Progressively, we are seeing different initiatives of independent groups providing services to the Aave ecosystem (e.g. Gauntlet, Certora). In addition, there are long-time partnerships with other teams (e.g. Chainlink). BGD will keep communication channels and relations with these parties, in order to move the ecosystem forward.

Compensation model

Our proposed compensation model from the Aave DAO to BGD Labs is based on 2 principles:

• Fixed cost for the DAO. We will be providing technical services to the DAO, so we don’t think there should be any mechanism changing the compensation depending on aspects that we consider out of the control of the community, for example, prices, or revenue of the protocol. Still, we are mindful of what is an amount that the DAO can cover at the current moment, without doing an estimation of what can happen in the future.
• Exposure only to stablecoins and AAVE. Any operative initiative needs to cover operative costs, and stablecoins are perfectly suitable for that. In parallel, apart from contributors, we are firm believers in the AAVE ecosystem, so we are prepared to receive part of the compensation in governance power (AAVE).

At the moment, the Aave treasury holds the following distribution of funds, both in general across the different networks, and specifically for stablecoins. In addition, the AAVE treasury contains 1’843’000 AAVE, which is currently being distributed mainly on liquidity mining for both the protocol and the Safety Module.

Considering the previous numbers, we request a total over 15 months of $8’000’000 in a basket of DAI, USDC, and USDT; together with 21’000 AAVE.

Even if we believe that the allocation of stablecoins should not impact in a meaningful way the treasury giving its growth over time, we propose a payment schedule of 40% at the start of the engagement ($3’200’000 in stablecoins and 8’400 AAVE) and the rest ($4’800’000 in stablecoins and 12’600 AAVE) as a stream extended for the 15 months of engagement.

Given that payment schedule, the impact on the Aave treasury at the start of the collaboration will be 7% of the current protocol treasury (non-AAVE) and 0.4% of the AAVE treasury; which we think the treasury can absorb really well, given the importance of the tasks.

Engagement expectations

• The duration of the engagement will be of 15 months (5 quarters) from the moment the first on-chain proposal is approved .
• BGD will tackle all SURE items on the task list and participate in all BEST EFFORT but is not possible to predict if all of them will be complete, as in multiple cases, decisions by the community are a pre-requirement, or the task itself has an open scope.
• BGD will have the freedom to come up with other developments to the Aave ecosystem if new needs appear during the engagement.
• The budget for external audits on the different developments is not included in the one of this proposal. At the moment, the Aave community already has a continuous engagement with Certora and the needs of the extra audit will be evaluated case-by-case on the list of tasks. It will be BGD responsibility to coordinate with security parties already engaging with the DAO and look for other security needs. In parallel, it will be the responsibility of the DAO to cover the cost of those needs.
• Deployment expenses during the completion of the tasks (e.g. deployment of smart contracts, creation of on-chain proposals, and other types of transactions required for integration on the ecosystem) will be covered by BGD. Subscription-based payments can be potentially covered temporarily by BGD, but the DAO should find a model to pay its own subscriptions. BGD will help set up that model.

Evaluation metrics

In order to simplify the KPIs of this collaboration, we propose a system of 3 types of scores on each metric: Exceptional > Good > Failure .

• Tasks completed . The clearest quantitative metric, but at the same time given the nature of the collaboration, is not the most representative, as in multiple cases the community should take certain decisions as pre-requisite.
  • Exceptional : Having completed all “legacy” tasks (migrations, deprecation, tokens rescue), plus a new iteration of the governance, plus at least 2 useful tools for the community. Extra tasks non-expected or where the community needs to coordinate before implementation will compensate one of the previous (e.g. support on asset listings, tokenomics, development help for other ecosystem’s participants).
  • Good : Having completed at least 2 legacy tasks, plus a new iteration of the governance, plus 1 useful tool for the community.
  • Failure : anything below the Good level.
• Participation in tasks . Evaluating general involvement and development/support efforts across the Aave ecosystem and most specifically on the pending tasks defined.
  • Exceptional : Provable participation on ALL the tasks defined, both SURE and BEST EFFORT.
  • Good : Provable participation on at least 75% of ALL the tasks defined.
  • Failure : anything below the Good level.

In addition to the previous metrics, it will be important to consider at the end of the engagement other aspects not so quantifiable, like how many good processes BGD had helped create on the community, how good have been the collaborations with external entities connected to the ecosystem (e.g. Chainlink), reaction on incidents (e.g. security) and general availability and participation for Aave-related events.

We believe this evaluation should be the central feedback point of the collaboration at the end of the engagement, for the Aave community to decide about extension or any optional bonuses.

Proposal roadmap

Ideally, we would like to start working on all the different aspects as soon as possible, but knowing the timing and requirement of the community, we think the following is the best timeline to follow:

1. Discussion about the collaboration here on the forum, to understand how is accepted by the community. An open meeting (e.g. Spaces) will be organized for BGD to explain in detail the proposal and the community to ask questions to the members.
   https://twitter.com/bgdlabs/status/1508459007287169029

2. Creation of a Snapshot vote, lasting for 6 days.
   https://snapshot.org/#/aave.eth/proposal/0x10e6378f193ec4a2953b3ca73b86947586676250191346a90ed4c83593f14883

3. If YES on 2), creation of on-chain vote.

4. If YES on 3) project kick-off.

[raho]

I think this is a fantastic idea and I would love to see it for Aave’s community! I am currently in Rabbithole’s metagovernance pod, acting as a Protocol lead.

I believe that working groups are a fantastic way not only for the completion of tasks, but also for protocol ‘ownership’. As more people are placed in dedicated roles (as mentioned above), governance participation could see a massive increase!

[superproduct]

I strongly support this initiative and the team is serving the interests of the community, growth and sustainability of the aave protocol

[Jordan]

Hi everyone,
Firstly I would like to thanks @eboado @Andyko @Emilio for staying in the ecosystem and looking to contribute forward to the maintaince and innovation of the Aave protocol. As ex-COO of Aave, I worked alongside them for the past 4 years and they are the Aave Protocol.
Secondly I think the cost is quite reasonnable and aligned with the current Business to DAO models out there (see Gauntlet) especially knowing that the Protocol would not be taking a bet on an unknown team but literally paying those who built and created its architecture to continue working on it.
There is plenty of tasks at hand from migrating the safety module to the tokenomics revamp which don’t have a strong lead in the community and i know they work with security first in mind.

One of the many issue most DAOs face today is the lack of community contributor who are well incentivized and have deep knowledge of the ins and outs of the code base; While the companies behind those protocol often work on others projects and sidequests as the marketing or financial upside looks more rewarding than focusing on innovation of the OG protocols.

Finally in a position where the founding team decide to stay around and work as community members having to be transparent and responsible in the eyes of the community is probably the best for the Aave protocol and i can’t think of any other protocol who has this luck.
So for me this is a no brainer, those are “the devs behind the aave protocol” who built during the last bear market and made the transition between ETHLend and Aave.
I will vote yes to this proposal.

Long the Bored Ghosts

[fig]

Had fun reading this - at first, I thought BGD was another token but I am relieved to hear it is not!

I will echo the sentiment above that @eboado @Emilio are a strong fit for the project - their involvement and passion for Aave has been very apparent in the forums and important discussions.

Do you intend on expanding the group beyond 3 members?

2nd - how did you choose the 15 month period? Seems one of the longer commitments.

Interesting to see how the community reacts to below:

@eboado

7% of the current protocol treasury (non-AAVE) and 0.4% of the AAVE treasury; which we think the treasury can absorb really well, given the importance of the tasks.

While I agree the treasury can rebound from this spend quickly, 7% is a significant amount of stablecoin use.

[eboado]

Hi @fig, thanks for your comment, as it opens to comment on certain points.

I answer one-by-one:

1. On the proposal, we outline the co-founders of the initiative, but we are already a bigger team. As we commented on our announcement on Twitter, we welcome talented people in the community to contact us to join us, but, even if we are targeting a team of slightly bigger, we are really confident from our analysis that currently, we are up to the proposal with our team.

2. Mainly there were two considerations when proposing this duration:

• The list of tasks is pretty extensive, and in the case of BEST EFFORT, not even completely scoped by the community. So there needs to be time enough to maneuver in order to do a good job.

• This is the first engagement for development from the community. Even if not only that, Aave has a really core component of development, so we believe some stability is important. Typical development cycles on established platforms are quarterly, with usually yearly macro-cycles. Considering that, we think a year plus an extra quarter of margin is a good duration.

3. About the budget, at the moment the operational expenses of an ecosystem like Aave are insignificant, compared with the value locked and other expenses like liquidity mining. If we take into account that apart from the current savings of the protocol, the treasury is growing at a rhythm of $2-4m per month, we are talking of 1-2 months of revenue to cover the initial payment and then only a small percentage of the revenue per month to cover the stream. I simplify a bit on that sense to not take much into account the current savings even, because personally I always defended the self-sustainability of the protocol treasury, to not depend on the AAVE treasury.
   Also, Aave v3 revenue streams were not really taken into account in the proposal, but it is pretty clear that it will increase the total savings of the protocol, as it has optimized channels for it.
   So given that basically, we plan to cover almost all technical needs during the period, we think it is quite a reasonable budget, and given the fixed nature of it, predictable.

[brandon]

I’ve had the pleasure of knowing @Emilio for about two years and been able to work next to him at a few hackathons. I can say that he’s the real deal and cares deeply about the Aave platform and community. I can’t think of better hands for development to be in.

Similarly, my interactions with @eboado have been solid and I trust this decision making and leadership.

I support this proposal and it’s great to see how far the Aave ecosystem has come since launch.

[pakim249]

This is awesome, and in my opinion long overdue. For AAVE to truly function as a base layer of the ecosystem, dedicated developers with deep knowledge of AAVE dedicated to community support are absolutely necessary. Many proposals have gone by in this forum with very limited developer support, which I feel has unfortunately burnt out a lot of people from engaging with AAVE. I believe that BGD is exercising very good judgement in dedicating their resources towards this.

Simply based on the promised SURE tasks, I would say the price paid is well worth it based on what the community will be getting. This type of work would probably require dozens of developers ordinarily, and imho the stuff in this list promises to be much more valuable than any other proposal so far.

As far as improvements to this proposal are concerned, I wonder if the evaluation metrics could be reworked a bit? I believe the team is trustworthy, but I think the spirit of decentralization demands that the DAO be able to provide feedback and accountability to this new team on a somewhat regular basis. 15 months seems quite long considering that.

Let’s get this bank demolition underway!

[fcmartinelli]

Love this proposal and think this is a great way to boost even further the decentralized contribution to Aave protocol.

The team behind BGD is extremely trustworthy and known to have delivered some of the finest code in DeFi to date. I’m sure once they have funding through this proposal they will manage to get further talent to help them tackle the vast scope of important tasks mentioned.

Looking forward to this

[eboado]

Hi @pakim249, really appreciate your support, being a really active member of the community.

Regarding your point about evaluation, something on what I would like to put the focus (and maybe not completely clear on the proposal) is on how we plan to operate on a daily basis.

The idea is, as much as possible, to have public development of all the tasks that don’t involve interaction with external parties looking for confidentiality. In addition to that, we (members of BGD) plan to be even more active than before in the community; meaning participating here on the forum, Discord, community calls, and specifically concerning this project, doing most probably bi-weekly summaries on how the different fronts are progressing.

That transparency, combined with the model of payment based on a continuous stream, should give quite a lot of confidence to the community to still have important power of decision, being able to hold BGD accountable.

Basically, as we comment on the proposal, at the moment we consider there is a big problem (with exceptions of course) of dedication when engaging with DAOs. So tasks apart, our proposal is mainly about that, dedication to and compromise with a community of which we are part.

[Shelly]

We at Certora strongly support the BGD initiative to develop core engineering methods and initiate new utilities to strengthen the Aave ecosystem. We are supporting and can personally attest to this highly professional, security oriented team.

The Aave team has always been super responsive to security findings and super pedantic about the code.

Certora plans to collaborate closely with BGD team on the developments to ensure its continuous security and correctness.

[samyak]

I totally support this proposal. Being the founding and core members of the Aave protocol who developed the core code for Aave and who knows in and out of what every line of code does. It is very important to have proper incentivization to make sure any upgrade on Aave is properly secure. I believe in “no one can audit better than the one who did the entire code”. So having those members align to protocol and giving proper incentivization will make sure that the code is extremely secure.

[0xMaki]

I support the proposal,

Mainly interacted with Emilio & briefly with Ernesto both are fantastic talent dedicated to the long term success of the protocol this seems like a nobrainer.

I hope to see BGD team grow further with this budget and showcase how other community-led contributors be incentivized to help in Aave development.

0xMaki

[FoxSteven]

I too support this proposal - I can think of no better three to lead it either

I’m excited to see more labs developing in the future to take the lead on various other initiatives.

[dhadrien]

As a former aavengineer working daily with Ernesto, Emilio and Andrei on Aave Protocol, I support this proposal. They are experts with strong ethics that work well together. They demonstrated multiple times an impressive ability to release ambitious yet secure code to improve Aave usability, security and soundness.

Aave Protocol is lucky to have BGD, it is a rare sign of true decentralization! I’m excited for Aave but also for DeFi in general to see one of its major protocol getting decentralized in real time.

[EzR3aL]

Hello everyone, first of all congratulations to Aave for launching v3. What a ride from EthLend, where Stani asked me to translate the dapp to v3 Aave now.

Secondly i am also in favour of BGD. Its nice to see these 3 people working on something that is a key protocol in DeFi.
I have only one question regarding the costs. As I really don’t know how “expensive” it is those numbers seem high for me. I think there are several people in here that feel so too. Thats why I think it would be great if you could ELI5 to us how they are being used. Maybe explain some costs for infrastructure, payments, salary and stuff like that. Just to have a better understanding.
In general the protocol should easily handle this amount.

Thank you

[JohannEid]

Hey everyone, as the head of integration at Chainlink I’ve had the pleasure of working with Emilio, Ernesto and Andrey for the last 2 years. I can attest personally of their unparalleled contribution to the Aave protocol and community.

They are hard workers who in my experience are both able to move fast, contributing to Aave being the a player in DeFi today and always with security in mind being one of the few protocols which has had 0 security issues since it’s conception.

I strongly support this proposal and look forward to working with this team on oracles for the years to come.

[eboado]

Hi @ezr3al, thanks for the support.

Regarding your question about the allocation of funds, some aspects:

• Even with the co-founders of BGD Labs being personally community members of Aave, BGD Labs will act as a service provider to the Aave DAO with this proposal. This means that we are an independent venture engaging with an entity (the Aave DAO) for the list of tasks presented, no matter if their scope is more or less opened. That being said, the budget proposed is a consequence of evaluating the importance of the service we provide, together with the difficulty of the tasks, together with the market of expertise out there: we will not be just 3 persons alone, we also want to attract talent. And of course, in order to be consistent with what we personally believe in, we tried to be conservative enough for the Aave DAO to absorb pretty well the cost.

• In terms of the breakdown of the budget, part of it will be used to pay for talent to tackle the different tasks, and part to the different costs that can appear in the road, mainly deployment costs, creation of proposals, and infrastructure subscriptions (at least initially). That being said, talent is the most costly part, given the scarcity on the market.

• I would not go into a detailed allocation of the budget, because we really believe in independence and privacy. So even if we think it is fine for BGD to have public financials in what regards the proposal (given the nature of the engagement), we also prefer to keep our internal financial planning private.

[Yael-StarkWare]

This is a great initiative! Knowing @eboado @Emilio and @Andyko from the Aave <> StarkNet project makes me fully competent that the project will be pushed forward to reach the maximal outcome and fulfill its goals. Surely the professional experience these guys have is exactly whats needed fo this type of project.
I would obviously love to see these features and improvements in the future also on StarkNet and hope that this initiative will continue to grow also past the 15 month period mentioned here.

[stani]

After waiting for a while to get community input first, I decided now that its good time to come here and express my full support for @eboado @Andyko and @Emilio for deciding to stay in the community after many years of development of the Aave Protocol.

First, I believe that the team of BGD would be fully capable of executing the roadmap given the existing knowledge of the protocol and given my personal experience with the team, they are the best protocol developers whom I worked during my web3 career. Additionally, the team would get all support from the Aave Companies (which whom continues to build new innovation on top of Aave).

Second, the proposal is remarkable from the perspective of decentralization, reinforcing the idea that Aave DAO utilizes services from various contributors and service providers to ensure protocol sustainability and the ops. I hope the proposal inspires other service providers to help the Aave community in various topics ranging from risk parameters, research, development, design, events and modelling interest rate strategies.

Lastly, the values of the BGD resonates the values of the Aave community and regarding the amounts they seem to be appropriate considering that BGD would have internal/external contributors helping to fulfil their roadmap, rest assured I am confident that the quality of the work would be in line what has been the build before in the Aave community.

Will vote hard YES on the proposal!