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
- Get blocks of first and last migrations
- Query v2 for staked balance and vault balance and linearize from initial to final time points
- Sum total amount migrated and determine linear (daily) migration amount
- Evaluate the daily migration amount as a proportion of the total linearized staked amount (pro-rata)
- Calculate the corresponding pro-rata share of the linearized surplus per day
- 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.