Reward Miners, Liquidity Providers and Holders

Hi,
I found your project and really like it. While the gas fees are high and prevent me from providing more liquidity to the AMM, I made myself some thoughts, how to prevent people from dumping mining rewards and incentive them to provide liquidity to the the MCB/ETH pair on Uniswap. So here are my thoughts I would like to share:

  1. The mining rewards are calculated: %AMM x %Uniswap to AMM x Holding Factor
  2. There is just one mining pool and it’s the AMM
  3. People need to maintain the same percantage to the MCB/ETH liquidiy pool on Uniswap, as they provide to the AMM.
  4. If they provide less to Uniswap, they receive percentual less in the AMM. For example: Providing 80% of the AMM value to Uniswap, will make them only earn 80% on the AMM.
  5. Every mining round people keep their MCB or provide them to Uniswap make them go up in the “Holding Factor”. E.g. 5% per month, so one month of holding makes the factor 1,05 , two month 1,1 , three month 1,15 etc… holding less tokens on the wallet and/or Uniswap then mined makes the “Holding Factor” go to 1 again.

Greets

2 Likes

It is an interesting suggestion. We will make it discussed in the governance meeting.

Inspired by you, considering the engineering complexity, I suggest the following rules to encourage the farmers holding MCB or providing Uniswap MCB/ETH liquidity:

  1. Every liquidity farmers have a mining effective factor of 1 initially.
  2. If the farmer holds MCB directly in the wallet or indirectly in MCB/ETH pool, his mining effective increases. The maximum mining effective is M (e.g. 2)
  3. To achieve the maximum mining effective factor, the farmer needs to hold N-blocks (e.g. 30-days means 199384 blocks) mining rewards.

For example, the farmer could mine T MCBs every block if he holds no MCB. The mining effective factor F is as follows if he holds X MCBs (we can convert the MCB/ETH pool share into some relevant MCB).

F= 1 + Min(\frac{X}{ T * N},1)* M

I propose that this algorithm should be calculated from the new cycle and should not be retroactive

Cool I’m glad I could provide something :slight_smile: