Proposal/Voting Matter for Discussion: Move the current Uni V2 MC/ETH pool to a managed Uni V3 pool
Hello, everyone! My name is Ben, and I work with ICHI, a Uni V3 liquidity management protocol. I would love to hear everyone’s thoughts on the idea below, as I believe it can strengthen the MC token and the mission to revolutionize gaming.
Motivation
There has been ~$30M deposited as staked liquidity for the MC token, according to https://staking.meritcircle.io/. These represent tokens are deposited to Uni V2 and locked for several months, where the estimated APY is ~220%. Unfortunately, most of the APY associated with this staking mechanism is due to MC token rewards directly allocated from the DAO, as stated in MIP 19. This MC token rewards system creates token inflation as the token is distributed into the open market. What if there was a way for the liquidity to earn yield, and provide an APY to LPs/Stakers without the need for added token rewards or a lockup period?
Idea
ICHI has built one of the best designs in the space for providing concentrated liquidity for any asset. ICHI’s Vaults have returned 25+% internal rate of return on dozens of assets, without the need for added token rewards.
By using ICHI on top of Uni V3, token depositors can earn more yield from trading fees without having to manage their positions. By having a profitable liquidity strategy in place, there will be no need to require a token staking lockup, and the DAO can allocate less tokens toward rewards; making the MC token stronger.
To better explain the idea, I have also answered the questions from the discussion on April 25th with this approach in mind. Discussion: Staking v2
Would you like to see a single-sided MC staking pool next to the LP pool?
ICHI only allows for single-asset deposits. This means that by using ICHI’s Vaults on a Uni V3 pool, users only deposit $MC. There is no need to go buy another asset to provide liquidity.
What asset would you prefer as an LP pairing asset next to MC; ETH, WBTC, USDC or something else?
Any ERC-20 token can be a paired asset.
What weights should the LP pool have?
ICHI manages LP positions, so there is no need to manage them yourselves. It’s a deposit-and-forget experience. ICHI makes it so that the positions concentrate and rebalance to optimize trading fees and mitigate impermanent loss. It is most optimal to keep each Uni V3 pool at ~80% deposit asset (such as $MC) and ~20% paired asset (such as USDC, ETH, etc). ICHI manages this for you.
What is the preferred platform for LP tokens? (currently uniswap v2 50/50 LP tokens)
Uniswap V3, depositors can earn more fees per $1 deposited due to concentrated liquidity.
How long would you want the locking periods to be?
No need for a locking period because the liquidity is already profitable. Trading fees are auto-compounded back into the depositor positions so that users can withdraw their liquidity + trading fees at any time.
Should the staking subsidy be fixed or partly variable?
Also, no $MC rewards are needed for the positions to earn yield unless the DAO wanted to supercharge the APY 
What % of DAO revenue should go to staking rewards? (currently everything used to build treasury, re-invest and buy back and burn $MC)
Because the positions earn without rewards, the revenue does not need to be given to staking rewards.
Should the DAO, outside of locked MC, also distribute ETH, WTBC or USDC from revenue to stakers with longer locks?
The DAO shouldn’t need to spend $MC to acquire other assets. This creates sell pressure on the $MC token. If using this new system, it good be a good idea for the DAO could distribute managed Vault LP tokens if they wanted.
How long should staking rewards be locked for?
No need to lock liquidity!
Should the DAO create mechanisms by which it builds long-term protocol owned liquidity?
By using this system, the DAO can use its $MC tokens to earn yield and grow its treasury. This will build long-term protocol-owned liquidity. All Vaults are self-custodial, meaning that users own a fungible LP token (that they own) representing their pool position.
