Single $IDLE staking

[Salome]

Summary

The Pilot League committee successfully implemented LP staking on 14th April, and we would now like to focus on building the IDLE single token staking model, as the community already voted to move forward with this implementation here.

The Idle community in the past has voiced its opinion about possible single staking implementations here Staking Implementation, Staking Model, and here Tranches + Staking.

Recap from previous posts about IDLE token staking

The purpose of the IDLE single token staking programme is to focus on finding use cases built upon the $IDLE token leading to increased utility. The initial discussion of such a staking framework started from existing models like Curve and later gathered several economic incentives ideas from the Idle ecosystem.

Single staking IDLE must add valuable utility, promote long term sustainability and incentivize the entire IDLE ecosystem for their commitment.

@8bitporkchop @falcone (and others) introduced possible staking frameworks, and reward mechanisms and the Treasury League is presenting the following ideas:

1. Stake $IDLE for a reduction in performance fees. A possible method might be to use a logarithmic formula where staking a percentage of all $IDLE (to be determined) would result in a fee reduction (to be determined)

2. Stake $IDLE to adjust the liquidity mining distribution of idleToken pools via voting and get boosted $IDLE rewards. This is similar to the Curve.fi gauge mechanism and means that with the same deposited amount, a depositor with staked $IDLE would get a higher amount of $IDLE/block than a depositor without staked $IDLE.
   Users with single staked $IDLE would periodically (to be determined) vote with their stake on which pool these boosted rewards would be applied. The total boosted rewards would be split amongst all pools and awarded proportionally to stakers of each pool (based on their IDLEToken deposit).
   Keep in mind that a boosted $IDLE distribution does not tap from fees or other funds, but this would require changes to the IDLE liquidity mining distribution weights for IdleToken depositors. These changes would require several modifications to the several existing smart contracts and require higher effort.

3. Stake $IDLE to receive a share of the protocol fees. As @8bitporkchop pointed out, to allow this, the FeeCollector would have to be modified in such a way that a proportion of the fees generated by the Idle protocol flow to the locked stakers to get a cut of the protocol fees (in $IDLE). At the time of writing this document, there are currently around $212,000 usd collected by the FeeCollector (with average weekly revenue around $10,000 usd from $200MM TVL). This modification is the most straightforward from a technical point of view. The Dev League investigated the use one of the following smart contract models:

   • Curve: There are several versions of the original Curve Model. Pickle Finance, has one, there is a more generalized form for UI’s and one other option is the version that is currently in discussion on Sushi. These contracts have been audited 4 times across 3 different firms.

   • Aave: This model and its basic functions can be deployed with limited efforts. It’s a lean staking approach that includes the Safety Module. By staking AAVE in the Safety Module, users help protect the protocol from a short fall event from underlying lenders and earn a reward as a result. This mechanism is based on a 10-day locking period. The contracts have been audited by 2 auditing firms.

4. Staking a certain amount of IDLE in order to boost voting power on snapshots.(similar to curve.fi, mstable and other voting mechanisms).This locking mechanism could entitle users to time-weighted votes (the larger the lockup-period, the larger the vote). Long term stakers are important in order to have responsible and secure Governance, therefore it makes sense to reward stakers with a boosted voting power and minimize the risk of short term holders to push for suboptimal outcomes or other types of Governance attacks.

5. A combination of all the previous 4.
   Note: The community must bear in mind that a huge tech component plays a role here as many things would need to be developed, customized and audited simultaneously before this option is ready for production.

Leagues Recommendation

Following all the research summarized earlier, the League Committee, therefore, suggests that Staking might start with option 3 (‘Stake $IDLE to receive a share of the protocol fees’) using Curves’ time-weighted staking model and later add option 1 and 2. This would allow Idle to use a battle-tested staking framework in a time-efficient manner, with added innovative features later to build an even bigger utility for $IDLE after.

The Treasury League has been crushing some APY forecasts and more insights and numbers will be shared in the next few days

Formalizing an IDLE singe token staking model

The next steps to take now is to formalize the final shape of the single token staking model. For more details about the additional features, there will be a follow-up post once the staking model is defined. This being said, the points which the Treasury League would like to focus on are:

• Final model
• Agreement on the amount of rewards allocated to the single staking program

The Treasury League is looking forward to listening to the feedback from the community and starting the implementation after the off-chain consensus has been archived.

[unicorn]

LOVE IT!!

how long until 1st set of “features” are live in production and how long for the remaining also to go live?

[Coinballers]

Fantastic analysis and fully support the recommendation @Salome.

I think it’s a big incentive for the community to get a share of protocol fees, and this will become more attractive as TVL grows, and performance fees increase.

Also, great to see that additional utility from the other models can be incorporated over time which should ensure Idle’s single token staking is amongst the most attractive to both partners & individual investors.

Fully support the proposed approach.

Great work, LFG

[Falcone]

Nicely laid out, I’m personally in favor of #3 first and then #1 shortly after.

I like both curve and aave contract, but like the aave with 10 day lock period, but with time weighted fee distribution model like crv.

[idlehusbandry]

If you think about it, 1 & 3 are similar, but implementing either one without the other would drastically change the “meta” for staking IDLE, and potentially create incentives to “game” the system.

Stake $IDLE for a reduction in performance fees

This solution incentivizes the people who use IDLE Finance and place liquidity with the smart contract. (allowing the smart contract to generate fees in the first place).

Also due to the performance fee of IDLE being a percentage, it will disproportionately favor larger Liquidity Providers. (Which is good, as you need a few whale anchor LPs).

Too much of this though, and you end up with too little fees in order to distribute to the IDLE holders. Which may not be ideal for price. (but then again, this is countered by large whales holding Idle and not selling due to it saving them a ton on fees paid to the protocol itself).

Stake $IDLE to receive a share of the protocol fees.

This solution incentivizes the people that buy idle, and hold idle. However, it does not incentivize actually using IDLE and placing liquidity with IDLE.

A virtuous cycle would be:
a. Users place liquidity with Idle and Stake Idle
b. Gain a discount on fees (incentivizes more liquidity, and buying IDLE) - Privatized Gain
c. Gain a proportion of the fees generated by the pool (incentivizes liquidity, and buying IDLE) - Socialized Gain

[ETM612]

In collaboration with Idle Leagues, as well as other investors including GreenField One (cc: @Felix) and LongHash (cc: @chris and Shi Khai), we have been discussing Idle’s potential staking design over the last few months; I’m excited to see this come to fruition and get the community’s feedback on the routes we can go for $IDLE staking.

I wanted to make a post from the point of view of our fund, gCC, rather than from my personal POV as a member of the Treasury League.

For context, gCC is an early stage venture investor that backs great teams building in the crypto space. We operate under a very different model from crypto hedge funds or liquid active investors; we are long time preference investors, not traders. We were the lead investors in Idle’s Seed round and we have high conviction in this amazing founding team.

We are excited about the incentives a proper staking model can create for long-term alignment between LPs, $IDLE holders/investors, community members, governance participants, external protocol partners (B2B), and other stakeholders (including participants that are a mix of some or all of these functions). We will continue to work closely with the Idle team as a fund (as we have been on a weekly basis) as well as from my position personally as a Treasury League Supervisor.

As a fund, our thinking is in line with the recommendation of the Leagues to start with option 3 (‘Stake $IDLE to receive a share of the protocol fees’). We can then observe the reaction from the community (i.e. how much $IDLE is staked, the community sentiment around the program, and what else the community wants to see), and from there evaluate together if other options listed are appropriate.

We look forward to continuing the conversation and supporting the work of Idle Labs, the Leagues, and the community as a whole!

[william]

After some analysis with the Dev League (@8bitporkchop, @gggggg) we can say that the options 3 should take something like 3 weeks from now considering that current Dev league members are part-time.

This would include the setup of contracts, tests, UI and the proposal itself to redirect part of the fees to the staking contract.

What needs to be decided is the total % of fees to be redirected to this contract, (the Treasury League is working on some numbers), and finally how to handle voting (on-chain and off-chain) for people who decide to stake because they will no longer have IDLE but only stkIDLE and the Governance module only support voting via IDLE.

Option #2, staking for boosted rewards, it’s really interesting but it requires a lot of work and different proposals because all the current Liquidity mining program should be changed / redirected to the new one and probably also all the governance contracts need to be migrated in order to use stkIDLE instead of IDLE, further analisys should be made but it’s a really big update (in the order of months considering the current part-time nature of the Dev League).

Option #1 and #4 have not be analized yet, but both should come after Option #3 is set up.

[idlehusbandry]

Ahhh Yes!

We hopping on that #ProductiveAsset Meme!

[8bitporkchop]

Regarding voting for stkIDLE holders, I believe that stkIDLE holders still need a mechanism to participate in governance. It doesn’t make sense to me for staker’s who are showing loyalty to the ecosystem by staking their IDLE to forfeit their voting rights.

With that said a possible solution that has been discussed by the Dev League is to vote delegate the IDLE in the staking contract to a community owned multisig. stkIDLE holders can express their opinions on proposals via an off-chain vote mechanism such as snapshot.page. The owners of the multisig can then certify this result, and execute an on-chain vote.

The process I see for.
When an IIP is formalized on-chain, a parallel snapshot vote for stkIDLE holders can be created.

An on-chain proposal lasts 3 days, therefore the snapshot vote should last for 2 days, and the multisig owners will submit their vote immediately after the snapshot vote closes.

I believe a 6-of-9 multisig would be more than enough for this purpose, based on the yearn multisig. However other common parameters could also be a 5-of-8, or 4-of-7

[Teo]

With Treasury League (@Davide, @RTP2016, @Salome, @ETM612, @emixprime) we had a deeper look at staking model scenarios and FeeCollector distribution weights.

We’d like to share a couple of resources for our community to explore the model and potential weights requirements for the FeeCollector:

• $IDLE Staking Calculator, where you can play with the model and evaluate different scenarios for this stkIDLE program.

• Rebalancer Cost Outlook: an analysis of the 2021 rebalance expenses, which should be considered when thinking about FeeCollector distribution weights and would potentially require a higher weighting compared to the current one.

Next Steps

We’re now coordinating with both Leagues to provide a proposal for FeeCollector weights (now 80% Smart Treasury, 15% Fee Treasury, 5% Rebalancer) – will then follow a FOR/AGAINST snapshot poll to signal community sentiment on the proposed weights.

[Salome]

Time to cast your vote Snapvote for the new proposed weights of the FeeCollector that are going to be used for the staking rewards
The Snapvote is open till 2021-06-03T04:00:00Z

[Coinballers]

Hi @Salome

What’s the latest on staking? I can see the proposal passed unanimously which is great, and it will be fantastic for the community to earn a % of protocol fees and encourage more holders into the protocol.

Assume we are all systems GO now with the vote passing. Have we started development now?

Can’t wait to be earning yield on my idle

[Salome]

The Temperature check is closed and the result shows that the community agrees with the proposed changes to the weights for the FeeCollector. The Dev League can now move on with the on-chain changes
This completes a mandatory step toward the final implementation of the staking model, the Dev team can next prepare to deploy the staking and FeeDistributor contract

[igor-brcapital]

Great to see that Idle community and governance support this proposal!

We are at BR Capital looking forward to see staking implementation due to our longterm vision.
I’ve read amazing report from Delphi Digital researching Curve tokenomics related to their staking model and I do think that this model works well as it was planned.

Ready to hold and stake for years!)