KVORUM
aaveSource: Aave governance v3 · #473

Upgrade Aave instances to v3.7 Part 1

executedApr 19, 2026, 10:38 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Upgrade Aave protocol from v3.6 to v3.7 across multiple networks by simplifying eModes configuration, removing isolated collaterals and L2 sequencer oracle features, and making the reserves list append-only. The upgrade includes cleanup of reserve configuration flags before contract implementation updates. Additionally, reimburse audit costs with 62,422 USDT to BGD Labs and 12,240 GHO to Certora on mainnet.

Type
contract upgrade
Funding
$74662

Key changes

  • Simplification of eModes configuration by adding an isolated flag(medium)
  • Removal of isolated collaterals and borrowable in isolation features(medium)
  • Removal of L2 sequencer oracle(medium)
  • Making reserves list append-only by removing the flow to drop reserves(medium)
  • Small improvements on liquidation calculations(low)
  • Reset debtCeiling to zero for all reserves with non-zero debt ceiling(medium)
  • Disable borrowableInIsolation flag for reserves that have it enabled(medium)
  • Unsetting sequencer uptime price oracle sentinel(medium)

Notable concerns

  • Upgrade affects multiple networks and requires coordination across Sonic, Optimism, Gnosis, Scroll, Celo, MegaEth, XLayer and Ethereum (EtherFi)
  • Protocol changes are non-invasive but represent significant simplification that removes features
ContractsPoolPoolConfiguratorPOOL_ADDRESSES_PROVIDER
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

289 words

Simple Summary

Upgrade the Aave protocol instances from v3.6 to v3.7

Motivation

Aave v3.7 focused on non-invasive simplification of the protocol. It includes the following changes and features:

  • Simplification of eModes’ configuration, adding an isolated flag.
  • Removal of isolated collaterals and borrowable in isolation, features not useful anymore.
  • Removal of the L2 sequencer oracle.
  • Explicit removal of the flow to drop reserves, making the reserves list append-only.
  • Small improvements on liquidation calculations.

Specification

Before upgrading the implementations, the payload cleans up reserve configuration flags and settings that are removed in v3.7. For each reserve:

  • Reset debtCeiling: If a reserve has a non-zero debt ceiling, it is set to zero via setDebtCeiling(reserve, 0). This also resets isolationModeTotalDebt to zero.
  • Disable borrowableInIsolation: If a reserve has borrowableInIsolation enabled, it is set to false via setBorrowableInIsolation(reserve, false).
  • Additionally, if a sequencer uptime price oracle sentinel is configured, it is unset via setPriceOracleSentinel(address(0)), as this feature is removed in v3.7.

After the cleanup, the payload upgrades the core protocol contracts:

  • Upgrade Pool implementation: The Pool contract proxy is updated to point to the new v3.7 implementation via POOL_ADDRESSES_PROVIDER.setPoolImpl(POOL_IMPL).
  • Upgrade PoolConfigurator implementation: The `PoolConfigurator contract proxy is updated to the new v3.7 implementation via POOL_ADDRESSES_PROVIDER.setPoolConfiguratorImpl(POOL_CONFIGURATOR_IMPL).

Part 1 is applied on the following networks: Sonic, Optimism, Gnosis, Scroll, Celo, MegaEth, XLayer and Ethereum (EtherFi). Part 2 will follow shortly.

An additional action is included on mainnet which:

  • transfers 62'422 $ as aUSDT to BGD Labs
  • transfers 12'240 $ as GHO to Certora

to reimburse the cost of the audits.

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal description details a multi-step v3.7 upgrade (reserve cleanup: debt ceiling reset, borrowableInIsolation disable, sequencer oracle removal, Pool/PoolConfigurator implementation upgrades) plus a mainnet-only token reimbursement to BGD Labs and Certora. However, the decoded on-chain actions only show two generic 'execute()' fallback calls to two contract addresses on Ethereum mainnet, with no decoded internal arguments or sub-calls. This is a common pattern for Aave governance payloads, where the proposal executor delegatecalls into a payload contract whose internal logic (matching the description) is not exposed in the top-level calldata decoding. Because the decoded actions provide no visibility into the specific parameters, targets, or amounts described in the prose, there is no basis to identify a concrete mismatch — but there is also no way to positively confirm the calldata matches every specific claim (e.g., token amounts, target reserve addresses, implementation addresses). Given the opacity of the decoded data, confidence in this comparison is low, and no discrepancy is flagged since none can be substantiated. This should not be read as an endorsement of full calldata-description parity, only that no contradiction is detectable from the available data.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

2 total
#0fallback()chain 0x1
Target
0x924b…cc50
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0x5132…9792
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.