Upgrade Aave instances to v3.4
01Summary
Upgrade Aave v3 Protocol from v3.3 to v3.4 across all networks. Key improvements include standardizing GHO token implementations on Ethereum Core, adding multi-call support, introducing a configurable Position Manager, removing unbacked logic, and simplifying flash loan fees. The upgrade has undergone extensive testing, fuzzing, and four independent security audits.
- Type
- contract upgrade
Key changes
- Standardization of custom a/v GHO on Ethereum Core into the usual a/v Token model with required migration steps(high)
- Addition of multi-call support to the protocol(medium)
- Introduction of configurable Position Manager allowing users to optionally switch emode or collateral enable/disable on behalf of users(medium)
- Removal of unbacked logic from the protocol(medium)
- Conversion of various variables to immutables given their constant nature(low)
- Migration from error codes to Errors(low)
- Flash loan fee simplification(medium)
- GHO facilitator restructuring with pre-minting of ~177M GHO to new facilitator instead of on-demand minting(high)
Notable concerns
- stkAAVE holders will no longer receive discount on vGHO after upgrade, with pending discount being lost due to technical limitations, though mitigation will reduce impact to less than 1 day of discount accrual
- Significant GHO movements expected during upgrade (~177M minted, transferred, and burned) which depends on current system state at execution time
- Upgrade requires coordination across all Aave v3 networks
Generated by Kvorum
02Description
Simple Summary
Upgrade the Aave v3 Protocol across all networks from v3.3 to v3.4.
Motivation
The motivation behind this proposal is to upgrade the Aave instances to version 3.4, which includes several improvements most notably:
- The “standardisation” of the custom a/v GHO on Ethereum Core, into the usual a/v Token model for any other asset, including all migration steps required on the protocol layer, not to affect users.
- Multi-call support.
- Introduction of the configurable Position Manager for users, to optionally allow switching emode or collateral enable/disable on behalf of the user.
- Removal of the “unbacked” logic from the protocol.
- Changes of different variables to immutables, given their constant nature.
- Migration to Errors, instead of error codes.
- Flash loan fee simplification.
And extensive list of features and Changelog can be found HERE
Specification
The upgrade payload updates the implementations of the PoolConfigurator, Pool,PoolDataProvider, AToken & VariableDebtToken on all networks.
On Aave V3 Ethereum, the proposal performs some additional actions, to account for aligning vGHO from being a custom implementation to the standard implementation.
It is important to note that stakers of stkAAVE will no longer receive a discount on vGHO after the upgrade.
Due to technical limitations, the pending discount will be lost upon upgrade time. The stkAAVE discount only manifests whenever a user interacts with the vGHO (by either repaying or borrowing).
To reduce the impact of this loss, Dolce vita will iterate the users and call vGHO.rebalanceUserDiscountPercent(user) for every user that receives a discount within < 24h before proposal execution.
This will reduce the loss to less then 1 day of discount accrual.
By upgrading the implementation of vGHO & aGHO the existing aGHO facilitator will be removed and the new aGHO will follow the same pattern as the current prime GHO facilitator, namely the whole GHO capacity will be pre-minted to aGHO instead of minting on demand. Therefore it is expected that on the upgrade we will see:
- ~177M GHO being minted to the new facilitator
- ~177M GHO being transferred to
aGHO - ~177M GHO being burned from
aGHO - ~23M GHO being minted to the new facilitator
- ~23M GHO being deposited into
aGHO
The exact numbers, will depend on the current state of the system and the amount of vGHO that is currently in circulation at the time of execution.
For a more detailed breakdown of the steps performed during the upgrades please check here
Security procedures
- The upgrade was extensively unit tested and fuzzed.
- Certora adapted its formal properties to ensure the upgrade's correctness.
In addition 4 audits by Independent Auditors were conducted.
References
- Implementation: AaveV3EthereumCore, AllOtherInstances
- Tests: AaveV3EthereumCore, AllOtherInstances
- Upgrade diff: v3.3 - v3.4
- Onchain Diffs: Per network diffs
- Snapshot
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
All four decoded actions are bare execute() fallback calls to distinct payload contracts on chain 0x1 (Ethereum mainnet), which is the standard Aave governance pattern: a mainnet vote triggers execution of one or more 'upgrade payload' contracts that internally perform the detailed protocol changes (and, for BGD-style multi-network upgrades, can themselves trigger cross-chain execution via bridge adapters). Because the calldata contains no arguments and no visible internal logic, it is not possible to verify granular claims from the description — e.g., the exact GHO minting/burning amounts, the specific set of networks touched, or the precise mechanics of the vGHO/aGHO migration — directly from the decoded actions. However, the shape of the calldata (multiple payload executions) is fully consistent with the description's claim of an upgrade payload deploying changes across the protocol, including a dedicated Ethereum-specific leg for the GHO facilitator migration. I found no numeric value mismatches, target mismatches, or claims in the description that are contradicted by the calldata; the opacity of execute()-style calls is routine for this type of Aave governance proposal and does not itself constitute a discrepancy. Given the inability to verify fine-grained details (GHO amounts, per-network scope) purely from calldata, confidence is medium rather than high, but nothing in the visible calldata contradicts the prose, so the overall assessment is consistent with no flagged discrepancies. A duplicate action_index of 0 across two entries appears to be a data artifact rather than a substantive issue.
Generated by Kvorum
04Actions
- Target
- 0xc258…9876
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x132d…9549
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x0282…24ca
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x1faa…7e10
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 570x57ab…2922 | For | 296.7K | 0.00% | — | 1y ago |
| EZezr3al.eth0x8659…7d0e | For | 40.6K | 0.00% | — | 1y ago |
| B90xb933…8dd1 | For | 39.6K | 0.00% | — | 1y ago |
| EC0xecc2…6ac9 | For | 25K | 0.00% | — | 1y ago |
| 870x8787…ea52 | For | 24.8K | 0.00% | — | 1y ago |
| 3D0x3ddc…05b0 | For | 20.1K | 0.00% | — | 1y ago |
| 8B0x8b37…2a22 | For | 10.9K | 0.00% | — | 1y ago |
| 7A0x7ae1…e585 | For | 10K | 0.00% | — | 1y ago |
| 2C0x2cc1…4df1 | For | 5.2K | 0.00% | — | 1y ago |
| 080x0865…24ce | For | 2K | 0.00% | — | 1y ago |
| 620x6276…b4e8 | For | 1K | 0.00% | — | 1y ago |
| 470x4723…26ac | For | 980.9 | 0.00% | — | 1y ago |
| AD0xad21…f892 | For | 805.4 | 0.00% | — | 1y ago |
| 0E0x0e00…ccfc | For | 797.1 | 0.00% | — | 1y ago |
| 440x4444…34b3 | For | 744.1 | 0.00% | — | 1y ago |
| B30xb356…c826 | For | 480 | 0.00% | — | 1y ago |
| A50xa54f…0f31 | For | 459.8 | 0.00% | — | 1y ago |
| F10xf13c…6dd3 | For | 141.6 | 0.00% | — | 1y ago |
| 270x2748…ac26 | For | 16.1 | 0.00% | — | 1y ago |
| 640x649f…35b8 | For | 10.4 | 0.00% | — | 1y ago |
| B10xb1e8…c153 | For | 8.8 | 0.00% | — | 1y ago |
| BB0xbb86…3527 | For | 4.8 | 0.00% | — | 1y ago |
| 1B0x1bcd…2cab | For | 4.3 | 0.00% | — | 1y ago |
| 5D0x5de5…e69c | For | 3.1 | 0.00% | — | 1y ago |
| 2F0x2f2f…f78a | For | 2 | 0.00% | — | 1y ago |
| 050x0579…4048 | For | 1 | 0.00% | — | 1y ago |
| 2E0x2e00…67fa | For | 1 | 0.00% | — | 1y ago |
| 450x4578…86f4 | For | 0.6 | 0.00% | — | 1y ago |
| 010x019e…2ee3 | For | 0.3 | 0.00% | — | 1y ago |
| 6E0x6e54…aea3 | For | 0.3 | 0.00% | — | 1y ago |
| 010x0100…7cc9 | For | 0.2 | 0.00% | — | 1y ago |
| 640x649f…6dca | For | 0.1 | 0.00% | — | 1y ago |
| 040x0429…dab6 | For | 0.1 | 0.00% | — | 1y ago |
| 790x79fa…0275 | For | 0.1 | 0.00% | — | 1y ago |
| FF0xff07…1c41 | For | 0.1 | 0.00% | — | 1y ago |
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedUpgrade Aave instances to v3.591%
- aaveexecutedUpgrade Aave instances to v3.6 Part 188%
- aaveexecutedUpgrade Aave instances to v3.6 Part 287%
- aaveexecutedUpgrade all Aave instances to 3.287%
- aaveexecutedUpgrade Aave instances to v3.7 Part 286%
- aaveexecutedAave v3.1 upgrade86%
- aaveexecutedUpgrade Aave instances to v3.7 Part 186%
- aaveexecutedUpgrade Aave instances to v3.6 Part 385%
- aaveexecutedUpgrade Aave instances to v3.385%
- aaveexecutedUpgrade the safety module to v1.5 PART 182%