Polygon v2 - Parameter Update
01Summary
This AIP updates risk parameters (Uoptimal, Reserve Factor, and Slope2) on Aave's Polygon v2 protocol across 10 assets to increase borrowing costs while maintaining deposit rates, encouraging users to migrate to the safer Polygon v3 protocol where liquidity mining incentives and better deposit rates are available.
- Type
- parameter change
Key changes
- Update Uoptimal parameter for DAI (71%), USDC (77%), USDT (52%), wBTC (37%), wETH (40%), MATIC (48%), BAL (65%), CRV (25%), GHST (23%), LINK (25%)(medium)
- Update Reserve Factor parameter for DAI (21%), USDC (23%), USDT (22%), wBTC (55%), wETH (45%), MATIC (41%), BAL (32%), CRV (38%), GHST (60%), LINK (50%)(medium)
- Update Slope2 parameter across all 10 assets, ranging from 105% (DAI) to 536% (wBTC)(high)
- Increase borrowing rates on Polygon v2 while maintaining deposit rates unchanged to encourage migration to v3(high)
Generated by Kvorum
02Description
Simple Summary
This AIP will update risk parameters on Polygon v2 to encourage users to migrate funds to v3. No users funds are at risk.
Abstract
With SD, MaticX and stMATIC rewards being distributed across v3, Aave DAO can further encourage the migration of users to the safer v3 protocol.
This will be achieved by updating the Uoptimal, Reserve Factor (RF) and Slope2 parameters. This is expected to increase borrowing rates, with deposit rates remaining unchanged.
Motivation
Currently, there are two communities distributing three tokens across Polygon v3.
- SD - Stader Labs
- MaticX & stMATIC - Polygon Foundation
This has led to Polygon v3 offering better deposit rates relative to v2. The TVL on v3 is increasing, largely due to incentives and LSTs being added to the liquidity pool whilst v2's TVL remains more correlated to asset spot pricing.
Liquidity Mining on v3 is encouraging users to migrate and this AIP will further encourage migration by holding v2 deposit rates constant and increasing v2 borrowing costs.
The approach presented has successfully passed TEMP CHECK and ARFC votes, with the community electing to migrate via Option 2, the conservative approach.
This AIP contains revised parameter updates in line with the ARFC Snapshot methodology. The methodogoly applied has been reviewed by Chaos Labs and Gauntlet at the time the ARFC was voted on.
Specification
The following parameters are to be updated:
| Asset | Uoptimal | RF | Slope 2 |
|---|---|---|---|
| DAI | 71.00% | 21.00% | 105.00% |
| USDC | 77.00% | 23.00% | 134.00% |
| USDT | 52.00% | 22.00% | 236.00% |
| wBTC | 37.00% | 55.00% | 536.00% |
| wETH | 40.00% | 45.00% | 167.00% |
| MATIC | 48.00% | 41.00% | 440.00% |
| BAL | 65.00% | 32.00% | 236.00% |
| CRV | 25.00% | 38.00% | 392.00% |
| GHST | 23.00% | 60.00% | 413.00% |
| LINK | 25.00% | 50.00% | 402.00% |
Implementation
A list of relevant links like for this proposal:
- Governance Forum Discussion
- Test Cases
- Pre-Post Payload Diff
- Payload Implementation
- Deployed Contracts
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: 0xA06c2e5BB33cd6718b08EC9335081Cbba62861f7
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded calldata contains a single action: a call to execute(address) targeting the standard Aave governance executor, passing the payload contract address 0xBBD2B7418395d1782f0016095C6A26487d184873. This address matches exactly the 'Deployed Contracts' link provided in the proposal's Implementation section, which is strong evidence that the on-chain action correctly invokes the payload described in the proposal. However, because Aave AIPs of this type execute all specific logic (the Uoptimal/RF/Slope2 parameter updates for each of the 10 listed reserves) inside the payload contract itself via an internal execute() function, the decoded action list here does not expose those individual parameter-setting calls for direct verification against the description's table of values. This is standard and expected for this proposal type — the top-level governance action is simply 'run this payload,' and further verification would require decoding the payload contract's bytecode/logic, which is outside the scope of the provided calldata. Given the target address match and the fact that this is the expected boilerplate execution pattern for Aave governance, I found no value mismatches, target mismatches, or omitted/extra actions I could identify from the available data. Confidence is medium rather than high because the specific numeric parameter changes claimed in the description could not be independently verified against decoded low-level calldata (only the top-level proxy call is visible).
Generated by Kvorum
04Actions
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0xBBD2B7418395d1782f0016095C6A26487d184873" }- 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 v287%
- aaveexecutedPolygon V2 Reserve Factor Updates & Interest Rate Increases87%
- aaveexecutedReserve Factor Updates - Polygon Aave v284%
- aaveexecutedReserve Factor Updates - Polygon Aave v284%
- aavecanceledReserve Factor Updates - Polygon Aave v284%
- aaveexecutedPolygon V2 Reserve Factor Updates83%
- aaveexecutedPolygon V2 Reserve Factor Updates83%
- aavecanceledReserve Factor Updates - Polygon Aave v282%
- aaveexecutedReserve Factor Updates - Polygon Aave v282%
- aaveexecutedReserve Factor Updates - Polygon Aave v282%