The Community Governance Process is distributed across many steps and it takes place in different online platforms.
There are 3 main portals that are used by the Idle community to drive an idea from early stage to execution:
Idle Forum
It is a Discourse forum that collects the discussions related to Governance and protocol improvements.
Idle Snapshot Pages
For $IDLE holders
For $stkIDLE holders
This interface allows community members to signal their voting sentiment regarding a possible proposal. This is an off-chain action and it does not influence the Voting Phase of an IIP.
Governance Dashboard
The Idle dashboard is the interface that allows community members to cast votes on-chain and determine if an IIP will be approved or not. It also allows the delegation of voting rights to third parties. Other platforms might integrate Idle protocol and provide voting features.
Now that we have described the portals, we list the processes. These steps may change in the future, according to the community’s will.
IIPs are formal on-chain proposals that are executed if the majority (50% +1) of the voters cast a “For” vote and at least 4% of the total voting right supply [520,000 $IDLE] has casted a vote on that proposal, in favor or against.
Community members can create a proposal if they have at least 130,000 $IDLE as delegated votes and hold them during the entire voting process (up to the implementation).
Idle’s architecture has been inspired by the COMP Governance modules, that govern the Compound protocol, and the Uniswap Governance Process.
The proposal journey consists of 7 steps:
-
Ideation & Discussion Phase: community members can propose early stage ideas in the Idle Forum (“Governance-Meta” or “New Features & Improvements” category) and receive initial feedback.
“Governance-Meta” includes discussion about how the Governance works and how we can improve it; “New Features & Improvements” embraces topics like the creation of new products, ecosystem grants, integrators programs, and tech changes of the current protocol. -
Temperature Check: Follow-up your Discussion post with a reply including a Temperature Check. The aim is to taste the sentiment of the community about a potential change.
The proposal should comply with the stkIDLE Voting Framework, launching the voting polls for both $IDLE holders and $stkIDLE holders. Both the Snapshots should last for the same period, have the same description and voting options. At the end of the voting phase, final results are calculated using this calculator (Leagues are in charge of updating the results).
The voting process is a secure off-chain action and requires that voters only sign a message.
The Snapshot poll for $IDLE holders takes into account the $IDLE held in an address, the Uniswap and Sushiswap LPs. The stkIDLE one counts only the staked $IDLE.
The Snapshot poll should last for 3 days and voters indicate their interest in bringing it forward to the next stage. You need to hold 100 $IDLE or $stkIDLE as voting power to submit a Snapshot poll. -
Forum Proposal: once the idea is more structured and has the form of a proposal, the initial proposer or a community member may decide to submit the idea as an IIP in the “Proposals” category on the Forum. Check “How To Propose an IIP”. Write a post labeled as follows: “[Proposal] - Your Title Here”. Here it can be further discussed among IDLE token holders and fine-tuned.
It is recommended to perform third-party audits before advancing to the next step. This means that a further IIP about code audit, financed by the proposer or through the ecosystem fund, should be launched and approved before the code implementation proposal. -
Consensus Check [optional]: This poll is “strongly suggested” only for ideas that embed new changes after the previous Temperature Check. You can launch multiple Temperature Checks to design the proposal, and the Consensus one represents the last poll before the on-chain journey. If the Temperature Check got approved and there are no further changes, it’s possible to move directly to the on-chain proposal.
This poll should comply with the stkIDLE Voting Framework, launching the voting polls for both $IDLE holders and $stkIDLE holders.
Please refer to Temperature Check to poll procedures and framework. - Pending State: the proposer or other people can deploy on-chain the official proposal, that is broadcasted as executable code. It starts its journey in a pending state. update the Forum post informing the Governance about the deployment.
-
Voting Phase: once the on-chain proposal is active, $IDLE token holders cast their vote “For” or “Against”. The voting phase lasts 3 days since the activation of the proposal.
The stkIDLE Voting Framework requires that an off-chain poll for $stkIDLE holders is launched too. This poll should last no more than 24 hours, and if it reaches the quorum (30% of circulating stkIDLE voting the poll + at least 70% on the same option), the multisignature will broadcast the delegated votes on-chain. -
Execution Phase: if the Governance quorum is met [520,000 $IDLE], the proposal can be executed 2 days after the closing of the voting phase (and no later than 14 days), remaining queued during that grace period.
If rejected, then the IIP will move to the ‘Rejected’ stage and the associated code will not be executed.
Please read the Forum Guidelines.
Some useful links:
Website
Discord
Official Documentation
Github