Commit Phase

The Commit Phase lasts for 3 days, after the end of the Proposal Phase. In the Commit Phase, Trustees order ballots in order of policy preference, ranking their highest policy preference at the top of the ballot, and their lowest policy preference at the bottom of the ballot. The default proposal is included in each ballot as well. Votes are scored using a modified Borda ballot counting method. Votes are also submitted to the chain encrypted to prevent tactical voting.

Committing a Vote

Commits are submitted to the CurrencyGovernance.sol contract for that generation. In order to determine the current CurrencyGovernance.sol contract, please see the section on Finding Active Contracts. Commits can only be submitted by addresses designated as Trustees in the TrustedNodes.sol contract.

Committing a vote is managed by the commit(bytes32 _commitment) function in the CurrencyGovernance.sol contract. The propose function takes the following inputs:

• bytes32 _commitment: This is a keccak256 hash of two values, a seed chosen by the trustee as a secret, the address of the trustee submitting the commitment, and a Votes array, detailed below. The seed is hashed with the data to prevent brute-forcing the Trustees' vote.

Here is some example code in Solidity for creating the commitment:

function encodeBallot(
    bytes32 _seed,
    Vote[] _votes
    )
    public
    pure
    returns (bytes memory)
{
    return keccak256(abi.encode(
        _seed,
        msg.sender,
        _votes
        ));
}

The Vote[] array is comprised of Vote structs that have two properties, an address proposal and an integer score. The address keys into the already submitted proposals in the previous phase. The purpose of the score is detailed below but has to be a number from 1 to the number of elements in the array, inclusive. It denotes the number of points this ballot gives the corresponding proposal, so a high score is for proposals that are supported a lot and a low score is for proposals that are supported a little.

The layout of this array is very important as there are many ways where it can be seen as invalid by the system! Each vote must be for a proposal that's actually being voted on. Additionally, each vote must be for a unique proposal and have a unique score (from 1 to the number submitted). Finally, the array must be sorted in strictly increasing order of the proposal addresses being voted on (comparing the hex values as if they were numbers). This is a measure to efficiently ensure that no proposal is voted on multiple times.

The number of votes must also be non-zero but is not required to include all existing proposals. Remember, even though each trustee has a default vote for the default proposal, they must successfully submit a valid ballot to count as having voted. A vote for only the default proposal is still a valid vote! It can be referenced while voting via the zero address.

The commit effectively posts a hash of the Trustee's vote to the smart contracts. Later, in the Reveal Phase, the Trustee provides the seed and the votes used to generate the hash, and the protocol checks the commit to ensure they are the same.

Modified Borda Count Vote

Ballots generated in the Commit Phase are subject to a voting scheme called Modified Borda Count voting. The strengths and weaknesses of Borda Count are well understood and can be accessed on the linked Wikipedia page.

In a Borda Count voting system, a voter ranks as many proposals as they wish. The first option is given a score equal to the number of ranked proposals, the second vote is given the score the first was given minus 1, and so on. All unranked proposals receive zero.

Example Borda Count Ballot. Note that Rank 1 receives the highest number of points, equal to the number of proposals.

During the reveal phase votes are tallied and a winner is publicly updated upon each reveal. Invalid votes (empty ballots, ballots that are not revealed, ballots that attempt to cheat the voting system, and ballots for trustees that never submitted a commitment) are counted as ballots ranking the default proposal as the first choice, with all other proposals left unranked. A proposal that ties the current winner does not replace it; in other words, ties are broken by favoring the proposal revealed first.

In the example election above, Proposal A wins with 7 points, followed by Proposal B with 6 points, and Proposal C with 5 points.