Final LP staking implementation

🗂 Proposals 📑 Formal Proposals
21

After reading some concerns here, I entirely agree we need to keep the medium and long-term in mind in any initiative the team proceeds with. We should be very careful of incentivising short term pumps or introducing bad (“whale”) actors. Of course, with any DeFi project the main attraction is economic incentive and gain.

Forgive my CeFi reference here, but in the wise words of a Goldman Sachs exec, it’s about being “long-term greedy”.

5 Likes
22

I also think that we shouldn’t use Gysr to a large extent due to the received by owning $GYSR next to some of the other concerns mentioned. Long-term holders of $IDLE should receive a boost in liquidity incentives not those of some other community/token in order to achieve the positive fly-wheel effect I pointed out when arguing for using a model similar to Curve. I think it is worth it to build the staking mechanisms in-house (probably based off a fork anyways) if that allows keeping incentives better aligned within the Idle community.

2 Likes
23

Something to consider, which ever solution we pick we yet have to deal with this, the 2/3 of the sushi reward can eventually not be claimed by contracts, it requires a proposal, sushiswap somewhat demands a plan on what happens to those sushi rewards and does not allow autoselling

regarding what felix said, i could imagine idle staking and our LP staking solution to be adjusted to a weight that gives a bonus just like on curve, it wouldn’t directly require lock up, but to get a higher bonus you’d have to stay longer

2 Likes
24

The problem that was brought up by @MRKWHG is also how to handle SUSHI rewards with pre cooked solutions like with gysr and the ampl model.

With standard solutions, the staking contract is the one who will receive rewards (if any, due to the limitation mentioned in the article) for all users, but there would be no way to redistribute those to the users directly. In the Ampl model there is a rescueFundsFromStakingPool which only the owner can call to retrieve those extra rewards, but then the community would need to decide at the end what to do with those rewards and if those needs to be redistributed a new solution/contract may be needed (I did a check in the Geyser.sol of GYSR but don’t see a rescue method).

This tweet was brought up in Discord always by @MRKWHG https://twitter.com/AmpleforthOrg/status/1353835004225155072 which outlines that there is a way of managing those rewards, so I contacted 0xMaki and he in turn proposed the use of Sushiswap Masterchef v2 contract for managing the staking and correctly distribute IDLE and redistribute SUSHI rewards.

This is the contract proposed sushiswap/MasterChefV2.sol at master ¡ sushiswap/sushiswap ¡ GitHub
I’m still looking into it if anyone else has some more info or comments would be great

2 Likes
25

After some discussions with Sushiswap Team it seems that Masterchef v2 contract is not suitable
for our use case, given that the rewards there are distributed proportionally and not with a
time weighted mechanism.

So given the newly brought up points I would say that the ampl model GitHub - ampleforth/token-geyser
could be the one suitable for our needs (here more info AMPL Talk — About the Geyser, FAQ section has
some good explanations and here there is some background on this model).
Contract code don’t need to be modified so it’s a matter of properly understanding and deciding these parameters (taken from here)

* @param maxUnlockSchedules Max number of unlock stages, to guard against hitting gas limit.
* @param startBonus_ Starting time bonus, BONUS_DECIMALS fixed point.
*                    e.g. 25% means user gets 25% of max distribution tokens.
* @param bonusPeriodSec_ Length of time for bonus to increase linearly to max.
* @param initialSharesPerToken Number of shares to mint per staking token on first stake.

and deploy the code. The missing piece would be the UI for interacting with it, but this can be done
quickly too given the limited number of interactions needed (here the ampl ui Ampleforth Liquidity Mining).

For the SUSHI rewards we can decide later what to do, those can either be redistributed at the end to the stakers like now or distributed only to the ones who kept the funds staked for the whole period or we can decide to keep them in the balance sheet of the treasury.

@Salome @emixprime @8bitporkchop @simoneconti @ETM612 or anyone else really, what’s your take on this?

3 Likes
26

william, that stuff sounds solid and i would go with the ampl model. Many thanks for your time.

We should just ignore the sushi rewards and put it into the treasury and maybe stake them in xsushi to earn more rewards on top. We can decide what to do with them on a later point when we have found suitable tokenomics.

Lets go! :rocket:

2 Likes
27

@william awesome, looks very solid to me.
Yes i’d be for doing that and then deciding how we deal with the sushi later/after. :blush:

1 Like
28

Let’s set up a new vote with the new options ASAP once the discussion has settled.

In my opinion we should decide already now what is gonna happen with the Sushi rewards, given the fact that if we only decide about this later/after the voting weight of a few LP whales can be even more disproportionate.

7 Likes
29

Agree with Salome, that we should decide upfront. The model AMPL geyser sounds like it meets our needs.

Specifically, I believe we should distribute the sushi rewards to the LP stakers who completed the ENTIRE PERIOD as an added time weighted incentive to encourage long term liquidity providers.

30

The new Snapshot have has been created, cast your vote now! Voting will end on 2021-04-12T16:00:00Z :rocket: :writing_hand:

3 Likes
31

Idle treasury could really use some of that SUSHI for diversification.

I’m not sure I follow the argument for deciding upfront on SUSHI rewards allocation. I understand the concern that LP program may create actors with concentrated voting power, but surely that concern will apply to all governance decisions, not only SUSHI distribution?

1 Like
32

Hi everyone - great discussion here. Responding to a few points that were brought up.

On the airdrop question, you are correct that there is no admin function in the current GYSR contract to withdraw arbitrary tokens. We have had discussions on the “right” way to handle those airdrops, and intend to support that case in the future.

Completely understand the competitive approach is not for every community. The non-competitive “Fountains” coming with GYSR v2 will provide a friendly alternative.

On the flip side, there are many pros to the “gamified” staking mechanics, such as increasing engagement and participation. It tends to appeal to more of the “power-user” persona.

It’s also worth noting that the Ampleforth contract is also competitive. It obviously does not include a GYSR spending multiplier, but the time bonus does pull from the larger pool in the same way.

And on the point of taking advantage of the GYSR multiplier, the v1 mechanics utilize a logarithmic curve to reduce the impact of big spenders. In v2, we are actually rolling out more efficiency improvements to improve “fairness” (though this is generally a hard question)

Just to clarify, there’s no additional reward for just “holding” GYSR token. It actually gets spent and becomes an income stream for the Geyser creator (which would be the pilot league multisig in this case)

6 Likes
33

The Temperature check is closed and the results shows that the community want to implement LP staking with the Ampleforth model . The extra SUSHI rewards will be kept in the balance sheet of the Idle treasury and staked to foster healthy long-term growth of the protocol. The Pilot League Committee can now move on with the IIP-6 on-chain implementation and LP staking will go in production next :rocket::fire:

image
image1440×709 83.8 KB

11 Likes