Proposal: Launch new liquidity mining programs for $OPIUM token

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

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.

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

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

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'
)

Math error here, closest to -10987 is -11000

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)

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 ?

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

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.

@Locutus can you please share a little more thoughts about “Olympus pro bonding” thing ? Just little explainer in short - what is so special in this approach ?
It will be much easier for other forum participants to better understand context… because its hardly the case that everyone would go further and google all the long details about Olympus )))
thank you!

ohh damn… it seems too complicated for me :woozy_face:, but any way , I pressed LIKE button :joy:))))

Discount bond.LP could sell their LP token to project for buying OPIUM with certain discount when it comes to maturity,Liquidity becomed PCV for opium protocol.

  1. The proposal consist of both Uni V3 and Bancor Liquidity Mining let’s just do both of them and users will decide their favorite method and desired risks. I’m personally FOR Uniswap just because it brings network effect and many tokens listed mainly on Uniswap perform much better
  2. Uniswap V3 allows you to control your impermanent loss
  3. Didn’t get what you mean about “free” liquidity
  4. Can you please elaborate on Olympus thing? Also very interested

Thanks!

Just released script that calculates Uniswap V3 rewards

Should be tuned a bit, and it’s ready to be used within Liquidity mining interface

Please review and contribute

Config:

  • fromBlock block from which rewards are calculated
  • toBlock block till which rewards are calculated
  • batchBlocks number of blocks for the batch rewards (ex. every 1000 blocks)
  • batchRewards number of $OPIUM tokens allocated to one batch

Flow:

  • Script iterates over all block batches and allocates rewards for each batch
  • Each batch is retreiving Uniswap V3 state from subgraph in provided block number
  • All Uniswap V3 positions that have liquidity including current tick are getting rewards in pro-rata basis based on their liquidity in current tick
  • If the positon holder happpens to be G-UNI DAI/OPIUM Pool, then rewards are distributed to all G-UNI holders in pro-rata basis based on their balance

Script is compatible with this UI

I read some analytic articles about Olympus Pro bonding,it seems like the bonding doesn’t work well in other projects,the reason for this is that OlympusDAO has a rebase mechanism while others don’t have

I’m not sure Uniswap V3 is eglible for most retail LPs to manage indeed,especially for LPs who provide low-marketcap token which may more eaiser to big pump and dump,If someone could give a scenario analysis on IL for those LPs on V3,it would be great for us to evalute the risk.
And let’s suppose we can launch V3 LM, the better choice is depositing LP to certain liquidity management protocol due to high gas cost on mainnet unless we could provide $opium on Arbitrum or Optisimism in the future.

There is an option to stake into G-UNI pool DAI/OPIUM it’s already available on Sorbet Finance

1 Like

Well, from all of the possibilities the Bancor is the best.As there is IL protection and as well we can vote for Bancor rewards on top of the pool. Its best solution by far - and is included in all market aggregators.

There is nothing to speculate about :slight_smile: as this is set and forget.

2 Likes