Proposal: Launch new liquidity mining programs for $OPIUM token

Governance
1

Summary

Launch new liquidity mining programs for $OPIUM on Uniswap V3, Bancor and Balancer

Rationale

Following the discussion proposed by @alirun in June I want to create a proposal to launch new liquidity mining programs with description of benefits of all the programs

Uniswap V3

Uniswap V3 shows the biggest trading volume on the market and can bring a huge impact on $OPIUM trading volumes through direct and routed (arbitrage) trades.

As @Caesar and @andrey mentioned, pair with stablecoin would bring some benefits such as less correlation with ETH and USDC has less fear of systemic risk than USDT.

Thus I propose to create and support OPIUM/USDC pair on Uniswap V3 with liquidity mining rewards.

Provisioning of the liquidity on Uniswap V3 is harder than Uniswap V2, because it requires periodical rebalancing of the concentrated liquidity towards the current price, thus I propose to create recently launched G-UNI Pool by Gelato Network.

Enter G-UNI, an automated liquidity provision ERC-20 for Uniswap v3, powered by Gelato. G-UNI combines the capital efficiency of Uniswap v3 with the simple user experience of Uniswap v2 by enabling users to simply deposit their funds in a G-UNI ERC-20 that manages their liquidity on Uniswap v3 automatically on their behalf.

Read more about G-UNI here

zerion.io and sorbet.finance provide a nice interface for G-UNI pools which will smooth liquidity provision user experience.

The proposal is to allocate 60’000 $OPIUM/month

The length of the program could initially be 3 months, during which additional governance proposal might adjust rewards according to the result of the program. The program might be prolonged for longer period if agreed by the community.

Balancer

Weighted (uneven) pools on Balancer allow liqudity providers to keep the exposure of their liquidity close to the exposure of simpply holding the token itself with additional benefit of receiving trading fees.

Also liquidity providers suffer from smaller Impermanent loss comparing to “Uniswap V2 style” even (50/50) pools.

Read more here about weighted pools and their benefits.

Possible pool weights:

  • 80/20
  • 90/10
  • 95/5

Possible pairs:

  • OPIUM/USDC
  • OPIUM/ETH

The proposal is to allocate 25’000 $OPIUM/month

The length of the program could initially be 3 months, during which additional governance proposal might adjust rewards according to the result of the program. The program might be prolonged for longer period if agreed by the community.

Bancor

As it was already mentioned, Bancor allows $OPIUM holders to have the following advantages:

  • Provide single-sided liquidity with $OPIUM token. Up to 150k BNT will be provided by Bancor protocol.
  • Eligibility to Impermanent loss protection (subject to minimum 100 days holding requirement of Bancor)

As Bancor pool is a very attractive way to provide liquidity, running a liquidity mining program on it will increase its total liquidity. Currently, the pool already has 1M$ of total liquidity.

Bigger liquidity, volumes and trading fees might as well encourage the Bancor DAO community to implement a liquidity mining program from their side.

The proposal is to allocate 25’000 $OPIUM/month without any risk of impermanent loss (subject to minimum 100 days holding requirement of Bancor).

The length of the program could initially be 3 months, during which additional governance proposal might adjust rewards according to the result of the program. The program might be prolonged for a longer period if agreed by the community.

Terms

TBD in forum discussion

5 Likes
2

60,0000 ?
its a typo ? does you mean 60k $Opium ?

3

Right, should be 60k $Opium.

4

Uniswap 3 + G-UNI :
In general I like the idea.
But, the process looks tricky. In which range we should incentivize LP’s ? And how we can separate those who provide liquidity in that range ? (I am not sure, does G-UNI approach solve this task may be ? )

Bancor:
I am in! :slight_smile:

Balancer:
dont get the idea. Why we want to be presented in their pools? 1inch+UNI+Bancor not enough ?
May be there is some hided meanings behind of this ?

And little more…
How about other networks?
I am active BSC user and I struggle to trade $OPIUM on BSC network. just take a look on this joke:

image
image468Ă—522 31.9 KB

Personally I want more liquidity on L2 :slight_smile: may be lets try to fix this instead of Balancer ?

5

There should definitely be another AMM pool for Opium, so thank you @tsudmi for these proposals!

All 3 proposed AMMs seem good to me, each having some advantage. However I would say that I am not a fan of putting another smart contract in between us and the chosen AMM, like G-UNI. The reason being that every extra smart contract is an extra risk, greater complexity adds greater risk.

So I’d prefer simpler solutions, and just pick an AMM for liquidity mining. If people want to use another tool to manage their liquidity position that tool should also be responsible for claiming any liquidity reward and distribute it (or do whatever they agree to do).

The second point I would raise, is that I think I prefer a pool between assets that usually move together in pricing. Pools with a stablecoin on one side tend to cause more impermanent loss. At least in my experience. From a liquidity provider’s point of view, I would therefore prefer an OPIUM/ETH pool.

If we do go for a stablecoin, I concur with the preference for USDC or DAI over USDT.

1 Like
6

Support launching LM on Bancor, we need bootstrap more OPIUM liquidity to get more users involved in this project at a early stage

7

I’m already on the Bancor pool so I’m a fan on the idea. The problem of ETH gas fees now should not be ignored. Right now, removing my Bancor liquidity would cost me at most $128, or about 60 $Opium, and today its not even a bad day.

Perhaps implementing the Balancer pool on Polygon could be an attractive alternative to get new investors. Not just because of the lower fees but also the possibility of extra rewards. The Balancer team seems pretty open to contribute with new pools on the platform too, as are the Polygon devs. For example: an initial Balancer pool for the QiDao project, BAL/QI/WMATIC/MAI/USDC, included rewards in Qi (from QiDao), BAL (from Balancer) and MATIC (from Polygon). Perhaps chatting with them could result on a pool that provides more rewards than just $Opium. A multi-coin pool like OPIUM/BAL/WETH, that pays both $opium and $bal, for example.

1 Like
8

Hi there! Kassandra from Gelato Network here, just want to chime in about G-UNI

In which range we should incentivize LP’s ? And how we can separate those who provide liquidity in that range ? (I am not sure, does G-UNI approach solve this task may be ? )

yes G-UNI approach sets up a single “public” or “shared” Uniswap V3 position. So anyone can add liquidity into this position and receives (fungible, erc20) G-UNI tokens, which represents the proportion of this shared position they own. So in that way the only LPs who receive the LM benefits (by staking their G-UNI) are the ones providing liquidity in the target range.

There is a privileged “manager” role which is the only account with the ability to adjust the range and concentration of all the liquidity in the position. This is probably important if the initial range has tight concentration and the pair includes volatile assets (much higher chance of going completely out of range), which $OPIUM is. This manager role could be a multisig, a dao/governance contract, or even some predefined on-chain strategy for when and what kinds of rebalances are permitted. So far, projects using G-UNI for LM have mostly opted for a simple multisig, where the signers are essentially trusted to only adjust the range in a sensible fashion and with community support / oversight. The wider you set the range, the less relevant this manager role is (you won’t need to rebalance as often or maybe ever in order to stay in range) but of course the trade-off for lower concentration is potentially less fee capture by this position. The manager role can also be completely burned and this fixes the range of the G-UNI position forever but also removes any trust in a “manager” role. (This works well for e.g. stablecoin pairs like our DAI/USDC G-UNI that was just onboarded as a MakerDAO collateral type, but probably not as suitable for volatile assets unless the range is very wide, almost like V2).

1 Like
9

Yes ottodv… I am not very fan of excessive layers of “smart” logic around my beloved assets )))
but as I mention in my first message - uni v3 complicated pools allows anyone participate LM program without risking IL at all thus not providing any meaningful value to the liquidity mining program… because for example - I can put my liquidity in some crazy ranges… which not realistically be achieved by the market. So we have to find a way how to separate these players from Opium LM incentive.
And, as @kassandra mention on her reply - it seems this is exactly what G-UNI approach can solve for us potentially.

10

Pretty sure only the active range would be incentivized by this LM program (as other projects do).

1 Like
11

That is for sure, but G-UNI tokens are now being used as collateral in MakerDAO to mint DAI, which I think gives a sufficient trust and security level for Opium LM programs

I would love to move forward the idea of G-UNI pool and see how it goes

12

As I said above:

“If people want to use another tool to manage their liquidity position that tool should also be responsible for claiming any liquidity reward and distribute it (or do whatever they agree to do).”

I have nothing against people wishing to use G-UNI or any other tool to manage their liquidity.

FORCING everyone to use the same tool however is another matter.

13

Make sense

Well let’s calculate rewards based on all positions and then all the rewards that will end up on G-UNI pool will be reallocated to the holders of G-UNI shares according to the amount and time of their holdings

Rewards may be fairly calculated based on the amount of liquidity provided on the current tick (current price)

There is also an option to calculate rewards based on the liquidity around the current tick, for example <price - 20%; price + 20%>

But the first option seems more fair to me

1 Like
14

Regarding the deployment

Considering the proposal to use DAI, let’s do the following:

  1. deploy Uniswap V3 pool
  2. deploy G-UNI pool

Uniswap

Pair: DAI/OPIUM
Fee: 1%

Call UniswapV3Factory at 0x1F98431c8aD98523631AE4a59f267346ea31F984

UniswapV3Factory.createPool(
  0x6b175474e89094c44da98b954eedeac495271d0f, // DAI
  0x888888888889c00c67689029d7856aac1065ec11, // OPIUM
  10000 // 1% fee
)

G-UNI

Initial liquidity range:

  • From: 1 OPIUM = 1.5 DAI
  • To: 1 OPIUM = 3 DAI

Which is:

  • From: 1 DAI = 0.33333 OPIUM
  • To: 1 DAI = 0.666666 OPIUM

Since the DAI token address < OPIUM token address, then ticks are calculated from DAI/OPIUM price

Uniswap V3 tick formula:

p = price
tick = log(sqrt(p)) / log(sqrt(1.0001))
---
pLow = 0.333333
tickLow = -10987
---
pUp = 0.666666
tickUp = -4055

Uniswap V3 tickSpacing for 1% fee is 200, so tickLow and tickUp must be adjusted to the number divisible by 200

tickLow = -10000
tickUp = -4000

Call G-UNI Factory at 0xEA1aFf9dbFfD1580F6b81A3ad3589E66652dB7D9

GUniFactory.createPool(
  0x6b175474e89094c44da98b954eedeac495271d0f, // DAI
  0x888888888889c00c67689029d7856aac1065ec11, // OPIUM
  10000, // 1% fee
  0, // Manager Fee
  -10000, // lowerTick
  -4000 // upperTick
)

Since the DAO is the caller of the G-UNI creation it will become a manager of the pool which will be possible to further govern via proposals

If you all guys agree I will perform couple of tests and can create a vote with the aforementioned commands for execution

15

I forgot to add another step:

  1. initialization of the Uniswap pool

Initialization
In order to be able to provide liquidity to Uniswap V3 pool it must be initialized with initial price called sqrtPriceX96

p = price
sqrtPriceX96 = sqrt(p) * 2^96
---
p = 0.4672897196 // 2.14 OPIUM/DAI
sqrtPriceX96 = 54159257000000000000000000000

Call UniswapV3Pool at deployed address

UniswapV3Pool.initialize(
  '54159257000000000000000000000'
)
16

Math error here, closest to -10987 is -11000

17

Thank you for that.

Created a vote already to deploy Uniswap V3 and G-UNI pools as described

https://signal.opium.network/#/proposal/Qma4w8cFZExGtvbV8mu8vce84j5KSvbHS8YPfzECCKKjQt

I also thought that 1.5 - 3.0 range is may be small, especially the upside. So I changed price range to

Initial liquidity range:

  • From: 1 OPIUM = 1.5 DAI
  • To: 1 OPIUM = 3.5 DAI

Which is:

  • From: 1 DAI = 0.2857142857 OPIUM
  • To: 1 DAI = 0.666666 OPIUM
p = price
tick = log(sqrt(p)) / log(sqrt(1.0001))
---
pLow = 0.2857142857
tickLow = -12600 (closest to -12528)
---
pUp = 0.666666
tickUp = -4000 (closest to -4055)
18

o wow… 3.5 DAI ? really?
How often we can change that parameter then ?
To be honest, I prefer more optimistic scenario lol :slight_smile: may be 1-6 at least
So, why you propose 3.5 as a ceil ? may be I dont know some fundamental nuances which telling you that there is liiitle chances to go above 3.5 in near perspective ?

19

Just released 2 subgraphs:

  • More efficient Uniswap V3 pools and positions state tracking based on code developed by @tsudmi at StakeWise
  • G-UNI pool state tracking

Might be interesting for you

1 Like
20

I am pretty much against using uni v3 as main liquidity - there are 2 things why

  1. stakers are not protected from IL

  2. We are paying for liquidity that could be almost free

Bancor fixes both things and offers set and forget solution. Only thing why would i prefer using uni - but v2 before bancor is if you would want to integrate Olympus pro bonding.