Being part of the scope of the Aave <> BGD engagement, we want to bootstrap the discussion on the community about sunsetting Aave v1 and Aave v1 AMM pools, currently deprecated in favor of Aave v2 and v3, and really reduced in size.
Aave V1 was deployed on the Ethereum network back in January 2020, being the first step of everything that would come afterward on the Aave ecosystem. Since then, countless developments happened in the community, amongst them, 2 more iterations of the protocol: Aave v2 and Aave v3.
After the deployment of Aave v2 Ethereum, almost 2 years ago (December 2020), the general approach of the community was to progressively sunset Aave v1, with steps like enabling a migration tool v1 → v2 and disabling stable borrowing on v1 (more information here https://governance.aave.com/t/aave-protocol-v1-v2-migration-tool-and-transition-plan/2053)
Right now, it is probably a good moment for the community to decide on the next steps.
We can identify 3 different options for the community regarding how to proceed with this procedure:
This involves disabling providing liquidity and new borrowings on the pool, also denominated as “freezing of the pool”. It will keep active repayments, withdrawals, and liquidations.
Given the time passed for migration to v2 and withdrawals/repayments, it seems quite reasonable for Aave v1 Ethereum, with the only disadvantage that users will not be able to refill the collateral of their positions. But that is perfectly solvable just by migrating the position to v2.
For Aave v1 AMM, with a pool size of ~$280’000 and collaterals of Uniswap v1 (quite deprecated and low on liquidity), this should be the clear option.
Continuing with the previous step of disabling stable borrowing, a possible next would be disabling variable borrowing too.
This is more conservative, as it would still allow refilling of collateral, but it will not mean really a sunset of Aave v1.
If the community has a hard stance on not really doing a sunset of Aave v1 for some specific reason. Would mean just leaving users over time unwinding their positions by themselves.
This strategy could create more overhead down the line for the community, but it is still an option to consider.
More options could appear during this discussion, and BGD can support all of those that have a realistic scope.
BGD has already prepared a repository to execute the technical steps via Aave Governance concerning Option 1. It is important to say that this should not bias the community in their decision, as the adaptations for Option 2 can be done fairly quickly.
The timeline for this will be:
- Discussion here on the forum, targeting ~7 days.
- Snapshot proposal, with the final options discussed by the community, or the ones in the previous section (plus More Discussion).
- On-chain governance proposal to execute the approved actions.