Reserve Factor Updates - Polygon Aave v2
01Summary
This proposal updates Reserve Factors (RF) on Aave Polygon v2 to incentivize user migration to v3. It increases RFs for major stablecoins (DAI to 26%, USDC to 28%, USDT to 27%) and other assets, with frozen assets receiving RFs up to 99.99% to generate near-zero deposit yields. This reduces supply-side returns on v2 without affecting borrowing rates or liquidation risk.
- Type
- parameter change
Key changes
- DAI Reserve Factor increased to 26%(medium)
- USDC Reserve Factor increased to 28%(medium)
- USDT Reserve Factor increased to 27%(medium)
- wBTC Reserve Factor increased to 60%(medium)
- wETH Reserve Factor increased to 50%(medium)
- MATIC Reserve Factor increased to 46%(medium)
- BAL Reserve Factor increased to 37%(low)
- CRV, GHST, LINK Reserve Factors increased to 99.99%(high)
Notable concerns
- Frozen assets (CRV, GHST, LINK) with 99.99% RF will provide near-zero deposit yields, affecting approximately $680k in user positions (less than 0.5% of Aave v2 TVL)
- Proposal will assess user elasticity and impact before implementing additional RF increases
Generated by Kvorum
02Description
Simple Summary
This AIP will update Reserve Factors (RF) on Polygon v2 to encourage users to migrate funds to v3.
Motivation
With the goal of transitioning users from Polygon v2 to v3, this publication, if implemented, will increase the RF of asset on the v2 deployment.
Increasing the RF routes a larger portion of the interest paid by users to Aave DAO’s Treasury. User’s funds are not at risk of liquidation and the borrowing rate remains unchanged.
By progressively increasing the reserve factors, the interest rate for supplying these assets on v2 will be increasingly less attractive, thus encouraging suppliers to transition positions to v3.
Of the assets that are currently frozen, with the exception of BAL, the RF is to be increaed to 99.99%. Around $680k of users positions, CRV, DPI, GHST and LINK will receive near zero deposit yield. This represents less than 0.5% of Aave v2’s TVL. The highest deposit yield of these assets at the time of writing is 0.21%. This change will have minimal affect.
The remaining assets are to receive an incremental 5% increase in the RF. After implementing this publication, user elasticity shall be assessed and the impact of the updates before moving forward with additional increases.
Specification
The following parameters are to be updated as follows:
| Asset | Reserve Factor |
|---|---|
| DAI | 26.00% |
| USDC | 28.00% |
| USDT | 27.00% |
| wBTC | 60.00% |
| wETH | 50.00% |
| MATIC | 46.00% |
| BAL | 37.00% |
| CRV | 99.99% |
| GHST | 99.99% |
| LINK | 99.99% |
Implementation
A list of relevant links like for this proposal:
The proposal Payload was reviewed by Bored Ghost Developing.
Disclaimer
The author, TokenLogic, receives payment indirectly from Aave Grant DAO via Butter as part of the Incentivised Delegate Campaign. TokenLogic is a delegate within Aave community.
Delegate: 0x2cc1ADE245020FC5AAE66Ad443e1F66e01c54Df1
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded calldata contains a single top-level action: a call to execute(address) targeting 0x812dDad273544754d0672A009C27550899e658Aa. This address matches exactly the 'Deployed Contracts' link provided in the proposal's Implementation section, confirming the on-chain action invokes the correct payload contract that the proposal authors identified as containing the Reserve Factor update logic. This is standard Aave governance pattern: the mainnet vote triggers execute() on a payload contract, which internally performs the granular parameter changes (in this case, on Polygon v2 reserves) — those internal calls are not separately decoded here, which is typical and expected boilerplate for this type of proposal, not a discrepancy. Because the internal RF-setting calls inside the payload are not present in the decoded data, I cannot verify the exact numeric RF values (26%, 28%, 99.99%, etc.) against calldata directly — this limits confidence to medium rather than high. However, given the target address matches the disclosed and reviewed payload contract, and no additional or conflicting actions appear in the calldata, there is no evidence of target mismatch, hidden transfers, or value discrepancies. I therefore find the description and calldata consistent, with the caveat that full verification of exact RF percentages would require decoding the internal logic of the payload contract itself, which is outside the scope of the provided decoded action list.
Generated by Kvorum
04Actions
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x812dDad273544754d0672A009C27550899e658Aa" }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedReserve Factor Updates - Polygon Aave v295%
- aavecanceledReserve Factor Updates - Polygon Aave v295%
- aaveexecutedReserve Factor Updates - Polygon Aave v295%
- aaveexecutedReserve Factor Updates - Polygon Aave v292%
- aavecanceledReserve Factor Updates - Polygon Aave v292%
- aaveexecutedReserve Factor Updates - Polygon Aave v292%
- aaveexecutedReserve Factor Update October 202392%
- aaveexecutedPolygon V2 Reserve Factor Updates91%
- aaveexecutedReserve Factor Updates (Jan 15, 2024)91%
- aaveexecutedReserve Factor Updates (March 13, 2024)90%