KVORUM
aaveSource: Aave governance v3 · #132

Aave v3.1 upgrade

executedJul 26, 2024, 02:18 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Proposal to upgrade Aave v3 to v3.1 across all active instances, focusing on security improvements and operational efficiency. Key features include virtual accounting, stateful interest rate strategy, freezing by emergency guardian, and various optimizations. PoolConfigurator and Pool implementations will be upgraded with data reinitialization on all networks.

Type
contract upgrade

Key changes

  • Virtual accounting implementation for improved asset tracking(high)
  • Stateful interest rate strategy replacing previous approach(high)
  • Freezing capability by EMERGENCY_GUARDIAN on PoolConfigurator(high)
  • Reserve data update on rate strategy and Reserve Factor changes(medium)
  • Minimum decimals requirement for listed assets(medium)
  • Liquidations grace sentinel feature(medium)
  • LTV0 on freezing for better risk management(medium)
  • Permission-less movement of stable positions to variable(medium)

Notable concerns

  • RISK_ADMIN role temporarily disabled on Avalanche requiring follow-up proposal to re-enable
  • Upgrade affects all active Aave v3 instances requiring coordinated deployment
  • Virtual accounting initialization required for all assets except GHO
  • GHO handled ad-hoc due to fixed rate mechanics
ContractsPoolConfiguratorPoolPoolDataProviderPoolAddressesProvider
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

501 words

Simple Summary

Proposal for the activation of Aave v3.1 as an upgrade on top of all active Aave v3 instances.

The codebase can be found on https://github.com/aave-dao/aave-v3-origin

Motivation

Aave v3 is a “living” DeFi protocol, which akin to any other software, receives upgrades over time on its different components. Sometimes, the improvements can be made in isolation in independent upgrades, for example, almost 1 year ago, we introduced a new 3.0.2 version, including only relatively minor changes and bug fixes.

However, since 3.0.2, we had multiple other ideas on the backlog heavily focused on security and optimisation, that over time got validated due to security incidents on similar protocols and by observing operational overhead for Aave contributors (e.g. governance proposals changing parameters). As some of this features in some cases were dependent between each other, end of 2023 we decided to batch them together in a new major-minor Aave v3 version we propose for activation here: Aave v3.1.

Specification

v3.1 is clearly focused in 2 fields: redundant security and optimisation of the logic to reduce operational overhead. With those principles in mind, the following is a summarised of the features/improvements included in the release (for extensive information, full specification can be found HERE):

  1. Virtual accounting
  2. Stateful interest rate strategy
  3. Freezing by EMERGENCY_GUARDIAN on PoolConfigurator
  4. Reserve data update on rate strategy and RF (Reserve Factor) changes
  5. Minimum decimals for listed assets
  6. Liquidations grace sentinel
  7. LTV0 on freezing
  8. Permission-less movement of stable positions to variable
  9. Allow setting debt ceiling whenever LT is 0
  10. New getters on Pool and PoolConfigurator for library addresses
  11. Misc minor bug fixes and sync the codebase with the current v3 production

Upgrade payloads

All the information about this upgrade can be found on the payload repository, but to summarise, for each network:

  1. The PoolConfigurator implementation is upgraded.
  2. The Pool implementation is upgraded. On initialization of the new implementation:
  • For each asset, indexes and rate data is updated to the most recent value.
  • Also for each asset (except GHO), virtual balance (virtual accounting storage variable) is initialized, together with the flag to enable virtual accounting.
  1. The PoolDataProvider address is updated on the PoolAddressesProvider.
  2. _pendingLtv is initialized for all frozen assets on the PoolConfigurator.
  3. The new stateful interest rate strategy is connected to every asset with the current production paramaters. GHO is handled ad-hoc in this stage, given its fixed rate.
  4. The RISK_ADMIN role is temporarily disabled for Aave v3 Avalanche, due to incompatibility with the new freezing and LTV0 mechanics. It will be re-enabled in a follow-up proposal.

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal describes a multi-step Aave v3.1 upgrade (PoolConfigurator upgrade, Pool upgrade with virtual accounting/index initialization, PoolDataProvider address update, pending LTV initialization, new interest rate strategy connection, and temporary RISK_ADMIN role disablement on Avalanche). The decoded on-chain action is a single execute()/fallback call to one payload contract address on mainnet. This is consistent with Aave's standard governance pattern where a single proposal action delegatecalls a payload contract (here matching the referenced UpgradePayload implementation in the linked repository) that internally performs all the granular steps described in the 'Upgrade payloads' section. Because the calldata only shows the outer execute() call and not the payload's internal logic, I cannot independently verify every internal step (e.g., exact parameters for interest rate strategies or the Avalanche RISK_ADMIN change) from the decoded action alone. However, there is no sign of a target mismatch, extra action, or omitted top-level action — the single decoded action aligns with the proposal's framing as one upgrade payload execution. Given the opacity of the payload's internals, confidence is medium rather than high, but nothing in the visible calldata contradicts the description, so I classify this as consistent with no flagged discrepancies.

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
0x3bf1…2d7c
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.