[Gauges] - Initial Gauges batch & Whitelisting process

Author

Treasury League: @Davide, reviewed by @Biaf @william @Teo

Background


Abstract

This proposal defines the initial batch of Gauges and introduces a framework to add new pools to the Gauges Controller.

Motivation

With the upcoming launch of Gauges, Idle DAO should vote on which Senior Tranches would be eligible to receive IDLE incentives and allow future prospective partners to whitelist their PYTs/pools in the Gauges.

Initial batch of whitelisted Gauges

This proposal would whitelist Senior Tranches that are currently in production, excluding DAI and FEI Best-Yield PYTs as they already receive IDLE from the Best-Yield LM program.

Furthermore, Leagues propose the listing of mUSD and mUSDcrv, which are in beta.
mStable approved the whitelisting of mUSDcrv into their Dial, allowing liquidity providers to accrue MTA rewards.

Lastly, pBTCcrv PYT will be launched in the next days. Its release was postponed to let pNetwork team upgrade their asset to v2 and launch new Curve/Convex pools. On Thursday 31st, the Convex pool will be available and Dev League will proceed with the integration into PYTs.

Proposed whitelisted Gauges are the Senior PYTs of:

  • stETH
  • FRAX3crv
  • MIM3crv
  • stecrv
  • alUSD3crv
  • 3EUR
  • mUSDcrv
  • mUSD
  • pBTCcrv

There will be a delay of a few days between the launch of Gauges and the first community voting period.
During this timeframe, the initial weights of Gauges will be proportional to generated fees among the listed PYTs.
With the first voting round, stkIDLE holders will be empowered to set the future Gauges weights.

Idle Gauges Whitelisting Framework

While PYTs will be the main beneficiary of Gauge listing, the process is also open to pools controlled by other protocols.

Any smart contract is eligible for Idle Gauges, including AMM pools, on-top PYT products, and tools that empower Idle DAO to expand the ecosystem with new use cases.

The whitelisting process will be composed of 3 steps:

  1. Forum Proposal

    Write a post labeled as follows: “[Gauges] - Proposal to add YOUR POOL NAME” and publish it in the “Gauges whitelisting” subcategory.

    Forum Proposal structure:

    Abstract
    Short description of why you are writing this proposal and the expected outcomes. This shouldn’t be deeply technical but should be accessible to a casual community member.

    Background
    Link to website, documentation, Github page, (eventual) previous forum discussions, and other useful links to support the proposal.

    Motivation
    Describe the proposed pool(s) and the corresponding protocol(s) that manages it.
    Clearly explain why this pool should be incentivized via IDLE Gauges and what are the benefits for the Idle DAO. Providing tangible elements, like data from previous discussions and forum posts, would be beneficial.
    If the pool is not directly managed by Idle DAO, please provide information on the protocol’s Governance structure, audits, and pool’s metrics (TVL, longevity).

    Specifications
    Share the address of the pool and, if available, the address of the LiquidityGaugeV3 contract.

    Next Steps
    Inform the community when you plan to launch the Temperature Check.
    The Forum Proposal can be moved to the Temperature Check phase at least after 3 days of discussion.

  2. Temperature Check

    Follow up your Forum Proposal with a reply that includes a Temperature Check. You need to have a minimum of 100 tokens in order to submit a Temperature Check. The aim is to taste the sentiment of the community about this potential whitelisting.

    Launch a Temperature Check using Snapshot pages for [IDLE holders](Snapshot) and [stkIDLE holders](Snapshot).
    Launch both Snapshots at the same time, with the same ending period.

    Idle Leagues will calculate the final $IDLE voting weights using the approved calculator, with the weighted votes of IDLE + stkIDLE.

    The structure of the Temperature Check is similar to the Forum Proposal one, replacing the Next Steps with the following section:

    Voting Options
    Please cast your vote on one of the following options:
    FOR: Approve the whitelisting of YOUR POOL NAME in the Gauge Controller
    AGAINST: Vote against the whitelisting of YOUR POOL NAME in the Gauge Controller
    DISCUSS MORE: Discuss more the proposal

    Duration: 3+ days of voting
    Quorum: 100,000 IDLE, as weighted sum of IDLE and stkIDLE votes
    Majority: the most voted option wins

    The voting weight of stkIDLE is calculated in the form of weighted IDLE tokens as
    (tot. IDLE stakes/tot. stkIDLE minted)tot. stkIDLE voting in the pool% of each option.

  3. On-chain Gauge Whitelisting

    Once Idle DAO approves the proposal via Temperature Check, the proposal is ready to be submitted on-chain.

    Deploy the LiquidityGaugeV3 contract related to the pool that should receive IDLE.

    Then, you can launch an IIP to add the newly deployed contract to the Gauges Controller. Please make sure to follow the proposed guidelines:
    [Guide] — How To Propose an IIP

    The on-chain journey consists of 3 days for on-chain voting and 2 days of queuing period. After 5 days, the on-chain proposal can be executed.

Specification

This proposal will:

  • Confirm the first batch of 9 Gauges (Senior PYTs)
  • Approve the Gauges Whitelisting framework

Next Steps

We are going to leave this thread open for discussions and in about 3 days, if there are no objections, we will proceed with the Temperature Check.

5 Likes

Can $IDLE tokens on Paladin be used to vote on the temperature check?

3 Likes

If there is a snapshot module ready for Paladin we can plug it potentially

3 Likes

Time to move the proposal to the Temperature Check phase!

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

:alarm_clock: Polls will close on 2022-04-04T11:30:00Z

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

Cast your vote :writing_hand:

4 Likes

The Governance approved the snapshot ! :white_check_mark: :partying_face:

image

1 Like