Following the launch of the Energy Web Chain in June 2019, EWF and the initial validator set collectively decided to use a consensus governance model based on Ethereum’s governance model in which validators convene via bi-weekly calls to evaluate and make decisions through discussion and “rough consensus”. In that model, the default assumption is that a proposal is accepted unless a majority opposes it. The discussions and decisions made via this process are available in the Governance Meeting Minutes.
As of Q4 2019, this model is no longer fit for purpose because the validator is large enough (20 validators and growing) and geographically diverse enough (12 countries spanning 16 time zones) that it is difficult to get consistent participation in the bi-weekly call from a majority of validators, which in turn makes it difficult for validators to express their opinions or true preferences about certain topics.
The EW Chain ecosystem will benefit from a more formal process of decision making and more robust record keeping of what decisions were made as well as how they were made. The EW Chain governance roadmap includes the potential for on-chain voting and experimentation with weighting (potentially governance by gas as described in the original EWF white paper) but those mechanisms require further research and development. As a first step, the EW Chain community needs a scalable mechanism to formalize decision making and have an audit trail of what decisions were made.
Proposed Initial Voting Mechanism
Per the group discussion in the 17 October governance call, a polling or voting system should be implemented using conventional technologies (i.e. not reliant on on-chain governance). After evaluating and discussing multiple options, in the 31 October governance call the validators collectively decided to use the EWF Discourse instance, EW Chain Discuss Forum, as the system for implementing an initial voting mechanism.
Below is a description of the initial voting procedures for EW Chain Governance. Importantly, this is only a first step in the evolution of the EW Chain Governance mechanism and the decision-making procedures described here are expected to change as the community continues to learn and grow.
Proposals are specific changes to the EW Chain protocol, governance mechanism, or operating procedures that require a collective decision by the EW Chain validators. All Proposals will be evaluated on an individual basis. Proposals will be related to Topic threads about a given issue.
NOTE: Proposals are exclusively related to the governance of the EW Chain itself. EWF’s organizational structure and operations, the EWF membership program, and EWF open-source software toolkits / applications are excluded from this governance mechanism and are managed at the sole discretion of EWF.
Any validator is free to make a Proposal, by creating a new Proposal Page in the Discuss Forum.
Fig. 1: Creating a Draft Proposal
Fig. 2: Providing Feedback on Draft Proposal
Fig. 3: Closed Draft Proposal
Immediately prior to the beginning of the voting event, EWF creates a new Proposal Topic page for each Proposal with precise language based on feedback in the associated topic thread and input from the validators (as described above). The Proposal Topic will feature a binary poll, with a “Yes” vote meaning adopting the proposal exactly as worded and a “No” vote meaning the proposal is rejected in entirety.
Fig. 4: Final Proposal for Vote
For a Proposal to be accepted (i.e. a change will be implemented as described in the Proposal) greater than 50% of the votes must be “Yes”. Any Proposal that does not achieve greater than 50% approval will be rejected.
Each validator organization is entitled to one vote, therefore the total number of votes is equal to the total number of validator nodes. EWF will be the sole administrator capable of reviewing vote submissions and will delete any duplicate votes from validator organizations.
Non-participation (i.e. a validator does not cast a vote) shall be counted as a “No” vote by default. This means that in order to implement the change as described in the proposal, a majority of validators must proactively vote “Yes”.
Validators are strongly encouraged, but not required, to participate in voting events. During each voting event, EWF will monitor voting activity and proactively contact validators who have not cast a vote to ensure that they have the requisite knowledge and capacity for casting a vote. If voting turnout proves to be a problem (e.g. a significant percentage of validators fail to participate in multiple consecutive voting events), EWF may work with the validators to change the frequency and/or duration of voting events, experiment with vote delegation mechanisms, and/or experiment with additional incentive and/or penalty mechanisms.
EWF will announce the commencement of each voting period via multiple channels (Slack, Discuss forum, email, governance calls). Each voting period shall be five days.
Each validator organization should designate only one representative to cast its vote during the voting period. Each voting representative acknowledges that they are responsible for casting a vote on behalf of their company, and that their company’s vote will be shared with the other governance participants (i.e. EWF and the other validators). Every validator organization is responsible for its own internal policies and procedures for voting event participation. Validators recognize that casting a vote for or against a given Proposal is binding for that Proposal only.
If multiple users from a single validator organization cast congruent votes (i.e. all votes are aligned), EWF will automatically de-duplicate the results and the company’s vote will be recorded accordingly.
If multiple users from a single validator organization cast conflicting votes (e.g. some “yes” and some “no”), EWF will attempt to contact the representative(s) of the validator to clarify which position is correct. If EWF is unable to clarify the validator’s position by the end of the voting period, then the conflicting votes shall be collectively be counted as a “No” vote by the validator for that Proposal.
During the voting period, all members of the Discuss Forum will be able to view how many votes have been cast, but the vote results will not be visible.
Fig 5: View of Results During Open Voting Period
The voting poll will be automatically closed 120 hours (five days) after opening. EWF will create voting polls only on Mondays make best efforts to avoid weeks in which holiday schedules disrupt normal business operations for a majority of validators. The timing of the poll creation shall be scheduled in such a way to provide every validator with five business days to make their vote.
Upon closing of the voting period, the anonymized results (i.e. distribution of votes between “Yes” and “No”) will be automatically viewable on the Proposal Topic page.
Following the close of the voting period, EWF will review the votes to ensure that only one vote per validator organization is counted.
Though the vote itself is “secret” voting, meaning no voters have knowledge of how other voters have cast their ballot, EWF will share the final results with with the validator set (and no other parties) after the voting period closes via documentation in the Proposal Topic page in order to maintain accountability, establish a robust audit trail for posterity, and reduce the potential for vote buying or collusion.
Fig. 6: View of Results After Voting Period is Closed
For accepted proposals (defined as greater than 50% of total votes cast in favor / “Yes”):
For rejected proposals (defined as less than or equal to 50% of total votes cast in favor / “Yes”):
EWF and/or the validator(s) who initiated the proposal or who voted in favor of the failed proposal may revise the language and/or parameters of the proposal and present the revised proposal to the community for consideration. Revised proposals that materially differ from the original rejected proposals may be put to a vote following the process described in this document.
Rejected proposals that are not materially revised may be re-considered for a vote after a period of 3 months following the rejection vote has elapsed.
To reiterate, in this system the “default” position is the status quo. Changes are only made when a majority of validators proactively vote “Yes” to approve the Proposal(s). Validators who do not participate are assumed to reject the proposal; habitual non-participation may lead to changes in the voting procedures including possible incentive and/or penalty mechanisms to encourage participation.