Final LP staking implementation

đź—‚ Proposals đź“‘ Formal Proposals
1

Since the community opted for a fairly standard LP staking program the Pilot League Committee decided that it can proceed with the implementation internally, without the need to set up a grant.

To gather all necessary information and make the process as smooth as possible the Pilot League Committee and the GYSR devs (@devin) had a conference call on the 31st of March.

After the group call, the goal now is to have all technical details sorted out by the end of the week and start implementation soon after. The lead developer for this internal implementation will be Pilot League Supervisor @8bitporkchop.

The Pilot League presents here the focal points of the GYSR implementation and, after a few days of discussion, the Committee plans to set up an off-chain snapvote to confirm the community decision.

Following the initial discussion (here), the community will be required to vote if the Pilot League Committee should:

  • Proceed immediately with implementation using GYSR v1 protocol and then switch to v2 once it’s live and tested,
  • wait for v2 (which will be available in around 2 months)
  • or even build a LP staking implementation from scratch.

At this point, no final decision has been made and all three options are possible.

To help the IDLE community make an informed decision in case they choose to use the GYSR protocol, below are the key points from the group call between the Pilot League Committee and the GYSR developers:

  1. In GYSRs V1, the $GYSR token acts as a multiplier during unstake events. Currently, V1 does not allow to disable the $GYSR multiplier feature. This could lead to a scenario where a user with large amounts of $GYSR can potentially take advantage of this mechanic and receive additional rewards in return. Since rewards are received from a shared pool, their gain would reduce the portion of rewards earned by other users. This kind of competitive environment for LPs is not ideal for the Idle ecosystem and the Pilot League is wary about the sustainability of this current model. Here are the details from GYSR whitepaper regarding how the multiplier is calculated.

  2. An implementation with GYSR will generate a new revenue stream for IDLE because $GYSR tokens spent by LPs will be earned by the deployer of the GYSR contracts (Governance/League).

  3. A migration from V1 to V2 is planned for mid-May but a more conservative timeline deployment for V2 can be 3 months from now. With this in mind, the Pilot League Committee proposes to set up a 3-month launch program in V1, and after deploying new contracts when V2 goes into production mode. Although migration from V1 to V2 is not mandatory, it’s highly recommended for Idle. Everything from V1 will continue to fully function, and also benefit from the webapp upgrade.

  4. Currently, v1 was audited by a minor auditing firm, while v2 will be audited by a top-tier auditing firm.

  5. Also, V2 will enable a competitive environment same as in V1, but it’s also possible to set up a more fair reward model. In V2 $GYSR will not compete for funds with other LPs, they are working on side use cases.

  6. Since in phase 2 of the LP staking programme Idle will be using V2, LPs will be required to “unstake” from V1 and “stake” again on V2. Therefore idle liquidity providers are economically affected and have to be aware of these constraints and know that they will have to manually adjust to the upgrade.

  7. Both in V1 and V2, it’s possible to send the funds only from the same address that deploys the LP staking contract. As the parameters might be adjusted during the program, the Pilot League proposes to transfer the final ownership approach after the deployment.

  8. The LP staking program would be split into 2 phases instead of setting up the whole reward pot of ~180k $IDLE. Management through the League is sustainable, as the subDAO would manage ~90k $IDLE per period.

The Pilot League Committee is looking forward to listening to the feedback from the community in order to start the implementation :nerd_face::rocket:.

8 Likes
2

Hi @Salome

Great to see this moving forward and I know that many in the community are keen to see this move quickly to address the pretty dire liquidity situation.

I’d like to hear from @devin if possible to better understand how much GYSR Liquidity Providers would need to hold to maximise the yield

  1. An implementation with GYSR will generate a new revenue stream for IDLE because $GYSR tokens spent by LPs will be earned by the deployer of the GYSR contracts (Governance/League).

As per the above excerpt it’s good to see that the model will generate additional revenue to the protocol.

I definitely think we cannot wait for months to implement, so I’m favouring the GYSR model that can be implemented soon, then improved with v2.

Very pleased to see @8bitporkchop leading the implementation :muscle:

4 Likes
3

Agree with this… Speed to market makes more sense I think

3 Likes
4

Yet another thing which discourages participation. Those with large number of assets will be fine. Small holders are priced out, for at least 3 months while the reward pot is dished out.

I would rather wait.

3 Likes
5

Hey @Coinballers,

When you un-stake from the Geyser contract, you can optionally spend some $GYSR to boost your reward. There are two important factors that come into play for this (Which the GYSR team could confirm).

  1. R = Proportion of total distributed reward tokens that have had $GYSR applied
  2. X = Number of $GYSR applied to an unstake operation

(Extract from the whitepaper. Section 7.3 FYI)

Screen Shot 2021-04-03 at 9.19.30 am
Screen Shot 2021-04-03 at 9.19.30 am740Ă—144 6.16 KB

The boost is logarithmic so if the proportion of distributed rewards (R) = 0.

Due to the way the contract was designed, the minimum $GYSR which can be used for the multiplier is 1

  • 0 $GYSR → 1x boost
  • 1 $GYSR → ~3x boost
  • 10 $GYSR → ~4x boost
  • 1000 $GYSR → ~6x boost

As more boosted rewards are claimed, the boosted reward gets scaled-down, which introduces the competitive environment raised in point 1 for stakers to claim their reward early.

For this reason, I think it’s important to choose a thoroughly considered Time Weighted Bonus for V1. I will run through some scenarios using a 3-month funding schedule.

  • If the time bonus is set to 3 months, then we have a situation where stakers are incentivised to wait with their stake until the very end of the program, then unstake at the very last instant of the schedule with $GYSR to maximise their boost. However, this introduces a race condition because the first person to unstake can claim a larger portion of the rewards than the second all things being equal.
  • If the time bonus is set to 2 months, the maximum boost occurs before the program ends, so early stakers can claim a maximum time bonus at 2 months using GYSR, and have an opportunity to restake for an extra month, with a lower boosted reward at the end of the schedule even using GYSR (due to the time bonus)
  • If the time bonus is set to 1 month stakers have three opportunities to claim with the maximum time bonus using GYSR, however, each subsequent opportunity would yield slightly smaller rewards due to the scaling mechanism.

I think the criticism with the 3 month bonus is the fact that it introduces a race condition at the end, where a significant amount of the rewards could be distributed to a few well-timed whales.

The 2 month Incentivises the use of GYSR before the end of the program, so there isn’t as much of a race condition at the end of the schedule, and is fairer to stakers who join the program up to one month after the start date.

The 1 month time bonus means more opportunity for stakers, and rewards early participation, however would mean stakers will need to spend more on gas costs. Additionally, 1 month seems to be a short duration for stakers to show a commitment.

Personally, for me it’s a choice between 2 months, and 1 month time bonus with a slight preference for 2 months. Would be interested in some other opinions.

7 Likes
6

2 months is my favourite option

5 Likes
7

Perfect, great explanation @8bitporkchop

As per @unicorn i think the 2 month option sounds like it will be a good balance between the options.

5 Likes
8

Our position is to go live now with GYSR v1 and then switch to v2.

A Staker is now aware of the potential risks with v1 and he has all the elements to take his decision. Regarding Time Bonus I agree with @8bitporkchop the 2 months is the fairest one.

We all know that time in crypto everything is super fast when it comes to issuing a token but times are dilated when it comes to roadmaps therefore I would not tie our decisions to a “delivery” of another protocol.

6 Likes
9

Well said on the GYSR multiplier. The optimal amount to spend depends on the size of the user’s stake and also the usage ratio.

Also a good analysis on the comparison of different time bonus periods. We generally recommend a time bonus period that is shorter than the funding schedule. As you mentioned, this allows more opportunities for the end user, and reduces the competition at the end of the funding schedule

This article on mechanics describes the different bonuses along with various strategies the end user might consider

7 Likes
10

Time to cast your vote (here) on the last snapvote before the on-chain IIP proposal :rocket: :money_with_wings:

7 Likes
11

At the current rate, it looks quite clear that the community is keen to move forward with GYSR v1 for the initial staking implementation. The diagram below illustrates this process.

stakingdiagram

The steps are as follows

  1. An EOA will create the geyser contract through the GYSR UI, using sushiswap LP token as the staking token, $IDLE as the reward token, and a 2-month bonus length period, and maximum time bonus multiplier or 2x.
  2. The ownership of the geyser contract will be transferred to the pilot league multisig
  3. [IIP-6] will go live to withdraw 180K $IDLE to fund the staking program
  4. Once [IIP-6] is executed the pilot league will fund 90K $IDLE to the geyser for a 3-month funding schedule. *
  5. The ETH (for deployment) and grant fees will then be transferred to the EOA from the multisig.
  • At this point stakers can deposit their stake to earn staking rewards. $GYSR can be used to boost rewards, and all earned $GYSR can be claimed by the pilot league multisig at any point in time.
2 Likes
12

Great to see us getting ahead of the game and ready for implementation @8bitporkchop

It would be fantastic to have this ready to go, given that it seems inevitable that the community is unanimously in favour of the proposal.

I’d like to see the LP staking program live ASAP.

Great work

2 Likes
13

After reviewing the comments and having discussions with community members, I am of the position more discussion is needed.

This doesn’t mean we eliminate any option, just discuss the pros, cons, externalities and risks of each option in more depth with additional opinions from key members of the community. On that note, I’d like to hear from @william on this as well as @Teo.

There are a few concerns I have with the GYSR implementation, one of the largest being the following:

The use of GYSR v1 introduces another system’s smart contract risk, an external token, and potential economic attack vectors to $IDLE distribution for LPs. Further, it involves additional risk relying on the execution of another team and new contracts (product delivery risk, new smart contract risk).

We need to delve deeper into these risks and even look at other options (for example, building an implementation leveraging another protocol’s staking contracts we adapt) before an IIP.

7 Likes
14

I agree and i’d like to discuss this a bit further, what is the direct point of a complicated solution like gysr? We could instead clone a reward structure like ampleforth’s geyser, which solves the same issue without external requirement to get ones Idle rewards, and it could still go live fairly quick, i fail to see how putting our LP’s hostage for other tokens is beneficial.

3 Likes
15

Hello lovely people of IDLE,

im new here and i have very limited knowledge about this protocol and this staking implementation but i would like to share my limited thoughts cause i have a really hard time to understand that mechanism behind that:

We had a short discussion in the gov channel on discord and now i wanna start with the basics of this system:
We implement this, very complex system, to get a multiplayer up and boost the yield for people who stake longer than others. To boost the yield we need this gysr tokens. And that people can buy this token to boost the yield you need liquidity. To get liquidity to the gysr tokens we need to pay LP rewards and increase the inflation of idle. And sorry, i dont see any benefit in that for the protocol. This system is much to complicated and bears additional smart contract risks etc.

Can someone explain me the benefit to the protocol please cause im too stupid to understand them.

Am i allowed to suggest a completely different token model i always recommend when i join a community? Cause it is really simple and understandable:

xIdle - like xSushi, xCover, xRuler, you stake your idle into a contract, the contract rebuys idle on the market if if you unstake your xIdle, you get more idle then when you went into the pool.

The advantages? Cashflow, you still can vote and you can use it as collateral or different other things. On top of that you can do something really awesome (CVP - Powerpool is doing that). You get a reward multiplayer! If you lp with 10k in the idle/eth pool you need as example 1k dollar locked into the xidle pool to get more rewards.

And in my opition, just release a completely normal rewards system and if you wish, just add a timelock on the rewards (XTK is doing that, you can claim the rewards, but it will take 6 weeks until they appear in your wallet - another example is CVP again, they have a vesting time of 10 weeks where your earned rewards will be vested over a period of 10 weeks time).

Thanks for reading this, i hope i can help and i really hope we find a very easy solution to this. Im just writing this at my day job, sorry for all typos and grammatical errors.

4 Likes
16

Thanks for sharing your opinion, it’s true that this model is adding some systemic risk, tied to the GYSR economic model and the associated smart contract risk and I have some concerns too on this side. On the other side this would allow us to start and iterate quickly.

I’m a bit concerned in allocating 1000 IDLE/day on the v1 directly, I think a solution could be to distribute 500 IDLE/day until we use gysr v1 and then move to 1000/day with either gysr v2 or another model (eg directly clone the AMPL one as suggested by @MRKWHG).

I think a couple of more days for the discussion are needed

2 Likes
17

The community decided to implement plain IDLE staking (no LP staking) after the LP staking implementation is done

18

Looks like the discussion got heated up again, and there are quite a lot of concerns regarding GYSR v1 multiplier effect and complexity of the implementation – I would advise anyone to take a couple of days more to discuss those points

My take on this is that I see the urgency from our community to spin off an LP Staking program and increase secondary market liquidity, but I’m wary of a staking system that could create imbalance and race conditions for LPs.

9 Likes
19

That’s why i would propose the structure of ampl’s geyser, it prevents trying to game it in any way, and increases the likelihood that rewards can compensate for IL even if the price rises a lot. It disincentivizes panic, and it could be thought about that weight being factored in with Idle staking and overall Idle return on stables later eventually.

And i know sushi rewards are nice and so on, but looking more forward, what does the community think about kyber’s new DMM? its more capital efficient, and kyber is migrating to a new token to incentivize liquidity economically, could be a nice addition.

2 Likes
20

Just start a normal lp reward programm like everyone else for the short term and if you have a good solution we can always change that. But this system is too complex and has 0 benefit to the protocol.

I just need someone telling me 1 reason why its a good idea to implement a token for a reward boost which needs a rewards boost so in can boost rewards?

If you dont have any, stop this idea and lets go back to basics. Normal LP rewards and if you wanna prevent the selling pressure put a timelock of 6 weeks on top of the rewards. And then we should define tokenomics, the value to hold the idle token and then we can talk about token distribution.
We can also head to a CRV style where you look up your idle to have veidle or xidle with a timelook and boost your rewards. But i think a own token for that stuff is completely useless.

3 Likes