Staking + Tranche Strategies Combined

I have written two proposals: “staking” and “tranches”. After reading the feedback from both, I thought of an idea that connects both of them. I wasn’t sure whether to add it to an existing forum or to create a new one since it combines both, so decided to start a fresh discussion. Sorry in advance.

For staking, users that stake, will get a portion of performance fees the protocol generates (10%).

For tranches, in order to partake in the high yield generating pools, you will need 1 IDLE for every x amount of USD/specific asset.

With mechanisms like staking eventually getting implemented and low circulating supply, IDLE will be to pricey for everyone to partake in High yield tranches. Because of this, they are only left with one option (To lease/rent IDLE token from platform during their investment period). In return, the platform gets a cut from that high performance yield they were able to enter.

I know all the above has been talked about briefly, but the info below, is the new combination implementation I was thinking about.

Staking(No Lock Required) - Users get 10% of protocol fees
Locked Staking - Users get 10% of protocol fees + a cut/fees generated from the high yield tranches.

Create 3 lock periods for staking

  1. 3 month
  2. 6 month
  3. 12 month

The longer lock stake period you choose, the more % you will earn from fees collected from the high yield tranches.

The locked staking pool, no matter what duration (3,6,12 month), will act as one pool, to make it easy to share/calculate fees generated. Users can “lease IDLE” from the locked staking pool, in order to be able to partake in high yield tranches. Fees % generated will get distributed in 3 different ways and quarterly (but this can be changed to monthly or w.e governance chooses).

Fees generated by high yield would be split as the following
12 month lock stakers: 65%
6 month stakers: 25%
3 month stakers: 10%

High yield tranches generate usually 60-100%+ APY. Many users will want to partake in this. Since APY is so high, it means cuts/fees for leasing IDLE from locked staking pool can be around 20% of w.e the user generated. As the platform gets more traction, these high yield tranches will bring in a lot fees. Many users will want to lock for 12 months to get 65% of that 20% generated throughout the year.

Also, locked stakers wouldn’t need to worry about losing their tokens, since it would simply be a protocol addition in order for users who don’t have any IDLE to be able to partake in high yield tranches. All tokens would remain in the “leasing/locked staking pool” at all times.

I know there’s a lot more that has to go in into creating tranches and so forth, but hopefully this helps other members from the team or community to think of extra additions that can help drive new and good utility for IDLE token.


I am a big fan of IDLE developing its own in-house tranche system.
Obviously, IDLE would be required to buy tranches but I also think that Saffron´s original mechanism has room for improvement and on their discord some new features are already being talked about…

My biggest key concern when adding new functionality to the protocol or to IDLE token is that we risk to destroy (one of) IDLE´s best selling points: ease of use/clean UI for mom & dad.

Its very easy for IDLE users (new and old) to be put away/scared by the introduction of complex financial frameworks.

Thanks for bringing this up @Falcone


recently mstable upgraded their savings account and now, basically, how much a user´s deposits also determines a staking reward earning power multiplier for each staking account.
Maybe can this framework also be considered in IDLE´s design.


Hi @Falcone I have read through your idea’s regarding Staking and Tranche’s and have given it some thought.

I believe that the most reliable method for implementing tranche’s will be through a partnership with . There are two main reasons I would recommend this pathway.

  1. Saffron has already established itself as a successful platform for implementing a risk mitigation strategy. Creating a partnership with saffron would mean a new user group would be introduced to idle, who are already familiar with tranche’s and saffron. If IDLE were to develop its own system there would need to be a thorough auditing and peer-review phase for users to be convinced to put significant money through it. (Essentially it would need to prove itself before it got mainstream adoption)
  2. IDLE should be simple to use. As mentioned by @unicorn introducing a tranche’s system will only aleianate idles core user group who are looking fro a simple, clean and safe method of earning yield through DeFi. Delegating the tranche’s system to saffron doesn’t come at the cost of detering IDLE’s core user group.

In terms of technical implementation this would be a perfect situation for the pilot league to establish a dev grant to develop a saffron adapter to use idle as the underlying yield generating strategy.

However since idle also values its security of its users, and as I understand it saffron is developed by anon developers, and is yet to be audited (but are in the process of getting one). I suggest to wait on this untill their security can be validated.

Staking is a complicating mechanism, and there are many methods to achieve a successful staking system. For me I see three mechanisms in which IDLE could introduce staking to add utility to the protocol.

  1. Stake $IDLE for a reduction in performance fees

    • For example: Say you have 10K of USDCBestYield, you can stake up to 2.5K Worth of IDLE to reduce your performance fee down to 1%. The exact number of IDLE to stake, and the minimum performance fee is up for debate.
  2. Stake $IDLE for a boosted $IDLE distribution (Similar to gauge mechanism).

    • How this could work is every week ~10,000 $IDLE will be distributed amongst all pools. Users who stake $IDLE can vote with their stake on which pool gets what percentage of this distribution in a gauge, The 10,000 IDLE is split based amongst all pools based on the gauge, and awarded proportionally to stakers of each pool based on their deposit.
  3. Locked staking, where users lock up $IDLE for a period of time (similar to voting mechanism).

    • This locking mechanism could entitle users to time-weighted vote (the larget to lockup-period, the larger the vote).
    • The FeeCollector could be modified such that a proportion of the fees generated by IDLE flow to the locked stakers to get a cut of the protocol fees.

Personnally I see a combination of these three strategies (an perhaps others) as working well within the $IDLE ecosystem, the first strategy is the simplest and would be the easiest to understand, in addition to this, it is scalable as it doesn’t need a constant topup of $IDLE to keep the protocol incentives, as the second strategy does.

The second strategy is more complicated, but would give greater incentives to the stakers, however if implemented in isolation it could work agains’t the protocol as it would rapidly increase the token inflation (curve has a similar issue before they added the 3pool distribution to veCrv holders).

The third strategy is also complex, and would require some rework on the governor contract which controls the timelock to value time-locked $IDLE higher. It would also make it more difficult for most users to use, unless the process was well explained.

Perhaps if the system befomes too complex parts of the voting and staking mechanisms should be offloaded into a separate site(something like, or anything else), specifically for this purpose, and leave the main site looking clean and easy to use.


Thanks for your thoughts. Totally agree. I would prefer the first staking implementation as the value is clear and it is simplest to implement and to explain, and it seems to have the least downsides. Additionally it aligns incentives well so that large holders of idle are inclined to invest more for longer, and large investors are incentivized to hold $idle


I really like the ideas of staking for #1 and #3 where you get the reduced performance fees in addition to locked staking.

One thing we might want to consider as well here while we’re talking about staking is liquidity incentives, and I’m wondering if we could tie this in with the ‘staking for a reduction in performance fees’ so that we incentive liquidity providers as well.

For example, instead of staking simply $IDLE tokens, users can also choose to stake LP tokens for a specific pairing we want to promote liquidity for (ie. WETH/IDLE LP tokens).

I’d argue that we should provide greater incentive for an investor willing to stake LP tokens over just $IDLE tokens as it benefits all participants in the protocol. A simple incentive could be that we provide a greater reduction in performance fees for LP tokens staked versus $IDLE tokens, or we could allocate a % of $IDLE tokens from the treasury to incentivize LPing.

The importance of $IDLE liquidity can’t be understated, and by doing this, we’d be able to:

  1. Improving slippage and overall trading conditions for all market participants
  2. Improve LP yields for existing liquidity providers as token price becomes more stable, while attracting new participants to begin providing liquidity
  3. Provide an additional form of yield and utility for $IDLE, hence increasing the value prop of $IDLE and attracting a new class of investors onto the protocol

+1 to rewarding IDLE LPs. This also paves the way to IDLE being accepted as collateral in lending protocols - those require reliable liquidity for liquidations.


@wlamhk you make some very good arguments here. Can I suggest that you copy/paste these ideas to the thread Staking implementation


Thought I would share this article from our friend Andre on Saffron Finance and Tranches…