Upgrade Aave V3 pools to Aave V3.0.2
01Summary
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
Generated by Kvorum
02Description
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:
- Pool
- PoolConfigurator
- 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
- 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
flashloanableflag 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
- Repository
- Storage/code diffs
- sigma prime 3.0.1 audit report
- PeckShield 3.0.1 audit report
- Cerora 3.0.2 audit report
- sigma prime 3.0.2 audit report
- Forum discussion
- Payload:Mainnet
- Payload:Polygon
- Payload:Arbitrum
- Payload:Optimism
- Payload:Avalanche
- Payload:Fantom
- Update diffs
- BorrowLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- BridgeLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- ConfiguratorLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- EModeLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- FlashLoanLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- LiquidationLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- PoolLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- SupplyLogic: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- PoolImpl: Mainnet, Polygon, Arbitrum, Optimism, Avalanche, Fantom
- PoolConfiguratorImpl: Polygon, Arbitrum, Optimism, Avalanche, Fantom
- ATokenImpl: Polygon, Arbitrum, Optimism, Avalanche, Fantom
- STokenImpl: Polygon, Arbitrum, Optimism, Avalanche, Fantom
- VTokenImpl: Polygon, Arbitrum, Optimism, Avalanche, Fantom
- AaveProtocolDataProvider: Polygon, Arbitrum, Optimism, Avalanche, Fantom
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
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
04Actions
- Target
- 0x31a2…960f
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0xa603Ad2b0258bDda94F3dfDb26859ef205AE9244" }- Calldata
- Target
- 0x5f5c…6711
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x7748d38A160EEeF9559e2b043eAec5CfFFCE3E4c" }- Calldata
- Target
- 0xd1b3…cfa3
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x209Ad99bd808221293d03827B86cC544bcA0023b" }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedUpgrade Aave V3 pools to Aave V3.0.2100%
- aaveexecutedAave Pool update83%
- aaveexecutedAave v3.1 upgrade82%
- aaveexecutedUpgrade Aave instances to v3.6 Part 281%
- aaveexecutedUpgrade Aave instances to v3.6 Part 180%
- aaveexecutedUpgrade all Aave instances to 3.280%
- aaveexecutedUpgrade Aave instances to v3.480%
- aaveexecutedRewards controller update across V3 pools80%
- aaveexecutedUpgrade Aave instances to v3.379%
- aaveexecutedUpgrade Aave instances to v3.6 Part 379%