Energy Web Chain Governance
Summary
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.
EWC Validator Roles & Responsibilities
The Energy Web Chain (EWC) is a public, Proof-of-Authority EVM blockchain.
Unlike other consensus mechanisms that depend on solving arbitrary difficult mathematical puzzles (Proof-of-Work) or locking up funds (Proof-of-Stake), Proof-of-Authority (PoA) relies on a trusted set of "authorities" - nodes that are explicitly permissioned to create blocks and secure the network. The EWC uses a specific PoA algorithm called AuRa (for a technical specification of AuRa, see here).
In the EWC, these authorities are called validator nodes; the organizations who host these nodes are referred to as Validators. To maintain credibility and trust, EWC Validators must be known, reputable entities with valid market influence and/or activity in the global energy sector.
EWC Validators have three primary responsibilities:
Securely host validator nodes: Each Validator organization is expected to host a validator node on the main EWC as well as the Volta test network (maintaining both is critical to have a test environment that mirrors the production EWC as closely as possible). Hosting a node includes installing, maintaining, and monitoring their node while following best practices for key management, regular maintenance / updates to the node host environment, and proactively alerting the EWC community if they identify any potential bugs, vulnerabilities, or risks that can impact validator nodes.
Participate in the EWC Governance: Validators are expected to offer opinions and contribute to technical and non-technical decisions (i.e. voting) relating to modifications of the Energy Web client, protocol, and governance mechanism itself.
Actively participate and contribute to the EWC community: All validators are expected to proactively contribute to the EWC community in one or more of the following ways on a regular basis: Developing Applications & projects on the EWC; Contributing to open-source EW-DOS code; Contributing to Community Fund Proposals; Contributing to Governance Proposals; Community Building.
To view the current list of EWC validators, visit https://validators.energyweb.org/
EWC Validator Eligibility
At the time of the launch of the EWC in June 2019, the initial cohort of 10 Validators (all of whom were founding EWF Affiliates) decided that organizations must meet the following criteria to be eligible to become EWC Validators:
Be legally registered organizations (not individuals);
Be an official Member of EWF (i.e. have an active Membership in good standing), and;
Demonstrate technical and security competence
In February 2020, the Validators asked for greater transparency and a formal structure for the EW membership program. The primary objective is to ensure that all members have sufficient reputation (i.e. good standing) and operational capabilities to strengthen the EW Chain and EW-DOS utility layer. Based on this feedback, the eligibility criteria for EW Membership was updated as follows:
To be eligible for EW Membership, organizations must:
Have legitimate operational activities that will contribute to the mission of EWF and the success of the EW Chain; this includes energy market participants (e.g. grid/market operators, utilities/retailers, aggregators), organizations who provide products and services to energy market participants (e.g. OEMs/technology providers, regulatory/research organizations, financial services), and organizations who actively contribute to the development of open-source technology that enhances the Energy Web Decentralized Operating System.
Have sufficient reputation (or “authority”) to credibly strengthen the Proof-of-Authority consensus mechanism (i.e. must have a minimum of three customer/project references that demonstrate the nature of the operational activities described above).
If you are part of an organization interested in becoming an Energy Web Member and EWC validator, please visit https://www.energyweb.org/workwithus/
EWC Validator Node Operational Functions
EWC validator nodes can:
Establish consensus about the state of the network by verifying the work / behavior of other validator nodes;
Reject blocks / transactions that violate input/output protocols defined by AuRa and the EVM state transition function;
Implement permissioning functions as described here (note: permissoining functions can only be implemented via a majority governance decision).
EWC validator nodes CANNOT:
Inspect or approve the contents of individual transactions;
Unilaterally verify transactions (any given transaction is only finalized after n/2 blocks, with n=total validators);
Associate identities with on-chain accounts;
Unilaterally modify account permissions, network topology, or network state.
EWC Governance Processes
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.
Validator Code of Conduct
The defining feature of the Energy Web Chain is its Proof of Authority consensus mechanism, which relies on reputable entities with valid authority in the global energy sector (i.e. actual market influence) to credibly maintain trust in the network. The adoption and success of the EW Chain is dependent on maintaining an engaged, active community of validators.
Like any community, the EWC validators must be aligned on a common set of principles and follow mutually-agreed upon rules. This Code of Conduct defines the operational and governance expectations and responsibilities for EWC validator organizations. The Code was formally adopted by a supermajority vote in December 2020 and amended by majority vote in December 2021.
Community Expectations for EW Chain Validators
Organizations hosting validator nodes must:
Proactively contribute to the EW Chain community in one or more of the following ways:
Developing Applications & projects: Building or participating in projects, applications, or markets that utilize the open-source EW-DOS technology stack.
Contribution to EW-DOS open-source code: Submitting pull requests to any of the open-source EW-DOS repositories, including the EW Chain, Utility Layer, and Toolkits.
Contributing to Community Fund Proposals: Identifying opportunities to leverage the Community Fund to support the development or integration of other relevant technologies/projects into the EW Chain or broader EW-DOS stack.
Contributing to Governance Proposals: Creating, responding to, and participating in threads (topic discussions) and formal voting proposals in the governance forum on a regular basis.
Community Building: Identifying and recruiting other organizations (e.g. energy market participants, regulators, researchers, technology partners) to participate in projects and/or the EWF community.
Actively participate in the EWC Validator Community:
At least one representative from each validator organization should attend the monthly governance meetings on a regular basis.
At least one representative from each validator organization should regularly (at least monthly) engage in the EWC governance forum to create or respond to different topics and proposals.
Engaging in discussions and helping answer questions from peers in the dedicated validator communication and support channels.
Hold themselves and peer validators accountable to:
Act with honesty, integrity, and openness in working in the best interest of the EWC community.
Comply with all applicable laws, rules, and regulations, particularly anti-bribery, anti-corruption, and anti-money-laundering laws, rules, and regulations.
Avoid conflicts of interest between the validator organization (and its core business) and the EWC (and EWC community).
Refrain from the following unacceptable behavior:
Non-participation: Organizations cannot just “set it and forget it”; if an organization sets up a validator node and subsequently never joins calls, participates in discussions, or contributes the the EWC community in any way then they will face a penalty or be removed from the validator set.
Obvious rent-seeking: The EW Chain is operated by and designed for the energy industry; its purpose (i.e. utility) is to support novel digital solutions that help advance the global energy transition. Validators who are transparently motivated solely by EWT block rewards, abuse their position as validators to create deleterious effects on EWT markets, and/or do not contribute to the mission and success of the EWC ecosystem as described above, will face temporary suspension and/or expulsion from the validator set. Rent-seeking is defined as validators liquidating greater than 10% of their block reward balance within any given 30-day period.
Lack of communication: Organizations who do not respond to official validator communications in the event of an operational or governance task will face temporary suspension and/or possible expulsion.
EW Chain Validator Organizational Accountability
Organizations who host EW Chain validator nodes are responsible for the following:
Keeping their node healthy and private keys secure. This includes implementing best practices for key management, regular maintenance / updates to the node host environment, and proactively alerting the EWC community if they identify any potential bugs, vulnerabilities, or risks that can impact validator nodes. Validator organizations are expected to perform node updates in a timely manner to support EWC network upgrades.
Monitoring their node. Proactively monitoring their node for issues and identifying faults that result in the node failing to successfully seal blocks.
Maintaining internal technical expertise to be self-sufficient. Each organization must possess sufficient internal technical resources to perform routine maintenance on the node / host environment as well as independent troubleshooting and fault diagnosis using the Wiki, Github, and the validator Slack channels (i.e. other validators in the community) as primary support tools.
Responding to official EWC validator communications in a timely manner. Validator organizations are expected to maintain an accurate contact list and respond to communications related to the operation and governance of the EWC.
Dedicating time to participate in meetings and governance decisions. At least one representative from each validator organization should plan on dedicating sufficient time each month to participate in calls, review documentation, and engage in the governance forum.
Code of Conduct Requirements & Enforcement
The following requirements were adopted by a majority vote in December 2021 and are effective immediately. These requirements are in addition to all existing terms of the Code and will be automatically monitored on a forward basis using the Validator dashboard (2022 onwards).
Validator Node Health Requirements
Each Validator node must achieve at least 95% uptime on a rolling 30-day basis (equivalent to no more than 36 hours of unplanned outages over the preceding 30-day period). A node is considered failed if it falls more than 120 blocks behind the latest block and/or fails to seal a block at its designated slot for 5 or more consecutive authority rounds. Node outages during regularly-scheduled network upgrades or planned maintenance windows are excluded from this requirement.
Governance & Community Participation Requirements
Energy Web Validators must participate in at least 75% of governance meetings and 90% of voting events on a rolling 6-month basis. Participation is defined as having one or more representatives from the Validator organization attending meetings and having one representative from the organization casting a vote in open proposals within the governance forum, respectively.
Each quarter, all Energy Web Validators must demonstrate at least one specific example of community participation as defined in the Code (i.e. Developing Projects & Applications, Contribution to open-source EW-DOS source code, Contributing to Governance Proposals, Contributing to Community Fund Proposals, Community Building).
Energy Web Token (EWT) Block Reward Requirements
As leaders and stewards of the EWC, Validators commit to responsibly managing liquidation of EWT reward balances so as to not create deleterious effects on EWT markets. Validators qualify to transfer block rewards from payout addresses to known exchanges if three requirements are met:
Time requirement: Validators must successfully host a node and comply with the Validator Code of Conduct for a period of 6 consecutive months following initial Validator node activation.
Balance requirement: Validators must maintain a minimum balance of block rewards equal to or greater than the trailing 6-month average reward earned per validator (for example, if the average validator earned 15,000 EWT total in block rewards in the preceding 6 months, all validators must maintain a balance of at least 15,000 EWT in their payout addresses to remain eligible).
Rent-seeking requirement: Once the time and balance requirements above are met, Validators may only transfer a maximum of 10% of their current block reward balance within any given 30-day period to known exchange addresses.
Current block reward balance is defined as the sum of EWT held in the Validator’s payout address(es) and EWT used in the Energy Web ecosystem on a rolling 12 month basis for business activity including but not limited to paying Energy Web Membership dues, Energy Web Chain transaction fees, procuring Utility Layer services, and staking EWT.
These requirements are designed to incentivize Validators to use EWT earned from block rewards in the Energy Web ecosystem.
Validator adherence to the Code of Conduct will be automatically monitored using the Energy Web Validator dashboard, which will collect data from the Validator governance forum, node telemetry, and the EWC itself to assign a quantitative performance score for each of the above categories.
The performance of each Validator will be made public via the dashboard so Validators and the wider community can hold each Validator accountable for maintaining compliance.
The Code will be enforced objectively as follows:
Single violation, defined as an initial breach of any one of the above categories, will result in an immediate two-week suspension of the validator node.
Secondary violation, defined as a breach of two categories concurrently, a breach of the code as listed below, or a second violation of a single category within a rolling 12-month period, will result in an immediate four-week suspension of the validator node. Reinstatement of the node is contingent upon the Validator submitting a written plan to remedy past violations and maintain compliance with the Code of Conduct within the governance forum.
Failure to perform necessary node updates as part of a planned network upgrade;
Significant violation, defined as a breach of all three categories concurrently, a breach of the code as listed below, or two or more secondary violations within a rolling 12-month period, will result in permanent expulsion from the EW Chain validator community.
Experiencing a major security failure in which a validator node's host machine and/or private keys are compromised by unauthorized actors;
Engaging in illegal, unethical, or anticompetitive behavior;
Last updated