Multiple rewards Liquidity Mining

[swamp-thing-sovryn]

Multiple rewards Liquidity Mining

Goal

A new liquidity mining contract will be deployed that will let users to get multiple tokens in exchange of staking LP Tokens as opposed to the current version which only rewards SOV:

1. Different reward tokens can be configured by the contract administrator. Reward amiunt per block can be configured depending when doing so.
2. LP Pools can be configured with different allocation points, i.e. weight, and be associated to multiple reward tokens.
3. Users, by depositing LP tokens, will get as many different tokens based on the aforementioned quantities.

Implementation

Upgrading the original LiquidityMining.sol contract would have been extremely complex the storage layout would require lots of changes. In order to make users experience smoother and not to make them to actively move their funds to the new contract and pay for the migration trnasaction fees, the following plan is proposed:

1. Implement the new liquidity mining contract as a brand new deployment, named LiquidityMiningV2.
2. Replace LiquidityMining contract with a new version that contains a new set of capabilities:
   a. Allows admins to stop some operations (see 3)
   b. Exposes a new interface to extract some data from it's state
3. Stop rewarding users by invoking stopMining
4. Define a period where users can opt-out of this automatic migration. Deposits will be forbidden but the users will be able to claim the rewards or even withdraw all their funds if they consider so.
5. One that period has finished, the LiquidityMining.sol contract will be locked the users will not be able to neither withdraw or claim rewards.
6. The admin will invoke a function on LiquidityMiningV2 that will:
   a. Copy the original pools and rewards configurations into the new liquidity mining contract
   b. Move the remaining SOV and LP Tokens stored in LiquidityMiningV1
7. Update the GUI to let the users interact with the new contract

Deployment steps

1. Replace LiquidityMining implementation by LiquidityMiningV1
2. Deploy LiquidityMiningV2
3. Add LMV1toLMV2Migrator as LiquidityMiningV2 and LiquidityMiningV1 admin
4. Disable LiquidityMiningV1 deposits
5. Let the users migrate and then invoke the migration functions to copy data from the old contract and transfer funds

[swamp-thing-sovryn]

@py-ro we should add a check to prevent initialize to be called twice ... in the previous version this check was put in place

require(address(SOV) == address(0), "Already initialized");

[py-ro]

👍

[swamp-thing-sovryn]

this parameter is never used I guess ... let's double check just to be sure

[py-ro]

you are right, it is never used

[swamp-thing-sovryn]

The require introduces a harder contraint making the onlyBeforeMigrationGracePeriodFinished worthless ... as suggested by Haku we might create a new modifier onlyMigrationGracePerioidStarted that checks the same condition as the require

[py-ro]

👍

[tjcloa]

this could be useful in the future, hence leaving it open