KVORUM
aaveSource: Aave governance v3 · #378

Aave V2 deprecation

executedSep 22, 2025, 10:39 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

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
ContractsLendingPoolCollateralManagerCollectorClinicStewardV2
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

391 words

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:

  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 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.
  3. 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

Clinic Steward V2 activation payloads

Other

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

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
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

4 total
#0fallback()chain 0x1
Target
0xb1d6…cc1e
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0x93a8…083c
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#2fallback()chain 0x1
Target
0xb9ca…af0d
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#3fallback()chain 0x1
Target
0xb9cc…28a8
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters48
VP participating898.2K
Outcome (current)For
Current support100%

06Voters

48 total
Filter:
VoterChoice% of totalRationale
EA0xea0c…6b5aFor333K37.07%—1y ago
570x57ab…2922For290.8K32.37%—1y ago
EZezr3al.eth0x8659…7d0eFor136K15.14%—1y ago
B90xb933…8dd1For39.6K4.41%—1y ago
870x8787…ea52For25.7K2.86%—1y ago
EC0xecc2…6ac9For25.2K2.81%—1y ago
3D0x3ddc…05b0For20.2K2.24%—1y ago
7A0x7ae1…e585For10.4K1.16%—1y ago
3E0x3e32…c4d0For7.6K0.85%—1y ago
2C0x2cc1…4df1For6.7K0.74%—1y ago
440x4444…34b3For7580.08%—1y ago
0E0x0e00…ccfcFor720.80.08%—1y ago
A50xa54f…0f31For552.80.06%—1y ago
4D0x4d26…7017For397.40.04%—1y ago
8B0x8b37…2a22For255.90.03%—1y ago
F10xf13c…6dd3For209.30.02%—1y ago
080x0865…24ceFor149.40.02%—1y ago
3F0x3f97…a109For64.80.01%—1y ago
AA0xaaa5…a30eFor8.90.00%—1y ago
F70xf7fb…dc1aFor60.00%—1y ago
010x010d…4ee4For1.30.00%—1y ago
050x0579…4048For10.00%—1y ago
010x019e…2ee3For0.30.00%—1y ago
010x0100…7cc9For0.20.00%—1y ago
160x168f…7400For0.10.00%—1y ago
2F0x2f2f…f78aFor00.00%—1y ago
7F0x7f21…31e0For00.00%—1y ago
E80xe8ee…0877For00.00%—1y ago
4D0x4d12…7d7cFor00.00%—1y ago
D70xd712…1366For00.00%—1y ago
150x1523…080fFor00.00%—1y ago
210x21ff…c5a8For00.00%—1y ago
140x1475…6e15For00.00%—1y ago
A00xa0d0…604aFor00.00%—1y ago
E60xe6b8…452dFor00.00%—1y ago
BE0xbef8…9999For00.00%—1y ago
AC0xacc9…0b28For00.00%—1y ago
7A0x7a04…17a8For00.00%—1y ago
950x95d2…88f9For00.00%—1y ago
D20xd248…32aeFor00.00%—1y ago
A60xa6ac…2bf3For00.00%—1y ago
930x93e0…f6eeFor00.00%—1y ago
EE0xee2a…58a7For00.00%—1y ago
380x38dc…472dFor00.00%—1y ago
C40xc4cd…47bcFor00.00%—1y ago
ED0xed4c…9508For00.00%—1y ago
EB0xeb0e…a99dFor00.00%—1y ago
4D0x4d4a…1bdfFor00.00%—1y ago
Showing 48

07Forum

No forum thread is confidently linked to this proposal.