Migration Mining (MM), a new mining variant

Migration Mining (MM) - a new form of incentive for crypto projects to get liquidity into a liquidity dependent protocol.

Executive Summary

Migration minings (MM) goal is to suck liquidity from project A to B. It has 6 main purposes:

1. Minimal cost for project B to get a lot of liquidity rewarded by project token B
2. Lock-up migrated liquidity in project B for an extended time
3. Have a clear target group with existing liquidity provider on project A
4. Make migration more easy, because it only needs 1 tx (and no waiting time for get several tx to get mined)
5. Allow small pool owner to migrate with minimal cost, because migrate is rewarded by project token B and payed by others.
6. Meme Power, because its something new! Migration mining woke - Liquidity mining broke!

User story for migration with migration mining

User visits migration page of target project B and will see a list of liquidity token he/she owns from project A. Now he/she selects one or several token and makes an approval tx to every liquidity token from A and can individually set a lock-up period from 60-360 days.

Reward in project token B is calculated and shown. He/she makes an approval tx to liquidity token and makes a tx to set the lock-up period. Then he/she waits until migration is completed.

Under the hood

1. User approves liquidity token from A with one tx
2. User set a lock-up period with another tx
3. Somebody calls migrate for the contract and pays for the gas, (this person gets project token B for paying eth needed for the migration)
4. migrate:
   • withdraw liquidity from project A -> get liquidity from project A
   • supply liquidity to project B -> put liquidity to project B with a lock-up period
   • send dust of unused liquidity back to owner
   • send reward token to owner

migration mining adds a lot of complexity to migration

1. rewards in project token B should be based on $ value

   • for $ stablecoin pools this is easy to calculate (2x the stablecoin)
   • for eth pools an oracle is needed
   • for other pools without $ stablecoin or eth at least 1 oracle is needed

2. To prevent migration washing a lock-up period must be applied for a time range from 60 to 360 days. This also has the very important side effect not only to migrate liquidity but also to hold!

3. To prevent people adding liquidity to project A for migration mining to project B a whitelist/snapshot has to be done (But how? And why should project B care about this?)

4. How to make this fair? Is it a fixed pool of project token B to distribute or is bound on migrated value? How long do we allow migration mining? Maximal duration is the minimum lock-up period. If we pay people calling migrate and pay them in project token B how do we adjust changing gas price?

Risk

• It opens up a liquidity war with project A (And ad lot of additional stress for ethereum)
• If successfull, other projects will make migration mining too and this time project B may lose liquidity
• How does-lock up work? This has to be implemented in project B and adds complexity and additional risk to the protocol.

Further thoughts

• If standard liquidity mining is done, an incentivize lock-up period may be a good idea anyway, if reward is adjusted accordingly!

• To do this right, it's a lot of work, needs audit and UX has to be slik!

  by martin krung 2020-08-23

Simple migration, as impemented by https://1inch.exchange

https://twitter.com/1inchExchange/status/1297182579829936128?s=20

Code here: https://github.com/CryptoManiacsZone/1inchProtocol/blob/feature/mooniswap-migration/contracts/OneSplitMooniswapMigration.sol

User story for simple migration

User visits migration page of target project B and will see a list of liquidity token he/she owns from project A. Now he/she selects one or several token and makes an approve tx to every liquidity token from A. Then he/she waits until migration is completed.

Under the hood

1. User approve liquidity token from A with one tx
2. Somebody calls migrate for the contract and pays for the gas
3. migrate:
   • withdraw liquidity from project A -> get liquidity from project A
   • supply liquidity to project B -> put liquidity to project B
   • send dust of unused liquidity back to owner