[ARFC] Aave v2 deprecation (tech) - next phase

Development
1

Simple summary

Propose to the community further non-invasive deprecation steps on the technical side, by setting the CF (Close Factor) to 100% allowing smoother liquidations, cleaning bad debt via a new ClinicSteward adapted for v2, and minor code adjustments.


Context

After years of v2 being in a deprecated stage, with the majority (or all) of the assets on Ethereum/Polygon/Avalanche being frozen or disabled for borrowing, we believe it is necessary to continue with progressive deprecation steps for the system.

Given that the pools are still relatively big (especially v2 Ethereum with approximately $300m in size), this phase is still not invasive to users, mainly focused on making smoother liquidations, for the DAO to be able to clean up all historic bad debt without systemically leaving dust.

This proposal is, even if independent, complementary to this other by @TokenLogic and the risk providers.


Specification

The proposal will execute the following two steps on each network:

  1. Replace the LendingPoolCollateralManager with a version implementing 100% CF (Close Factor). For clarity, this means that whenever a position is eligible for liquidation (when reaching 1 HF), the liquidator will be able to close 100% of the position, instead of 50% if over the Close Factor threshold.

  2. Grant FUNDS_MANAGER role from the Collector to a ClinicStewardV2 smart contract, an adapted version of the one done HERE for Aave v3, for the DAO to clean up historic v2 bad debt with Collector’s funds.

    Additional details on its configuration:

    • The final budgets per asset (existing bad debt) will be defined later in this thread, before the AIP stage. To be confirmed by Chaos Labs as a risk provider.
    • The roles configuration of the steward will be the same as on v3’s: 2-of-3 for the superadmin (to not be really used), in this case, replacing kpk by one of the other risk providers. And a Dolce Vita EOA for the cleanup role, totally constrained by pre-defined budgets and on-chain logic.

  3. Do very minor changes to the precision of the system to have more compatibility with v3.

On the security side, the different components are to be reviewed by Certora.


Next steps

  • Receive feedback from the community during the following days.
  • Create the ARFC Snapshot.
  • If the ARFC Snapshot is positive, proceed to AIP on-chain.
6 Likes