If the unclaimed were to be used in emission’s then it would be more deflationary to the supply compared to airdropping more. I like this idea.
Finally, we’ll soon remove the word Soon™️ and Imminent™️. haha
All fine with me.
I will continue to flog dead horse about emissions tail off.
Will they tail off at similar rate for $BADGER and $DIGG at similar rate? I would advise a function similar to $SNX where they drop a smooth 5% a week or something like that so there is no cliff and there is the several months time needed to get lending (of $CLAW?) against BTC pools in place.
Hope this happens Soon™️
This is also my biggest general concern. I know it was discussed in December, and IIRC the reply at the time was along the lines of “we can explore how to use the treasury to provide further incentives once we get beyond the initial liquidity mining period.” But now that we’re halfway through the initial 8 weeks, I’d prefer to see a gradual trail off exactly like you’re describing.
I do have one concern with this BIP others have mentioned - I simply don’t understand the need to incentivize SUSHI preferentially over the UNI pool. Eth_man and Piotr basically spelled out why. Don’t get me wrong, I like sushi, I just don’t see the logic behind skewing incentives so heavily there over UNI.
Everything else looks great though, and I echo that this is the standard to hold future BIPs to. Great work.
Thank you everyone for the kind words here and on Discord.
And thanks to all who participated in the voting.
I’m aiming to land at a model that implies no preferential treatment for Uniswap or Sushiswap LPs.
In my opinion, making distributions volume-based now would be favoring Uniswap because Uniswap had the head start in building liquidity => it makes sense to use it for trading => it has more volume.
Also, volume already manages itself. If the volume is higher on one DEX than on the other, LPs get more rewards there => more liquidity flows there without losing much as we adjust the rewards.
For part I/ Sushi LP should we factor in the Onsen xSushi rewards ( for as long as they are there)?
No, the plan is to not factor in the Onsen rewards. Uniswap LPs by design make more from fees, and Sushiswap compensates for that through Sushi emissions, decided by their governance.
Factoring them in would disincentivize Sushi governance in increasing emissions for the Badger pair.
So I prefer not to interfere with that process and let LPs decide what’s best for them.
the idea is not for all the pools to have the same APY. If that were the case, the liquidity for Badger-WBTC would be quite small.
With the numbers you’ve mentioned, if there were 1000 Badger pooled to staking, they would earn 60000 Badger per week.
If 1000 Badger were pooled to one of the LPs with the corresponding amount of WBTC, 1000 Badger would earn 40000 Badger.
Currently, ~1.72x more Badger is sitting in the Staking contract than in both (!) LPs.
By the way, the numbers on vfat.tools show slightly smaller APY for Sushi than it has been (based on 70000 instead of 80000 emissions)
I personally choose equalizing rewards per Badger/DIGG pooled per LP over equalizing liquidity on two DEXes.
As for Sushi rewards, at the current level of emissions they mostly compensate the fee cut on Sushi (LPs get 0.25% fees instead of 0.3% on Uniswap)
The 1.85/1.5/1.25 bonuses are mostly reference points. I assume that in one week the liquidity ratio, and thus the bonus will change. 1.85 looks a bit much to me too, hence the vote. But there is no ‘right’ number here, so it’s up to the governance to decide.
The end goal for me is to have the pro-rata model that treats LPs the same way on both DEXes, no matter which one dominates.
I plan to propose using unclaimed Badger emissions in the Part III: liquidity mining program extension.
We kind of have to use them to have somewhat balanced Badger/DIGG emissions.
Yeah, the current idea is to drop smoothly at around 10% weekly rate.
In terms of composition, I’m thinking of cutting Badger emissions at a higher rate, simply because we’ve already distributed most of the Badger liquidity mining supply.
Great thanks @Mr_Po Appreciate it
Thanks for the clarification points. Makes sense.
This and this ^ seems to be a vocal minority coming out to support the sushi pools where are the uniswap supporters ! With the current vote it’s going to remove the bonus for early liquidity providers who risked more getting in early and supporting the protocol, and are now having the reward and the incentive for remaining in the uni pool removed…
I pretty much agree. I mean while there were choices initially I went with Uniswap wBTC/Badger just because my expectation was this would be the pair to support LP wise simply due to volume considerations. And because of this it would offer the best hope for Badger price support through wBTC LP.
I think the whole rewards sliding in the sushiswap direction is not really sending me a great message here. I also have real mixed feelings about spreading LP rewards across multiple contracts as all this does is dilute potential liquidity. I know there are people who are very vocal about sushiswap - great but don’t forget us die hard uniswap supporters. We are here, and have been here on uniswap for a very long time (since v1 btw) and are not going away.
I mean if this is what Badger sees for the DIGG future why then even offer a Uniswap wBTC/DIGG if the sushiswap wBTC/DIGG is going to get preferential rewards treatment? Pool your liquidity in one spot to consolidate volume and reduce slippage for traders and get the best chance at LP based price support for DIGG vs. wBTC as well.
But perhaps I misunderstand the reasoning or execution here.
You’re making logical sense, but limiting to one pool isn’t what the market will want. Having two pools, equal, gives people some choice. You don’t want to tell people that the only way they can do what they want is with one pool, that is also a turnoff.
Great proposal, thanks for your work.
I’m hearing from team members in the discord that there is a problem with the Uniswap LP. The exact message is here: “it’s an arbitrage bug, hard to explain. Essentially the pools are not kept in sync, and the routing on the uniswap frontend encourages trading in lower liquidity pools. There is not a way to switch currently without losing multiplier.” If this is the case, and this proposal is designed to encourage Sushiswap LPing, then I second this position (why even offer Uni LP for DIGG). Unless there is a way to prove providing liquidity for DIGG on Uni won’t have the same bug/won’t be slowly un-incentivized by the team, then we shouldn’t have this pool.
Lower liquidity pools always have this issue. I have already seen it with respect to Honeyswap and Main net so I am not surprise that sushiswap is seeing some arb between Uniswap LP’s. This is exactly a reason to consolidate liquidity somewhere.
If the above is true (I consider this rumor) a statement should be made defining the ‘observation’. Why this is a ‘problem’ and what are ‘possible’ solutions. I have not even heard of this until now even though I would have expected is based on what I see generally. This was also true of low liquidity pairs between Uniswap v1 and v2. Pool prices by definition are synchronized pretty much by arb traders. This is also true of exchanges generally.
what r u guys doing? R we just a discussion project?
all good except i feel like the incentives that are gotten out of lps on uni and sushi are not being taken into account. sushi already has its own incentives, incentivizing lps to provide there instead of uniswap. why do we need to reward them further? i just may have to take everything and switch pools
I agree with this. LP distribution between Uni and Sushi should be based on the trading volume of each market.
I’m a Uni LP provider and have been from the start and now feel like I’m getting shafted to be honest
exactly, but then we’d lose the multipliers we have earned in the Uni pool as well
Absolutely agree, well said. I’ve been a Uni LP from the start too and feel like we’re getting shafted