Time flies on Aave! 
Today is the anniversary of Aave <> Bored Ghosts Developing, and we think it is a good moment to give a wider update to the community on everything that has been done during this time, together with what is planned for the last 3 months of our current engagement.
Given the extensive list of items, and that we always publish here on the forum about all our contributions, we will try to be concise, without going into the details of every project/involvement, as usually, each deserves a post by itself.
How bored have you been, ghosts?
Well, not really much 
First, we would like to highlight our contribution to Aave in some high-level aspects:
-
Considering its magnitude and real decentralization, Aave is a fast-moving ecosystem. Anybody familiar with software development knows that for a system to evolve fast, there needs to be quite a big effort “behind the scenes” to keep all the existing infrastructure (and new) working optimally.
With the decentralized, on-chain, and multi-contributor nature of Aave, keeping quality together with speed takes even more effort, as we like to think that apart from the more “visible” projects that we present to the community, the “bored”/silent work we have been doing in the background has re-enforced the image of Aave as not only an innovative but a rock-solid protocol. -
The release of Aave v3 was not a final step, but the initial one, as v3 is an incredibly powerful protocol that will keep organically evolving.
Apart from the 3.0.1/3.0.2 improvements, we are glad to see that during this year, the community has approved moving forward with further development of v3 features, like betting on e-mode, initial iterations on Portals, and supporting initiatives using v3 roles.
-
Being conscious of the criticality of the Aave governance, we put a lot of focus on this part of the ecosystem, and we believe it has given clear value, with a really solid procedure to avoid any issue with governance proposals, together with incredible frequency on new ones, from several contributors.
From approximately 70 governance proposals during Aave v1, v2, and the first months of v3, we have currently almost 220 in less than 1 year. Given the coordination required for each one of them, we are really happy with our role in it. -
A fundamental part described in our engagement post was the criteria and initiative of coming up with new ideas to make Aave better.
Apart from the planned items to deliver in advance, we have released a multitude of non-planned projects which have received really good feedback from the community. This solidifies the image of the Aave ecosystem as an ever-evolving system.
-
Lastly, we hope that no matter the full decentralized approach of Aave, anybody trying to integrate, build on top, or research around it now knows that Bored Ghost Developing is here to help.
And specifically, what has been done?
Initially, we think it is important to re-visit the initial scope defined by the Aave <> BGD post and its evaluation metrics:
-
On our initial engagement tasks, even if being a relatively open scope, we identified 20 different “fields” of contribution, with 14 being mandatory contributions for us (SURE), and 6 being BEST EFFORT, depending on the needs of the community.
Out of the 14 SURE, we have finished or have as work-in-progress 12 tasks, with only the closure of LEND-to-AAVE migration and new AAVE tokenomics not touched at the moment. Regarding the first, we will prepare before the end of this engagement all the necessary infrastructure required for a proposal for the community to have the option to use it.
Regarding the second, it depends on the community’s willingness to change tokenomics, but we are available to help with it at any point.Out of the 6 BEST EFFORT, we have participated and delivered value on all 6, with multiple items/projects on each.
-
Even if using the initial scope as a reference, we have contributed to multiple projects which are not easily classifiable in the initial scope, but clearly give value, like Safety Module 1.5, the analysis on network upgrades (e.g. The Merge), or others.
This has shown us that it is fundamental for contributors of our nature to have the flexibility to deliver what we think is valuable, of course apart from what is agreed.
-
There is an important unbalance between scopes of contribution: some scopes have multiple projects, while some others 1 big item.
Part of our work was identifying how to contribute everywhere, but at the same time prioritizing base on the needs of the moment, requirements from other contributions, security audits pipeline, etc.
-
In terms of the Evaluation Metrics, regarding Tasks Completed we will be on the Exceptional level once the Aave Governance V3 and Rescue Mission Phase 2 and 3 are completed, and pretty close currently of Exceptional on Participation on Tasks.
It is important to highlight that those metrics by themselves are not fully representative, as multiple extra items have been delivered.
Sections of contribution
For the sake of clarity, it is also important for the community to have a more precise classification of the fields on which we have delivered value, not limited to the initial list of tasks.
Security
Even if probably the less visible part of our work, the security of the protocol has been the highest priority of our collaboration, with specific new projects looking to improve it, our presence as a point of contact for disclosures, or analysis for the community touching security aspects of the protocol.
Projects
- Aave <> Chainlink Proof of Reserve
- Analysis of network upgrades
- Technical support on Harmony Horizon exploit
- Analysis and plan of action post-Midas exploit (jEUR, agEUR)
- Proposals for bounties
- Analysis and technical support on the CRV incident on Aave v2 Ethereum
- Participation in the USDC de-peg event
- Aave Forest initial proposal
- Evaluation of current security partners of the DAO (Certora, SigmaPrime)
Aave v3
Being the current iteration of the liquidity protocol, Aave v3 has been an important focus, with the majority of the items directly or indirectly affecting it.
This includes protocol improvements themselves, analysis, expansions of Aave, etc.
Projects
- Technical Framework for v3 asset listing
- Aave v3 Cross-chain listing template
- Aave v3 expansions: Metis analysis and report
- Framework for evaluation of Aave expansions to new networks
- Plan of action, coordination, and activation of Aave v3 Ethereum
- Aave v3.0.1
- Coordination and activation of Aave v3 Metis
- Discussion of Aave permissions management, with Risk Council proposal
- stataToken v3
- Aave v3 Listing/Config Engine
Governance
The Aave governance is the system controlling everything else of the ecosystem, so it is a fundamental component, even more taking into account that total and optimal decentralization is one of the most important continuous goals of the community.
Given its importance as a “base layer”, our contribution in this section is extensive, from adding security assurance to governance proposal to developing a new iteration of the system, passing through multiple tooling to help contributors navigate the Aave Governance.
Projects
- BGD proposal reports
- Aave Seatbelt
- Aave Governance Level 2 parameters update
- Aave Governance V3
- Aave Cross-chain Infrastructure
- Voting/proposition delegation guide for Aave Governance
- Aave proposals
Safety Module
Currently the third main component of the Aave on-chain ecosystem, together with the liquidity protocol and the governance.
On this side, our role has been developing a new 1.5 version which solidifies all fundamental mechanisms of the system, advising other parties looking to improve the dynamics of the Safety Module and working on the migration from stkABPT Balancer v1 to Balance v2.
Projects
- Renewal Safety Module allowance
- Aave Safety Module v1.5
- stkABPT migration from Balancer v1 to v2
Aave v1/v2 and other legacy consolidations
All Aave major versions (v1, v2, v3) live in parallel on the public blockchain, as due to their decentralized nature, there is no option to completely switch them off.
However, the approach has always been maintaining the “legacy” versions of the protocol, while using levers to progressively reduce their importance and have users migrating to the newest iterations of Aave.
Within this field, we have been monitoring and providing the required support to Aave v1 and v2, in parallel with proposing to the community progressive off-boarding paths or even developing solutions for users to migrate from Aave v2 to v3.
Projects
- Security analysis and plan of action for the FEI RF problem
- Initial strategy to sunset Aave v1
- renFIL off-boarding strategy
- Aave v2→v3 migration tool: smart contracts and UI
- xSUSHI price feed update on Aave v2 Ethereum
- Aave v2/v3 Collectors unification
- Technical feedback on BUSD offboarding
Support to other contributors
With multiple entities contributing to different types of tasks on Aave (risk, security audits, treasury, growth), part of our role is to act as a technical expert party to facilitate those contributions, without adding any risk to the ecosystem.
We have been actively supporting every contributor to Aave, for example by reviewing their governance proposals, developing frameworks to make them more agile in their work, or providing transparency on technical matters (e.g. Guardian).
Projects
- Aave proposals reviews
- Aave <> Paraswap fee claimer
- Technical support to Aave Guardian
- Technical support to all other contributors and partners (Llama, Gauntlet, Chaos, Certora, ACI, etc)
- Aave Risk Stewards proposal: CapsPlusSteward
Support to external parties
Aave lives in an open blockchain environment, with a multitude of partners and builders on top of the protocol.
To improve the perceived quality of Aave, we have tried to support anybody willing to interact with Aave, for example guiding through the process of asset listing, activating rewards programs (liquidity mining), or in general solving doubts about technical matters.
Projects
- Support to all external teams activating liquidity mining
- Technical support to external teams on listings (e.g. cbETH)
- Technical feedback to Platypus and their locked funds on Aave
Tooling/UI/Misc
Finally, there are multiple projects that don’t fit in specific classifications, or that indirectly touch multiple of them.
The common principle behind all of these is the same: if we identify something that can be improved on the ecosystem, we try to do it.
Projects
- Refactoring of state management of the Aave IPFS UI
- Generalized price sync adapters
- Strategy regarding the pricing of WBTC
- Aave Rescue Mission
- Aave helpers repository
- Aave Address book
- Aave Tenderly CLI
- Aave Debt Swap contract
- Introduction of ProxyAdmin and TransparentProxyFactory on Aave
- Participation as a reviewer on AGD for 1 period
- Aave Robot
So what’s next?
With 3 months left of our current engagement, we still have plenty of work to do, including the following:
- Aave Governance v3. The new iteration of the Aave Governance and one of the SURE points of our initial scope. Currently in the last steps, so we expect its release way before the end of the engagement.
- Aave Cross-chain infrastructure. Complementary to Aave Governance v3, and with a similar timeline.
- Aave Robot. Automation around Aave, including but not limited to Aave Governance V3 and Cross-chain governance.
- stkABPT migration from Balancer v1 to v2. Another SURE item in our list, blocked for some time by other requirements, but to be delivered pretty soon.
- New expansions to other networks. With the community pre-approving BNB Chain, zkEVM, zkSync, Starknet, and Scroll, we are actively working on the tech analysis step of them.
-
And more projects that we are finishing! Keep an eye on the forum
Annex. Index of projects
1. BGD proposal reports
https://github.com/bgd-labs/aave-proposals-reports
Relation with Aave <> BGD initial scope
- Create and improve tooling to monitor governance proposals and their general correctness
Aave is a decentralized ecosystem on which the decisions are made via governance smart contracts and its proposals payloads.
One of our objectives was to give maximum assurance to the community that no technical problem appears on those proposals, so since the start of our engagement, we have been routinely creating expert reports for each governance proposal going to voting.
A total of 129 proposals reports have been created, and counting.
2. BGD proposals review
Relation with Aave <> BGD initial scope
- Create and improve tooling to monitor governance proposals and their general correctness
- Technical support on community initiatives related to the DAO treasury strategies
Proposal reports definitely help give assurance to the community/participants in governance, but as we start working with Aave, we noticed something: it is really important to complement the expertise of other contributors in other areas with our technical expertise.
So, even if mainly work “behind the curtains”, we have been supporting almost each and every proposal going to voting on governance, proposed by all contributors like Gauntlet, Chaos Labs, Llama, Certora, SigmaPrime, teams looking for asset listings, etc.
We think this has been quite instrumental in not having any major problems with any governance proposal, with even a really rare need to cancel them.
3. Aave Seatbelt
https://governance.aave.com/t/bgd-release-aave-seatbelt/8310
https://github.com/bgd-labs/seatbelt-for-ghosts
Relation with Aave <> BGD initial scope
- Create and improve tooling to monitor governance proposals and their general correctness
- Explore and propose to the community integrations of the ecosystem with other protocols
Expert reviews and support are good, but what about a more automated way?
We have created the Aave Seatbelt, a tool that automatically and openly generates simulation reports for any proposal going live on the Aave governance. This means that, apart from us (they are fundamental to our reviews!), everybody can visit https://github.com/bgd-labs/seatbelt-for-ghosts/tree/main/reports/Aave/0xEC568fffba86c094cf06b22134B23074DFE2252c and see exactly which changes (storage, events, etc) will happen whenever a proposal is executed.
Even if the initial version was inspired by Uniswap’s Seatbelt, at the moment Aave Seatbelt is completely different, adapted to Aave’s morphology, and covering not only Ethereum, but also Polygon and Optimism (Arbitrum and Metis coming soon!).
4. Aave Address book
https://governance.aave.com/t/bgd-release-aave-address-book/8461
https://github.com/bgd-labs/aave-address-book
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
First and foremost, we are a group of developers, and we know how problematic is not to have a proper source of truth for integrating software systems.
Aave was lacking a proper repository/package for developers to easily integrate the smart contracts of the ecosystem, with the maximum assurance of being maintained and updated regularly.
So we created the Aave Address Book, which solves this, by listing all the addresses of all the smart contracts of Aave.
Do you want to use the Aave Pool on a Foundry test, anon? forge install bgd-labs/aave-address-bookand import {Pool} from ‘aave-address-book/AaveV3Ethereum.sol’
5. Renewal Safety Module allowance
https://governance.aave.com/t/aip-renewal-of-safety-module-aave-allowance/8463
https://app.aave.com/governance/proposal/82/
Relation with Aave <> BGD initial scope
- NEW
We create a proposal to update the allowance of AAVE from the Ecosystem Reserve to the Safety Module, required for the incentives distribution on the latter.
6. Proposals for bounties
https://governance.aave.com/t/bgd-proposal-for-bounty-fallback-oracle-misconfiguration/8421
Relation with Aave <> BGD initial scope
- Point of contact for security disclosures and action
Even if being work that because of its nature doesn’t get done in public, we have been a point of contact for any security disclosure concerning Aave, analyzing them, providing answers to the entities submitting them, and designing/executing plans of action.
The “tip of the iceberg” of this work comes to light really rarely (which is good for Aave!), but whenever we think a submission deserves a bounty from the DAO, we take it as our task to help security researchers to get their well-deserved reward, for example HERE.
We also think a more structured bounty program should be moved forward, given that only a really updated one is present at the moment, and ad-hoc evaluations create friction. So we are actively participating in the discussion on https://governance.aave.com/t/temp-check-aave-bug-bounty-program-on-immunefi/12596/3
7. Aave <> Chainlink Proof of Reserve
https://governance.aave.com/t/bgd-aave-chainlink-proof-of-reserve-phase-1-release-candidate/10972
https://github.com/bgd-labs/aave-proof-of-reserve
Relation with Aave <> BGD initial scope
- Explore and propose to the community integrations of the ecosystem with other protocols
With Aave present in multiple networks, and their heavy usage of bridged assets, we considered integrating Chainlink Proof of Reserve into this use case was really fitting into Aave’s use case and approach to security.
The initial phase of the system was released support Aave on Avalanche.
8. Analysis of network upgrades
https://governance.aave.com/t/bgd-technical-analysis-aave-ethereums-pos-merge/9226
https://governance.aave.com/t/bgd-technical-analysis-aave-shanghai-capella-ethereum-upgrade/11917
Relation with Aave <> BGD initial scope
- NEW
The core of the Aave ecosystem is its smart contracts, and these technically run in underlying blockchain networks. Therefore, any upgrade on the software of this network needs to be carefully evaluated for it to cause any impact on Aave’s infrastructure.
We have performed these analyses on theoretically disruptive events like the Ethereum Merge (Bellatrix/Paris hard fork) and the latest enabling of staked ETH withdrawals (Shanghai/Shapella).
9. Technical Framework for v3 asset listing
https://governance.aave.com/t/bgd-aave-v3-listings-technical-parameters/9504
Relation with Aave <> BGD initial scope
- Technical support on listing of new assets
From the moment we started working with Aave, we noticed there was a really important lack of guidance on how to properly do Aave v3 listings, especially regarding the parameters configuration.
Consequently, we published an extensive guide of all parameters of Aave v3 assets, and basic tips and validations on how to define them, which we know have helped with asset listings.
10. Aave Tenderly CLI
https://governance.aave.com/t/bgd-aave-tenderly-cli/9932
https://github.com/bgd-labs/aave-tenderly-cli
Relation with Aave <> BGD initial scope
- Create and improve tooling to monitor governance proposals and their general correctness
Simulation tooling is incredibly powerful for developers, giving that extra confidence in implementation that sometimes is difficult to achieve only with tests.
We created a CLI tool tailored for Aave and using Tenderly under the hood, allowing for the simulation of Aave governance proposals (pre-creation, running) and how everything would look on the app.aave.com interface post-execution.
11. Aave v3 Cross-chain listing template
https://governance.aave.com/t/bgd-aave-v3-cross-chain-listing-template/9354
https://github.com/bgd-labs/aave-proposals (renamed from its initial name aave-v3-crosschain-listing-template)
Relation with Aave <> BGD initial scope
- Create and improve tooling to monitor governance proposals and their general correctness
- Technical support on listing of new assets
The lack of full-flow documentation and additional complexity (multiple chains involved) of cross-chain listings was creating an important barrier for contributors, even those technical.
We created a template repository with multiple helpers, documentation, and examples, initially focused on cross-chain proposals, but that became the current aave-proposals (more later).
12. Aave proposals
https://github.com/bgd-labs/aave-proposals
Relation with Aave <> BGD initial scope
- Create and improve tooling to monitor governance proposals and their general correctness
- Technical support for teams developing products on the ecosystem, depending on capacity
We will release more extensive details about it soon, but aave-proposals is the place to go for anybody that wants to create an Aave governance proposal, currently used as the base by all engaged service providers.
It includes everything present before on the Aave cross-chain listing template + a lot more things like better simulation reporting, abstractions, integration with other tools from BGD, and especially, defining good practices on how to write, test and submit on-chain governance proposals.
Aave-proposals is continuously evolving, even with contributions of other service providers using it, so keep an eye on it !!
13. Framework for evaluation of Aave expansions to new networks
Relation with Aave <> BGD initial scope
- Technical support on deployments for new chains
Before we started working on Aave, evaluating if a network was suitable to host an instance of the protocol was done ad-hoc, following certain procedures, but not as transparent as up to the standards of the DAO.
Expanding to other networks is a key element of the Aave ecosystem, so both for the sake of the community and of external ones (like the one of the candidate network), we decided to propose and follow a procedure pre-expansion, consisting of multiple rounds of governance, with operational evaluations (technical, risk) in the middle.
Aave v3 Metis has been the first network following this procedure, but all other candidates are also in different stages of it.
14. Security analysis and plan of action for the FEI RF problem
https://governance.aave.com/t/bgd-aave-v2-ethereum-fei-security-report/10251
Relation with Aave <> BGD initial scope
- Maintenance of Aave V2 contracts until migration to V3
As a consequence of the closure of FEI on Aave v2, we detected a problem with the protocol when configuring the Reserve Factor of an asset to 100%, and fixed it on v3.0.1.
We also followed closely everything surrounding the FEI case, being a quite edge scenario with the dynamics of emission of the asset getting disrupted.
15. Aave Governance Level 2 parameters update
https://governance.aave.com/t/rfc-aave-governance-adjust-level-2-requirements-long-executor/8693
https://github.com/bgd-labs/aave-gov-level-2-update
Relation with Aave <> BGD initial scope
- NEW
- Migration of ABPT Balancer pool to Balancer v2
- Implementation and deployment of Aave Governance V3
The Aave governance has 2 levels of requirements (e.g. proposition power to submit a proposal, threshold of YES votes for a proposal to pass), depending on the criticality of the system touched by a proposal.
In the case of the most restrictive Level 2, and due to being defined a long time ago, these requirements were extremely high, in practice almost self-locking any update on the most critical Aave systems and progress on projects touching them.
We designed a solution to update these parameters and fulfill the voting requirements, together with following quite critical steps on for example permissions migration.
16. Refactoring of state management of the Aave IPFS UI
https://governance.aave.com/t/bgd-aave-ipfs-ui-improving-state-management/10610
https://github.com/aave/interface/pull/964
Relation with Aave <> BGD initial scope
- Technical maintenance and improvement of the Aave liquidity protocol UI
- Technical maintenance and improvement of the Aave safety module UI
- Technical maintenance and improvement of the Aave governance UI
Envisioning potential future blockers, we decided to refactor the state management of the Aave UI maintained by Aave Companies.
The objective of this was to allow more complex logic of meta-transactions (e.g. on v2→ migration) or simplify any potential support of non-evm networks in the future.
17. Technical support on Harmony Horizon exploit
https://governance.aave.com/t/harmony-horizon-bridge-exploit-consequences-to-aave-v3-harmony/8614
https://governance.aave.com/t/arc-harmony-recovery/10468
Relation with Aave <> BGD initial scope
- Point of contact for security disclosures and action
As a technical provider of the DAO, we followed/follow closely the Harmony Horizon bridge exploit incident, directly affecting Aave v3 Harmony, activated prior to our engagement with the DAO.
We provided transparency to the community, proposed solutions, and coordinated with the Aave Guardian and Harmony representatives.
18. Initial strategy to sunset Aave v1
https://governance.aave.com/t/arc-strategy-on-sunsetting-of-aave-v1/9450
Relation with Aave <> BGD initial scope
- Managing deprecation of Aave V1
We initiated a discussion about the different options to sunset Aave v1 Ethereum, and after the feedback from the community, we created a governance proposal to execute the outcome.
Afterward, we provided Aavechan Initiative technical feedback on proposed additional steps concerning Aave v1 “deprecation”
19. renFIL off-boarding strategy
https://governance.aave.com/t/update-renfil-interest-rate-strategy-on-aave-v2-ethereum/11049
https://github.com/bgd-labs/aave-v2-zero-rate-strategy
Relation with Aave <> BGD initial scope
- Maintenance of Aave V2 contracts until migration to V3
In another case of emission/redemption dynamics of an asset getting disturbed, we followed closely the event, by proposing active steps like halting borrowing and interest accrual with a Zero rate strategy and monitoring progress on liquidations for the off-boarding of renFIL.
20. Strategy regarding the pricing of WBTC
https://governance.aave.com/t/wbtcs-and-others-pricing-mechanism-on-aave/10825
Relation with Aave <> BGD initial scope
- Maintenance of Aave V2 contracts until migration to V3
Given the subjectivity of the topic, we opened a discussion around the pricing strategy on assets like WBTC, clearly correlated with an underlying like BTC, and consequently having important implications on what is the “fairest” way of valuing it.
After an interesting discussion with the community, we also include their decision on the pricing mechanism for Aave v3 Ethereum, with v2 Ethereum coming soon too.
21. Aave <> Paraswap fee claimer
https://governance.aave.com/t/bgd-aave-paraswap-fee-claimer/10671
https://github.com/bgd-labs/aave-paraswap-claimer
Relation with Aave <> BGD initial scope
- Technical support on community initiatives related to the DAO treasury strategies
ParaSwap offers a referral program for integrators, with the Aave protocol being one via the Collateral Swap and Repayment with Collateral features.
We created some infrastructure of smart contracts for the Aave Collector to receive this additional stream of income in a permissionless manner.
22. Aave v3 expansions: Metis analysis and report
https://governance.aave.com/t/bgd-aave-metis-infrastructure-technical-evaluation/11374
https://github.com/bgd-labs/aave-reports-candidate-networks
Relation with Aave <> BGD initial scope
- Technical support on deployments for new chains
As a follow-up of the framework for the expansion of Aave to new networks, we put it into practice for one of the candidates, Metis Andromeda.
The result was a comprehensive report of all the technical aspects of Andromeda affecting its suitability for hosting Aave.
Additionally, we provided the appropriate feedback to the Metis team on those points deserving some improvement.
23. Generalized price sync adapters
https://governance.aave.com/t/bgd-generalised-price-sync-adapters/11416
Relation with Aave <> BGD initial scope
- NEW
We developed a solution for better pricing of assets listed on Aave highly correlated in price (e.g. ETH, stETH), and submitted to additional technical risk consequence of how Chainlink and the Aave protocol work.
This solution has been used afterward on multiple occasions, for example with LSTs.
24. Analysis and plan of action post-Midas exploit (jEUR, agEUR)
https://governance.aave.com/t/jeur-incident-plan-of-action/11379
Relation with Aave <> BGD initial scope
- Point of contact for security disclosures and action
We followed closely the exploit event of Midas protocol on Polygon, given the side effects caused on assets listed on Aave v3 Polygon like jEUR and agEUR.
We analyzed the impact, presented a plan of action for the community to discuss, and created governance proposals to execute it.
25. Plan of action, coordination, and activation of Aave v3 Ethereum
https://governance.aave.com/t/bgd-aave-v3-ethereum-new-deployment-vs-aave-v2-upgrade/9990
https://github.com/bgd-labs/aave-v3-ethereum-proposal
Relation with Aave <> BGD initial scope
- Technical support on deployments for new chains
We analyzed both the possibility of upgrading Aave v2 Ethereum to v3 or activating an additional Aave v3 instance, and presented to the community the pros/cons of both options, together with our recommendation of proceeding with a new deployment.
After the consequent discussion and approval from governance, we coordinated all aspects surrounding Aave v3 Ethereum, aligning all the requirements from other contributors like risk or security, together with doing all the ad-hoc work required for it (e.g. activation governance proposal).
This procedure also has served as a good example of how other network expansion should be done
26. Aave v3.0.1
https://github.com/bgd-labs/aave-v3-ethereum-proposal
https://github.com/aave/aave-v3-core/pull/701
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
Overlapping with Aave v3 Ethereum, given its deployment quite some time after the initial v3 instances, we decided that could be a good moment to introduce different minor improvements and fixes.
We developed part of the fixes included and coordinated all the procedures, including reviewing the fixes coming from external contributors, security audits, and updates to the Aave community.
27. Aave v2→v3 migration tool: smart contracts and UI
https://governance.aave.com/t/bgd-aave-v2-v3-migration-tool/11611
https://governance.aave.com/t/temp-check-ethereum-v2-to-v3-migration/12636/2
https://github.com/aave/interface/pull/1352
https://github.com/aave/interface/pull/1442
(and others on UI)
https://github.com/bgd-labs/V2-V3-migration-helpers
Relation with Aave <> BGD initial scope
- Migrating V2 markets to V3
Given that both Aave v2 and v3 live in parallel on Ethereum, Polygon, and Avalanche, and with the occasion of the Aave v3 Ethereum release, we built an Aave v2→v3 migration system, comprising both the infrastructure of smart contracts, together with the UI development on app.aave.com, given its role as an entry point to Aave.
This tool has been really successful, with hundreds of millions in value migrated from Aave v2 instances to v3.
28. xSUSHI price feed update on Aave v2 Ethereum
https://governance.aave.com/t/bgd-swap-of-price-feed-of-xsushi-on-aave-v2-ethereum/11901
Relation with Aave <> BGD initial scope
- Maintenance of Aave V2 contracts until migration to V3
To mitigate the risk regarding the xSUSHI pricing model, we proposed to replace it with an off-chain calculated one.
29. Discussion of Aave permissions management, with Risk Council proposal
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
We initiated a discussion and propose a path forward on how to use the granular roles of Aave v3 to both improve the speed of certain parameter updates and facilitate the contributions of risk providers like Chaos Labs or Gauntlet.
A Risk Council concept was presented to the community, which progressively is being worked on with additional ideas like the Risk Stewards.
30. Aave Debt Swap contract
https://governance.aave.com/t/bgd-aave-debt-swap-adapter-contract/12738
https://github.com/bgd-labs/aave-debt-swap
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
A missing complementary component for Collateral Swap and Repayment with Collateral was a mechanism to swap a debt position on Aave from one asset to another.
We designed and implemented a smart contract for it, that both users and integrators can leverage.
31. stataToken v3
https://governance.aave.com/t/bgd-statatoken-v3/11894
https://github.com/bgd-labs/static-a-token-v3
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
In order to facilitate integrations of deposits on Aave and other use cases, we created and deployed an ERC-4626 compatible contract representing “wrapped aTokens”, not growing in balance, but on exchange rate.
Additionally, we developed surrounding infrastructure like a stataToken factory contract, to be aligned with other practices in the Aave ecosystem.
32. Introduction of ProxyAdmin and TransparentProxyFactory on Aave
https://github.com/bgd-labs/solidity-utils/tree/main/src/contracts/transparent-proxy
Relation with Aave <> BGD initial scope
- NEW
More on the purely infrastructural level of smart contracts, we started introducing a more updated implementation of the Transparent Proxy pattern, including a factory on top, better practices on the implementation side (Initializable), and the usage of ProxyAdmin for permissions holding.
33. Aave v2/v3 Collectors unification
https://governance.aave.com/t/bgd-aave-v2-v3-collectors-unification/12434
https://github.com/bgd-labs/aave-collector-unification
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
- Maintenance of Aave V2 contracts until migration to V3
- Technical support on community initiatives related to the DAO treasury strategies
On a system like Aave, even if more optimal than in off-chain software, it is unavoidable to have temporary legacy components among all the sub-systems.
One such part was the Collector contract and periphery, in charge of holding and distributing the funds of the DAO itself, which was not aligned between networks and v2/v3 versions.
We developed an upgrade for this, together with improving the access control system, to simplify integrations.
34. Aave v3 Listing/Config Engine
https://github.com/bgd-labs/aave-helpers/tree/master/src/v3-config-engine
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
Part of all tooling to interact with Aave we built on aave-helpers, but a project by itself. Interacting with the Aave PoolConfigurator and other smart contracts of the protocol can be prone to errors for contributors, and also problematic for reviews, especially on relatively complex cases like Aave v3 Listings.
Aave v3 Listing Engine was the first iteration of a “middle” smart contract that allows creating an asset listing payload in a really simple and imperative way, hiding all the complexity for the proposer. We initially used it for all the listings on Aave v3 Ethereum.
Over time, we generalized a bit more the Listing Engine, becoming a Config Engine that can be (and is) used not only for listings but for other parameter changes like risk, borrowing, caps, or e-mode.
We will publish a more detailed description of the Aave v3 Config Engine soon!
35. Upgrade of all instances to Aave v3.0.2
https://github.com/bgd-labs/proposal-3.0.2-upgrade
https://governance.aave.com/t/bgd-upgrade-of-aave-v3-periphery-to-3-0-1-across-networks/10744/13
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
With Aave v3 Ethereum running on v3.0.1 from day 0, we also developed an upgrade for all other networks.
During the process, we also noticed certain improvements to be done on top of v3.0.1, so we include them in the upgrade in the form of a new v3.0.2, applied additionally in Ethereum too.
36. Aave Rescue Mission
https://governance.aave.com/t/bgd-rescue-of-tokens-locked-on-aave-overview-and-phase-1/8150
https://github.com/bgd-labs/rescue-mission-phase-1
Relation with Aave <> BGD initial scope
- Rescue locked funds send directly to contracts of the Aave ecosystem
Generally, the smart contracts of the Aave ecosystem allow for the “rescuing” of tokens sent by mistake to them, so we developed a solution to help users with this “rescue mission”, by detecting all tokens sent by mistake, creating a proposal payload releasing those funds from the corresponding smart contracts of Aave, and providing a user interface for eligible users to interact with the rescue contracts.
Phase I of this rescue mission has been executed, and Phase II and III are coming pretty soon.
37. Aave Safety Module v1.5
https://governance.aave.com/t/bgd-aave-safety-module-v1-5/12148
https://github.com/bgd-labs/aave-stk-v1-5
Relation with Aave <> BGD initial scope
- NEW
Important technical improvement of the Aave Safety Module, currently still in voting, introducing better slashing dynamics, improving the system of cooldown for withdrawals, and other misc aspects, like enabling the GHO discount model from the stkAAVE side.
38. Coordination and activation of Aave v3 Metis
https://github.com/bgd-labs/aave-v3-metis-proposal
https://governance.aave.com/t/launch-aave-v3-on-metis/7056/79
Relation with Aave <> BGD initial scope
- Technical support on deployments for new chains
Once the technical and risk analysis of Metis was positive and the Aave governance approved the expansion, we took care of all the technical aspects of the expansion, including the deployment of the Aave smart contracts (not active), the governance proposal for the Aave community to approved the activation of the pool with its initial assets and configurations and the coordination with the risk providers regarding those configurations.
39. Aave helpers repository
https://github.com/bgd-labs/aave-helpers
Relation with Aave <> BGD initial scope
- Technical support for teams developing products on the ecosystem, depending on capacity
- Coordination with other parties contributing to Aave
An ever-growing collection of tooling for developers to interact with Aave and test those interactions.
Different from aave-proposals, this repository is focused on pure smart contract helpers quite oriented to Foundry setup, without much assumptions on where these helpers get used.
40. Technical support to Aave Guardian
https://governance.aave.com/t/community-guardian-renewal/9177
Relation with Aave <> BGD initial scope
- Technical support for teams developing products on the ecosystem, depending on capacity
- Coordination with other parties contributing to Aave
The Aave Guardian is a group of volunteering community members that allow the Aave ecosystem to have an emergency mechanism faster than the on-chain governance, together with executing changes on networks without cross-chain governance (currently only Avalanche) once the Aave governance has approved them.
As the presence of a technical entity with good knowledge of the Aave protocol is really helpful, our role within the Guardian comprises the creation of executable payloads to be executed, transparently explaining to its member what governance-approved changes are getting applied and notifying them in case of emergency to proceed with appropriate actions.
41. Aave Risk Stewards proposal: CapsPlusSteward
https://governance.aave.com/t/arfc-aave-v3-caps-update-framework/11937/4
https://governance.aave.com/t/bgd-risk-steward-phase-1-capsplusrisksteward/12602
https://github.com/bgd-labs/aave-helpers/tree/master/src/riskstewards
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
As a follow-up of the concept of Risk Council, and especially detecting a bottleneck created by the high amount of on-chain governance proposals, we proposed the concept of granular Risk Steward smart contracts, with permissions over the protocol to execute really limited actions, and controlled by expert parties.
The first iteration of this, already approved by the community, is CapsPlusSteward, which will allow for more agile updates of caps on Aave v3.
42. Technical support to all other contributors and partners (Llama, Gauntlet, Chaos, Certora, Chainlink, etc)
Relation with Aave <> BGD initial scope
- Technical support for teams developing products on the ecosystem, depending on capacity
- Coordination with other parties contributing to Aave
- Technical support on community initiatives related to the DAO treasury strategies
Fully decentralized systems like Aave with numerous contributors require even more coordination than centralized ones, and this coordination can mark the difference between success and failure.
Even if this work doesn’t always reflect in the shape of announcements or specific projects, we have been working really closely with practically everybody contributing to Aave requiring technical expertise. This includes all the service providers of the DAO in security, risk, treasury, and development, but also all types of partners like Chainlink, networks where Aave is hosted, applications built on top, teams providing rewards programs, etc.
The qualitative objective (we hope achieved) of this is clear: if you need anything related to Aave, Bored Ghosts can help or point you to the appropriate place.
43. Support to all external teams activating liquidity mining
https://github.com/bgd-labs/example-liquidity-mining-aave-v3
Relation with Aave <> BGD initial scope
- Coordination with other parties contributing to Aave
Aave v3 has a quite powerful system to allow external entities to incentivize activity (supplying/borrowing) on specific assets listed on Aave.
Given these teams are usually not familiar with the inner workings of this system, we have been helping them with examples, tests, and general guidance for them to activate their rewards programs on top of Aave.
Amongst the teams, we helped are Lido, Stader, and Polygon.
44. Voting/proposition delegation guide for Aave Governance
https://github.com/bgd-labs/how-to-delegate-aave
Relation with Aave <> BGD initial scope
- NEW
Given our presence on the governance forum, and especially with the proliferation during this last year of both Level 1 and Level 2 proposals, we noticed sometimes it was not completely clear to the community how to exercise their votes or surrounding mechanisms like voting and proposition delegation.
So we released a small guide about it, trying to answer the most common questions.
45. Aave Forest initial proposal
https://governance.aave.com/t/bgd-aave-forest/12755
Relation with Aave <> BGD initial scope
- Research new features and improvements from V3
- Explore and propose to the community integrations of the ecosystem with other protocols
Still a work-in-progress project, but we presented to the community the concept of Aave Forest, a framework of prevention and protection for the protocol against any potential exploits, with Owls on the prevention side and Rangers on the protection one.
This project is part of the effort to adopt more the granular system of permissions of Aave v3, similar to the Risk Stewards, just focused on security in this case.
46. Participation as a reviewer on AGD for 1 period
Relation with Aave <> BGD initial scope
- Coordination with other parties contributing to Aave
We participated as a reviewer on the Aave Grants DAO committee during the period 2022, providing our expertise in evaluating the most technical candidates for grants.
47. Analysis and technical support on the CRV incident on Aave v2 Ethereum
https://governance.aave.com/t/arfc-repay-excess-crv-debt-on-ethereum-v2/10955/7
Relation with Aave <> BGD initial scope
- Point of contact for security disclosures and action
- Maintenance of Aave V2 contracts until migration to V3
We followed closely the incidence of bad debt of CRV created on Aave v2 Ethereum, by borrowing against USDC with high Liquidation Threshold.
Apart from advising all the involved parties and looking for mitigations/solutions, we helped Llama review the technical aspects of the bad debt closure.
48. Technical support to external teams on listings (e.g. cbETH)
Relation with Aave <> BGD initial scope
- Coordination with other parties contributing to Aave
We helped (directly or indirectly through teams like Llama or ACI) external parties looking for listings on Aave, initially validating the interactions with the protocol and configurations (e.g. oracles), later on providing guidance on how to use our available tooling like the Aave v3 Config Engine.
49. Participation in the USDC de-peg event
https://governance.aave.com/t/arc-stablecoin-volatility-risk-parameter-recomendations/12241/5
Relation with Aave <> BGD initial scope
- Point of contact for security disclosures and action
We followed closely the USDC de-peg event on March 2023 given the potential implications for Aave.
This includes actively discussing with the risk providers of the community regarding the plan of action (mitigation/protection), providing transparent technical information to the community, and coordinating with Aave Guardian mitigations like the freezing of some assets.
50. Evaluation of current security partners of the DAO (Certora, SigmaPrime)
https://governance.aave.com/t/sigma-prime-security-assessment-services-for-aave/8518/2
Relation with Aave <> BGD initial scope
- NEW
Given the quite close relationship between the development and security fields in an ecosystem like Aave, we actively participated in giving feedback and guiding the engaged security providers that we considered worth it given Aave’s needs.
51. Technical feedback on BUSD offboarding
https://governance.aave.com/t/arc-busd-offboarding-plan/12089
Relation with Aave <> BGD initial scope
- Managing deprecation of Aave V1
We provided technical feedback on the plan of action to off-board BUSD from Aave v2 Ethereum, another case of emission/redemption dynamics of an asset being disturbed.
52. Technical feedback to Platypus and their locked funds on Aave
Relation with Aave <> BGD initial scope
- Point of contact for security disclosures and action
Following an exploit on the Platypus protocol on Avalanche, and in parallel with monitoring and analyzing any implication for Aave (none), we provided guidance to the Platypus team on the proper process to request funds from the Aave DAO funds rightfully owned by them but locked by the attacker by mistake on the Aave v3 Avalanche pool.
After the Platypus team diligently submit all the proofs/documentation regarding their claim, we analyzed the legitimacy of it and guide them during the creation of a governance proposal to unlock the funds.
engineering legends moving us forward 
all the branding too - well done 