[ARC] Aave Community Plan for V2 -> V3 Migration

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
7 Likes

This proposal is the most important, beyond current risk mitigation efforts due to market conditions.

Migrating users from V2 → V3 continues to be a worthwhile pursuit and should be a point of focus for the community. It seems like many of these values are a placeholder for now.

In the interim, we would advocate for more aggressive cap and LTV / LT reductions.

While parameter adjustments are a great incentivization tool, it is also important to inform and educate users who may not feel these effects directly, nor read the forum.

Would it be worth some sort of announcement in the UI @AaveLabs ?

4 Likes

As i understand the linked thread, most(all) insolvencies were caused by eMode on v3.
v2 worked as expected with 0 insolvencies. If that’s true, how does this work as an argument to speed up v2-v3 migration?

To me personally this feels a bit rushed. As of today more than half of v2 assets are completely missing on v3. The one more volatile asset listed (CRV) is isolated, but there’s nothing configured to borrow against - as one can see by liquidity movements(which are inexistent for CRV), noone is interested to use v3 in that case. By forcing migration i would expect to liquidity to move to other venues in case they exist.

How much sense does an eMode with these two assets actually make? What’s the usecase for ppl potentially entering? What’s the downside risk for aave? Is it worth the tradeoff?

3 Likes

Thanks for this feedback. Timing of migration is certainly something we value community feedback on because it is also a strategic preference by the community. As for the assets missing - we will follow up with more detailed analysis on user positions and their asset composition.

In general, a migration from V2 to V3 decreases risk broadly in the Aave ecosystem because V3 has more risk controls (supply cap, borrow cap, etc.). In addition, V3 has more granular Guardian controls, so in times of extreme unforeseen events, action can possibly be taken faster and more granularly on V3 to protect user funds.

These are great questions. It is important for the community to align on what the intended use case for eMode is - it may not be worth the trade-off strategically. If we operate under the assumption that the community still wants stablecoin e-Mode, we recommend a shorter list of assets.

We look forward to hearing more thoughts from the community and collaborating with contributors including @ChaosLabs @Llamaxyz @MarcZeller (ACI).

1 Like

The following is posted on behalf of Index Coop and our customers who utilize our icETH product built on top of Aave v2.

Several of these proposed changes could have significant negative implications for customers who utilize our Ethereum staking product with leverage. Unfortunately, it is not technically viable for us to migrate these users directly to V3 without their on-chain consent.

It is crucial to view Aave depositors not only as individual users or customers but also as other protocols that rely on Aave as a fundamental infrastructure component. These protocols often exhibit greater dependence on the V2 protocol and immediate migration is not as simple as it sounds. As an index provider, our focus is on creating products for long-term, passive investors. Although we can and will provide upgrade paths and alternatives, we cannot mandate migration.

Furthermore, V3 is a relatively new protocol and has not been as extensively battle-tested as V2. In the interest of user safety, we recommend refraining from actions that accelerate adoption, allowing capital to migrate organically as confidence increases. Ultimately, V3 is the superior product, and rational actors will transfer capital without intervention. At the very least, we request a more extended period before implementing changes that expedite this process.

Reducing LTV and liquidation threshold on overlapping assets in V2 This change could heighten the liquidation risk for icETH customers.

Disabling borrowing of overlapping assets in V2 Consequently, we would be unable to further leverage the product, making it challenging to issue new units or facilitate effective arbitrage.

Increasing reserve factors on V2 for all overlapping markets This adjustment could potentially transform the product into a negatively yielding one.

6 Likes

Thanks, @funkmasterflex - this type of feedback is important because Aave is not a protocol in isolation but rather an ecosystem with integrations. These inputs help guide the community in determining the pace of migration and which levers listed above to use/not use. Different stakeholders have different priorities and preferences - we look forward to hearing more of those and moving this discussion forward transparently.

2 Likes

Thanks @Pauljlei,

We don’t have a strong opinion towards which option is preferred as it comes down to the community’s preference for how aggressively they want to migrate users and whether or not they intend to deprecate V2 markets.

From our POV, V2 seems to be in a relatively safe position with the efforts of the community and risk providers. V2 continues to be a large source of income for Aave and an aggressive migration might cause Aave to lose some of its TVL. Therefore, we don’t see the need to aggressively migrate users and protocols to V3.

Some thoughts on the levers:

stkAAVE:

  • Monetary incentive to migrate is likely strong, however, it ensures no stickiness.
  • Do we expect to recoup 23,100 AAVE in revenue in a reasonable time frame on V3?

LTV & LTs:

  • Invasive and potentially leads to bad user experience under unnecessary forced liquidations, however, clearly results in V3 being more capital efficient.
  • Forces users to make decisions about managing their HF, exiting, or migrating
  • After migration plan: V2 remains useable under safer risk parameters (great for SM)

Disable borrowing:

  • Potentially forces new borrowers to V3 but cuts off potential revenue for V2.
  • It also doesn’t directly incentivize users to exit their current position unless utilisation increases.
  • After migration plan: V2 becomes limited in market offerings.

RF:

  • Pretty invasive yet not as forceful as LTV/LTs as it directly makes V3 supply rates more attractive and incentivizes borrowers to pay back their positions on V2 given higher utilisation.
  • This could effectively kill V2 markets if not reverted over time, therefore, cutting off revenue.

Supply/Borrow Caps:

  • Agree that there is no need to increase V3 protocol risk for the sake of migration.

Our thoughts:

For a soft migration [preferred option]:

  • Continue to add asset listings to V3 with better LTV & LTs if risks permit it.
  • Continue to address LTV & LTs on V2 ensuring the protocol stays safe.

Over time, the continued addition of new assets with greater capital efficiency should encourage new users & (hopefully) old users to migrate, without hurting V2.

One thought is having a migration button on V2 interface along the lines of “Borrow x% ($x) more on V3”

For a hard migration:

  • Increase LTVs & LTs on V2 without forcing liquidations. However, this may take longer than 8 weeks.
  • and/or slightly increase reserve factors s.t. V3 is noticeably better for lenders and subsequently borrowers, but doesn’t kill V2 markets.
2 Likes

Hi @Pauljlei, some feedback from our side:

Levers

  • stkAave distribution to v3
    • Are there any incentives for stkAave for v2 markets at the moment?
    • What is the amount of token dilution?
    • Are there any incentives for stkAave operating at the moment? Is there any way to port those incentives to v3 to avoid token dilution?
  • Decrease LTV and liquidation threshold on overlapping assets in V2
    • Make sure that there are as minimal forced liquidations as possible, or none.
  • Disable borrowing of overlapping assets in V2
    • Makes sense with the UI change but it should also guide users on how to migrate their assets and do borrows in v3
  • Increase reserve factors on V2 for all overlapping markets
    • The increased IR for borrowers on v2 should be communicated to them in advance and potentially allow them to pay back before the IR resists too much
    • Why does Gauntlet not recommend this?
  • Increase V3 supply cap and borrow cap
    • Not in favour of this for the reasons outlined on the proposal

General Comments/Questions

  • Do you have an expected quantitative result of changing these levers on a week by week or even aggregate basis? Which accounts are likely to migrate based on the underlying conditions changing?
  • The question posed by @sakulstra: most(all) insolvencies were caused by eMode on v3. v2 worked as expected with 0 insolvencies. If that’s true, how does this work as an argument to speed up v2-v3 migration? Or is the main aim of e-mode for stablecoins to allow for high leverage, so therefore insolvencies are part of the equation?
  • Agreed with @sakulstra as well - if most v2 assets are not on v3 then would the adjustments to encourage migration to v3 only be for overlapping assets? Moreso, if some v2 assets are not listed on v3 and only on v2, and other key assets largely migrate to v2, there would not be enough capacity to borrow the assets migrated to v3, and holders of those assets would be incentivised to use other venues. Is there a solution for this? Should we aim to list more assets on v3 (with risk mitigating parameters) to avoid mismatches?
1 Like

Thanks all for your feedback. We target an initial Snapshot vote on 3/27/2023. Given the differing preferences above, this Snapshot will be a temperature check on which levers the community would prefer to use for initial migration facilitation. The Snapshot will also include the option of “Do not facilitate migration at this time.”

If the community chooses to be proactive around migration, then we will follow up with more recommendations and target a Snapshot vote for specific recommendations on 4/11/2023. From a risk management perspective, migration is a priority, however, there are limitations as described by community members above.

Hello,

The Aave-Chan Initiative is firmly against any form of LM StkAave distribution and will vote accordingly.

We support change of risk parameters to make V2 slightly less attractive than V3 for overlapping assets and let the market migrate over time and intend to present ARFCs to make this happen shortly.

3 Likes

Hello @pauljlei,

I am posting these remarks on behalf of Morpho Labs, the main contributor to the Morpho protocol, itself, one of the biggest users of AaveV2.

We think that this migration plan is too aggressive for the moment, considering that:

  • AaveV2 has many on-chain integrations, as mentioned by @funkmasterflex, and a large ecosystem that took years to build. While making significant changes, such as pausing borrowings or reducing LTV and liquidation thresholds on major assets, could be adapted to active users, it would undoubtedly disrupt many of these integrations. Aave is a foundational layer of DeFi that should provide trust and consistency to its ecosystem and developers, and sudden major changes should be avoided to maintain this stability.
  • AaveV3 is a relatively new platform, and both its implementation and models for parameter selection need time to prove themselves as safe as those of AaveV2. As @sakulstra pointed out, most insolvencies that occurred during the USDC issue happened on AaveV3 instances, for example. The most conservative users and protocols may want to wait before migrating to V3.
  • The AaveV3 protocol offers several advantages over AaveV2, providing a natural incentive for users and projects to migrate their liquidity gradually. Whether a migration plan is necessary or not is a topic for community discussion, taking into account all tradeoffs.

Therefore, we recommend a more conservative approach. Specifically, we are opposed to disallowing borrowing on overlapping assets at this time.

3 Likes

Looks like there is a divide between direct users who prefer a faster migration, and indirect users who access Aave via intermediaries like Index Coop and Morpho, who prefer a more gradual migration. @funkmasterflex and @MathisGD Could you elaborate on how the migration would work on your protocols? For example, looking at the icETH webpage, I don’t see an option for users to choose Aave V3 (only Aave V2 is listed under “Initial Parameters”). So how can icETH users access Aave V3 if they prefer it to V2? Additionally, if indirect users are less in tune with the details of the money market protocol compared to direct users, then they might not know that V3 is a better product than V2.

In terms of the levers, here are our thoughts:

  1. stkAave distribution to V3 - is it possible to reduce the safety incentives on v2 to reduce the dilution?

  2. decrease LTV and LT - if careful calibration can reduce forced liquidation, we would be in favor of this approach?

Lastly, we second @sakulstra’s questions about eMode. Currently, what are the usecases for people using stablecoin eMode?

2 Likes

Index Coop is in the process of building a new icETH token that utilizes Aave V3. This transition is not an easy one. V3 has been live for a little over a month and it would be unreasonable to assume that design, implementation, audits, and testing would be done during this time. Moreover, icETH can be built on any lending protocol and it is wrong to assume the immediate migration of the product to V3 “just because it’s new and better”. We must monitor and simulate V3 as an entirely new protocol.

As it stands, there is no simple option or button for users to migrate. This is not how real DeFi is built. This is a slow and steady and most importantly SAFE game. Index has been managing leverage products for multiple years without a single dollar being liquidated. This is not something we’re willing to sacrifice for the sake of speed.

We build products on Aave, but we are also one of the largest users of Compound with our ETH and BTC FLI products. Migrating these products to V3 is also something we are considering. Index Coop is a unique Aave integration example. INDEX is one of Aave’s largest voters through the Aave holdings in the DeFi Pulse Index. We believe it is in the best interest of Aave DAO and its integration partners to undergo a gradual migration.

4 Likes

Summary

Aave’s top priority is migrating liquidity from V2 to V3, focusing on the Ethereum deployment due to its significant liquidity share. To this end, we will soon release a structured migration plan based on four key pillars.

  1. Adopt a “case-by-case” approach to evaluate individual use cases and take appropriate actions accordingly.

  2. Address any constraints related to existing positions.

  3. Prioritize migration goals over timelines.

  4. Employ an iterative process to improve outcomes and make more informed decisions using data. We look forward to sharing this plan with the community and working collaboratively toward a successful migration.

Case-by-case approach

The transition from V2 to V3 involves a myriad of scenarios and considerations, and different assets require tailored risk management strategies. As a result, we believe it is crucial to examine the relevant risk controls for each case separately, prioritizing a use-case-first approach over a toolkit-first approach. Therefore, we are committed to assessing risk parameters for each asset to ensure that adequate measures are taken to manage risks effectively.

We are considering various asset classes for migration from V2 to V3, each with unique characteristics and requirements. The asset classes include:

  1. Long tail assets may require targeted risk management strategies to promote their migration to V3.
  2. Blue-chip tokens will likely migrate naturally over time due to their strong market demand and lower risk profiles.
  3. Stablecoins and stablecoin E-Mode considerations may require specific approaches to ensure stable liquidity migration and minimize potential impacts on price stability.
  4. LSDs and LSD E-Mode considerations require a thorough analysis of the associated risks and strategic risk management plans to facilitate the migration of liquidity.
  5. Isolation Mode assets, where cross-collateralization is no longer available, necessitate tailored risk management strategies to encourage their migration to V3.
  6. Ongoing revenue potential to the protocol from each asset, which we will consider as we evaluate the migration of different asset classes to V3.

By taking a use-case-first approach and assessing each asset class’s specific risks and requirements, we aim to promote the efficient and successful migration of liquidity from V2 to V3.

Let’s consider two assets, A and B, identical in most aspects except for one key difference. Asset A can be listed with a higher Loan To Value (LTV) ratio on Aave V2 than it currently is, while all other settings remain the same.

In contrast, Asset B has become considerably more volatile and less liquid, necessitating a lower LTV ratio and a strict supply cap on Aave V2, while all other settings remain the same. Taking a case-by-case approach, we can tailor the risk management strategies for each asset, optimizing the migration of liquidity from V2 to V3. The transition may occur naturally for Asset A, as suppliers seek higher leverage for their collateral and borrowers find better terms on V3. However, Asset B may require a more targeted approach, including a detailed analysis of the associated risks and a strategic plan for risk parameter settings on both V2 and V3 deployments, to encourage a successful and efficient migration of liquidity.

Existing Positions

Position Structure and Cross-collateral considerations, i.e., supplied and borrowed assets and overall position leverage for each asset.

To facilitate the migration of positions from V2 to V3, it is essential to ensure that the majority of the collateral assets provided together can be accommodated in V3, along with sufficient liquidity of assets. This requires carefully evaluating the collateral basket’s composition and liquidity, including any unique characteristics or risks associated with the assets. This approach will help promote the smooth and efficient migration of positions from V2 to V3, allowing suppliers and borrowers to access better terms and benefits on V3 while minimizing potential disruptions.

Goals before timeline

While we recognize the importance of a complete and swift migration, our primary goal is to perform a successful liquidity migration, prioritizing goals ahead of timelines. The process of migrating liquidity from V2 to V3 requires careful planning, evaluation, and execution, and we believe it is essential to take the necessary steps to ensure that the migration is completed successfully. We understand that external factors, such as adapting protocols built on top of Aave V2 (index, morpho) and the perceived trustworthiness of Aave V3, can also impact migration timelines. Therefore, we must consider these factors while developing our migration plan to ensure that the migration process is not rushed and all necessary measures are taken to promote a successful migration. While we will push to perform the migration as quickly as possible, our focus is on promoting a smooth and efficient migration process that prioritizes the interests of the Aave community and risk managers.

Iterative process

We believe that each step in the migration process should involve a careful analysis of available data and a thorough evaluation of alternatives to ensure that the most effective measures are taken to promote liquidity migration. It is equally important to measure the impact of these actions once they have been taken. By tracking the transition of liquidity following each action, we can quantify the effectiveness of each measure in each case and make informed decisions to improve our approach accordingly. Therefore, we will continue using data-driven insights to refine our migration plan and ensure that we maximize our efforts to promote a successful migration from V2 to V3.

Additional considerations

Protocol Integrations

It is important to consider the impact of protocol integrations and proprietary strategies built on top of Aave V2 when planning the migration to Aave V3. Therefore, when migrating, we must work closely with integrated protocols and consider their needs and timelines. This will ensure the migration is as smooth as possible for all parties involved, promoting a successful transition to Aave V3.

E-Mode

E-Mode requires specific attention, especially in light of the recent depeg events. As outlined in Chaos Labs’ preliminary evaluation, we believe measures should be taken to address specifically these events systematically. Moreover, we believe that the LT of stablecoin E-Mode should be re-evaluated and configured at lower levels than other V3 deployments given:

  1. The value of E-Mode can come from listing multiple stablecoins and needs to account for all pairwise correlations
  2. Decreasing LT will come at the cost of forcing liquidations while increasing LT is free
  3. Since there is no E-Mode on V2, it is not a hurdle for the migration and, therefore, not a top consideration for migration

stkAAVE Incentives

As a general approach, incentives create initial traction but are not a sustainable measure, as mentioned by @MarcZeller. As mentioned, levers should be considered case-by-case, but we do not think they are useful as a general approach.

4 Likes

Gauntlet Update for V3 Ethereum Migration

Tl/DR:

We have published a Snapshot vote here so that the community can align on the levers for migration.

Summary

There have been many great comments and observations in this thread around the strategic priorities of the community and the usage of the protocol. As some users mentioned, there can be structural inhibitors to migration. Currently, there is no clear consensus around the levers of migration and their timing.

Given that there are so many potential levers and differing opinions on them, there are many permutations of migration plans. Instead of offering many different migration plan options in an attempt to encapsulate all the comments above, it will first be valuable for the community to align on levers, which are strategic and philosophical in nature. We hope that this approach is less overwhelming to the community. Following community alignment, we can then provide more granular migration plans.

To summarize, we aim to find clarity on the following:

  • Does the community want to facilitate migration at this time?
  • Which levers does the community approve of?
  • Which levers does the community disapprove of?

We have published a Snapshot vote (users can select multiple options) with the options that we mentioned originally in this forum post above:

  • YES stkAave incentives
  • NO stkAave incentives
  • YES decrease V2 LT/LTV on overlapping assets
  • NO decrease V2 LT/LTV on overlapping assets
  • YES disable V2 borrowing on overlapping assets
  • NO disable V2 borrowing on overlapping assets
  • YES increase V2 RF
  • NO increase V2 RF
  • YES increase V3 caps
  • NO increase V3 caps
  • Don’t promote migration at this time
  • Abstain

To visualize how this plays out, if more people vote NO on increasing V2 RF than people vote YES on increasing V2 RF, then this would be a lever we would deprioritize.

There is no perfect solution in governance to address complex decisions such as migration, but we hope that this can help the community voice their preferences and quantify them. We aim to be as inclusive as possible.

Next Steps

  • To allow ample time, voting begins on Monday, 3/27/2023

Quick Links

2 Likes

As the Aave-chan Initiative, we are grateful for this proposal and understand the importance of encouraging migration to V3. However, we have specific positions on the levers presented in the proposal.

Lever Position
stkAave incentives Not supportive
Decrease V2 LT/LTV on overlapping assets Not supportive
Disable borrowing on V2 overlapping assets Not supportive
Increase reserveFactor Supportive
Increase V3 caps Supportive

We believe that liquidity mining is not necessary to encourage users to migrate to V3, and we are concerned about the potential risks associated with decreasing LTV and liquidation thresholds on overlapping assets in V2 for the health of current users positions. We also believe that disabling borrowing on overlapping assets in V2 could negatively impact user experience and lead to a loss of market share and potential revenue.

However, we support an incremental increase in the reserve factor in V2 for all overlapping markets and an increase in supply and borrow caps on V3 to incrementally make V3 more attractive.
.
Additionally, we believe it is important to align V3 risk parameters with V2 when V2 parameters are more favorable (e.g. AAVE).

We will vote in the upcoming Snapshot vote in alignment with our positions. We appreciate the opportunity to provide feedback and contribute to the decision-making process

3 Likes

For stETH migration to stETH from v2 to v3, there is around 8% of slippage …that is to much for me, I don’t want to migrate in this conditions…

hello, the slippage is 0, V2 has stETH that is ~worth 1 ETH, V3 has wstETH that is worth ~1.08 ETH

you lose zero in the migration.

2 Likes

Following the community vote, we have published our recommendations for the next steps here.
We invite the community to participate in the discussion around this proposal.

1 Like