KVORUM
aaveSource: Aave governance v3 · #178

Upgrade all Aave instances to 3.2

executedOct 7, 2024, 12:06 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Upgrades all active Aave v3 instances to version 3.2, introducing Liquid eModes (allowing single assets in multiple eModes with granular collateral/borrowing controls) and fully deprecating stable borrowing. Includes $76,000 GHO reimbursement to BGD for external security procedures.

Type
contract upgrade
Funding
$76000

Key changes

  • Upgrade Pool and L2Pool implementations to 3.2 with stableDebtToken address set to address(0) for all assets(high)
  • Complete deprecation of stable borrowing by removing code artifacts that increased gas consumption and code size(high)
  • Introduction of Liquid eModes allowing single assets to be listed in multiple eModes with granular control over collateral and borrowable status(high)
  • Upgrade PoolConfigurator implementation to 3.2(medium)
  • Deploy new ProtocolDataProvider compatible with v3.2 and update on addresses provider(medium)
  • Migrate all assets currently in eMode to be both borrowable and collateral in eMode(medium)
  • Migrate InterestRateStrategy to version without stable rate calculations(medium)
ContractsPoolL2PoolPoolConfiguratorProtocolDataProvider
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

364 words

Simple Summary

Upgrades all active Aave instances to Aave 3.2 which debuts "Liquid eModes" and fully deprecated stable borrowing.

Motivation

EModes have been a powerful feature since the inception of Aave v3. Liquid eModes builds on this success by increase the flexibility in configuring eModes. With Liquid eModes it is now possible, to have a single asset be listed in multiple eModes. At the same time, it's possible to granularly control which assets are collateral and borrowable inside an eMode.

Stable debt has been off-boarded from Aave v3 for quite some time. What was remaining on the protocol code were merely artifacts that increased gas consumption and code size. Therefore the 3.2 release removes these artifacts in a backwards compatible way.

In addition to the upgrade itself, the proposal payload includes reimbursement of $76’000 denominated in GHO, to cover the cost of extra external security procedures incurred.

Specification

Aave 3.2 focuses on two main areas of the aave protocol:

  • The final deprecation of stable borrowing
  • Improvements on the eModes, introducing "Liquid eModes"

The proposal will execute to following operations on each active Aave v3 pool:

  • Upgrade the Pool/L2Pool implementation to 3.2, which will internally set the stableDebtToken address to address(0) on all assets
  • Upgrade the PoolConfigurator implementation to 3.2
  • Deploy new ProtocolDataProvider compatible with v3.2, and set it on the addresses provider contract
  • Migrate all assets currently in eMode to be both borrowable & collateral in eMode
  • Migrate the InterestRateStrategy to a new version without stable rate calculations

An additional payload will transfer 76,000.00 GHO to the BGD-controlled address 0xb812d0944f8F581DfAA3a93Dda0d22EcEf51A9CF.

Security procedures

In addition to unit tests & integration test suites, the changes have been audited in 5 audits by 4 independent auditors:

Stable Rate and Liquid eModes

Liquid eModes

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal description outlines a multi-part upgrade (Pool/L2Pool, PoolConfigurator, new ProtocolDataProvider, eMode migration, interest rate strategy) applied across all active Aave v3 instances, plus a separate 76,000 GHO reimbursement payload to a specified BGD address. The decoded calldata consists of four generic execute() calls (delegatecall-style payload execution pattern typical of Aave governance) to four distinct payload contract addresses, with no further decoded arguments exposed. This structure is consistent with the description's claim of applying the upgrade to multiple pool instances plus one additional payload for the GHO transfer — four actions roughly matching 'each active pool' (likely core, Lido, EtherFi) plus the GHO payload. However, because the decoded_function for every action is a bare fallback() with no arguments, it is impossible to verify the specific numeric details (e.g., 76,000 GHO amount, the exact recipient address, or the specific implementation addresses being set) directly against the calldata. No contradictions were found, but the opacity of the decoded actions limits verification confidence. I did not flag any discrepancies since nothing in the visible calldata contradicts the description, but confidence is low due to the lack of decoded parameters to cross-check specific claims like the GHO amount and recipient.

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

04Actions

4 total
#0fallback()chain 0x1
Target
0xb08c…9622
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0xf519…f290
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#2fallback()chain 0x1
Target
0x4e48…a790
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#3fallback()chain 0x1
Target
0x6d0a…d0b4
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.