ARC. Strategy on sunsetting of Aave v1


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

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:

Option 1: disable additive actions on the pool

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.

Option 2: disable only borrowing

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.

Option 3: not doing anything

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.

Next steps

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:

  1. Discussion here on the forum, targeting ~7 days.
  2. Snapshot proposal, with the final options discussed by the community, or the ones in the previous section (plus More Discussion).
  3. On-chain governance proposal to execute the approved actions.

Apart from V1 AMM, what can be the avantages for the communauty to choose option 1 or 2 instead of option 3 ?

I think is important to also understand who currently continue to use Aave v1 ? Are they users stuck on contract wallet. Are they none active wallets, rate arbitrators or bot or script that continue to use Aave v1 smart contract ?

In general, going with an option like 1) or 2) instead of 3) boils to how much overhead (coordination, engineering, potential problems) the Aave community wants to have in the future.
The Aave v1 protocol works by itself on-chain, being completely decentralized, but still, there are off-chain components and/or changes driven by tokens-markets potentially required in the future. For example, from the BGD perspective, we must keep in mind when doing developments that Aave v1 is still functioning, which obviously is a cost for the Aave community.

Regarding current users of Aave, there are both smart contracts and externally owned accounts (EOAs), but it is important to understand that in both 1) and 2) options, these users don’t get really affected; it is not as if they will get liquidated or anything like that. It is just that the pool will not allow more addictive actions, like borrowing more or supplying more liquidity. Of course, with 1) it will not be possible to refill collateral, but consider that if a user is able to refill collateral, is also able to migrate the position to Aave v2 Ethereum.
Regarding users “stuck” on other contracts out there, it boils down to if other platforms allow “closure” of their user positions, which in turn would withdraw from Aave v1; they should always, and if not, should not be Aave’s problem.

1 Like