Voting Framework for stkIDLE Holders

Treasury League

This post would like to define the framework that makes off-chain polls eligible for on-chain vote broadcasting on behalf of stkIDLE holders.

With the launch of $IDLE staking, stakers have no more access to voting features.
To enable the voting option, the governance tokens deposited into the staking contract are delegated to a community multisig. That address can be used to vote on governance proposals based on a snapshot vote of staking users. The community multisig is located at 0xb08696efcf019a6128ed96067b55dd7d0ab23ce4 (cit. documentation).

The implementation of an ad-hoc off-chain voting strategy lets stkIDLE holders cast their preference for on-chain proposals.
The on-chain voting phase lasts for 3 days and the off-chain polls should be created within that period.
Both Snapshot and Scattershot can host those voting sessions, according to the needs of each proposal. Only stkIDLE holders can vote on those polls.

The community multisig is in charge of on-chain vote broadcasting once the polls reach the thresholds.
The wallet will vote for only one option with 100% of the delegated votes.
This means that if just the relative majority of voters say “YES”, the multisig will vote on-chain for “YES” with the entire stake.

In order to make a poll eligible for on-chain vote broadcasting, the main thresholds are quorum and relative consensus. Here below we list a couple of scenarios that might help the community to set the parameters.

Scenario 1: low quorum (30% of stkIDLE) but high consensus (70%+ on the same choice). This option would require a minimum of 21% of stkIDLE voting the same thing. A lower barrier to entry would allow the Governance to easily reach the 520,000 $IDLE quorum on on-chain proposals. Drawback: a tiny group can potentially pivot a large number of votes.

Scenario 2: high quorum (60% of stkIDLE) but low consensus (51% on the same choice). This option would require a minimum of 31% of stkIDLE voting the same thing. Benefit: the parameters require a large voting base, so the final vote is not influenced by few individuals.
Drawback: if the poll does not meet the quorum, the vote is not broadcasted and this voting power can not help the Governance reaching the 520,000 $IDLE quorum.

To avoid sybil attacks, the number of voting addresses is not counted as a reference metric.

Polls launched via Snapshot/Scattershot can be manually counted as part of the Governance decisions.
The previous chapter illustrated off-chain votes used to bridge the on-chain ones, while here we present dedicated off-chain polls that mirror the off-chain ones launched for IDLE holders.

The final voting report of the Temperature Checks would represent the sum of IDLE votes + stkIDLE votes.

In this case, the stkIDLE amount is calculated in the form of weighted IDLE tokens using the formula:
total IDLE staked / total stkIDLE minted * total stkIDLE voting the snapshot * % of each option

E.g. There are 100 IDLE staked and 50 stkIDLE, and we have 25 stkIDLE voting off-chain. This means that an equivalent of 50 IDLE has cast a vote. We then multiply this number by the shares of each option (e.g. 80% voted ‘yes’, 20% voted ‘no’). A total of 50 * 0.8 = 40 IDLE will increase the ‘yes’ weight, and 50 * 0.2 = 10 IDLE will be added to the ‘no’ option.
Results coming from this Temperature Check would be combined with the votes cast by IDLE holders on their ad-hoc poll.

Next steps

  • Gauge community sentiment on the scenarios and finalize the parameters with a poll

What is your preferred scenario?
Do you have other metrics that could improve the voting framework?
The thread is open for comments!


I would prefer option 1 - low quorum high concensus. Although my stronger preference would be to enable stkIDLE holders to vote directly with same or higher value than idle holders, rather than proxy voting via the multisig.


Thanks, @Davide. In lieu of direct stkIDLE on/off-chain voting, my preference is option 1.
I think having a lower quorum reduces the chance of missing out on participation if there were too many inactive stakers proportional to active members. I also think having a 70% consensus also reduces the chances of “stalemate” voting.

Interested to hear other community views before we move this to vote!

cc @Coinballers @unicorn @JonnyReid


Great overview, thanks @Davide, I think this is something urgent and crucial for everyone, especially now since all the upcoming initiatives that need to be voted by the DAO

I personally prefer option 1.

Currently, I feel more the potential risk of not reaching the on-chain quorum having this high (60%) quorum, and so facing a blocker, instead of the risk of seeing pivoting votes.

I’d like to see the community’s thoughts on that, again this is something very important for the DAO :raised_hands:


It’s amazing to see the time and effort put into allowing Governance participation via staked $IDLE.
I like both options, in the sense that both will strength idle Governance.
At this point I feel that option 1 will work best to incentivize more participation.


First I have to thank the Leagues for making stkIDLE voting real🤩 This was a requested utility that benefits the Governance process and can contribute to more user participation.
I also favor option 1 with the expectation that it can contribute to increase community participation.


With the current GovernorAlpha, which is the contract in use for on-chain voting, votes for both stkIDLE and IDLE holders would have equal weight (ie stkIDLE holders will vote with their ‘full’ locked IDLE balance) but votes cannot be ‘splitted’ because a single address (the staking contract which have all the IDLE staked) cannot vote both in favor and against a proposal with only part of the votes


Thank you all for your interesting contributions!
You added many insights to this conversation, and we can now move to the Temperature Check phase!

In the spirit of the proposal, this poll is the first one launched for both $IDLE token holders and stkIDLE holders (IDLE stakers).

:date: End date: 5th August

Poll for $IDLE token holders

Poll for $stkIDLE token holders

Pick one of the following options:
OPTION 1 : Approve option 1 for on-chain stkIDLE vote broadcasting and the proposed solution for off-chain polls
OPTION 2 : Approve option 2 for on-chain stkIDLE vote broadcasting and the proposed solution for off-chain polls
DISCUSS MORE : Discuss more the on-chain and off-chain Voting Framework for stkIDLE holders
AGAINST : Not proceed with this proposal

Cast your vote :writing_hand:

This calculator uses the suggested formula to sum IDLE and stkIDLE votes and will show final results.


What a huge participation!

87% of IDLE stakers voted the poll and thousands of votes came also from IDLE holders :raised_hands:

With 93.6% in favor, the Governance approved the following parameters:
Voting strategy: stkIDLE holders voting space
Threshold to make the poll valid: 30% of circulating stkIDLE voting the poll + at least 70% on the same option

Voting strategy: stkIDLE holders voting space
Threshold to make the poll valid: no quorum required
Voting weight: the voting stkIDLE amount is calculated in the form of weighted IDLE tokens using the formula: “total IDLE staked / total stkIDLE minted * total stkIDLE voting the snapshot * % of each option”

The sum of the voting weights cast by $IDLE and stkIDLE holders represents the final snapshot results.
Starting from today, any off-chain or on-chain proposal would comply with this framework.

The final $IDLE voting weights have been calculated using the approved framework.


Hey @Davide,

I have just summarized the results of the votes for IIP-24.

The IIP won’t be executed on-chain due to the fact that the stkIDLE pool did not reach the minimum threshold of 30% of circulating stkIDLE voting in the poll (only 27% voted).

I’m taking then the chance to further discuss the thresholds set more than 1 year ago. The number of staked IDLE steadily increased and consequently the number of stkIDLE

What about lowering the quorum threshold to 25%


The number of staked IDLE increased a lot, and there are more than 1m tokens locked in the staking module.
As a result, the 30% quorum can now represent a barrier to broadcasting votes on-chain, as we need more votes to reach the threshold.

I agree that this value can be lowered to 15% - 20%, being more flexible


As long as voting rounds are well announced on all channels, there shouldn’t be a querum in my opinion.

Maybe we can think about a different way of schedule and a bit longer voting rounds.
For example, 5 voting days instead of 3, and minimal announced 1 week before start.

In my opinion the website should be a bigger role in things, in this subject…
This kind of things ( voting rounds) must be on the homepage.

1 Like