Idle Staking
Idle Staking details

Idle Staking

What is IDLE Staking

Staking allows users to lock away some of their $IDLE for a flexible period (up to 4 years) in return for a claim on the protocol fees. The protocol fees are used to purchase $IDLE on the open market and are distributed to stakers on a weekly schedule.
The contracts for IDLE staking are based on the Curve VotingEscrow contracts which can be found here:
The purpose of the $IDLE single token staking program is to build upon the $IDLE token leading to increased utility. The Curve staking model was decided by the community and to distribute protocol fees to stakers. In this model $stkIDLE linearly decreases from the lockup date to the end date.
For example, if a staker locks 100 $IDLE for 4 years, they will receive 100 $stkIDLE. After 1 year this balance will be 75 $stkIDLE, and 50 $stkIDLE the following year. After 4 years the $stkIDLE balance will be 0. Stakes can increase their $stkIDLE by either staking more $IDLE into their existing lock, or increasing their lock end date.
In this way, long-term stakers are incentivised to lock their tokens for a longer duration to maximize the rewards per staked $IDLE. The maximum lockup duration is 4 years.

Technical Specifications

The staking implementation consists of three contracts.
The implementation repository is located here:


The staking contract is implemented as a non-standard ERC-20 token, which is non-transferable and can only be created by staking $IDLE by callingcreate_lock(uint256 _value, utin256 _unlock_time).
By default smart contracts cannot participate in staking, as this would allow for trivial which could be implmented to circumvent the non-tranferable nature of $stkIDLE. Smart contracts can however be whitelisted via a governance proposal (if you're planning to integrate the staking contract, feel free to reach out to Dev League members in Discord).
$IDLE which is deposited to the staking contract is delegated to a community multisig which can be used to vote on governance proposals based on a snapshot vote of staking users. The community multisig is located at 0xb08696efcf019a6128ed96067b55dd7d0ab23ce4
A stakers $stkIDLE balance decays over the duration of the staking period linearly. For example if a staker locks 100 $IDLE for 4 years, they will receive 100 $stkIDLE, After 1 year this balance will be 75 $stkIDLE, and 50 $stkIDLE the following year. After 4 years the $stkIDLE balance will be 0, and stakers can withdraw their original 100 $IDLE which was deposited by calling withdraw().
When a user has an active stake, they can choose to extend their lock duration or deposit most $IDLE, both of which increase their $stkIDLE balance. This can be achieved by calling increase_unlock_time(uint256 _new_unlock_time) or increase_amount(uint256 _amount) .


Fees are distributed weekly. The proportional amount of fees that each user is to receive is calculated based on their $stkIDLE balance relative to the total $stkIDLE supply. This amount is calculated at the start of the week. The actual distribution occurs at the end of the week based on the fees that were collected. As such, a user that creates a new vote-lock should expect to receive their first fee payout at the end of the following epoch week.
The available $IDLE to distribute is tracked via the “token checkpoint”. This is updated at minimum every 24 hours. Fees that are received between the last checkpoint of the previous week and first checkpoint of the new week will be split evenly between the weeks.
Stakers can claim their fees by calling claim().

Sushiswap Exchanger

Protocol fees are generated in wETH and allocated to a number of protocol beneficiaries from the FeeCollector; such as the smart treasury, the fee treasury, and the rebalancer. As part of IIP-10, the Sushiswap exchanger was added as a beneficiary to FeeCollector.
This contract exchanged the protocol fees from wETH to $IDLE via SushiSwap and deposits the $IDLE to the FeeDistributor.
In order to make this process sustainable for the future, the SushiSwap Exchanger is implemented as an upgradeable contract, such that if liquidity for $IDLE migrates to another exchange the contract can be upgraded to use that.
The SushiSwap exchanger implements a FeeExchanger interface which is located here
Last modified 2mo ago