Aave Governance V3 Activation
01Summary
Migration of Aave Governance from v2.5 to v3, transferring all permissions and executing smart contract upgrades across multiple chains. Aave Robot systems will be activated to support the new governance framework.
- Type
- governance change
Key changes
- Migrate ownership of v2 Executors to v3 Executors to prevent permissions lock(high)
- Upgrade implementations of Governance v3 voting assets (AAVE, stkAAVE, aAAVE) for compatibility with new system(high)
- Activate Aave Robot systems for optimal functioning of Governance v3(high)
- Transfer permissions for ARC and swap adapters on Base(medium)
- Temporary transfer of certain permissions to Mediator contract to enable atomic execution of Level 1 and Level 2 proposals(medium)
Notable concerns
- Two governance proposals must be atomically executed (Level 1 and Level 2) for successful migration
- Temporary permission transfer to Mediator contract required for synchronization
- Current v2.5 governance system will cease functioning upon execution of both proposals
Generated by Kvorum
02Description
Simple Summary
Proposal for the migration of the Aave Governance v2.5 to v3, transferring all permissions from the v2 system to v3, executing all required smart contracts upgrades and different miscellaneous preparations.
Additionally, Aave Robot systems is activated, being requirement for the optimal functioning of Governance v3.
Motivation
v3 is a the next iteration for the Aave governance smart contracts systems, controlling in a fully decentralized manner the whole Aave ecosystem.
Being a replacement on the currently running v2.5, a set of two proposals on v2.5 need to be passed to migrate one system to another: once both are passed and executed on the current governance smart contracts, these will stop working, and the new v3 ones will start operating.
Specification
A full specification can be found HERE, but as summary:
-
2 governance proposals need to be created: one running on the Level 1 Executor (Short Executor) and another on the Level 2 Executor (Long Executor).
-
As both proposals need to be atomically executed, a
Mediatorcontract will temporary receive certain permissions, in order to sync both Level 1 and Level 2. -
High-level, the proposals do the following:
- Migrate the ownership of the v2 Executors to the v3 Executors, in order to avoid any possible permissions lock.
- Upgrade the implementations of the Governance v3 voting assets (AAVE, stkAAVE and aAAVE), to make them compatible with the new system.
- Fund Aave Robot.
- Transfer permissions for ARC and for swap adapters on Base.
-
Implementation: V2Ethereum, V3Ethereum, V3EthereumLong, Avalanche, Polygon, Base
-
Tests: Ethereum, EthereumLong, Avalanche, Polygon, Base
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal description outlines a broad migration plan (executor ownership transfer, token implementation upgrades, robot funding, ARC/Base permission transfers) that, per the linked specification, is implemented via distinct 'payload' contracts (EthShortV3Payload, EthLongV3Payload, etc.), each invoked through a generic execute() call by the governance executor. Only one decoded action is provided here, calling execute() on a single address with no further argument detail — consistent with the standard Aave/BGD governance pattern where a single delegatecall to a payload contract encapsulates all the granular sub-actions described in the prose. Because the calldata only exposes the top-level execute() call and not the internal logic of the payload contract, we cannot directly verify each granular claim (e.g., exact addresses receiving ownership, exact funding amounts to the Robot). However, this is expected and normal for this proposal type — the pattern matches the well-documented BGD governance v2-to-v3 migration structure, and there is no evidence of a target, value, or function mismatch. No numeric values, target addresses, or extra/missing actions can be flagged as discrepancies given the information available. Confidence is medium rather than high because full verification of internal payload logic against every specific prose claim is not possible from the single decoded action provided.
Generated by Kvorum
04Actions
- Target
- 0xaf0c…1e2a
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aavecanceledAave Governance V3 Activation Short98%
- aavecanceledGovernance V3 Activation98%
- aaveexecutedAave Governance V3 Activation Short98%
- aaveexecutedGovernance v2.5 Activation91%
- aaveexecutedAdjust Aave Governance Level 2 requirements82%
- aaveexecutedMigrate Robots to Chainlink Automation v280%
- aaveexecutedRobot Maintenance79%
- aaveexecutedUse AAVE Ecosystem Reserve to vote YES on proposal to adjust Level 2 Governance requirements77%
- aaveexecutedMigration of remaining Gov v2 permissions & DAO's Paraswap positive slippage77%
- aaveexecutedFunding Aave Robot for Governance V2 Automation74%