3.2 patch for legacy periphery
01Summary
Upgrade the Aave Pool contract across all networks to improve backward compatibility with legacy integrations. The upgrade adds a fallback mechanism to getReserveData() that returns a MOCK_STABLE_DEBT address, allowing integrators using immutable old ProtocolDataProvider contracts to continue functioning after the v3.2 stable rate removal without needing to update their infrastructure.
- Type
- contract upgrade
Key changes
- Pool contract upgrade across all networks to add fallback on getReserveData() view function(high)
- Configuration of MOCK_STABLE_DEBT variable on PoolAddressesProvider(medium)
- getReserveData() now returns MOCK_STABLE_DEBT address for stableDebtTokenAddress to ensure compatibility with legacy ProtocolDataProvider peripheral contracts(high)
Notable concerns
- Proposal affects immutable integrator infrastructure that cannot be updated directly
- Addresses non-critical compatibility issue arising from v3.2 stable rate borrow mode removal
Generated by Kvorum
02Description
Simple Summary
Upgrade the Pool contract across all networks, to add an extra fallback on the getReserveData() view function, allowing for integrators unable to update peripheral contracts (Aave Pool Data Provider) to still be compatible with v3.2.
Motivation
Aave v3.2 included the removal of all the logic of stable rate borrow mode, and the release of a new ProtocolDataProvider maintaining retro-compatibility.
However, post-release we have been contacted by integrators with totally immutable infrastructure depending on so-called “hardcoding” of legacy peripheral contracts, in this case, an old version of the ProtocolDataProvider, designed to be replaced on the core contract of Aave (PoolAddressesProvider) whenever an upgrade happens.
Even if non-critical, this has created issues for those integrators, and from the Aave side, it is possible to increase even more the retro-compatibility by doing a simple upgrade on the Pool smart contract.
Specification
The governance proposal will configure a MOCK_STABLE_DEBT variable on the PoolAddressesProvider, together with upgrading the Aave Pool contract across all networks.
On this pool upgrade, the only modification would be to now return the previously configured MOCK_STABLE_DEBT address for stableDebtTokenAddress on Pool.getReserveData(), this way removing any type of unexpected behavior from integrators using legacy ProtocolDataProvider peripheral contracts, consuming getReserveData().
Security considerations
The proposal was tested via unit tests and Certora checked the upgrade and proposal.
References
- Proposal Implementation
- Protocol Upgrade Implementation
- Pool implementation diff
- Tests
- Discussion
- Upgrade repository
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal describes a technical upgrade: setting a MOCK_STABLE_DEBT address on the PoolAddressesProvider and upgrading the Pool implementation across all networks so getReserveData() returns this mock address for stableDebtTokenAddress. The decoded calldata, however, only shows three generic execute() fallback calls to three distinct payload contract addresses, all on chain 0x1 (Ethereum mainnet). No decoded arguments, storage writes, or sub-calls are exposed — this is consistent with Aave's common governance pattern where a mainnet executor delegatecalls into a 'payload' contract that itself contains the detailed upgrade logic (and potentially triggers cross-chain messaging to other networks), but it means the specific technical claims (MOCK_STABLE_DEBT configuration, Pool implementation upgrade, per-network scope) cannot be independently verified from the calldata alone. Nothing in the decoded actions contradicts the description — the three separate payload targets are plausibly the three components referenced in the linked implementation repo (PoolAddressesProvider config, Pool implementation, and payload orchestration) — but the opacity of the calldata prevents a confident line-by-line verification. Given the lack of contradicting evidence but also lack of granular confirmation, I assess this as consistent with low confidence rather than flagging discrepancies that would require speculation about the payload's internal logic.
Generated by Kvorum
04Actions
- Target
- 0x55c0…c776
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xf4ab…0ac3
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x5649…5ab2
- 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
- aaveexecutedUpgrade Aave instances to v3.382%
- aaveexecutedUpgrade all Aave instances to 3.282%
- aaveexecutedAave Pool update82%
- aaveexecutedAave v3.1 upgrade80%
- aaveexecutedUpgrade Aave instances to v3.6 Part 179%
- aaveexecutedUpgrade Aave instances to v3.7 Part 278%
- aaveexecutedUpgrade Aave instances to v3.6 Part 278%
- aaveexecutedUpgrade Aave instances to v3.7 Part 178%
- aaveexecutedUpgrade Aave instances to v3.577%
- aavecanceledUpgrade Aave V3 pools to Aave V3.0.277%