V2 Stable Debt Offboarding
01Summary
Introduce a permissionless swapToVariable(address asset, address user) method to allow users to migrate from stable to variable debt on Aave V2 Ethereum. This completes the deprecation of stable rate borrowing following a critical bug discovered in November 2023 that affected stable borrow rate mechanisms.
- Type
- protocol addition
Key changes
- Add new permissionless `swapToVariable(address asset, address user)` method enabling migration from stable to variable debt(high)
- Update pool implementation by calling `AaveV2Ethereum.POOL_ADDRESSES_PROVIDER.setLendingPoolImpl(LENDING_POOL_IMPL)`(high)
- Complete deprecation of stable rate by allowing users to migrate existing stable debt positions to variable rate(high)
Notable concerns
- Stable debt positions currently exist without rebalancing capability, creating technical overhead for security reviews
- The change addresses an asymmetric situation where stable rate has been halted for new borrowings but existing positions remain locked at stable rate
- A critical bug in stable borrow rate mechanisms was discovered on November 4, 2023 via Immunefi bug bounty program
Generated by Kvorum
02Description
Simple Summary
Introduce a new method swapToVariable(address asset, address user) that allows permissionless swapping from stable to variable debt.
Motivation
On the 4th of November 2023 10, a report was received via the Aave <> Immunefi bug bounty program about a critical bug related to the stable borrow rate.
Only certain assets were affected due to their configuration, but given the nature of the bug, together with the progressive deprecation of stable rate that started before (not enabled in Aave v3 Ethereum, the main instance of Aave at the moment, or any other afterwards), the fix involved a full deprecation of minting mechanisms of stable debt: halting new borrowings in that mode and also halting rebalancing and swapping from variable to stable.
Even if with the halting of minting of stable rate we are fully confident that there is no further vector, the current situation is extremely asymmetric, and creating really important technical overhead, for example when doing security evaluations/reviews of the protocol: there are user positions at stable, which factually have fixed rate until they decide to close it, without any kind of rebalancing applicable.
Therefore, after evaluating the scenario for some time, we think the better solution is to progress on the deprecation of stable rate, by migrating all user positions from stable to variable.
Specification
On execution this proposal will call:
AaveV2Ethereum.POOL_ADDRESSES_PROVIDER.setLendingPoolImpl(LENDING_POOL_IMPL)to update the pool implementation
References
- Implementation: AaveV2Ethereum
- Tests: AaveV2Ethereum
- Snapshot
- Discussion
- Diff
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal follows Aave's standard governance execution pattern: a single top-level action that calls execute() on a payload contract via delegatecall. This payload contract (per the linked implementation source) is expected to internally call setLendingPoolImpl on the PoolAddressesProvider, deploying a new LendingPool implementation containing the swapToVariable function described in the prose. However, the decoded calldata for this action is opaque — it shows only a generic execute() fallback call with no arguments, since the actual logic lives inside the target contract's bytecode rather than being passed as calldata. This means the specific claims in the description (the new function signature, the setLendingPoolImpl call) cannot be independently verified from the decoded action alone; they can only be confirmed by reviewing the linked source code, which is outside the scope of the calldata analysis. Because the single decoded action is fully consistent with the expected structure for this type of Aave proposal (delegatecall to a payload contract) and there is no sign of a redirected target, unexpected value transfer, or extra/missing top-level action, I do not flag a discrepancy. However, confidence is marked low because the calldata itself does not expose enough detail to fully corroborate the specific functional claims made in the description.
Generated by Kvorum
04Actions
- Target
- 0x64c6…fc17
- 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
- aaveexecutedAave V1 Deprecation79%
- aaveexecutedMultichain Stable Debt Token Upgrades78%
- aaveexecutedAave V1 Deprecation Phase 377%
- aaveexecutedAave V1 Deprecation Phase 277%
- aaveexecutedAave V2 deprecation76%
- aaveexecutedUpgrade all Aave instances to 3.276%
- aaveexecuted3.2 patch for legacy periphery72%
- aaveexecutedAave v3.1 upgrade71%
- aaveexecutedAave Pool update70%
- aaveexecutedUpgrade Aave instances to v3.370%