Proposal: Move v2.1 liquidity to v3

To clear some misunderstandings -

  • it was unfortunate that this happened right after v3 launch, as it creates the false impression that it was a v3 problem. Most large stakes already had full protection in v2.1 and their withdrawal from v2.1 would have resulted in the same issue. If any, v3 is actually better in that regard since liquidity off-curve doesn’t suffer IL - a property that v2.1 doesn’t have. The built-in mechanism that v2.1 has (24h lock period) doesn’t seem as it would have made much difference.
  • as @xrx mentioned, v2.1 migrations to v3 currently don’t include migrating their respective surplus, so v2.1 currently owes some liquidity to v3. It’s impossible to calculate exactly how much since the time component has an impact over trades/migrations. Technically it’s even possible (and actually very likely) that certain pools of v2.1 owe more than the entire surplus to v3.

There can be a certain compromise - performing a “naive” simulation that takes the following into account -

  • all migrations from v2.1 to v3
  • rate change in the pool between the first migration to the last migration
  • respective surplus in the pool
  • apply all of them in a linear fashion
  • deduct the amount that was actually migrated from the result

This is a very rough way to calculate how much was migrated while taking into account rate changes in between these migrations. It’s of course not scientific but maybe this can receive enough DAO support.
It’s also (still) not very straightforward but maybe doable.
Interested to hear what others think.

4 Likes

Yudi’s suggestion seems the most fair if we can all agree on the assumptions in the math - even if this leaves a defecit in v2.1 pools.

If this goes through, v2.1 users will not be forced to terms they never agreed to, and v3 users will get everything they feel they’re owed from v2.1. I would further suggest that permanently re-enabling withdraws for v2.1 be added to this proposal.

3 Likes

I don’t know how you read yudi’s comment, but it pushes my opinion even more to a force migration from v2.1 to v3.

  • Reason1: Impossible to calculate exactly how much is owed fromm v2.1 pools to v3 pools
  • Reason2: It’s very likely that certain v2.1 pools owe more than the entire surplus to v3.
1 Like

You have been an adamant proponent of a forced migration since the beginning of this thread. You were the very first person to respond to this thread, in fact, so you should know that people (Yudi included) have been saying its impossible to calculate since the beginning. For the first time, Yudi has laid out a number of reasonable assumptions which could likely be used to approximate what is owed from v2.1.

Yet I am supposed to believe that this new information coming to light would somehow “push” your opinion “even more to a force migration”. I’d say it’s highly unlikely that you could be pushed any more in that direction than you already were - and it’s seeming increasingly more likely that you’re unwilling to compromise and unwilling to view the situation (and potential solutions) objectively.

I also noticed that you didn’t reply to my previous question. I was hoping you could address it this time because it might be a good learning opportunity for me, or for you.

2 Likes

If you’ve followed my posts, you should have seen the arguments I have provided why I think a forced migration is the most fair solution. I already stated multiple times that I’m focused on the protocol as whole and don’t cherrypick single pools, like most of the “Anti-Force” people in here do.
Had a bit of a pause in here, because it looks like there will be no vote in the next few months and the focus of the contributors is on different topics, so I shifted my focus as well.
Will probably just absorb the conversation in here the next few weeks and then publish a summary of my current findings

I’m generally against forced migrations, I think it’s way too aggressive.
I’m merely trying to suggest a path that will allow us all to move forward (including open withdrawals on v2.1) and my suggestion is a compromise - since it’s impossible to scientifically calculate the exact value - it can be a very rough estimation.

Thanks dude, I totally agree. I think we should move forward quickly, however! Some people are afraid that the deficit will grow when the price of TKN increase. Migrating should thus be done before it gets out of hand.

3 Likes

I guess the next step is to get some simulations so that everyone can see some rough numbers before moving to a vote.
Would also be great to get some more feedback in here.

4 Likes

Hey Yudi, when can we get these simulations ready?

1 Like

Unfortunately the guy who’s working on that is sick so it’s taking a bit longer.
I imagine the simulation for some of the pools (ETH, LINK) will be ready sometime next week.

1 Like

Just an update that the work on the simulations is underway.

3 Likes

The proposal is titled “Move” without mention of “handle”, which would allow more options than only to “move”. Could we agree “handle” should be in the proposal, which takes in to consideration all the issues around “handling” v2.1? The proposal is to seek the best way or options to “handle v2.1”, which could include an option to “move to v3” as well as other options.

1 Like

Simulations with some analysis will assist community members with further discussion to decide their preferred pathway but we still need a comprehensive list of the various pathways and options, pros and cons. The proposal started with a good format and some posts attempted to categorise more options / pathways. Would @ILRekt be open to collecting the various pathways and updating the proposal?

1 Like

I don’t see why not and @ILRekt can update the title on this thread. I see this more as a discussion rather than a proposal and probably a good idea to wait on the simulation before making any decisions (of which there have been many expressed on how to move forward).

Data Insights on v2.1 → v3 Migrations

Part 1: Simulating Pro-Rata Migrations Retrospectively Example

Q: What if previous migrations to v3 had taken the pro-rata share of the surplus?

TLDR - The pro-rata method is not suitable for over 30% of pools due to the total calculated surplus owing to v3 being larger than the current v2 vault balance. Another 30% were in deficit on v2 with no surplus to migrate. Only 30% of pools were suited to this method.

Pain points

  • An accurate simulation is incredibly complex if not impossible as, from the very first migration, the vault balance on v2 would be different and thus subsequent trades and AMM actions would have all yielded different outcomes.

Idea

  • Simplify by linearizing vault and staked balances, surplus and migrations. Makes linear assumptions about price.

Setup

  1. Get blocks of first and last migrations
  2. Query v2 for staked balance and vault balance and linearize from initial to final time points
  3. Sum total amount migrated and determine linear (daily) migration amount
  4. Evaluate the daily migration amount as a proportion of the total linearized staked amount (pro-rata)
  5. Calculate the corresponding pro-rata share of the linearized surplus per day
  6. Sum total amount of pro-rata surplus that should have been migrated

Example LINK Migrations

  • As the staked balance is depleted over time but the migration amount remains constant the pro-rata share of the surplus gets larger with time.
  • !!! Under this scenario, withdrawing a pro-rata portion of the surplus results in a total surplus owed to v3 of 1.8M LINK (however there is only 920k in v2 vault).

Conclusion

The pro-rata method of migrating surplus retrospectively is incredibly challenging. Basic assumptions regarding balances and migrations still do not lend this method to be applicable to all pools. In an important case of LINK, the surplus to be migrated would exceed the current v2 vault balance - making this method not a fitting solution.

8 Likes

Data Insights on v2.1 → v3 Migrations

Part 2: Migrate Current v2 Surplus to v3

Data Set: 20220913 - Surplus Migration w IL - Google Sheets
Note: While this value is calculated for every token in the spreadsheet, it is applicable to only those with a v2 surplus and a non-zero v3 staked balance

Q: What if we migrate the current v2 surplus to v3?

TLDR - Migrating the surplus from v2 has a value of ~$9.1M and is applicable to 51 pools. The majority of v3 pools significantly benefit from the migration however big pools such as ETH, WBTC and USDC are not effected due to being in deficit on v2.

Idea

  • Evaluate the current surplus on v2 stakes and migrate this to v3

Setup

  1. Get v2.1 → v3 migrations to identify key pools
  2. Scrape v2 positions and sum for staked balance per pool
  3. Get v2 vault balance per pool
  4. Calculate surplus per pool
  5. Evaluate v3 surplus positions pre- and post- migration of the v2 surplus

Data

Analysis block: 15523726
Pools with Migration: 108


Figure 1. Current v3 surplus per pool (red).


Figure 2. Current v3 surplus per pool (red) overlay v3 surplus post-v2-surplus migration (green). Y-axis truncated at (-1,1).


Figure 3. As above - Figure 2 - without truncation.

LINK Example
Table 1. LINK surplus position on v2 and v3 currently and post migration of the v2 surplus.

token v2_current_surplus_perc v2_postMigration_surplus_perc v3_current_surplus_perc v3_postMigration_surplus_perc
link 94.2% 0% -48.3% -33.9%

Migrating the LINK v2 surplus to v3 improves the deficit on v3 pools by 14%.

Pain points

  • Some surplus may not be able to be migrated due to insufficient protocol-owned pool tokens.

Conclusion

Migrating the v2 surplus to v3 can help alleviate the deficit on over 50 pools. In the case of LINK this is a significant improvement for v3 LPs, however other large pools in deficit on v2 are not improved by this method. Additionally, there may be constraints to how much surplus can be migrated to v3 depending on the portion of v2 protocol-owned liquidity.

7 Likes

Data Insights on v2.1 → v3 Migrations

Part 3: Migrating IL from v2 to v3 to offset the deficit

Data Set: https://docs.google.com/spreadsheets/d/18cehllrocu3U-3gDzaNDkpxwX-Pjt-44Xzn53-4X3rI/edit?usp=sharing
Note: While this value is calculated for every token in the spreadsheet, it is applicable to only those with a non-zero v2 vault balance post-IL migration.

Q: Since v2 positions are exposed to impermanent loss (on a position-basis) this IL could be utilized on v3 to mitigate the deficit. So could we consider migrating the IL-incurred on currently staked v2 positions to v3?

TLDR - Migrating the full amount of IL that has been incurred on currently staked v2 positions could yield $1.3M relief to the v3 deficit. However, this method is not applicable to pools where the IL exceeds the current v2 vault balance. Modifications to this method to include large value pools (such as ETH, WBTC) might be more suitable to assist with the v3 deficit.

Setup

  1. Get current stakes on v2 (includes the rate - price - at which the TKN was deposited)
  2. Get the current rate (price of the TKN) and evaluate the IL-incurred per position (%)
  3. Multiply the IL by the user stake to get the IL-incurred in TKN and sum for all positions currently in the pool
  4. Total IL on the pool divided by the staked balance is the average IL per pool

Data

Analysis block: 15523726
Pools with Migration: 108

The average IL incurred on currently staked v2 positions exceeds the total staked balance in some cases. That is, migrating the entire IL incurred on all pools is not a feasible solution.


Figure 1. Average IL per pool. Negative one (-1) on the y-axis indicates IL is 100% of the current v2 staked balance. Y-axis is truncated - MATIC is approximately -12.

In this implementation, the applicable pools must: have IL to migrate; must not result in a negative v2 vault balance post-IL-migration; and must have a non-zero v3 staked balance. Thus the number of applicable pools is 74 and, as can be seen in Figure 3, this improves the deficit state considerable for v3 pools. However, the value associated with this migration is just $1.3M. This is a small component of approximately $30M of IL that has been incurred on currently-staked v2 positions. The primary reason being is that when the IL-incurred exceeds the v2 vault balance we omit this pool (i.e. migrate nothing).

Large pools including ETH, WBTC, USDC, and USDT all fall into this category of omission and so considering how much - if any - of the IL incurred on these pools to migrate to v3 is a difficult task. See Modifications section below.


Figure 2. Current v3 surplus per pool (red).


Figure 3. Current v3 surplus per pool (red) overlay v3 surplus post-v2-IL migration (green). Y-axis truncated at (-1,1).


Figure 4. Current v3 surplus per pool (red) overlay v3 surplus post-v2-IL migration (green).

Modifications

After evaluating the above method yields just $1.3M in migration value, I investigated a thresholding method whereby an arbitrary limit is set to the minimum for the vault balance post-migration.
Let’s say we set the minimum vault balance to 50% of its current balance. In this method, the IL is migrated to a maximum value of 50% the TKN in the vault. This way, at least some of the TKN in v2 pools can contribute to the v3 deficit.

As an example, if we set the threshold to 50% of the current vault balance then the total migration value comes to ~$6.4M and this method is applicable to 90 pools. A summary of this effect on the surplus/deficit for v2 and v3 is shown in Table 1 below.

Table 1. Example of the thresholding method at 50% current v2 vault balance and its effect on the v2 and v3 deficits. IL is migrated up to the maximum amount defined by the threshold.

token v2_current_surplus_perc v2_postMigration_ILthreshold_surplus_perc v3_current_surplus_perc v3_postMigration_ILthreshold_surplus_perc
eth -37.1% -68.5% -60.0% -51.9%
link 94.2% 76.7% -48.4% -45.7%
usdc -6.8% -53.4% -41.1% -29.0%
usdt 8.4% -45.8% -43.9% -32.8%
wbtc -64.2% -82.1% -50.6% -25.2%

Conclusion

IL-incurred on v2 positions could be migrated to v3 to assist with the deficit. Taking the entire IL amount incurred, but limiting the applicable pools to those where the IL does not exceed the current v2 vault balance, could contribute $1.3M to the deficit. However this omits large value pools that would benefit from alleviation of their deficit. One modification to this method may be to take IL from a given pool up to a particular threshold (be it a percentage of the vault balance or a dollar value). This would allow a greater coverage of pools and also allow contributions from large value pools whom have incurred a substantial IL.

4 Likes

If we strive to be legal and ethical, there is only one solution to this.

Allow withdrawals from v2 indefinitely according to each LP position’s own IL loss.

Let the surplus be part of a compensation plan when that happens.

3 Likes

No updates? When will this be voted? Why is this dragging on for so long?

1 Like

My oh my, what did I miss? I’m getting myself caught up, and will opine once I’ve digested all of what transpired.