KVORUM
aaveSource: Aave governance v3 · #334

Upgrade Aave instances to v3.4

executedJul 2, 2025, 02:12 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

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
ContractsPoolConfiguratorPoolPoolDataProviderATokenVariableDebtTokenvGHOaGHO
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

486 words

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

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

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
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
0xc258…9876
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#0fallback()chain 0x1
Target
0x132d…9549
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0x0282…24ca
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#2fallback()chain 0x1
Target
0x1faa…7e10
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total
Filter:
VoterChoice% of totalRationale
570x57ab…2922For296.7K0.00%—1y ago
EZezr3al.eth0x8659…7d0eFor40.6K0.00%—1y ago
B90xb933…8dd1For39.6K0.00%—1y ago
EC0xecc2…6ac9For25K0.00%—1y ago
870x8787…ea52For24.8K0.00%—1y ago
3D0x3ddc…05b0For20.1K0.00%—1y ago
8B0x8b37…2a22For10.9K0.00%—1y ago
7A0x7ae1…e585For10K0.00%—1y ago
2C0x2cc1…4df1For5.2K0.00%—1y ago
080x0865…24ceFor2K0.00%—1y ago
620x6276…b4e8For1K0.00%—1y ago
470x4723…26acFor980.90.00%—1y ago
AD0xad21…f892For805.40.00%—1y ago
0E0x0e00…ccfcFor797.10.00%—1y ago
440x4444…34b3For744.10.00%—1y ago
B30xb356…c826For4800.00%—1y ago
A50xa54f…0f31For459.80.00%—1y ago
F10xf13c…6dd3For141.60.00%—1y ago
270x2748…ac26For16.10.00%—1y ago
640x649f…35b8For10.40.00%—1y ago
B10xb1e8…c153For8.80.00%—1y ago
BB0xbb86…3527For4.80.00%—1y ago
1B0x1bcd…2cabFor4.30.00%—1y ago
5D0x5de5…e69cFor3.10.00%—1y ago
2F0x2f2f…f78aFor20.00%—1y ago
050x0579…4048For10.00%—1y ago
2E0x2e00…67faFor10.00%—1y ago
450x4578…86f4For0.60.00%—1y ago
010x019e…2ee3For0.30.00%—1y ago
6E0x6e54…aea3For0.30.00%—1y ago
010x0100…7cc9For0.20.00%—1y ago
640x649f…6dcaFor0.10.00%—1y ago
040x0429…dab6For0.10.00%—1y ago
790x79fa…0275For0.10.00%—1y ago
FF0xff07…1c41For0.10.00%—1y ago
Showing 35

07Forum

No forum thread is confidently linked to this proposal.