Final discussion for the LP staking implementation for IDLE

Hey @unicorn, I think that there are some misunderstandings and I would like to clear such points :slight_smile:

The scope of my reply is only one question: “will the community and the Idle protocol benefit from these parameters, or is there a risk of missing the main goals?”

I do not see how I argued in defense of such players. I did the opposite, acknowledging the mission of “rewarding long-term liquidity providers”. We are saying the same thing in this sentence!

I focused my observations exclusively on 80-100% fee scenarios, where potential drawbacks might be more evident (as it’s part of the available options). My aim was only to understand the benefit of this decision, and get confirmations from the community that this would not represent a barrier to increase liquidity.

I would argue this would be the opposite, and my goal during the above conversation was to let anyone join the program and increase liquidity. I am not sure how a higher penalty would translate into broader participation, as potentially only whales can afford this risk.

Starting from the fact that seed investors have a 2-year locking (with 20% cliff on 26th May) and won’t be able to be LPs until that date, can you please better explain how slashing % of rewards would favor “little guys”?

By incentivizing LP staking, the Idle community is potentially reducing the number of $IDLE governance tokens available for voting purposes.

This is fine because liquidity growth is an important goal. LPs are mainly sophisticated users, and also active participants in the governance. However, if the voting threshold is never met due to $IDLE scarcity, governance decisions and protocol updates won’t be possible.

If LPs have too strict penalties to move in/out to vote, the governance process would suffer.

5 Likes

@unicorn – thanks for your feedback and your support has always been appreciated since our early days.

I’ve been following this thread from the sidelines as I was proud to see our community modeling the program out and wanted to have this initiative mainly community-led. However, I’d now chime in here to point out a couple of things.

I’m pretty sure you and @Davide had a misunderstanding on a couple of things, but it seems to me you’re both trying to incentivize long-term LPs/users.

As overstressed by us in previous posts and our chats, and as you also reported, $IDLE is a governance token, and that is how we issued it. That’s why there wasn’t any AMM pool, or related LP reward program, as that’s a legal constraint for the genesis team. However, the community can lead development for new protocol components. This initiative seemed pretty fluid to me as a community-led process (idea proposal + request in roadmap + forum model discussion). And that’s why I’m not getting the reason behind the allusion to vested accounts.

Also, I would like to ask @devin some more indications on the discussed features: the models we’re discussing here would require implementing slashing unvested rewards or slashing % of rewards for unstaking LPs tokens prior to 6 months. Would that be possible with one of the current Gysr implementations? The time bonus is great, and I personally think it can have many interesting use cases. Do you think it could be applied here for LP staking? It’d also be great if you can give the community some more clues on how $GYSR token is involved in this process?

In general, I believe it’s a matter of balance between incentives and restrictions, and even during the next 6 months, we’d still be here to analyze results and adjust parameters. Now, if we really want to move forward with this initiative, it’s time to vote.

There are 3 different snaps vote that @Salome has almost ready to initiate, and I’d expect to have an outlined model by end of this week. The third one is supposed to be about the specific % of slashing – since it seems to me there are still some mixed feelings on this spec, I would advise having the community vote slashing unvested rewards VS slashing % of rewards (and eventually adding time-weighted rewards if it’s feasible).

7 Likes

Great summary and walk through of the things that need to be considered @Davide. I’d like to once more comment given your remarks as well as @devin’s.

This is the fundamental outcome we want: reward those here for the long term providing value in the Idle ecosystem.

However, we don’t want to put an undue burden on Liquidity Providers (i.e. stake for the entire time or lose all your rewards) as this actually disincentivizes their liquidity; rather, we want to reward long-term behavior.

With this in mind, the bonus structure that GYSR allows for may do the trick:

This is effectively the same as backloaded vesting, which is what I think is the best structure – it allows for optionality, doesn’t overly punish LPs that provide liquidity (and therefore value to Idle) for some portion of the LP staking initiative, and incentivizes those to stay in longer while not disincentivizing liquidity from LPs who want/need that optionality (at the cost of higher future rewards).

6 Likes

Happy to see feedback from actual LPs.

On the subject of early withdraw fee VS bonus rewards I think an easy solution is to have a dynamic early withdrawal fee where the longer you stake the smaller the withdraw fee will be.

So an LP staking for 6 months - 1 day gets 99% of his rewards… And the smart treasury still gets 1%

@devin big fan of GYSR … Can something like a dynamic early withdraw fee be implemented using GYSR protocol?

2 Likes

In the current implementation, only time bonus is supported. We are actually heads down on our V2 at the moment, which is launching next month. This does in fact include the ability to configure a “vesting period”, and withdrawing early will discount rewards proportionally.

You can also check out our docs for FAQ and other info

2 Likes

Can the “discounted rewards” be transferred to idle´s smart treasury in the new V2?

Also @devin is V2 going to be available in 30 days or next week (April)
?

It’s time to caste your vote for the LP staking implementation Snapshot :writing_hand: :rocket:!

3 Likes

I agree with you, another approach could be used, many platforms distribute the same amount of rewards to everyone but they have some kinde of lock time, for example: Aave 10 days lock time to withdraw the capital, Synthetix and pNetwork 1 year constraint to withdraw the rewards, Curve lock time decided by the user from 1 month to 4 years. We could hypothesize a constraint on the rewards of 30/90 days or do something like Curve where the more time you constrain the more rewards you receive, with a progressive increase as time increases.

5 Likes

@Salome Thanks a lot for the work you are doing. It’s great!

I want to share our feedback as Dialectic on the topics. From what we are seeing from our farming activity an attractive APY for a LP Program launched by a token X to incentivize a pair X / ETH should be in the order of 100% APY.

If we take this parameter it means that 1000 IDLE** daily could generate **3.6M liquidity pool.

Regarding the platforms we strongly suggest to go ahead with just one platform avoiding to split liquidity. Sushi will be easier to manage than Uni v3 with NFLP Tokens.

For the lock-up I strongly support the TWR, the other ones are something not so common for LPs of pairs (ETH / Token) but more as protocol bootstrapping.

6 Likes

I see that ‘SushiSwap only’ is winning the snapshot vote.
While Sushiswap has higher TVL, Uniswap has almost 4x the actual volume.
Incentivizing sushiswap will be less effective in terms of actually getting IDLE into the hands of users.

1 Like

I don’t think so, it depends from the APY. If APY is compelling LP are happy to provide liquidity on Sushi, the process is exactly the same at the end.

1 Like

Sorry, what i meant to say is - Sushiswap had higher liquidity, Uniswap has 4x transaction volume. So we may not be adding liquidity where it is most needed.

The Temperature check is complete and the result showed that the community wants to implement LP staking on Sushiswap only, with 1000$ IDLE rewards per day and a time-weighted reward mechanism. We can now move on with the implementation :man_technologist::fire::woman_technologist:

8 Likes

Let’s get this liquidity staking live!!! Great job :clap:

4 Likes

As far as I can see, the vote was decided pretty much by 3 addresses:

Unlike with the other two polls on staking program, I haven’t seen much discussion in this forum around the first one: Uni/Sushi/Both.

How did voters make that choice? Even more interested in rationale of the 3 heavy voters above. I think it’s important for the protocol that observers can understand how governance majority makes its choices.

2 Likes

From discussions within the GOV forum and in telegram informally, I believe that the preference for SUSHI comes from the view that their is greater mutual value & collaboration opportunity with Sushi including fee sharing programs which can help drive idle revenues.

1 Like

I’d like to ask.

If we pursue a path of leveraging the GYSR model suggested to expedite development times, is it more efficient from an implementation perspective to bundle BOTH liquidity provider staking and IDLE TOKEN staking into a single packaged execution?

As we know both staking models were convincingly passed in the snapshot poll, and it strikes me that a more agile implementation could include both.

Much of the community is eagerly waiting the additional utility that both staking models will bring to idle.

So can we bundle for efficiency and get both models up and running.

Personally I’m keen to accelerate developments, sensibly :wink:

@Salome @Davide @william @emixprime

1 Like

I agree with this approach if possible. I do know the more Agile approach is delivering the highest value in increments so even if we can’t ship together it could be shortly after given some of the core functionality is in place.