KVORUM
aaveSource: Aave governor v2 · #208

Upgrade Aave V3 pools to Aave V3.0.2

canceledApr 29, 2023, 01:05 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Upgrade Aave v3 pools across Ethereum, Polygon, Optimism, and Arbitrum to v3.0.2 with improvements to isolation mode, LTV0, and flashBorrow handling. Also authorizes Guardian to upgrade Avalanche and Fantom pools via delegatecall. Affects Pool, PoolConfigurator, token implementations, and AaveProtocolDataProvider contracts.

Type
contract upgrade

Key changes

  • Upgrade Pool implementation to v3.0.2 across all networks(high)
  • Upgrade PoolConfigurator implementation to v3.0.2 (excluding mainnet)(high)
  • Replace AaveProtocolDataProvider with next iteration (excluding mainnet)(medium)
  • Update aToken, variableDebtToken, and stableDebtToken implementations for all reserves(high)
  • Enable flashloaning flag on all reserves to maintain current behavior(medium)
  • Grant ISOLATED_COLLATERAL_SUPPLIER_ROLE to SWAP_COLLATERAL_ADAPTER and MIGRATION_HELPER(medium)
  • Improvements to isolation mode, LTV0, and flashBorrower initiated flashloans handling(high)

Notable concerns

  • Upgrade affects multiple networks simultaneously requiring careful coordination
  • Storage layout changes require verification to prevent misalignment issues
  • Changes to flashloan functionality across all reserves should be monitored
ContractsPoolPoolConfiguratoraTokenvariableDebtTokenstableDebtTokenAaveProtocolDataProvider
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

698 words

Simple Summary

This proposal upgrades the Aave v3 instances on Ethereum, Polygon, Optimism and Arbitrum to the v3.0.2 version. The v3.0.2 is an upgrade based on the v3.0.1 version already running on the new Aave v3 Ethereum pool which comes with improvements to the handling of isolation mode, LTV0, and flashBorrower initiated flashloans. If this proposal succeeds, it will also authorize the upgrade of the V3 pools on Avalanche and Fantom via a delegatecall by the Aave Guardian.

The upgrades to be performed will affect the following contracts:

  1. Pool
  2. PoolConfigurator
  3. aToken/variableDebtToken/stableDebtToken

And replace the AaveProtocolDataProvider on the PoolAddressesProvider with it's next iteration.

Motivation

Aave v3 Ethereum has been activated via Aave governance at the end of January. But in reality, as described HERE, the smart contracts on Ethereum are a slightly improved version of v3, the so-called v3.0.1.

In an ecosystem like Aave, with liquidity pool instances spread across multiple networks, it is fundamental to try to keep version consistency, which is not the case at moment, with Polygon, Avalanche, Optimism, Arbitrum, Fantom, and Harmony running still on v3.0.0. Therefore this proposal aligns all pools at v3.0.2.

Specification

Upon execution on the respective network the proposal will:

  • call POOL_ADDRESSES_PROVIDER.setPoolImpl(NEW_POOL_IMPL) to replace the Pool implementation (all networks)
  • call POOL_ADDRESSES_PROVIDER.setPoolConfiguratorImpl(NEW_POOL_CONFIGURATOR_IMPL) to replace the PoolConfigurator implementation (all networks, excluding mainnet)
  • call POOL_ADDRESSES_PROVIDER.setPoolDataProvider(NEW_PROTOCOL_DATA_PROVIDER) to replace the AaveProtocolDataProvider (all networks, excluding mainnet)
  • iterate through all currently listed tokens on the pool (fetched via POOL.getReservesList()) (all networks, excluding mainnet)
    • call POOL_CONFIGURATOR.updateAToken(inputAToken) to replace the aToken implementation
    • call POOL_CONFIGURATOR.updateVariableDebtToken(inputVToken) to replace the vToken implementation
    • call POOL_CONFIGURATOR.updateStableDebtToken(inputSToken) to replace the sToken implementation
    • call POOL_CONFIGURATOR.setReserveFlashLoaning(reserve, true) to enable flashloaning on the reserve
  • call ACL_MANAGER.grantRole(ISOLATED_COLLATERAL_SUPPLIER_ROLE, SWAP_COLLATERAL_ADAPTER) to maintain pre-upgrade behavior (all networks, excluding harmony)
  • call ACL_MANAGER.grantRole(ISOLATED_COLLATERAL_SUPPLIER_ROLE, MIGRATION_HELPER) to maintain pre-upgrade behavior (mainnet, avalanche, polygon)

Security and additional considerations

We applied the following security procedures for this upgrade:

  • Code diffing: Comparing the codebase of all v3.0.0 with the one of v3.0.1, more specifically the one on Aave v3 Ethereum, to not have any unexpected logic included.
  • Storage diffing: Comparing the storage layout of both versions, to verify that there is no misalignment between them, which could create important problems.
  • Assets configurations pre/post upgrade: In a simulation environment, validating the configurations of the assets pre-upgrade are the same as post-upgrade, only with those changes that are intended (e.g. enabling the new flashloanable flag only present on v3.0.1, later explained).
  • Additional E2E tests: Also in a simulation environment, checking that the main actions available on the pool can be performed (e.g. supply, borrow) on all pools with non-frozen assets.
  • Extra review: Given their involvement in the development of Aave v3, we have requested AaveCompanies to take a look at the procedure, in order to have multiple parties validating it.
  • Audit: Certora and SigmaPrime reviewed the v3.0.1 -> v3.0.2 changes

The decision to enable flashloanable for all the assets has been taken in order to have the highest possible consistency with the current state of the assets in the pools: currently, all are flashloanable, so by enabling the new flag, they will continue to be so.

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The decoded top-level actions consist of exactly 4 calls, all originating from the Ethereum mainnet governance executor: (1) a direct fallback execute() on the address that the description explicitly links as 'Payload:Mainnet', and (2)-(4) execute(address) calls on separate bridge/executor contracts, each passing the exact addresses the description links as 'Payload:Polygon', 'Payload:Optimism', and 'Payload:Arbitrum'. This structure is fully consistent with the description's claim that the proposal upgrades Ethereum, Polygon, Optimism and Arbitrum directly, while explicitly NOT including Avalanche or Fantom in the direct action set — which matches the description's statement that Avalanche/Fantom require a separate delegatecall by the Aave Guardian rather than direct execution here. All four target/argument addresses match the reference links in the proposal text exactly, so there is no target_mismatch. The detailed internal specification (setPoolImpl, setPoolConfiguratorImpl, token implementation updates, flashloan flag enabling, ACL role grants) is not independently visible in this decoded action set because those steps execute inside the payload contracts' own execute() logic once triggered — this is a case of legitimate summarization/necessary abstraction for a cross-chain payload pattern, not a hidden or contradictory action. Confidence is medium rather than high because the internal calldata of the payload contracts (where the granular per-asset and per-role actions actually occur) was not provided for direct verification against the detailed specification section. Given the strong structural and address-level match with no contradicting or unexplained top-level actions, this proposal is assessed as consistent.

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
0x31a2…960f
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1execute(address)chain 0x1
Target
0x158a…d45b
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0xa603Ad2b0258bDda94F3dfDb26859ef205AE9244"
}
Calldata
#2execute(address)chain 0x1
Target
0x5f5c…6711
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x7748d38A160EEeF9559e2b043eAec5CfFFCE3E4c"
}
Calldata
#3execute(address)chain 0x1
Target
0xd1b3…cfa3
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x209Ad99bd808221293d03827B86cC544bcA0023b"
}
Calldata

05Tally

Summed from votes

Voters15
VP participating488.4K
Outcome (current)For
Current support100%

06Voters

15 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.