KVORUM
aaveSource: Aave governance v3 · #383

Aave v2 Deprecation - Update

executedOct 7, 2025, 12:58 AM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal implements the next phase of Aave v2 deprecation across Ethereum, Polygon, and Avalanche by increasing borrowing costs through interest rate curve adjustments, raising reserve factors to 85%, freezing Ethereum v2 reserves, updating the aWBTC implementation, and allocating $1M and $2.5k budgets for bad debt coverage on Ethereum Core and AMM respectively.

Type
parameter change
Funding
$1000002500

Key changes

  • Increase Base rate to 5% for commonly borrowed assets (wETH, USDC, USDT, DAI, POL, AVAX) across all three chains to discourage borrowing(high)
  • Reduce Uoptimal parameter across reserves to target 25% utilization level, progressively moving away from current higher utilization rates(high)
  • Reduce Slope2 parameter to 40% across most assets to avoid excessive borrowing costs at near-full utilization(high)
  • Increase Reserve Factor to 85% to lower deposit rates and discourage idle capital in v2(high)
  • Freeze all reserves on Ethereum V2 Core(high)
  • Update aWBTC implementation on Ethereum Core to correct metadata configuration (symbol & name)(medium)
  • Allocate $1M budget to Ethereum Core ClinicSteward and $2.5k to Ethereum AMM ClinicSteward for bad debt coverage(medium)
  • Increase Slope1 rates for select assets on Polygon (wETH from 10% to 15%, POL from 12% to 15%) and Avalanche (wETH, AVAX, USDT.e, DAI from 9-10% to 15%)(medium)

Notable concerns

  • ClinicSteward budget estimation on v2 was inadequate due to higher prevalence of positions with residual collateral compared to v3
  • aWBTC metadata was incorrectly configured in previous proposal 378 due to technical differences between v2 versions
  • Reserve factor increases to 85% may further reduce incentives for v2 deposits
ContractsAaveV2Ethereum.POOL_CONFIGURATORAaveV2Ethereum.CLINIC_STEWARDAaveV2EthereumAMM.CLINIC_STEWARDAaveV2PolygonAaveV2Avalanche
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

1,167 words

Simple Summary

This proposal presents the next round of parameter updates to be implemented as we work towards deprecating v2 instances of Aave Protocol across Polygon, Ethereum and Avalanche.

Motivation

This proposal builds on previous efforts that froze both Polygon v2 and Avalanche v2, supporting the deprecation of Aave v2 and ensuring a smooth, controlled, and secure transition to Aave v3.

The proposed changes are designed to increase borrowing costs through adjustments to the interest rate curve parameters, creating stronger incentives for users to migrate to Aave v3. Where practical, a standardized approach of reducing the Uoptimal parameter has been applied, alongside adjustments to the Base and Slope1 parameters to raise borrow rates. At the same time, the Slope2 parameter has been reduced to avoid excessive borrowing costs at near-full utilization. Overall, these changes raise borrow rates without exposing users to extreme costs.

The updated Uoptimal parameter now exceeds current reserve utilization levels and is expected to be progressively lowered toward a 25% target.

For commonly borrowed assets, the Base parameter is increased to 5%, with further increases planned as reserve liquidity decreases. This gradual adjustment ensures a minimum borrow rate is always maintained.

Additionally, the Reserve Factor is increased to 85%, resulting in lower deposit rates that discourage idle capital remaining in v2.

These changes represent a coordinated effort among several service providers to align incentives and ensure the long-term health of the Aave ecosystem.


As a follow up to the previous deprecation proposal this proposal includes the following changes:

  • In proposal 378, the metadata(symbol & name) was incorrectly configured on the aWBTC implementation due to minor technical differences between the different v2 versions. Therefore, this proposal will update the aWBTC implementation on mainnet Core, with a code-wise identical but correctly initialized version.
  • In proposal 378, the clinic steward was configured with estimated budgets based on the existing bad debt following the same practice as on v3 activation - namely taking the current deficit and adding a minor(5%) buffer on top. While on v3 this worked fine, on v2 this estimation fell short. The ClinicSteward overestimated debt whenever a position is not clean, meaning when there is residual collateral. On v2 mainnet, this situation is far more common than on v3, which was not considered in the budget planning. Therefore this proposal sets the available budget to 1M$ on Core and 2.5k on AMM, respectively so the remaining bad debt can be covered. It's important to note that the configured "budget" does not directly reflect the amount spent, but is just a safety net on the clinic steward. The overall funds spent will not exceed the total bad debt.

Specification

Ethereum v2

RF / Base / Uoptimal

AssetRF CurrentRF ProposedBase CurrentBase ProposedUoptimal CurrentUoptimal Proposed
wETH85.00%85.00%0.00%5.00%80.00%25.00%
wBTC90.00%90.00%0.00%20.00%65.00%25.00%
USDC70.00%85.00%0.00%5.00%90.00%60.00%
USDT70.00%85.00%0.00%5.00%80.00%40.00%
DAI70.00%85.00%0.00%5.00%80.00%50.00%

Slopes

AssetSlope1 CurrentSlope1 ProposedSlope2 CurrentSlope2 Proposed
wETH3.80%5.00%80.00%40.00%
wBTC0.00%0.00%300.00%40.00%
USDC12.50%12.50%60.00%40.00%
USDT12.50%12.50%60.00%40.00%
DAI12.50%12.50%60.00%40.00%

Additionally:

  • freeze all reserves on Ethereum V2 Core via ILendingPoolConfigurator(AaveV2Ethereum.POOL_CONFIGURATOR).freezeReserve(asset).
  • updates the aWBTC impl on Core via AaveV2Ethereum.POOL_CONFIGURATOR.updateAToken(AaveV2EthereumAssets.WBTC_UNDERLYING, WBTC_IMPL).
  • renews the budget for Corevia IClinicSteward(AaveV2Ethereum.CLINIC_STEWARD).setAvailableBudget(1_000_000e8).
  • renews the budget for AMM via IClinicSteward(AaveV2EthereumAMM.CLINIC_STEWARD).setAvailableBudget(2_500e8).

Polygon v2

RF / Base / Uoptimal

AssetRF CurrentRF ProposedBase CurrentBase ProposedUoptimal CurrentUoptimal Proposed
wETH99.99%99.99%0.00%5.00%40.00%25.00%
wBTC99.99%99.99%0.00%20.00%37.00%25.00%
USDC.e99.99%99.99%0.00%5.00%77.00%65.00%
DAI99.99%99.99%0.00%5.00%71.00%45.00%
USDT99.99%99.99%0.00%5.00%52.00%35.00%
POL99.99%99.99%0.00%5.00%48.00%25.00%

Slopes

AssetSlope1 CurrentSlope1 ProposedSlope2 CurrentSlope2 Proposed
wETH10.00%15.00%134.00%40.00%
wBTC0.00%0.00%134.00%40.00%
USDC.e15.00%15.00%134.00%40.00%
DAI15.00%15.00%134.00%40.00%
USDT15.00%15.00%134.00%40.00%
POL12.00%15.00%134.00%40.00%

Avalanche v2

RF / Base / Uoptimal

AssetRF CurrentRF ProposedBase CurrentBase ProposedUoptimal CurrentUoptimal Proposed
wBTC.e99.99%99.99%20.00%20.00%45.00%25.00%
wETH80.00%85.00%0.00%5.00%45.00%25.00%
USDC.e80.00%85.00%0.00%5.00%80.00%25.00%
AVAX80.00%85.00%0.00%5.00%45.00%25.00%
USDT.e80.00%85.00%0.00%5.00%80.00%45.00%
DAI80.00%85.00%0.00%5.00%80.00%80.00%

Slopes

AssetSlope1 CurrentSlope1 ProposedSlope2 CurrentSlope2 Proposed
wBTC.e0.00%0.00%300.00%40.00%
wETH10.00%15.00%300.00%40.00%
USDC.e0.00%0.00%75.00%40.00%
AVAX5.00%15.00%300.00%40.00%
USDT.e9.00%15.00%75.00%40.00%
DAI9.00%15.00%75.00%40.00%

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The only decoded on-chain action available is a generic execute()/fallback() call to a single payload contract on Ethereum (chain 0x1). This matches the standard Aave governance execution pattern, where the DAO's governance contract calls a purpose-built payload contract that internally performs all the granular changes (interest rate curve parameter updates across Ethereum/Polygon/Avalanche v2 markets, reserve freezes, the aWBTC implementation fix, and ClinicSteward budget updates) described in the proposal text. Because the calldata is opaque at this level of decoding (no internal calls, function selectors, or parameter values are exposed for the sub-actions on Polygon, Avalanche, or the specific rate/budget parameters on Ethereum), I cannot verify individual numeric values (RF, Base, Slope1, Slope2, Uoptimal, budget amounts) against the tables in the description, nor confirm the freeze and aToken update calls independently. There is nothing in the visible calldata that contradicts the description, and the single execute() call to a dedicated payload contract is exactly what would be expected for a proposal of this type and scope. Given the lack of granular visibility into the payload's internal logic, confidence in this comparison is low, and no discrepancies can be responsibly flagged — flagging based on absence of visible detail would risk a false alarm. The overall assessment is therefore 'consistent' with low confidence, reflecting that nothing observable contradicts the description, while acknowledging the comparison is limited by the level of calldata decoding provided.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

1 total
#0fallback()chain 0x1
Target
0xc5c4…83cc
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters28
VP participating887.4K
Outcome (current)For
Current support100%

06Voters

28 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.