KVORUM
aaveSource: Aave governance v3 · #37

Aave V1 Deprecation Phase 2

executedMar 2, 2024, 08:09 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Approve upgrade of Aave v1 liquidation manager to allow liquidation of healthy positions with a 3% bonus, continuing phase 2 of the Aave v1 deprecation and off-boarding process to reduce operational overhead.

Type
contract upgrade

Key changes

  • Upgrade liquidation manager implementation to allow liquidations of collateralized positions with 3% liquidation bonus(high)
  • Facilitate further off-boarding of Aave v1 by enabling liquidation of healthy positions to reduce stuck liquidity(high)
  • Continue phase 2 of Aave v1 deprecation strategy as part of long-term off-boarding plan(medium)

Notable concerns

  • Liquidation of healthy positions represents a departure from normal liquidation mechanics
  • Aave v1 is an older architecture with different structure than v2 and v3, requiring ongoing monitoring and development resources
Contracts0xc3a6c8719bdb1a4f78fa0a4dd46301c73ee23a900x60eE8b61a13c67d0191c851BEC8F0bc850160710
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

244 words

Simple Summary

Approve further steps of Aave v1 off-boarding, to reduce operational overhead on deprecated Aave instances. Therefore the proposal suggests to upgrade the liquidation manager to allow liquidation of healthy positions with a fixed 3% bonus.

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. The proposed changes are in line with was suggested in the original offboarding plan for phase 2.

Specification

The proposal contract calls:

  • ADDRESSES_PROVIDER.setLendingPoolLiquidationManager(LIQUIDATION_MANAGER_IMPL);

to update the implementations accordingly.

This upgrade will:

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The decoded on-chain action set contains a single generic execute() call to a payload contract address, which is the standard pattern used in Aave governance proposals (a short executor payload that internally performs the specific protocol calls, such as setLendingPoolLiquidationManager). The calldata itself does not expose the internal logic beyond the execute() entrypoint, so I cannot directly verify the internal setLendingPoolLiquidationManager call or the exact liquidation bonus parameter from calldata alone. However, this is consistent with how Aave v1/v2/v3 governance proposals are typically structured, and the proposal provides links to the payload contract source and tests that implement exactly the described logic. There is no evidence of target mismatch, extra unstated actions, or omitted significant actions - only one action exists and it aligns with the single specification action described (upgrading the liquidation manager). Given the inherent opacity of the execute() pattern, confidence is medium rather than high, but no discrepancy is flagged since the description matches the typical structure and referenced implementation for this type of proposal.

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
0xc3a6…3a90
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.