KVORUM
aaveSource: Aave governance v3 · #98

Aave V1 Deprecation Phase 3

executedMay 10, 2024, 06:37 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Approve final phase of Aave v1 deprecation by disabling most pool functions (except liquidation, repay, withdraw), setting all interest rates to zero, replacing stablecoin oracles with capped oracles, increasing liquidation penalty from 3% to 5%, and updating core contract indexing to reduce operational overhead.

Type
protocol deprecation

Key changes

  • Disable all pool actions except liquidation, repay, and withdraw to prevent new positions(high)
  • Set all reserve interest rate strategies to zero interest rates(high)
  • Replace stablecoin oracles with capped oracles for consistency with Aave v2(medium)
  • Increase liquidation penalty from 3% to 5% while reducing gas overhead(medium)
  • Update POOL_CORE indexing upon interest rate updates(medium)

Notable concerns

  • No capital injection to core despite potential bad debt; treasury managers can inject capital later if liquidity constraints prevent withdrawals
  • Exact amount of bad debt cannot be calculated due to collateral being basketed across small positions
  • This is the final phase of v1 off-boarding
ContractsPOOLPOOL_COREPOOL_LIQUIDATION_MANAGERAave v1 stablecoin oracles
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

397 words

Simple Summary

Approve further steps of Aave v1 off-boarding, to reduce operational overhead on deprecated Aave instances.

Motivation

The Aave protocol v1 was released in January 2020 and eventually superseded by Aave protocol v2 in December on the same year.

While Aave v1 has been deprecated for a long time, some liquidity is still stuck on the protocol 1. Even if this instance is not covered by the Aave Safety Module, being part of Aave, it still is monitored and evaluated whenever development and/or security decisions are made.

This creates meaningful overhead for all involved development & security teams, which directly adds cost to the Aave DAO. Additionally, the architecture of Aave v1 is quite different to Aave v2 & v3, making it the most ad-hoc instance of Aave.

On 6th of february a first set of measures was implemented by the DAO to accelerate the offboarding process, followed by a second proposal on 3th of march.

This Phase 3 is the final phase of the off-boarding as suggested on the forum with some slight modifications:

  • the proposal does not inject capital to core. The rational being that:
    • there is enough liquidity for even the biggest account of each asset to withdraw.
    • it's not possible to calculate the exact amount of bad debt as some of the debt is collateralized with a basket of relatively small collateral positions.
    • if a situation in which a user cannot withdraw due to liquidity constrains ever occurs the treasury managers can easily inject capital at any point.
  • the proposal also replaces the stable asset oracles with the capo oracles introduced on aave v2 for consistency across the pools.

Specification

Upon execution the proposal upgrades the following contracts:

  • POOL: in order to disable all actions, but liquidation, repay & withdraw
  • POOL_CORE: in order to update the index upon IR updates
  • POOL_LIQUIDATION_MANAGER: in order to increase the static liquidation penalty from 3% to 5%, while reducing the gas overhead

Also, the proposal will change the pool configuration:

  • all reserves interest rate strategies will be replaced with a zero interest rate strategy
  • the stablecoin oracles are replaced with the capped oracles also used on ethereum v2

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal calldata consists of a single action: a call to execute() on an external payload contract. This is the standard pattern used by Aave governance proposals, where the actual multi-step logic (contract upgrades, interest rate strategy changes, oracle replacements, liquidation penalty updates) is encoded in the bytecode of the linked payload contract rather than being individually decoded as separate governance actions. Because the decoded calldata does not expose the internal steps performed by the executor, I cannot directly verify each specific claim in the description (e.g., the 3%→5% liquidation penalty change, the interest rate strategy replacement, or the oracle swap) against granular calldata parameters. However, this opacity is expected and consistent with how Aave v1/v2/v3 upgrade proposals are typically structured, and the single action target matches the pattern of an omnibus deprecation/upgrade payload as described. There is no evidence of a target mismatch, value mismatch, or extra/omitted action visible in the calldata that would contradict the description. Given the lack of granular visibility into the payload contract's internal logic, confidence in this comparison is low, but nothing in the available decoded data contradicts the description's claims, so I record this as consistent overall while flagging low confidence due to the opacity of the single delegatecall action.

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
0x9ccc…92fd
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.