Author
Treasury League
Summary
This post would like to define the framework that makes off-chain polls eligible for on-chain vote broadcasting on behalf of stkIDLE holders.
Rationale
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).
Solution
ON-CHAIN VOTES
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.
OFF-CHAIN VOTES
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!
End date: 5th August
