Aave V2 deprecation
01Summary
Proposal to continue Aave V2 deprecation by setting Close Factor to 100% for smoother liquidations, deploying ClinicStewardV2 with budgets totaling ~$1M to clean up historic bad debt across Ethereum, Polygon, and Avalanche, and making minor precision adjustments for V3 compatibility.
- Type
- protocol deprecation
- Funding
- $~1,013,500
Key changes
- Replace LendingPoolCollateralManager with version implementing 100% Close Factor, allowing liquidators to close 100% of positions when HF reaches 1 (previously 50%)(high)
- Grant FUNDS_MANAGER role from Collector to ClinicStewardV2 contract to clean up historic V2 bad debt(high)
- Deploy ClinicStewardV2 with designated budgets: $1M Ethereum core, $1k Ethereum AMM, $2.5k Avalanche, $5k Polygon(medium)
- Make minor precision adjustments to system for V3 compatibility(low)
Notable concerns
- Implementation across multiple networks (Ethereum core, Ethereum AMM, Polygon, Avalanche) requires coordinated execution
- ClinicStewardV2 role permissions require careful configuration to prevent misuse despite budget constraints
- V2 pools remain relatively large ($300M on Ethereum) and deprecation is still ongoing
- Complementary to parallel V2 deprecation proposal which should be coordinated
Generated by Kvorum
02Description
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.
Motivation
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:
-
Replace the
LendingPoolCollateralManagerwith 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. -
Grant
FUNDS_MANAGERrole from theCollectorto aClinicStewardV2smart 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 pool are as follows:
- 1M $ on Ethereum core
- 1k $ on Ethereum AMM
- 2.5k $ on Avalanche
- 5k $ on Polygon
- The roles configuration of the steward will be the same as on v3’s for the superadmin (to not be really used). And a Dolce Vita EOA for the cleanup role, totally constrained by pre-defined budgets and on-chain logic.
- The final budgets per pool are as follows:
-
Do very minor changes to the precision of the system to have more compatibility with v3.
On the security side, the different components have been reviewed by Certora.
References
Aave V2 deprecation payloads
- Implementation: UpgradePayloadMainnet, UpgradePayloadAMM, UpgradePayloadPolygon, UpgradePayloadAvalanche
- Tests: UpgradePayloadMainnet, UpgradePayloadAMM, UpgradePayloadPolygon, UpgradePayloadAvalanche
Clinic Steward V2 activation payloads
- Implementation: ClinicStewardV2Activation
- Tests: ClinicStewardV2Activation
Other
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The four decoded actions are all generic execute() delegatecall invocations on payload/executor contracts, with no internal arguments decoded. This is the standard Aave governance pattern where a mainnet proposal triggers pre-built 'payload' contracts (one per network: Core, AMM, Polygon, Avalanche) that themselves contain the detailed logic (Close Factor change, role grants, budget configuration, precision tweaks) and, for L2s, dispatch cross-chain messages. The count (4) and mainnet-only execution align with the four referenced payload contracts (UpgradePayloadMainnet, UpgradePayloadAMM, UpgradePayloadPolygon, UpgradePayloadAvalanche) named in the proposal's References section, so nothing in the visible calldata contradicts the description. However, because the calldata does not expose the actual parameters (100% Close Factor value, FUNDS_MANAGER grant, specific budget figures, or EOA address), it is not possible to independently verify these quantitative claims from the decoded arguments alone — the analysis relies on trusting the linked, audited payload source code. Given this opacity, confidence in a full match is low, but there is no evidence of any value mismatch, target mismatch, or omitted/extra action visible in what was decoded, so the assessment defaults to consistent rather than flagging an unverifiable claim as a discrepancy.
Generated by Kvorum
04Actions
- Target
- 0xb1d6…cc1e
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x93a8…083c
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xb9ca…af0d
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xb9cc…28a8
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| EA0xea0c…6b5a | For | 333K | 37.07% | — | 1y ago |
| 570x57ab…2922 | For | 290.8K | 32.37% | — | 1y ago |
| EZezr3al.eth0x8659…7d0e | For | 136K | 15.14% | — | 1y ago |
| B90xb933…8dd1 | For | 39.6K | 4.41% | — | 1y ago |
| 870x8787…ea52 | For | 25.7K | 2.86% | — | 1y ago |
| EC0xecc2…6ac9 | For | 25.2K | 2.81% | — | 1y ago |
| 3D0x3ddc…05b0 | For | 20.2K | 2.24% | — | 1y ago |
| 7A0x7ae1…e585 | For | 10.4K | 1.16% | — | 1y ago |
| 3E0x3e32…c4d0 | For | 7.6K | 0.85% | — | 1y ago |
| 2C0x2cc1…4df1 | For | 6.7K | 0.74% | — | 1y ago |
| 440x4444…34b3 | For | 758 | 0.08% | — | 1y ago |
| 0E0x0e00…ccfc | For | 720.8 | 0.08% | — | 1y ago |
| A50xa54f…0f31 | For | 552.8 | 0.06% | — | 1y ago |
| 4D0x4d26…7017 | For | 397.4 | 0.04% | — | 1y ago |
| 8B0x8b37…2a22 | For | 255.9 | 0.03% | — | 1y ago |
| F10xf13c…6dd3 | For | 209.3 | 0.02% | — | 1y ago |
| 080x0865…24ce | For | 149.4 | 0.02% | — | 1y ago |
| 3F0x3f97…a109 | For | 64.8 | 0.01% | — | 1y ago |
| AA0xaaa5…a30e | For | 8.9 | 0.00% | — | 1y ago |
| F70xf7fb…dc1a | For | 6 | 0.00% | — | 1y ago |
| 010x010d…4ee4 | For | 1.3 | 0.00% | — | 1y ago |
| 050x0579…4048 | For | 1 | 0.00% | — | 1y ago |
| 010x019e…2ee3 | For | 0.3 | 0.00% | — | 1y ago |
| 010x0100…7cc9 | For | 0.2 | 0.00% | — | 1y ago |
| 160x168f…7400 | For | 0.1 | 0.00% | — | 1y ago |
| 2F0x2f2f…f78a | For | 0 | 0.00% | — | 1y ago |
| 7F0x7f21…31e0 | For | 0 | 0.00% | — | 1y ago |
| E80xe8ee…0877 | For | 0 | 0.00% | — | 1y ago |
| 4D0x4d12…7d7c | For | 0 | 0.00% | — | 1y ago |
| D70xd712…1366 | For | 0 | 0.00% | — | 1y ago |
| 150x1523…080f | For | 0 | 0.00% | — | 1y ago |
| 210x21ff…c5a8 | For | 0 | 0.00% | — | 1y ago |
| 140x1475…6e15 | For | 0 | 0.00% | — | 1y ago |
| A00xa0d0…604a | For | 0 | 0.00% | — | 1y ago |
| E60xe6b8…452d | For | 0 | 0.00% | — | 1y ago |
| BE0xbef8…9999 | For | 0 | 0.00% | — | 1y ago |
| AC0xacc9…0b28 | For | 0 | 0.00% | — | 1y ago |
| 7A0x7a04…17a8 | For | 0 | 0.00% | — | 1y ago |
| 950x95d2…88f9 | For | 0 | 0.00% | — | 1y ago |
| D20xd248…32ae | For | 0 | 0.00% | — | 1y ago |
| A60xa6ac…2bf3 | For | 0 | 0.00% | — | 1y ago |
| 930x93e0…f6ee | For | 0 | 0.00% | — | 1y ago |
| EE0xee2a…58a7 | For | 0 | 0.00% | — | 1y ago |
| 380x38dc…472d | For | 0 | 0.00% | — | 1y ago |
| C40xc4cd…47bc | For | 0 | 0.00% | — | 1y ago |
| ED0xed4c…9508 | For | 0 | 0.00% | — | 1y ago |
| EB0xeb0e…a99d | For | 0 | 0.00% | — | 1y ago |
| 4D0x4d4a…1bdf | For | 0 | 0.00% | — | 1y ago |
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedAave V1 Deprecation Phase 385%
- aaveexecutedAave V1 Deprecation84%
- aaveexecutedAave V1 Deprecation Phase 284%
- aaveexecutedUpgrade all Aave instances to 3.280%
- aaveexecutedAave v3.1 upgrade78%
- aaveexecutedV2 Stable Debt Offboarding76%
- aaveexecutedUpgrade Aave instances to v3.7 Part 276%
- aaveexecutedUpgrade the safety module to v1.5 PART 276%
- aaveexecutedUpgrade the safety module to v1.5 PART 176%
- aaveexecutedMultichain Stable Debt Token Upgrades76%