Introducing $IDLE Gauges model for Tranches

Treasury league & Development League - @Davide @dantop, reviewed by @teo @william @RTP2016 @emixprime @biaf


  • Introducing the potential implementation of Curve Gauge Voting and Farming Boost modules

  • Routing 30% of the $IDLE currently allocated to the LM fund into the Gauge Voting for 6 months (178,200 $IDLE). The overall $IDLE emission rate would not change.

  • Aligning LPs and $IDLE token holders, and incentivizing liquidity provision on the Senior class of the Perpetual Yield Tranches.

This proposal is to introduce the Gauge Voting and Farming Boost modules, adding new Governance features to $IDLE on the Ethereum network.

This post suggests routing 30% of the $IDLE currently allocated to the LM fund into the Gauge Voting for 6 months (178,200 $IDLE). The goal is to incentivize liquidity provision on the Senior class of the Perpetual Yield Tranches while aligning LPs and $IDLE token holders.

The approval of the proposal will empower Development League to build the smart contract infrastructure and transfer 178,200 $IDLE from the IdleController to the IdleGaugesFund contract.

With the launch of Gauges, Idle protocol will distribute $IDLE to Best Yield (BY) pools via IdleController and to Perpetual Yield Tranches (PYT) via Gauge Voting. The overall $IDLE emission rate will not change (3,300 $IDLE/day).

The concept of liquidity gauge has been initially introduced by Curve protocol in late 2020.

How does the Gauge Voting Model work?
This model is based on 4 modules:

  1. Locking system
  2. Fee-sharing
  3. Gauge Voting
  4. Farming Boost

Idle DAO has already implemented two modules with stkIDLE minting (locking system) and the fee-sharing mechanism. IDLE token holders lock their governance tokens for up to 4 years, and receive an amount of stkIDLE proportional to the locking period (with 4 year lock, 1 IDLE = 1 stkIDLE).

This proposal aims to set up the remaining two features: Gauge Voting and Farming Boost.

Partly thanks to its tokenomics, Curve managed to become one of the most significant DeFi protocols globally. This model incentivizes LPs to lock the tokens to boost individual returns further.
Because of this, and taking into account that Idle DAO is working closely with integration partners like other DeFi protocols, wallets, fintech products, or institutional LPs, we feel that this mechanism would solidify the relationship between our protocol and liquidity providers.

The introduction of Gauges in Curve brought to a flourishing development of DAO2DAO and DAO2VOTERS proposals. To collect more veCRV votes, indeed, protocols listed on Curve started offering rewards to voters that chose their pools. Instead of rewarding pools’ LPs with governance tokens, protocols prefer veCRV bribes.

Bribes became a more efficient way to get a higher share of CRV emission and increase the $ value of incentives distributed to LPs, thus stimulating more liquidity provision. The mechanism is now an industry standard, and there are also projects (such as Votium, CRV Vote Incentives, Bribe Protocol) that collect bribes.

If you need more info about Curve project, check out these intro articles: Gemini, Messari.

By integrating the Gauge Voting and Farming Boost modules, token holders that lock their $IDLE (minting stkIDLE) will be able to vote on PYT $IDLE allocation and also boost their individual rewards.

In the beginning, only the Senior class of PYT will be eligible to receive gauge incentives.
That class receives a smaller share of the underlying yield due to the coverage protection they receive, and $IDLE farming would stimulate further liquidity deployment in this class of tranches.

With the incentivization of Senior PYT TVL, the Junior side will overperform the market returns, attracting new liquidity and continuing building the flywheel that supports TVL growth. In the mid-term, Idle DAO could expand the list of incentivized pools out of Idle protocol: for example, bootstrapping liquidity provision on products built on top of PYT (Frax model).

The modularity of the Curve model enables Idle to implement Gauges as an alternative mechanism to distribute governance tokens. Its co-existence with Governor Bravo is reported in the chapter “Final Considerations”.


  • Less $IDLE circulating supply due to more locked tokens
  • Development of $IDLE booster vaults by other protocols
    • New $IDLE-based products
    • Protocols accumulating accrued $IDLE
  • Alignment between LPs and $IDLE token holders
  • DAO2DAO collaborations, with protocols fostering token holders to vote for their PYT

Tokenomics Specifications
The Idle protocol currently distributes about 3,300 $IDLE per day, 1.2m $IDLE per year.
On November 26th, we completed the first full year of liquidity mining, and we joined the second year - on January 26th the LM distribution will last 10 months.

Idle Best-Yield on Ethereum represents the main Idle product today, and it’s the place where most of the TVL is located; thus, it’s crucial to not drastically influence returns for current LPs.

This proposal routes 30% of the $IDLE allocated to the liquidity mining program into Gauges for 6 months, resulting in 990 $IDLE/day distributed over a semester (178,200 $IDLE in total).

The Best-Yield reward reduction represents a minor component of the yield generated via Idle protocol, while that amount would empower Idle to sustain Gauges funding.

If this proposal was to be approved, the next steps would be:

  • Development of a Gauge system to let stkIDLE holders vote on $IDLE distribution on PYT
  • IIP to transfer 178,200 $IDLE from the IdleController to IdleGaugesFund
  • Transfer of Gauges admin keys to Timelock, and Gauges production release

Technical Specification
Curve Finance Gauge system consists of three main contracts (more details):

  • LiquidityGauge: Measures liquidity provided by users over time to distribute CRV and other rewards;
  • GaugeController: Central controller that maintains a list of gauges, weights and type weights, and coordinates the rate of CRV production for each gauge;
  • Minter: CRV Minting contract, generates new CRV according to liquidity gauges.

CRV inflation is controlled by the CRV token main contract that encodes an inflation schedule (a piecewise linear function) for the token itself.
In the Gauge system, when a user provides liquidity for a Liquidity Gauge, a portion of CRV inflation is reserved to reward him staking liquidity tokens (mathematical details can be found in Curve Docs). The users’ reserved CRV portion depends on the reserved portion of CRV for the liquidity Gauge (the weight) and the amount of liquidity tokens staked by the users. This portion can be further boosted by allocating veCRV to the desired Gauge.
When an address claims CRV, the Liquidity Gauge internally calls the Minter that finally calls the CRV token contract that validates and mints the amount. This is the only interaction that is not possible with IDLE (IDLE tokens are already mined).

Idle Finance Gauges
The main difference between $IDLE and $CRV is that $IDLE is not mintable, so a mechanism to release $IDLE linearly to Gauges is needed. A desirable feature is also having a fine-grained control on epochs and inflation rate.
Such a system can be achieved by replacing the CRV token (as seen in the previous section) with a contract that distributes IDLE to Liquidity Gauges following parameters governed by Idle DAO.

The system would consist of the following smart contracts, as in Curve Finance:

  • LiquidityGauge: measuring liquidity provided by users over time.
  • GaugeController: maintaining a list of gauges and respective weights.
  • IdleDistributor (now called IdleDistributorProxy): forked from Curve’s Minter, it will be slightly modified.
  • IdleGaugesFund (now called IdleDistributor): holding and releasing $IDLE tokens on IdleDistributor request. This component will also maintain parameters for $IDLE distribution to Gauges.

The main difference between the Idle Gauge system and the Curve Gauge System is in the IdleGaugesFund that replaces the CRV token (that encodes the release schedule).
This component would replace any hardcoded mining parameter with parameters that the DAO can decide and commit at any time. This system allows us to reuse a big chunk of Curve Finance code, adapting it to Idle tokenomics.

A scheme of the potential Idle Gauge system is reported below.

As an example, let’s take the proposal introduced above, and the required actions (and functions calls) that should be taken to distribute the proposed $IDLE amounts:

  • The IdleGaugesFund is deployed and new epoch parameters are committed: start_epoch_time: START_TIMESTAMP, epoch_duration: 6 months, ratio: 178200 / SECONDS_IN_6_MONTHS or (2 * 178200) / SECONDS_IN_A_YEAR
  • When epoch starting time comes, the update_epoch_parameters is called, effectively starting the IDLE distribution.

Final considerations
The proposal opens to a series of considerations:

  1. Currently, Idle LM program distributes $IDLE through the IdleController contract. The upcoming Governor Bravo will be used only for on-chain voting, and it will govern the related Timelock, owner of all Idle contracts.
    With this proposal, two Governance modules will exist simultaneously: Governor Bravo to select which Best-Yield pools receive $IDLE allocation (amount proportional to generated fees) and on-chain voting, and Gauges for PYT $IDLE allocations (dynamic amounts) and individual boost.
    If more $IDLE will be locked, the voting power of stkIDLE holders will become a vital aspect of Idle Governance.
    Today, Idle DAO uses off-chain snapshots to let stkIDLE holders vote on-chain proposals, with a Leagues-controlled multisig in charge of on-chain vote broadcasting.
    To avoid centralization issues, stkIDLE holders should be empowered to vote on-chain in a permissionless and trustless way.
    In the long term, Idle DAO should decide whether to proceed with a dual-sided Governance, replace all on-chain DAO activities with voting available only via $stkIDLE, or keep Governor Bravo as the main DAO infrastructure.

  2. The 6-month Gauge program is intended to test if Gauges model overperforms current LM on Best-Yield. Three months after the launch, Idle Leagues will provide quantitative analysis about Gauges performances. This mid-term deadline will enable Idle DAO to properly evaluate the capital efficiency of the initiative.
    According to the outcomes, Idle DAO could fund the Gauges for a longer time period, replace overall $IDLE LM on Best-Yield with Gauges, or even reduce the $IDLE emission rate.

Next Steps
This is a massive initiative for the Idle community and its token holders! Take your time to explore the specifications and drop your feedback.

Key points to assess:

  1. Idle community feedback regarding proposed model and $IDLE allocation
  2. Idle community feedback about empowering only $IDLE or $stkIDLE for on-chain IIP voting.

We will leave this thread open for comments regarding this proposal, and in about a week, if there are no objections, we will proceed with the Temperature Check.


The proposed reduction (30%) is a small component of the total yield generated via Idle, therefore I would rather support a 50% allocation into gauge voting.
This would still respect the fact that Best Yield is Idle’s best selling point but at the same time, it would go a long way incentivizing senior tranches, which are amazing for protocols themselves, and therefore incentivize them to ALSO add their own rewards to senior tranches.
In the end, I feel that 50% is a better representation of Idle commitment to foster DAO2DAO alliances.

Idle tranches is a superior product IMHO when compared with other alternatives out there, so it is important that incentives effectively can help capture the long tail of other protocol’s (and DeFi whales) risk management strategies.
50% means we are open for business.

One point I would like to add to the conversation here is that, if technically possible (@william @dantop ), I would like to see the amount of incentives (30-50%) allocated to gauge voting to be dynamic (weekly adjusted): it would be closer to 30% when the amount of $stkIDLE decreases and go as high as 50% if there is more $stkIDLE locked.

The split to senior tranches should be proportional to TVL, thus incentivizing even more protocols interested in owning their risk management strategies to fund and reward senior tranches with their own treasuries.

That being said, I would support onchain voting being available only to $stkIDLE holders.


In general it’s possibile I think, but I would advise to stick to the Curve implementation as much as we can given its complexity and also considering time of development.


We can always adjust the time between gauge polls, for example from 6 months to 3.


Thanks @unicorn for the feedback!

The rationale behind a 30% allocation is to preserve rates on Idle Best-Yield while bootstrapping a new product.
Current LPs should not be affected by the liquidity mining reduction, and routing 50% of the stream would weigh more on final APYs.

Consider that the $IDLE initial flow is intended to test if Gauges model overperforms other products, and three months after the launch Idle Leagues will provide quantitative analysis about Gauges performances.

Thus, the increase of the stream can be proposed just after the report, having more info on how to adjust the $IDLE allocations.


Snapshot vote!

:writing_hand: Please share your preferences below:

  • FOR: Approve $IDLE Gauges for Tranches
  • AGAINST: Vote against $IDLE Gauges for Tranches
  • DISCUSS MORE: Discuss more the proposal

:arrow_right: Poll for $IDLE holders: HERE
:arrow_right: Poll for $IDLE Stakers (stkIDLE holders): HERE

:alarm_clock: Polls will close on 2022-02-01T17:00:00Z .

The final $IDLE voting weights will be calculated using the approved framework .


Congrats IDLE DAO, the Governance approved the snapshot! :white_check_mark: :partying_face:

Dev League has already started working on the model :building_construction: :muscle: