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:
- Minimal cost for project B to get a lot of liquidity rewarded by project token B
- Lock-up migrated liquidity in project B for an extended time
- Have a clear target group with existing liquidity provider on project A
- Make migration more easy, because it only needs 1 tx (and no waiting time for get several tx to get mined)
- Allow small pool owner to migrate with minimal cost, because migrate is rewarded by project token B and payed by others.
- 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
- User approves liquidity token from A with one tx
- User set a lock-up period with another tx
- Somebody calls migrate for the contract and pays for the gas, (this person gets project token B for paying eth needed for the migration)
- 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
-
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
-
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!
-
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?)
-
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
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
- User approve liquidity token from A with one tx
- Somebody calls migrate for the contract and pays for the gas
- 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
