Governance process
As a Proof-of-Authority network, the Energy Web Chain is governed by its community of known, vetted validators: https://validators.energyweb.org/
The fundamental tenet of the EW Chain governance mechanism is "one validator = one vote", so each validator is equal in terms of decision-making power. The primary function of the governance mechanism is to make decisions regarding:
Validator eligibility & operational standards / procedures
Technical changes & updates to the EW Chain (e.g. network upgrades, client updates, etc.)
Utilization of the Energy Web Community Fund
Evolution of the governance mechanism itself
All decisions are made via a formal voting process, with a simple majority of "yes" votes required to adopt a proposal.
Within the EW Chain validator set, there are three committees that provide leadership and recommendations in three areas as follows:
The Technical Committee focuses on technical upgrades and modifications of the core EW Chain system components as well as the security and performance of validator nodes.
The Community Fund Committee focuses the utilization of the EW Community Fund, including proposals and grants.
The Operations Committee focuses on day-to-day operations of the EW Chain and validator community, including facilitating governance meetings/voting events and managing the governance process itself.
All governance decisions impacting the EW Chain begin with a formal proposal, which is reviewed and ultimately decided by a vote among all validators. The process for making and implementing decisions is as follows:
Validators coordinate proposals via monthly meetings and a dedicated governance forum (this is only available to active validators; a public summary of governance meetings and decisions is published separately).
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 are evaluated on an individual, case-by-case basis. Any validator is free to make a Proposal by creating a new Proposal Page in the Governance Forum.
When a Proposal is created, it is announced to the entire validator community via Slack, email, and meetings. It is then open for comment and review for a period of up to 10 days to provide the validators with an opportunity to offer feedback or revisions to the Proposal language. Once the feedback period expires, the language of the Proposal is finalized.
One or more Proposals are batched into a Voting Event; there is maximum of one Voting Event in any given month. When one or more Proposals are finalized and ready for a vote, the Operations Committee administers the voting process itself:
On average there are 1-2 voting events per quarter (note: the frequency of voting events varies depending on the volume and complexity of proposals, but the intent is to maintain a voting schedule at regular intervals so all validators know in advance when they should expect to evaluate and decide on Proposals).
A voting event is defined as a ten-day period during which Proposal polls will be open for voting.
Each voting event will feature all Proposals that have not been formally decided since the preceding voting event (i.e. all new or pending Proposals).
Voting events are announced at least one week in advance via the regular monthly validator governance call, and via Slack, email, and the Discuss Forum. This announcement will also specify which Proposal(s) shall be decided in the current voting event.
Voting is performed via a binary poll on each Proposal page in the Governance Forum. A “Yes” vote means adopting the proposal exactly as worded and a “No” vote means rejecting the proposal in its entirety.
For a Proposal to be accepted (i.e. a change will be implemented as described in the Proposal) greater than 50% of active validators must vote “Yes”. Any Proposal that does not achieve greater than 50% approval will be rejected; this means the status quo is the default position.
Each validator organization is entitled to one vote, therefore the total number of votes is equal to the total number of validator nodes. The Operations Committee acts as an 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) is 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”.
For example, if there are 20 validator nodes then there are 20 total votes in the current voting event. In this case a Proposal will only be adopted if 11 or more validators vote “Yes”.
Validators are required to participate in at least 90% of voting events each year. During each voting event, all validators receive multiple instructions / reminders via email and Slack to ensure that they have the requisite knowledge and capacity for casting a vote. Failure to participate in at least 90% voting events violates the Validator Code of Conduct, and may result in penalties.
Each validator organization designates 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 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 accidentially cast congruent votes (i.e. all votes are aligned), the Operations Committee 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”), the Operations Committee will attempt to contact the representative(s) of the validator to clarify which position is correct. If the validator’s position is not confirmed 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.
The voting poll automatically closes 10 days after opening, giving validators two full business weeks to cast 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.
Governance process
All governance decisions impacting the EW Chain begin with a formal proposal, which is reviewed and ultimately decided by a vote among all validators. The process for making and implementing decisions is as follows:
Validators coordinate proposals via monthly meetings and a dedicated governance forum (this is only available to active validators; a public summary of governance meetings and decisions is published separately).
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 are evaluated on an individual, case-by-case basis. Any validator is free to make a Proposal by creating a new Proposal Page in the Governance Forum.
When a Proposal is created, it is announced to the entire validator community via Slack, email, and meetings. It is then open for comment and review for a period of up to 10 days to provide the validators with an opportunity to offer feedback or revisions to the Proposal language. Once the feedback period expires, the language of the Proposal is finalized.
One or more Proposals are batched into a Voting Event; there is maximum of one Voting Event in any given month. When one or more Proposals are finalized and ready for a vote, the Operations Committee administers the voting process itself:
On average there are 1-2 voting events per quarter (note: the frequency of voting events varies depending on the volume and complexity of proposals, but the intent is to maintain a voting schedule at regular intervals so all validators know in advance when they should expect to evaluate and decide on Proposals).
A voting event is defined as a ten-day period during which Proposal polls will be open for voting.
Each voting event will feature all Proposals that have not been formally decided since the preceding voting event (i.e. all new or pending Proposals).
Voting events are announced at least one week in advance via the regular monthly validator governance call, and via Slack, email, and the Discuss Forum. This announcement will also specify which Proposal(s) shall be decided in the current voting event.
Voting is performed via a binary poll on each Proposal page in the Governance Forum. A “Yes” vote means adopting the proposal exactly as worded and a “No” vote means rejecting the proposal in its entirety.
For a Proposal to be accepted (i.e. a change will be implemented as described in the Proposal) greater than 50% of active validators must vote “Yes”. Any Proposal that does not achieve greater than 50% approval will be rejected; this means the status quo is the default position.
Each validator organization is entitled to one vote, therefore the total number of votes is equal to the total number of validator nodes. The Operations Committee acts as an 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) is 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”.
For example, if there are 20 validator nodes then there are 20 total votes in the current voting event. In this case a Proposal will only be adopted if 11 or more validators vote “Yes”.
Validators are required to participate in at least 90% of voting events each year. During each voting event, all validators receive multiple instructions / reminders via email and Slack to ensure that they have the requisite knowledge and capacity for casting a vote. Failure to participate in at least 90% voting events violates the Validator Code of Conduct, and may result in penalties.
Each validator organization designates 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 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 accidentially cast congruent votes (i.e. all votes are aligned), the Operations Committee 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”), the Operations Committee will attempt to contact the representative(s) of the validator to clarify which position is correct. If the validator’s position is not confirmed 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.
The voting poll automatically closes 10 days after opening, giving validators two full business weeks to cast 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, the Operations Committee reviews 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, the final results indicating how each validator votes are shared with the rest of 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.
For accepted proposals (defined as greater than 50% of total votes cast in favor / “Yes”):
The relevant validator Committee works with the validator(s) who initiated the proposal to formulate an implementation plan and timeline.
For rejected proposals (defined as less than or equal to 50% of total votes cast in favor / “Yes”):
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 the following month.
Rejected proposals that are not materially revised may be re-considered for a vote after a period of 6 months following the rejection vote has elapsed.
Last updated