ARC. Strategy on sunsetting of Aave v1

Governance
1

TL; DR

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.


Context

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.


Options

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.
8 Likes
2

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 ?

3

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
4

We have published a Snapshot vote, starting on Monday November 21st for the community to take a decision on the matter, you can participate on https://snapshot.org/#/aave.eth/proposal/0xe4d1c311dcd4a4e392e0333494d3aac8a2521071097e85eeedc34994fa6ed72e

As mentioned before, from a perspective of maintenance overhead, Option 1 is most probably the natural one, but we will execute the decision of the Aave community.

1 Like
5

Hey builders! PM me if you want to add a comment to the article

1 Like
7

Following the approval on Snapshot, we have created a proposal to freeze both Aave v1 and Aave v1 AMM on Ethereum.

The proposal will be open for voting in approximately 24h on https://app.aave.com/governance/proposal/?proposalId=129

3 Likes
8

Has there been any security review(s) done in connection with this proposal?

9

This proposal is actually similar to others triggering parameter changes on the protocol, so same as those, security auditors don’t review them (with exceptions when the proposal payload is really large). The main reason is that these changes don’t really modify the protocol, but call one/multiple functions on it (in this case freezeReserve() on the Pool Configurators of v1). In addition, audit time is quite valuable, so we use our criteria to what we consider worth it or not.

Our approach for this proposal is similar to any other of this nature:

  • Implement a test suite, that executes the proposal payload and validates post-conditions (in this case, that the different assets are effectively frozen). HERE
  • Once live verify the post-effects using the Aave Seatbelt reports on https://github.com/bgd-labs/seatbelt-for-ghosts
  • Generate our BGD proposal report, which is basically a final “manual” review of everything (we will publish it for 129 in the following hours).

The proposal payload can be found on https://etherscan.io/address/0x6f02253c80a041a773efa35c98d4bc14a0f6ef9e#code doing:

  1. Fetch the addresses of all the assets on v1
  2. Per each asset, call freezeReserve(assetAddress)
1 Like
10

Thanks for the explanation. I support this proposal.

11

The on-chain proposal 129 to freeze Aave v1 and v1 AMM has not reached the necessary YES support to pass.

Given that the support on the pre-approval on Snapshot was relatively high (above the 320k required on-chain and 2000+ votes), we are open to propose it again in the future, if the community shows will to it here on the forum. If not, we respect the decision.

12

Hey @bgdlabs,
i think the problem is really the weekend. We already saw it several times, that when a proposal ends on the weekend there aren’t enough votes. My suggestion would be to start a new proposal on a Monday or tuesday. More people will see it whether on the forum, twitter, etc.

I would like to see it again and vote again YES.

1 Like
13

From historical data weekends vote struggle more to reach quorum.

I invite the community to consider avoiding publishing AIPs on fridays from now on.

Mondays seems a better fit. and as this proposal was non-contentious we are supportive of a re-run by BGD Labs

3 Likes
14

I am in support to resubmit this proposal. As it was over the weekend, I missed the vote.

1 Like
15

We echo some of the comments shared above.

Please resubmit this AIP - preferably early/mid-week - and you have our support.

Seems like it will pass with another try and education around the timing of the vote.

1 Like
16

Given that there seems to be clear support, we will be re-submitting the proposal on Monday 19th, with the vote starting on the 20th.

5 Likes
17

The proposal has been submitted again, and voting will start in approximately 24h https://app.aave.com/governance/proposal/?proposalId=132

1 Like
18

We are in support of this proposal! We believe it is time to wind down Aave V1 in favor of leaner operations.

Quick question, how much does Aave spend of maintaining Aave V1?
I hoped that number would be contained in this proposal.

19

That is a good question @Kene_StableLab .

From the technical side, the maintenance of Aave v1 is not what we can consider “high”, but as with any legacy technology, there are “tail costs” associated with it, said:

  • Always keep in mind potential security problems on the smart contracts, for example, when new attack patterns are discovered on DeFi.
  • Maintenance of legacy user interfaces covering Aave v1. This affecting @AaveLabs and all other entities with user interfaces.
  • The off-boarding tasks themselves, like the current freezing.
  • The personnel expertise regarding all the components of v1, which usually is more concentrated in fewer people than in the case of Aave v2 and v3.

Difficult to quantify the cost, but it definitely exists.