Hello Aave community members! As you are probably already aware, the Aave <> BGD proposal has passed on-chain, which means our contribution (defined here) to the Aave community starts from today.
One of our main objectives towards the community is to be as transparent as possible, on all the different fronts of the scope we engaged in. So today we want to present a first raw summary of what is coming from BGD in the upcoming weeks/month.
This initial “roadmap” can suffer slight variations down the line, but we hope it serves as a good overview of what the community should expect. And of course, we are happy to consider any feedback on the priorities.
Implementation phase
- Migration Aave v2 Ethereum → Aave v3. Pretty critical infrastructural work, in order to have an Aave v3 pool on currently the biggest deployment of Aave, Ethereum. We estimate this to be completed during the next 2 months, but extensive security procedures will need to be applied, given the nature of the migration: v2 proxy contracts will be updated with fully compatible v3 ones, on “hot” storage. It is highly probable that this will be executed in steps, given the high number of smart contracts affected.
- Governance proposals’ verification tooling. At the moment, the visibility of what changes will happen once a proposal passes is quite reduced. This puts quite a big dependency on experts on the Aave codebase to check each and every proposal (usually programmatically) for potential unintended side effects, or even governance attacks. Following a similar approach to the one used by Uniswap/Compound with the Seatbelt tool, we will be releasing a tool to better understand (even to non-experts) what exactly a governance proposal would do if passing. We will have news about this during the following 2 weeks.
- Migration aBPT/stkABPT to Balancer v2. Due to the complexity of this migration, currently, the aBPT (AAVE/ETH 80/20) pool on Balancer used by the Safety Module still runs on Balancer v1 contracts. Being a fundamental part of the ecosystem, both on the Safety Module and liquidity sides, it is completely fundamental to proceed with this item. During the following 2 weeks, we will publish a step-by-step plan on what will be done, to be implemented, and executed (if security procedures allow) during the following month.
- Rescue of funds locked on Aave ecosystem contracts. After an important delay on this, the community is eager to have some progress. We will publish this week a step-by-step plan of implementation and execution, together with the scope of the recovery. We will let everybody know with enough time in advance if any action is needed, mainly for those community members who sent the tokens by mistake to a contract on the scope.
- Misc Aave UI fixes. We will start submitting different PRs to the Aave interface, mainly for small bug fixing and improvements.
Design phase
- Governance v3 prototype. Still in the brainstorming and experimentation phase, but we intend to have an initial prototype for the next iteration of the Aave governance approximately during the next month. The current challenge is having the right equilibrium between system complexity and voters-inclusion. In addition, we will have a public discussion with the community to present the idea and receive feedback on it.
- Open discussion on the community concerning AAVE tokenomics. Once the discussion about evolved AAVE tokenomics is kickstarted by the community, we will give the feedback on the technical aspects, and which direction BGD thinks is better. No timeline can be given at the moment, but we are internally discussing already potential pros/cons of different approaches.
- Exploration of different options and models to expand cross-chain governance to all Aave pools. The main objective is to find a technical solution to not depend on Guardian due to the lack of infrastructure for Ethereum → otherChain messaging.
Technical support
- Technical support on listings of stMATIC, sAVAX, FRAX, UST, CVX, MAI (and some others still on previous listing phases, like Snapshot). This mainly includes coordination tasks (e.g. Snapshot → Guardian), together with support to other teams writing payloads, and in some of the cases ourselves doing it.
Security
-
Security reviews on misc upcoming proposals:
- Aave Grants DAO renewal.
- Unification of reserve factor in only 1 ecosystem reserve on Ethereum: redirecting v1 reserve factor to v2 ecosystem reserve.
- Enabling of DPI borrowing on v2.
- Listing of DPI on Aave Arc.
- Listing of DAI on Aave Arc.
- Update of reserve factors on Aave Arc.
- Coordination with the Certora team in defining a timeline of developments that will need properties-proving.
Coordination
- Bounty management regarding the Aave v3 mock-oracle security disclosure.
Regarding the official communications from BGD about Aave ecosystem’s developments, depending on the type of update, it will happen regularly on the following channels:
- Aave governance forum (Development category). Mainly for long-format updates, for example technical designs on which we need feedback from the community.
- #bored-ghosts channel on the Aave discord. Usually for visibility of governance’s forum posts, and summaries of progress on developments.
- @bgdlabs Twitter account. Official channel of communication of BGD Labs.
We appreciate your feedback! 
