Aave V2 was launched on Dec 3 and has shown exceptional resiliency. No particular issues were found during the launch, and after 40 days is now securely holding 500 Millions of fund and already issued 10M in flashloans, mostly thanks to the repay with collateral and swap features. Users in V2 enjoy these new possibilities and substantially lower gas prices. Now that V2 has shown enough resiliency to safely hold a sizeable amount of funds, the genesis team thinks it’s time to start the transition from Aave V1 to Aave V2. The first step is to release the official V1 -> V2 migration tool. This tool will be integrated in the Aave V1 UI and provide the ability to V1 users to safely migrate their whole position in one transaction. To reduce gas costs, the migration tool supports the CHI token.
The genesis team believes that the best strategy to have a seamless migration is the following:
Phase 1: Release the migration tool; submit a governance proposal to disable borrowing of the less used stablecoins and all the collateral assets in Aave V1.
An initial list of assets disabled might be:
BUSD
SUSD
All the collateral assets
Phase 2: Submit a governance proposal to disable borrowing on:
DAI
USDC
USDT
Phase 3: Submit a governance proposal to freeze the stablecoins reserves. Freezed reserves will allow users to withdraw/repay/liquidate, but not borrow or deposit.
Phase 4: Freeze all the collateral reserves. Users will not be allowed to deposit more collateral, which means they will be required to migrate.
The idea behind this migration schedule is to progressively lower the borrow demand in V1 in order to replenish the stablecoins reserves. This way integrators like Curve/Yearn/idle/mstable and others will have the possibility to migrate their liquidity to the new version of the protocol.
The whole migration process should be relatively short to bring Aave V2 to full operation as soon as possible. The team believes that a period of two weeks for each phase (which includes 3 days of voting + 1 day timelock) should conclude the migration in approximately two months, which is a reasonable amount of time for users and integrators to properly act.
In my opinion, this plan is far too accelerated and would hurt Aave and its users if executed in this form in the near future. It is not a matter of only the technical readiness, but also economic and tax concerns that can deter suppliers, reducing the liquidity for everyone.
The value of ETH and many tokens have risen greatly in the past few months. Nearly all of the deposits on Aave have occurred in the past 12 months. In the US, the safe tax view is that deposits to Aave are taxable events (as token to aToken trades). I believe that it is also reasonable to consider v1 to v2 migration as a taxable event unless we hear otherwise because the two systems are completely separate and access different markets… it’s not just an upgrade of code or a swap analogous to a stock split like LEND to AAVE.
This means that if a US person or entity (and probably other jurisdictions as well) migrates from Aave v1 to Aave v2, they will immediately incur the higher short-term capital gains tax on the difference in value from when they deposited the collateral to the time when the migration takes place. This means basically immediately paying income tax on that difference, which is likely a large percentage of the collateral value.
One important use case for suppliers is the ability to postpone taxes by depositing collateral and borrowing against it, then slowly selling the collateral on their own schedule. By proceeding to phase 4 within a matter of weeks, making it impossible for them to deposit more collateral to maintain a healthy safety ratio, we are effectively forcing them to migrate immediately and incur a huge tax bill. In the announcements, it’s made to sound like you can take as long as you want to migrate, no rush. But this is simply not true if you have a large borrow. You can’t continue on the way you were before with the same level of risk and you may be forced to migrate or be liquidated. Either way you’re at risk of incurring a big surprise tax bill at any time.
I think a foundational part of DeFi like Aave should provide stability and predictability. Giving people notice that they’re effectively forced to migrate their positions and incur a huge tax bill within a matter of weeks is not that.
I think that everyone on Aave would be hurt if suppliers in the future are turned off from depositing into Aave because we establish a track record of rapidly deprecating its services on a timeframe too short for a financial platform. It makes me wonder if Aave v3 is going to come in a year, requiring another taxable event aToken migration.
I hope you all can consider this point of view and please let me know if you have any questions.
This is a good question and I haven’t thought extensively about an ideal schedule for everyone. But my quick take on this…
I think that it would be reasonable for the disabling of borrowing over 2-3 months, so that anyone depending on borrowing from Aave in the short-term can continue for a while longer while planning the change over. Then delay the disabling of depositing to start in 8-12 months, so that anyone who wants to can maintain their collateral ratio at least until most people have switched over to long-term capital gains or had ample time to plan a change.
I would love to see what other people think as well, and I would like to better understand the tradeoffs of operating two systems in parallel. Is the main concern for having a speedy migration making sure as much liquidity is available as possible in a single new system so that it is more useful, for example for large flash loans? Are there other risks, like maintaining two systems takes a lot more effort, or may confuse users, etc?
Also I just want to give a quick example that might help illustrate why the migration is very difficult for some people tax-wise and what the timeframe looks like. Imagine someone spent their life savings of $100,000 to buy ETH on March 17, 2020 at $125, getting them 800 ETH. They immediately deposited into Aave. Fast forward to now and it’s worth over $900,000. They’ve been using Aave to borrow USDC to pay for their rent, so they can stay invested in ETH and not have to pay any taxes immediately.
Now if they have to execute the migration within the next few weeks while the gains are still short-term, the $800,000 difference between what they paid for the ETH and what it’s worth now would immediately become taxable at income tax rates in the US. Suddenly they have to pay almost $300,000 in taxes this year.
Before having to migrate, they didn’t have any immediate taxes to pay. They could’ve slowly sold off over several years. Now they suddenly have a $300,000 tax bill. They don’t have that much USD, so they either half to sell 37.5% of their ETH to pay it, or borrow $300,000. Both of these put them in a financially worse or riskier situation. They are surprised because they didn’t think that just months after depositing into Aave, the system would be deprecated.
I just came across this post which describes the same tax issue mentioned that would be a deterrent for future large depositors, especially institutions. It has an interesting solution for future deposits, but the current deposits are still going to face this issue even if this is implemented.
Just had an idea for a solution to the migration tax problem, based on the Optional LP Share Withdrawals thread!
The Optional LP Share Withdrawals can be implemented, and an extra feature added to allow you to deposit your v1 aTokens. The smart contract could take your aTokens as a deposit, and migrate it to v2 for you, without returning to you the v2 tokens. Then perhaps it won’t be seen as a taxable token swap, solving the issue. Though probably it needs to be possible for the v1 aTokens to be returned to you on withdrawal in order for it to be considered a loan to avoid the taxable event.
Or perhaps v1 aTokens can be allowed as collateral in Aave v2, combined with the Optional LP Share Withdrawals idea.
I’m not that well read in the workings of AAVE. But I am borrowing BUSD, and using ETH as collatoral.
Would love to migrate to V2, but currently it would cost me 600 dollars.
That’s a bit much for me to handle.
Problem is: if pools get disabled, borrowings get disabled. Probably my APY that I would have to pay would increase massively. Even now BUSD sometimes spikes up to 40% APY for half a day.
So it would force me too gamble: will the 600 dollars outway the fees I have to pay for the APY or not?
Hello guys, this is a great feedback. Unfortunately the ETH usage is at all time high and the price of ETH does not help, and transactions are super expensive. Migration in particular, especially if you deposited and borrowed many assets. I agree overall that the migration schedule needs to be adjusted to adapt with the network conditions and don’t overcomplicate life for V1 borrowers. As you can see, no proposals have been made after the release of the migration tool.
In the more-than four months since Aave V2 was launched, ~60% of the Aave protocol liquidity organically migrated from Aave V1 to the Aave V2 reserves.
With significant reserves in, the community has the opportunity to implement a plan to transition the remaining reserves from V1 to V2. The community has the opportunity to bring about this change to ease the borrowing pressure on V1, to address high transaction fees that exist now, and may increase further upon the implementation of Berlin Hardfork. The migration can benefit not only Aave users, but also the Aave ecosystem as a whole because it will allow protocols integrating with Aave to have additional stablecoins liquidity available (due to the ecosystem-wide stablecoin liquidity crush).
The transition plan can have several phases to progressively allow users to upgrade their liquidity on Aave V2 at their own pace.
If governance approves this proposal, the next proposed transition phase could be to disable the ability to take new stablecoins loans.
Summary of proposal :
Activation of phase 1 of the transition plan, creation of an AIP vote disabling new stable rates loans of all assets on Aave V1.
IMO, it is a better path to continue to draw liquidity from V1 by offering better and more attractive features on V2, NOT by reducing functionality on V1.
I believe this because the pace of innovation and development on V2 is a really good carrot.
Disabling fixed rates on V1 seems to be a cruel stick.
Sure, but imagine that I am managing some decent sized loans on V1.
I am not ready to repay the loans. In fact, I’d like to take out a larger loan, but I no longer will because of the new policy and how much I like taking out loans with stable rates.
Will this user migrate to V2? Maybe at some point. Will this user take out more loans on the AAVE protocol, probably not with this new policy in place.
This policy will move users from V1 to V2. But it would have other consequences too and it’s important to consider them. Not necessarily yield to them, but certainly consider them.
One direct advantage is that the Aave collector (InitializableAdminUpgradeabilityProxy | 0x464c71f6c2f760dda6093dcb91c24c39e5d6e18c) which holds the income generated by the protocol reserve factor, would also start receiving the value generated by V1 borrowers. V1 does not have the capability of collecting interest through reserve factor, so effectively the protocol is losing revenue every day. Right now the fee collector grows around 20/25K a day thanks to V2, and that would essentially double if the outstanding V1 debt would migrate to V2.
Indirectly of course, V2 provides way better user experience and lower transaction costs so it has higher user retention
I’d be disappointed to have the V1 Stable Loan option removed. Stable rates are consistently lower on V1 than V2 which has kept me from migrating. If it were possible to move funds from V1 to V2 while maintaining my existing V1 Stable rates I would gladly pay the gas fee to fund my migration. If maintaining the current rate is not possible between V1 and V2, another angle would be to provide a direct incentive (Aave tokens?) to V1 borrowers in the migration process to justify and offset any stable rate disparity they would incur moving from V1 to V2.