Summary
Given the recent market events and deployment of Aave V3 Ethereum, we would like to help re-start the community conversation around migrating users from V2 → V3 Ethereum.
Here, Gauntlet presents some levers the community can utilize to migrate users from Aave V2 to V3. Since V3 markets have overwhelmingly overlapping use cases with V2, we prioritize a quick and decisive migration over the span of ~8 weeks. We plan to make V3 temporarily more attractive during this migration period, and although some of the levers would inevitably make V2 less attractive, the protocol can offer a better user experience in V3 to compensate.
Below we present levers we recommend and would like to gather feedback from the community. We also present a short list of levers that could substitute or complement the ones we recommend. The final plan could be anything in between or with additional levers. We are painting high-level plans with sample step-by-step actions and will follow up on a deeper plan and analysis once the community expresses its intent. We value input from the community and are open to hearing ideas outside of our proposed paths.
Levers for Consideration
- stkAave distribution to V3 (strategic decision by the community)
- Give stkAave incentives for Ethereum, Avalanche, Arbitrum, and Polygon V3 markets.
- Pro: Migrating stkAAVE incentives would directly encourage users to migrate from V2 to V3 and could partially offset the gas fee incurred during the migration.
- Con: This will lead to token dilution.
- Decrease LTV and liquidation threshold on overlapping assets in V2
- We can implement small reduction in LTVs and LTs for assets both listed on V2 and V3 on a biweekly basis so that every two weeks, we can encourage certain assets users to migrate from V2 to V3. The community can select the assets depending on how the migration proceeds.
- Pro: Directly encourage existing users on V2 to switch over to V3.
- Con: If done without careful calibration, might increase risk in the system or even force liquidate accounts. We can mitigate this by monitoring user health factors after applying the change.
- Disable borrowing of overlapping assets in V2
- Pro: Directly deprecate the use case in V2 so new users would choose V3 over V2.
- Con: If we do not make the UI clear about how V3 can achieve the same functions new users want to use in V2, they may choose to use other platforms instead. However, this can be mitigated by a minor change in the UI.
- Increase reserve factors on V2 for all overlapping markets (not encouraged)
- Increasing reserve factor would decrease supply interest on V2 and drive token suppliers to V3
- Pro: Directly impact supplier interest rate on V2 and drive suppliers towards V3. Has a second-order effect in that when suppliers pull liquidity and move to V3, Utilization will go up and thus borrow rate in V2 would go up, which should cause borrowers to pay back their loans
- Con: May hurt user experience for V2 because of the decreased interest rate payout, but this impact should be minimal if we are applying the change gradually with guidance for V3 user group’s migration.
- Increase V3 supply cap and borrow cap (not encouraged)
- Accommodate more usage of Aave V3 preemptively in order to smooth the migration efforts.
- Pro: Increase supply / borrow cap is a necessity if use cases rise in V3.
- Con: Increase supply / borrow cap may increase protocol risk in terms of price manipulation and extreme events.
Migration Plan Example
Note that the numbers here are for illustration, and the final implementation would depend on deeper quantitative analysis.
Week 1 - 2 | Week 3 - 4 | Week 5 - 6 | Week 7 - 8 | ||
---|---|---|---|---|---|
Levers | |||||
stkAave distribution migration (V3) | 550/day | 500/day | 400/day | 200/day | |
RF increase for overlapping assets (not encouraged) | +5% | +5% | +5% | +5% | |
Disable borrowing assets on V2 | Disable overlapping markets | Disable overlapping markets | Disable overlapping markets | Disable overlapping markets | |
Supply / borrow caps (not encouraged) | 2x supply / borrow cap when hit 0.8x pending liquidity conditions deem it relatively safe to do so | 1.3x supply / borrow cap when hit 0.8x pending liquidity conditions deem it relatively safe to do so | 1.3x supply / borrow cap when hit 0.8x pending liquidity conditions deem it relatively safe to do so | 1.3x supply / borrow cap when hit 0.8x pending liquidity conditions deem it relatively safe to do so | |
LTV, LT decrease | maintain 4% reduction for overlapping assets | maintain 3% reduction for overlapping assets | maintain 2.5% reduction for overlapping assets | maintain 1.5% reduction for overlapping assets |
New Feature Use for Aave V3 Ethereum
Emode
As stated in Gauntlet’s recent methodology and in previous forum posts, our analysis shows that stablecoin emode on Aave V3 Ethereum should only contain USDC and DAI at a 97.5% LT, 97% LTV, and 1% LB.
We will discuss the risk mitigation steps for Aave V3 Avalanche in a separate post.
Isolation Mode
Here is Gauntlet’s current methodology for isolation mode. Our analysis shows that isolation mode alone is not the most effective lever for migrating risk on the protocol. We will analyze these main benefits: 1.) can be the only collateral in an account, 2.) can only borrow stablecoins, and 3.) will have a debt ceiling. Consider the scenario where an account holds 2 assets, one that is considered riskier and one that is considered safer. For the sake of illustration, assume that an account is supplying USDC and WETH and borrowing DAI. If the price of WETH falls, liquidators will tend to prefer to liquidate USDC to WETH. This partially helps to prevent liquidation cascades. In addition, if the price of WETH falls too quickly for healthy liquidations to occur, the USDC collateral provides a buffer for insolvency risk. For 2), many risky positions that are at high risk of liquidation cascades will borrow stablecoins. 3) is a valid benefit to the protocol, but it comes at the cost of user experience through restrictions 1) and 2).
GHO Considerations
One concern that we see with the new GHO implementation and its currently proposed parameters is liquidations in emode and the collateralization of GHO with stablecoins.
We highly advise against allowing users to mint GHO against stablecoins in emode. This has already been highlighted, but with the emode parameters available, high leverage can be achieved through borrowing GHO against stablecoins. We will provide more insight into the exact liquidity changes and market conditions that manifested this past weekend, but the liquidity conditions for GHO will initially be substantially lower than other stablecoins.
Asset Listing Schedule
Please note that for the updated supply and borrow caps below, we provide values for all the assets below. However, we are only considering the listing of SNX, MKR, YFI, and UNI in the near future before the adoption of GHO. We will wait until then to move forward with the listing of smaller assets.
Updated borrow and supply cap values for all V2 assets on Ethereum
Next Steps
- Welcome community feedback
- Targeting Snapshot vote on 3/27/2023