DigixDAO User Guide: Voting

This is part (5/6) of the DigixDAO User Guide that will be released over the next few days, making it easier for users to digest the entirety of the guide.

We will be releasing the full guide in a downloadable PDF at the end of the series for those who prefer an offline version of our guide.

Another guide, focusing on interacting with the DigixDAO governance platform will be provided as well in the coming days.

Voting

Voting underpins every decision in DigixDAO and was designed for a single purpose — to decide whether funds should be released to a Proposer. Before any funds are released, a Project has to be Endorsed by a Moderator, pass the Moderator voting round at the Draft stage and thereafter pass the Participant voting round at the Proposal stage. This section will introduce the mechanics of Endorsements, Moderator and Participant voting and the Quorum and Approval Threshold requirements for Projects and Special Projects.

Moderator Endorsement

Before any Project can be voted on, it has to first be Endorsed by a Moderator at the Idea stage. Although Endorsement should be relatively easy to achieve, the purpose of Endorsement is to allow Moderators to filter out any Projects which might be considered unfit for DigixDAO.

Moderator Voting

During the Draft stage, Moderators are given 10 days to vote after it is finalised by a Proposer. Moderators are allowed to vote either “yes” or “no” on a Project. Results of Moderator votes are updated immediately and can be viewed by all Participants. Moderators are able to change their vote at any time during the 10-day period. Provided that the relevant Quorum and Approval Threshold requirements are met, the Project will move to the Proposal stage for Participant voting.

Participant Voting: Commit-Reveal

After a Project is approved by Moderators at the Draft stage, the remaining voting phases are open to all Participants to cast their vote. Participants will first be able to vote on a Project at the Proposal stage, and also thereafter at the relevant Review stages of a Project. Contrary to Moderator voting, Participant voting is done through a 2-stage Commit-Reveal process.

The table below compares the voting periods for Participant voting at the Proposal and Review stages:

The Commit-Reveal duration is longer for a Special Project (to change the configurations of DigixDAO) compared to a Project (to request for funding) to allow Participants more time to cast their votes. After a Projects is approved at the Proposal stage, the duration for Commit-Reveal is shorter at the Review stage as it takes less time for Participants to verify whether a Milestone has been delivered by the Proposer.

As a Participant at the Commit phase, you are able to commit your vote with either a “yes” or “no”. While committing your vote, you will be asked to download a commit file which represents your committed vote. At the Commit phase, you are able to change your vote at any time by downloading a new commit file. As the new commit file invalidates all your previous commit files, you will only be able to reveal your most recent committed vote at the Reveal phase.

At the Reveal phase, you can only reveal your committed vote by providing your latest commit file. As only votes which are successfully revealed are counted, we advise you to keep track of the Projects which you have initially committed your vote.

Quorum

Quorum is the minimum Stake a Project must receive for a particular voting round to be valid. If the Quorum requirement is not met, the Project will not pass a voting round even if a majority vote is achieved. Quorum is necessary for all voting rounds of any Project and is applicable for both Moderator and Participant voting. As the amount of ETH requested increases, the Quorum for the minimum Stake also increases in a linear manner.

The Quorum required for each voting round is determined by the formula below:

Where:

• Total Stake in Quarter is the total value of all the Stake in DigixDAO for a particular Quarter.
• x% is the minimum % of Stake that is required even if 0 ETH is requested. We have set this value to 5% for the launch of DigixDAO.
• ETH requested by Project is the amount of ETH a Project is requesting from DigixDAO. During Moderator Voting at the Draft stage, this value would be the total amount of ETH that is requested by the Project for the first Milestone. During Participant Voting at the Proposal and Review stages, this value would be the amount of ETH requested to fund the delivery of the next Milestone.
• ETH currently in DigixDAO is the amount of ETH currently available for funding Projects in DigixDAO, which is 20,000 ETH at the launch of DigixDAO.
• Scaling Factor is necessary to reflect the different levels of Quorum requirements of (i) Moderator voting at the Draft stage, (ii) Participant voting at the Proposal stage and intermediary Review stages and (iii) Participant voting at the final Review stage. For the launch of DigixDAO, the scaling factor is set at 0.35, 0.25 and 0.07 for (i), (ii) and (iii) respectively. The value of the scaling factor for (i) is higher than (ii) and (iii) as Moderators should be more active in participation as compared to Participants. The value of (ii) is higher than (iii) because the voting at the final Review stage does not release further Milestone funding, which should warrant a lower quorum requirement.

Applying the Quorum formula to a Project put up for Participant Voting during the Proposal stage and assuming:

• Total Locked DGD in Quarter is 1,000,000 DGDs
• x% is 5%
• ETH requested by Project is 20 ETH to deliver the first Milestone
• ETH currently in DigixDAO is 20,000 ETH
• Scaling Factor is 0.25

The Quorum required for the Participant voting round to be valid would be 50,250 Stake.

Approval Threshold

Where Quorum deals with the validity of a voting round, the Approval Threshold considers whether that voting round has been approved based on the % of the total number of votes that have been successfully cast. For all voting rounds, Projects require an Approval Threshold of more than 50%, which translates to a simple majority vote from all eligible voters in a given voting round.

Taking the assumptions in the Project example above, assuming that a total of 50,250 Stake was successfully cast, the Project would require an approval threshold of more than 25,125 Stake to be approved by Participants.

Predictive Voting Incentive

To incentivise careful consideration when voting on Projects, Participants receive a small amount of bonus Reputation Points if the result of the subsequent voting round matches their vote in the current voting round. Reputation Points are considered when determining the amount of DGX a Participant can claim as rewards at the end of a Quarter. Taking a Participant’s vote during the Proposal stage as an example:

If eligible, the bonus Reputation Points that a Participant will receive is determined by the formula below, which considers the correctly predicted result as an imaginary vote solely for the purposes of calculating the bonus Reputation Points:

where:

• Bonus Reputation Points is the bonus Reputation Points a Participant would receive for correctly predicting the result in the subsequent voting round
• Quarter Points earned from imaginary vote is the Quarter Points that would have been awarded to the Participant had the imaginary vote been considered as an actual vote
• Reputation Points earned per Quarter Point is used to convert the value of Quarter Points to Reputation Points as the Predictive Voting incentive is distributed in terms of Reputation Points. The Predictive Voting incentive is not suitable for distribution as Quarter Points because Quarter Points are meant to measure active participation in DigixDAO. Considering the nature of Predictive Voting incentive, no action was taken by the Participant to earn the incentive
• p% is necessary to scale down the amount of bonus Reputation Points received from Predictive Voting. Scaling is necessary as in fact, no action was taken by the Participant to earn the bonus Reputation Points. Hence, the weight of each bonus Reputation Point received from Predictive Voting should not be the same as each Quarter Point earned by a Participant for casting a real vote. For the launch of DigixDAO, a value of 15% was set for p%

Applying the Predictive Voting incentive formula for the configuration values that are set for the launch of DigixDAO:

• Quarter Points earned from imaginary vote is 1
• Reputation Points earned from imaginary vote is 1
• p% is 15%

a Participant would earn a bonus of 0.15 Reputation Points for each instance where the result of the subsequent voting round matches his vote in the current voting round.

We always appreciate feedback from the community on any angles, so do drop us a note or join our channels below:

· Medium: https://medium.com/digix

· Reddit: http://reddit.com/r/digix

· Twitter: https://twitter.com/digixglobal

· Facebook: https://www.facebook.com/digixglobal/

· Github: https://github.com/digixglobal

· Telegram: https://t.me/digixofficial§

· Discord: https://discord.gg/CCDBJJC

· Instagram: https://www.instagram.com/digix.global/

· YouTube: http://www.youtube.com/c/DigixGlobal