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:
- Locking system
- Gauge Voting
- 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.
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
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
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.
The proposal opens to a series of considerations:
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.
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.
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:
- Idle community feedback regarding proposed model and $IDLE allocation
- 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.