Ethereum v2 Reserve Factor Adjustment
01Summary
Proposal to increase Aave v2 Ethereum Reserve Factors (RF) across 33 assets to discourage deposits and encourage migration to Aave v3. Initial increases range from 5% to 9.99% depending on asset, with periodic 5% increases every 14 days planned up to 99.99% maximum, contingent on market conditions.
- Type
- parameter change
Key changes
- Increase Reserve Factor for ONE_INCH from 99.00% to 99.99%(medium)
- Increase Reserve Factor for AMPL from 99.90% to 99.99%(medium)
- Increase Reserve Factor for BUSD from 99.90% to 99.99%(medium)
- Increase Reserve Factor for BAL from 99.00% to 99.99%(medium)
- Increase Reserve Factor for BAT from 99.00% to 99.99%(medium)
- Increase Reserve Factor for CRV from 99.00% to 99.99%(medium)
- Increase Reserve Factor for CVX from 99.00% to 99.99%(medium)
- Increase Reserve Factor for DAI from 25.00% to 30.00%(high)
Notable concerns
- Reserve Factor increases reduce deposit rates, which may negatively impact v2 depositors seeking yield
- Market conditions must permit increases; proposal depends on ongoing risk monitoring between cycles
- Historical precedent only exists on Polygon v2; Ethereum v2 is significantly larger with $3 billion TVL still at risk
Generated by Kvorum
02Description
Simple Summary
This publication proposes periodically increasing the Aave v2 Ethereum Reserve Factor (RF) to encourage users to migrate to Aave v3.
Motivation
With Aave v3 now crossing the $8 Billion TVL threshold and $3 Billion remaining in Aave v2, this publication seeks to encourage users to migrate from v2 to v3 by increasing the RF.
With all other variables held constant, increasing the RF over time in isolation will result in a reduced deposit rate. Users are encourage to migrate to v3 in search of higher yield.
With market conditions permitting, we propose initiating a periodic 5.00% RF increase across all assets every 14 days as mentioned here up to a threshold of 99.99%. During each increase cycle we will monitor how users respond and, if any potential risks are identified, the next RF increase will be delayed until it is safe to implement.
Do note that increasing the RF parameter does not directly affect users' health factor, and this method has already been implemented on Polygon v2 for some time.
Specification
The below shows the current and proposed RF for each reserve.
| Asset | Current RF | Recommended RF |
|---|---|---|
| ONE_INCH | 99.00% | 99.99% |
| AMPL | 99.90% | 99.99% |
| BUSD | 99.90% | 99.99% |
| BAL | 99.00% | 99.99% |
| BAT | 99.00% | 99.99% |
| CRV | 99.00% | 99.99% |
| CVX | 99.00% | 99.99% |
| DAI | 25.00% | 30.00% |
| DPI | 99.00% | 99.99% |
| ENS | 99.00% | 99.99% |
| ENJ | 99.00% | 99.99% |
| FEI | 99.00% | 99.99% |
| FRAX | 30.00% | 35.00% |
| GUSD | 20.00% | 25.00% |
| KNC | 99.00% | 99.99% |
| LINK | 30.00% | 35.00% |
| LUSD | 25.00% | 30.00% |
| MANA | 99.00% | 99.99% |
| MKR | 99.00% | 99.99% |
| RAI | 99.00% | 99.99% |
| REN | 99.00% | 99.99% |
| SNX | 99.00% | 99.99% |
| sUSD | 30.00% | 35.00% |
| xSUSHI | 99.00% | 99.99% |
| TUSD | 99.00% | 99.99% |
| UNI | 99.00% | 99.99% |
| USDC | 25.00% | 30.00% |
| USDP | 20.00% | 25.00% |
| USDT | 25.00% | 30.00% |
| UST | 99.00% | 99.99% |
| WBTC | 30.00% | 35.00% |
| WETH | 25.00% | 30.00% |
| YFI | 99.00% | 99.99% |
| ZRX | 99.00% | 99.99% |
Upon implementing this proposal, a subsequent AIP will be submitted every 2 weeks that increases the RF by 5.00% up to a maximum of 99.99%, subject to market conditions.
References
- Implementation: AaveV2Ethereum
- Tests: AaveV2Ethereum
- Snapshot
- Discussion
Disclosure
TokenLogic, karpatkey and Chaos Labs receive no payment for this proposal. TokenLogic and karpatkey are both delegates within the Aave community.
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal's on-chain footprint is a single generic execute() call to a payload contract, which is the standard pattern used by Aave governance proposals: the executor delegatecalls into a purpose-built payload contract whose internal logic (not exposed in this top-level decoded calldata) performs the actual per-asset setReserveFactor updates described in the specification table. Because the decoded action has no arguments or internal calls visible, it is not possible to directly verify that the specific reserve factor values (e.g., DAI 25%→30%, ONE_INCH 99%→99.99%, etc.) match what the payload contract actually sets. However, this opacity is expected and routine for this proposal type — the description also links directly to the implementation source code for the payload contract, which is consistent with the described intent. There is no evidence of a target mismatch, extra hidden action, or value manipulation in what is visible; the single action's target and lack of value transfer are consistent with a parameter-adjustment payload rather than a fund transfer or access-control change. Given the inherent inability to verify the granular values from the decoded calldata alone, confidence is marked low, and the assessment defaults to consistent absent any visible red flags such as multiple unexplained actions, fund transfers, or mismatched targets in the decoded data itself.
Generated by Kvorum
04Actions
- Target
- 0xc7c0…c581
- 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
- aaveexecutedEthereum v2 Reserve Factor Adjustment92%
- aaveexecutedEthereum v2 - Parameters Update89%
- aaveexecutedReserve Factor Updates89%
- aaveexecutedReserve Factor Updates89%
- aaveexecutedReserve Factor Upgrades89%
- aaveexecutedReserve Factor Upgrades89%
- aaveexecutedReserve Factor Updates - Polygon Aave v287%
- aavecanceledReserve Factor Updates - Polygon Aave v287%
- aaveexecutedReserve Factor Updates - Polygon Aave v287%
- aaveexecutedReserve Factor Updates (Jan 15, 2024)87%