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

Slopes

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

Slopes

Avalanche v2

RF / Base / Uoptimal

Slopes

References

• Implementation: AaveV2Ethereum, AaveV2Polygon, AaveV2Avalanche
• Tests: AaveV2Ethereum, AaveV2Polygon, AaveV2Avalanche
• AToken code diff
• Snapshot
• Discussion

Copyright

Copyright and related rights waived via CC0.