CONTENTS OVERVIEW

An operator is an entity who participates in hosting worker nodes to execute business case logic in a network of worker nodes. The operator is represented by their dedicated EWX account.

An EWX account may be created using the publicly available Polkadot wallets. EWX is currently supported by below wallets:

1. Nova Wallet - https://novawallet.io/

2. SubWallet - https://www.subwallet.app/

The EWX account MUST NOT be used as a worker node account because they serve different purposes. The operator account nominates a worker node account which can represent the operator when submitting worker node results to EWX.

An EWX account can hold EWT for staking and claiming rewards.

A subscription is an EWT staking action initiated by the worker node operator to agree and commit in actively participating in executing a group of solutions subject to the solution group’s terms and conditions. In return, the operators expect to gain rewards by diligently performing the solution executions while having the possibility to get slashed when underperforming. The solution registrar sets the stake amounts and other configurations upon the creation of the solution group and solutions.

The Multisig Pallet in the Polkadot SDK provides a robust mechanism for multi-signature account management, enabling secure and coordinated actions among multiple participants. This pallet is integral for collaborative decision-making and securing high-value operations in decentralized ecosystems.

Key functionalities:

• Creation of Multisig Agreements: Facilitates the creation of multi signature agreements among multiple accounts with a defined threshold of required approvals. Supports both single-use and reusable multi signature setups for flexibility in different use cases.

• Threshold-Based Execution: Allows execution of transactions once the required threshold of signatures has been collected and ensures that no action is performed unless the predefined consensus is reached among signatories.

• Time-Locked Approvals: Introduces optional time-locks for multisig operations, giving signatories a limited window to approve or reject a proposal and ensures timely decision-making and reduces risks associated with prolonged inactivity.

Energy Web X is an ecosystem comprising multiple applications and services including but not limited to the EWX blockchain, EWX Token Bridge, Lift & Lower Pallets, worker nodes, and worker node networks.

EWX is a substrate-based blockchain under EWF. It is the backbone of the entire EWX ecosystem. The EWX Token Bridge is an EWC Smart Contract which facilitates the migration of EWT from EWC to EWX. The lift and lower pallets are equivalent to EVM-based smart contracts which enables the lifting and lowering of EWTs between EWC and EWX.

In order to better understand the Energy Web Ecosystem, this section provides a high level introduction to the core concepts and terminologies which will be used across this documentation.

The server-based worker node is a decentralized application mainly offered to enterprises to be deployed in highly configurable execution environments on-cloud or on-premises. Deployment can be done via Dockerization.

It is mainly composed of the worker node dApp and a Node RED server bundled in a single package. It automatically syncs the subscriptions of the worker node account set in its environment variable and subsequently runs any active solutions for diligent execution and submission of votes.

Lowering is the exact opposite of token lifting. It is the process of migrating EWT from EWX to EWC. Normally, this will be used to withdraw rewards claimed after gaining them by operating worker nodes.

The Scheduler Pallet provides a powerful framework for scheduling time-based and event-driven tasks within the runtime. It is integral for automating and orchestrating on-chain operations at specified block heights or based on dynamic triggers.

Key functionalities:

• Scheduled Task Management: Enables the scheduling of on-chain calls to execute at a specified block number or recurring intervals and supports delayed execution, enabling precise control over task timing for one-off or periodic operations.

• Flexible Call Dispatching: Allows scheduling of any callable extrinsics, making it versatile for automating runtime functionality. It also supports tasks requiring root-level permissions or limited by specific user-defined filters.

Learn about the EWC Governance and the role of Validators in depth in our .

The XCM Pallet is a critical module in the Polkadot SDK that facilitates Cross-Consensus Messaging (XCM), enabling secure and interoperable communication between different chains. This pallet is fundamental to Polkadot’s interoperability framework, allowing Parachains, relay chains, and other consensus systems to exchange messages and assets seamlessly.

Key functionalities:

• Cross-Consensus Communication: Implements a universal messaging protocol for interaction between different consensus systems and allows Parachains and relay chains to send and receive messages reliably, forming the backbone of Polkadot’s interoperability.

• Asset Transfer and Management: Supports transferring assets, such as tokens or NFTs, across chains using the XCM protocol.

The Marketplace App is a decentralized desktop application which provides an intuitive interface for the general community with limited technical background to easily participate in running worker nodes on their local machines. It also provides an interface to lift and lower EWTs. It supports Windows, MacOS, and Ubuntu systems.

The Marketplace App is a decentralized desktop application which provides an intuitive interface for the general community having limited technical background to easily participate in running worker nodes on their local machines.

It supports Windows, MacOS, and Ubuntu systems.

Download and Installation

Download and install the Marketplace app on your machine from the download links provided in the official .

The Eth-Bridge Pallet is a component responsible for facilitating interactions between a Substrate-based blockchain and an Ethereum-based network. It implements the BridgeInterface and provides functionality for publishing transactions and generating lower proofs. This enables other pallets that implement BridgeInterfaceNotification to execute functions on the Ethereum-based smart contract or request proofs for token operations.

Key functionalities:

• Transaction Publishing and Management: Accepts and processes transaction requests from external pallets, handling them sequentially to ensure that they are executed in the order they are received. Publishes transactions by packaging and encoding them to be compatible with Ethereum, complete with timestamps and unique transaction IDs to track and verify their status.

• Consensus and Confirmation Collection: Manages the collection of ECDSA confirmations from authors to prove consensus for a transaction, ensuring that all required signatures are gathered before submission. Utilizes a confirmation system where authors can add their confirmations until the required threshold is met, after which the transaction is ready to be dispatched to Ethereum.

• Dispatching Transactions to Ethereum: Appoints an author responsible for sending a transaction to Ethereum once sufficient confirmations have been collected.

• On-Chain and Off-Chain Coordination: Integrates with off-chain workers (OCWs) to monitor unresolved transactions and prompt authors to act as needed. It also alerts the originating pallet with the outcome of a transaction through the BridgeInterfaceNotification callback, enabling state commitment or rollback based on the results.

The Avn Pallet provides functionality that is common for other pallets such as handling offchain worker validations, managing a list of validator accounts and their signing keys.

Key functionalities:

• Validator List: Maintains a list of active validators, each represented by an address and a cryptographic key.

• Bridge Contract Address: Stores the address of an associated bridge contract on the Ethereum network.

• Off-Chain Worker Integration: Provides mechanisms for off-chain workers to run only once per block to avoid duplicate operations. Includes functionality for interacting with external services for retrieving finalized blocks and requesting signatures.

• Signature Verification: Offers tools to validate Ethereum ECDSA signatures, ensuring that signatures are produced by known validators.

Lifting & Lowering

What is lifting?

Lifting is the process of migrating EWTs from Energy Web Chain (EWC) to Energy Web X (EWX).

How long does it take to reflect my lifted EWT to my account?

Lifted tokens take approximately 30 minutes to reflect in your EWX account after successful transaction from the Marketplace app.

What is lowering?

Lowering is the process of migrating EWTs from Energy Web X (EWX) to Energy Web Chain (EWC).

How long does it take to reflect my lowered EWT to my account?

Lowered tokens take approximately 24 hours to reflect in your EWC account after successful transaction from the Marketplace app.

A vote is initiated upon the submission of the Merkle-tree root hash of the calculated data for each specific use-case. All votes are tied to a voting round.

A voting round is determined by the unique identifier provided by each BC when the Smart Flow fetches the data from the respective BC system for each specific use-case.

For the current implementation, each worker computes the consensus right after its successful submission of a vote in a voting round. The worker fetches the previous vote submissions from EWX under the current voting round. The worker groups the root hashes and counts the submissions from unique operators per unique root hash.

The consensus is determined when a particular root hash contains the majority of submitted votes.

When the majority of votes is not met, the voting round becomes stale and no response coming from the network of worker nodes is expected. However, this scenario may be confirmed externally by directly querying on-chain using a third-party application which will not be available in this phase.

EWF will develop a more robust consensus orchestrator environment and will be available towards Q4 2024. More details will be shared once requirements are finalized at EWF.

InEExS Project Consensus Mechanism

In the case of the InEExS Project, consensus is determined using the formula below:

M = TO * 0.5 + 1

Wherein, M = majority of votes, and TO = Total operators subscribed in the solution group.

A worker node is a decentralized application (dApp) which enables enterprises to construct distributed computing networks which securely execute sensitive business operations. Each worker node can execute multiple solutions at the same time; subject to the limits of each operator system.

Worker nodes were originally developed to solve a paradox that hinders advanced renewable energy tracking solutions like 24x7 matching and green electric vehicle charging: credibility relies on accurate, publicly verifiable results (e.g., proof that digital representations of renewables are not double counted). But inputs from separate organizations, such as granular renewable energy production and electricity demand data, are commercially sensitive and need to remain private. Complex commercial, legal, and technical requirements often make it challenging for a single actor to unilaterally access and process all requisite data. The ability to establish a shared source of truth from segregated, individual information sources has been an ongoing challenge in multilateral settings; the challenge is even greater for energy market participants seeking to exchange and process granular data to procure services from distributed energy resources.

The Energy Web Worker Node toolkit solves these challenges by enabling enterprises to configure, launch, and maintain distributed computing networks that ingest data from external sources, execute custom workflows based on business logic, and vote on results in order to establish consensus without revealing or modifying the underlying data. Worker Nodes apply concepts and components from blockchain technology in a novel, enterprise-friendly architecture to provide all stakeholders with cryptographic proof that mutually agreed rules and processes are followed correctly, ensure computational outputs from business processes are correct, and preserve the privacy and integrity of underlying data for auditing purposes.

Currently, there are 2 types of worker nodes available:

1. Server-based Worker Node

2. Marketplace Desktop Application

The Assets Pallet is a core component in the Polkadot SDK that provides comprehensive tools for managing and interacting with fungible token assets. This pallet enables the creation, transfer, and governance of assets on-chain, supporting decentralized ecosystems with robust asset functionality.

Key functionalities:

• Asset Creation and Registration: Allows users or entities to create new fungible assets with customizable properties such as total supply, name, and metadata. It also enforces administrative roles for managing the lifecycle of assets, including minting and burning.

• Asset Transfer and Balances Management: Enables secure and efficient transfer of assets between accounts and tracks account balances for each asset type, with configurable rules for minimum balances and dust handling.

• Minting and Burning Mechanisms: Provides authorized administrators the ability to mint new tokens to increase supply or burn tokens to reduce supply. It also ensures precise control over asset supply and its distribution across holders.

• Permissioned Operations: Supports a robust permissions system to define administrative roles such as asset owners, issuers, and freezers.

To acquire $stEWT, please follow the steps described in the Liquid stake to get stEWTsection.

The Ethereum-events pallet handles the management of Ethereum events and their processing within the blockchain environment. It supports tracking event submissions, validation, and challenges while providing secure mechanisms for event processing and recording.

Key functionalities:

• Event Tracking and Management: Efficiently tracks and manages Ethereum events, including ingress counters, to maintain order and ensure unique identification of events.

• Event Validation Pipeline: Handles the lifecycle of Ethereum events from submission to processing, with mechanisms to mark events as unchecked, pending, or processed.

• Challenge and Validation System: Allows validators to challenge event validity, enforcing quorum-based decision-making for robust and decentralized validation.

• Event Integrity Protection: Ensures that events cannot be processed more than once, maintaining a consistent and secure state in the blockchain’s event records.

There are two options on how to deploy your Worker Node:

1. If you would like to run Worker Node in fully managed (SaaS) or in Bring your own cloud (BYOC) mode, please our Launchpad Worker Node offering. Please refer to Worker Node Managed Offering Documentation for full details.

2. Alternatively If you would like to use open-sourced version, please follow instructions covered in Worker Node Server Energy Web Repository.

Reward period is the schedule for worker nodes to participate in vote submissions and gain rewards. The solution registrar defines the duration of reward periods. For example, if rewards are to be paid daily, the reward period needs to be set to a 24-hour estimated equivalent in blocks. Each block is approximately 12 seconds in duration.

The Energy Web Chain (EWC) is a publicly-accessible EVM-based blockchain formed as a software infrastructure with permissioned validators hosted by EWF Affiliate organizations. It relies on a Proof-of-Authority consensus mechanism with capacity for a 30x performance improvement and 2-3 orders of magnitude lower energy consumption compared to Ethereum.

The KYC Verification comes with three (3) statuses:

1. KYC Verification In-Progress

2. KYC Verification Successful

3. KYC Verification Rejected

KYC Verification In-Progress

When KYC verification is in processing phase, the Marketplace app shows the respective status on the screen.

KYC Verification Successful

When KYC verification succeeds, the operator will be whitelisted in the target solution group and will be allowed to subscribe to it. The screen will display the KYC status as "KYC Verified".

To proceed with the subscription process, please refer to page.

For solution groups that enable KYC verification, not everyone is eligible to participate in submitting solution results as votes. In such case, an info icon will be shown in the Dashboard to provide such detail:

KYC Verification Rejected

When KYC verification is rejected, the operator is no longer allowed to subscribe to the target solution group.

The Energy Web Chain is comprised of different components that provide the functionalities determined by the blockchain’s protocol.

Broadly speaking, protocols are defined rules and standards. Internet protocols, like HTTP protocol for example, define standard procedures for the transfer of data over the internet.

A blockchain network is no different. In a decentralized and self-executing system like a public blockchain, protocols are of significant importance in establishing how the system works, and then ensuring that the system continues to self-execute as designed.

Protocols exist to determine specific aspects of blockchain behavior, such as:

• How transactions are validated

• Who gets to validate transactions and when

• How validators are compensated

• How peer nodes interact with each other

The system components below ensure that the Energy Web blockchain adheres to Ethereum's protocols, and the protocols established by OpenEthereum's . (OpenEthereum is the Ethereum client that is used by the Energy Web Chain.

System Components

System Contracts are that implement the protocols. Read more about Energy Web's system contracts

The validator node architecture monitors validator behavior to ensure consistent and secure blockchain operation. Read more about the validator node architecture

To disconnect, click on the operator address located on the top-right of the screen and then click on the disconnect icon as highlighted below:

Some solution groups published in the Energy Web X ecosystem require operators to submit KYC details for verification before they are allowed to subscribe.

This section provides step by step processes in the KYC verification.

Your total $stEWT balance of the currently connected EWX account is available on the left panel of the Marketplace app or at the account dialog on the upper right corner of the screen.

The Energy Web Chain (EWC) is an open-source, public blockchain blockchain technology. It is the foundational trust and persistence layer of EW-DOS.

The blockchain performs three key functions in EW-DOS:

1. Provides the smart contract mechanism to store (DIDS)

2. Facilitates on-chain verification and transactions between parties

3. Executes smart contracts that are used by EW-DOS's decentralized applications, SDKs and utility packages.‌

Each set of worker nodes deployed by Energy Web, Energy Web customers of any energy enterprise is governed and anchored to unique pallets on Energy Web X(in traditional Web 3 language a pallet on a substrate-based blockchain is similar to a smart contract on an EVM but more powerful and flexible). Whit this architecture in place, Energy Web has. scalable way to launch worker nodes.

What is the Energy Web Token?

The is the native utility token of the Energy Web Decentralized Operating System (EW-DOS). Tokens are used in EW-DOS to pay for on the , and for staking to secure the as well as . You will need EWT in your digital wallet (we recommend using ) if you want to make transactions or use applications or smart contracts that are deployed on the Energy Web Chain main network.

Sign up as an operator

Prerequisites

Prerequisites

• Connected EWX account

• Worker account seed phrase

Start earning rewards by subscribing to any of the solution group available on Marketplace. Browse through the solution group list on the Discover page, and pick on a solution group of your interest to see its details such as minimum/maximum subscription amount, base reward, active solution group reward and more.

Guides available for subscriptions:

The Energy Web Token (EWT) is the native utility token to access services and orchestrate stakeholders within its blockchain system. In the context of Energy Web Chain, EWT compensates validators for processing transactions, and are used to pay for transactions.

Energy Web X leverages and complements the existing Energy Web Chain by introducing new technical capabilities that streamline the deployment and operation of Worker Node networks.

To maximize the security of every Energy Web solution using worker nodes, EWT will be required to interact with worker nodes and Energy Web X. Most notably, Energy Web Tokens will be required to:

• Reward worker node networks: worker nodes are software packages that need to be run by individuals and/or businesses. To attract entities to run worker nodes, enterprises will need to include rewards, paid in EWT, that compensate worker node operators for their work.

A ZEL Request refers to a "Zero Export Limit" request. This request is made by generators or dispatchable assets to set their output to zero, often indicating that they are not able to inject power into the grid for a specific reason.

ZEL Requests can be relevant in several scenarios, such as:

1. Maintenance: When maintenance is being conducted on a generator, it may need to curtail its output temporarily.

2. Technical Issues: If there are technical problems that prevent a generator from operating safely or effectively, a ZEL Request signals that they will not produce energy.

The Marketplace app allows you to browse through a list of available solution groups with or without a wallet being connected. Without the connection however, you won't be able to perform token lifting, lowering or subscription. To connect:

1. Click on Connect button either on the left-side panel or on top corner of the screen

Prerequisite

• Operator account with funds more than the minimum subscription amount

The Balances Pallet is a core module in the Polkadot SDK, responsible for managing token balances, enabling secure transfers, and supporting the blockchain’s economic operations. It provides robust mechanisms for balance management, transaction fees, and account lifecycle, ensuring a stable and efficient economic framework for Substrate-based blockchains.

Key functionalities:

• Account Balances Management: Maintains and tracks balances for all accounts, divided into free balance (spendable) and reserved balance (locked for specific purposes).

• Token Transfers: Enables secure token transfers between accounts with features like keep-alive transfers to prevent accounts from being reaped.

An operator account is only allowed to link with a single worker account at a time. Unlinking allows you to generate a new worker account or import another worker account that can be linked with the same operator.

Prerequisites

Some of the solution groups have Unsubscription Delay enabled. This means that unsubscription will only take place after a certain number of blocks are processed. As an example, assuming that 1 block takes around 12 seconds and the delay requires 100 blocks, we can approximate that the unsubscription will take place around 20 minutes later.

You will see the information related to unsubscription delay when you click Opt-in.

SAFc is an innovative system designed to promote the adoption of Sustainable Aviation Fuel (SAF) by issuing and managing SAF certificates. These certificates serve as verifiable proof that a specific volume of SAF has been produced or utilized, ensuring transparency and accountability in the aviation industry's transition to greener fuels.

To create an EWC account, first choose your preferred wallet by either downloading the app or using Ledger (via ). Alternatively, you also may refer to our interactive guide .

The Green Proofs system ensures that energy usage is verified as green by managing and validating green certificates for various energy operations. All data sent to workers originates from the Green Proofs application, which transforms it into operations like issuing, transferring, or retiring certificates.

Solution groups requiring KYC verification can be identified with the KYC required marker.

To initiate for KYC verification, please follow below simple steps:

1. Connect your operator account to the EWX Marketplace app

2. Click on the solution to request for KYC verification

The Green Proofs for EVs (GP4EV) system plays a crucial role in ensuring that electric vehicle (EV) charging is green by managing and verifying green certificates for each charging session. All the data sent to workers in this process originates from the Green Proofs application, which transforms this data into operations like issuing, transferring, or retiring certificates.

Learn about Energy Web's different Green Proofs solutions in our devoted section on .

In a centralized system, such as a bank or a broker, a designated authority or central operating system would be in charge of adding transactions or information to the system, making sure that each transaction is trustworthy, up to date with the whole system, and does not duplicate previous transactions.

In contrast, public blockchains are decentralized, peer-to-peer systems that have no central authority or oversight like this. Designated actors are responsible for processing transactions, creating new blocks and maintaining the integrity and history of previous blocks.

The system for determining these actors and how they are selected is called a . These mechanisms determine the process of who can confirm transactions and create new blocks on the blockchain and the protocol for how they do so. Because there is no central oversight, consensus needs to be designed in a way that prevents or disincentivizes malicious or uninformed actors from corrupting the integrity of the chain.

There are many consensus algorithms. You may have heard of some widely used ones like or . Each mechanism has its own way of determining who is eligible to process transactions and create new blocks, and how how actors are selected to do so.

The Energy Web Chain uses the Proof-of-Authority (PoA) consensus mechanism.

All consensus mechanisms have disadvantages and advantages and are chosen based on the purpose and use case of the blockchain it will be serving.

The Preimages Pallet is a specialized component in the Substrate runtime that facilitates the storage, retrieval, and management of large data blobs (preimages) on-chain. It is particularly useful for governance and other modules requiring access to detailed proposals or large datasets while minimizing storage costs.

Key functionalities:

• Efficient Storage of Preimages: Allows users to submit and store large preimage data off-chain initially, ensuring cost-effective on-chain storage.

• On-Demand Retrieval: Enables on-chain modules, such as governance proposals, to reference and retrieve preimages only when they need to be executed or evaluated.

The Green Proofs for Bitcoin (GP4BTC) platform is a solution to bring consistent metrics and much-needed transparency into the climate impacts of individual Bitcoin mining companies so industry stakeholders can make better decisions to align with a net-zero future.

Below are some examples of how a Worker Nodes are being used within Projects that EW is conducting with various of partners.

Learn more about our live use-cases:

The Token-Manager Pallet is designed for managing tokens and handling token operations within a Substrate-based blockchain. This pallet facilitates various features, including secure token transfers, scheduling of token “lowering” operations to Ethereum (tier1), and interaction with external token contracts. It also enables the governance of token-related actions through nonces and proofs, ensuring a seamless operation between blockchain tiers.

Key functionalities:

• Token Balance Management: Tracks the balances of individual accounts for different tokens. This allows the management and querying of token balances by specifying the token ID and account ID. Each account’s nonce is tracked, representing the number of transfers conducted, ensuring the integrity of transaction sequences.

The Marketplace App requires some $EWT on EWX chain. To acquire it, simply bridge $EWT either from EWC or ETH chains to EWX chain. Follow the steps described in .

The Offences Pallet is a critical component in the Substrate framework designed to detect, record, and manage misbehavior within the network. It ensures the integrity of the system by imposing penalties on validators and other actors who deviate from expected behavior, such as equivocation or inactivity.

Key functionalities:

• Misbehavior Detection: Facilitates the detection of offenses, such as double-signing or equivocation, leveraging integrated modules or external monitoring tools while it supports configurable offense types to adapt to specific network requirements and threat models.

• Offense Reporting and Recording: Provides a structured mechanism to report misbehavior, with offenses recorded on-chain for transparency and accountability. It also tracks offenders and their associated penalties to discourage repeated violations.

The Proxy Pallet is a versatile module in the Polkadot SDK that facilitates secure delegation of account operations. It allows users to authorize other accounts, called proxies, to perform specific actions on their behalf. This feature enables enhanced account management, operational flexibility, and secure delegation, particularly beneficial in multi-sig setups and automation scenarios.

Key functionalities:

• Account Delegation: Enables accounts to delegate specific operations to proxy accounts with configurable levels of permissions and supports use cases such as transaction signing, staking operations, and runtime-specific actions.

• Proxy Types and Permissions: Defines distinct proxy types to grant granular permissions, ensuring proxies can only execute authorized actions.

• Time-Limited and Announced Proxies: Introduces time-limited proxies that automatically expire after a predefined duration, enhancing security. It also implements delayed announcements for high-risk actions, allowing users to monitor and cancel actions if necessary.

• Security and Revocation: Includes mechanisms for account owners to revoke proxy permissions at any time, ensuring full control while it protects against unauthorized actions through runtime checks and adherence to defined proxy types.

Lifting is the process of migrating EWT from EWC to EWX. EWT will be needed by participants to register as worker node operators and to stake to solution groups containing the Smart Flows.

The system architecture of a validator node on the Energy Web Chain is made up of two components:

1. The OpenEthereum Client

2. Telemetry monitoring system

Together these two components allow validators to run a local node of the chain, validate transactions, seal blocks, and monitor validator behavior and metrics.

OpenEthereum Client

A client is software that allows you to run a local node on your machine and interact directly with the blockchain. Every validator must run a full node in order to participate in validation.

Remember that the Energy Web Chain is derived from the Ethereum blockchain. Because of this we use an Ethereum client to connect with the chain called . Anyone can create a client, as long as it implements the protocols laid out in , and there are a number of Ethereum clients to choose from.

Energy Web uses the OpenEthereum client because it supports the , which is a consensus algorithm specifically for Proof-ofAuthority blockchains. OpenEthereum allows validators to connect to the chain, collect transactions and seal blocks according the AuRa consensus algorithm.

To read more about OpenEthereum, you can

To read more about Ethereum clients, see the

Telemetry Monitoring system

The monitoring system collects comprehensive, real-time data and metrics on validator performance and provides a user interface for viewing the data. It is important to gather as much data about the validator nodes as possible in order to ensure a secure and performant blockchain. To do so, we rely on well established industry solutions to transfer these metrics off the validator node to protect the sensitive nature of the data.

The use of the telemetry monitoring system is opt-in. Validators can disable it if they have their own monitoring system in place that allows for real time tracking of all relevant metrics.

Telemetry Architecture

There are four components involved in the data collection process:

• client - monitors validator node behavior

• : open-source server agent that collects data from the OpenEthereum client

• - open source database that stores the data collected from Telegraf

• - data visualization tool that queries the InfluxDB for data and provides graphical interface for data visualization

All components are run in separate docker containers managed by docker compose. For additional information on docker visit: and .

Data Collection Process Overview

1. The OpenEthereum client collects data on the validator node. Collected data includes:

   • CPU usage

   • Memory usage

   • Disk usage

Ethereum

The Energy Web blockchain is derived from Ethereum blockchain technology. Ethereum provides a strong foundation for the Energy Web Chain because it is open-source, widely used, and many well-developed tools for development on Ethereum exist today.

Ethereum-based technology is used as EW-DOS's trust layer because anyone can use Ethereum to build and deploy decentralized applications that run on blockchain technology. This aligns with the purpose of EW-DOS, which is to build decentralized, open-sourced applications that accelerate decarbonization of the energy grid.

What Sets Ethereum Apart from Other Blockchains?

Prior to Ethereum, most blockchains were protocols created to exist as a public, decentralized ledger for financial transactions (think Bitcoin).

Ethereum developed the (EVM) to allow users to store and execute programs on the Ethereum blockchain. This lets programmers write programs that contain logic and state management, both which are critical to. These programs are called . Once it is deployed on the blockchain, a smart contract has an address on the blockchain and anyone can use to interact with the contract or call its public functions. You can read more about how to interact with smart contracts .

This means that blockchain technology can not only be used to buy and trade cryptocurrency, but also to create robust applications for decentralized finance, asset trading, gaming and, in our case, a decentralized energy market.

Read an overview of Ethereum and the Ethereum Virtual Machine on the Ethereum documentation's "What is Ethereum" section .

Ethereum Fundamentals

The Energy Web Chain is derived from Ethereum, but it is a separate blockchain using a different consensus protocol and unique governance mechanisms. However, most of the fundamentals of the Ethereum network are the same for the Energy Web Chain. These fundamentals are helpful in understanding the role that blockchain technology plays in EW-DOS. This is especially true if you want to develop and deploy smart contracts on the Energy Web Chain.

If you are unfamiliar with Blockchain technology, or the Ethereum Virtual Network, there are some additional resources below to get you started.

• (this is an overview of transactions in Ethereum, but we explain more about transactions on the Energy Web Chain )

Additional Resources

• on

Prerequisites

• Connected EWX account

• Connected worker account

1. Click on Export Account located on the left panel of your Dashboard page

1. Click Confirm to reveal the worker account mnemonic

1. Enter your password and click Continue

1. Click on Backup Mnemonic to backup as file or Close to close the pop-up

What is a Worker Node?

A Worker Node is a lightweight off-chain processing unit with an ability to execute business logic in a form of NodeRed flow file.

A Worker Node executing logic can actively contribute in meaningful way to range of use cases. Examples can be found here: Worker Node Usage Use Cases.

Worker Nodes functionalities and EWX blockchain connection enable transparency and verification capabilities for your system. Additionally, thanks to its lightweight architecture, worker nodes are perfectly suitable and a good fit for applications that require decentralized execution components.

How can it be used?

Worker Node, apart from its initial set-up, is entirely controlled by Blockchain based actions. That means that after your initial Worker set-up is completed, no additional changes will be needed.

Blockchain based action controlling Worker Node behavior could be applied via the Marketplace App - an EW built Blockchain Operator UI, or by directly interacting with blockchain.

To understand more about how Worker Nodes can be used, please go to the section.

High level architecture within EWX ecosystem

Below you can find a High Level Architecture to understand how worker node fit into the wider EWX ecosystem.

Server Based Worker Node uniqueness

Server based Worker Node main differentiation is visible when you compare it to the Marketplace Desktop App.

The Marketplace Desktop App contains both Worker Node running engine as well as Blockchain Interaction UI.

For Server based Worker Nodes, the Blockchain Interaction UI was de-coupled from Worker Engine to achieve the best from both sides.

When you would like to use Server Based Worker Node?

1. You want to have a reliable PROD-level set-up for your Worker Node

2. You don't want/can't use desktop application for blockchain set-up management/worker engine (e.g. because you don't want to keep your desktop running 24/7)

3. You anticipate heavier loads to be run on top of your Worker Node

Worker Nodes Larger landscape fit

Similarly as for blockchain or DLT (Decentralized Ledger Technology) application, Worker Node technology should mainly be considered for specific use-cases.

Active/Reactive Use cases types

You can consider utilizing Worker Nodes for either Active or Reactive use case types.

1. Active use cases describes a situation when system relies on Worker Nodes as a primary executors of business logic. In such a case, Worker Nodes plays a non-removable role from the system and biggest advantage is their flexibility, lightweight architecture and decentralized nature. Example - Oracle Network ------------------------------

2. Reactive use cases describe a situation when system rely on Worker Nodes as a verification layer that ensures that result of the logic execution is done in tamper-proof and trustless manner. The decentralized nature additionally participates to the overall system security and ensures verification possibilities. Example - verification of 24/7 energy matching algorithm

Worker Nodes use - Reactive use case

Main roles that Worker Nodes play in above use case type:

1. Application runs the business logic itself along with Worker Nodes

2. Worker Nodes executed functionality is part of a "bigger" system

3. Reactive way of using Worker Nodes offers a balance between Speed & Security

Worker Nodes use - Active use case (Coming Soon!)

Types of problems Worker Nodes help solving

There are four types of problems that Worker Nodes along with their capabilities coming from EWX Ecosystem are best equipped to solve.

1. Need for trustless execution (decentralized)

2. (Public) Verifiability of results e.g. for auditing needs

3. Need for system participants incentivisation

4. Need for blockchain use with strong security, advanced governance and data privacy care

Each use case type is presented below.

Trustless execution - Worker Nodes use ensures that multi-party consensus can be achieved.

Verifiability - Worker Nodes EWX integration allows for auditability and verifiability of execution results

Participants incentivisation - Worker Nodes EWX integration allows for incentivisation of active, well-behaving system contributors

Need for Blockchain use with maintained privacy - Use of Worker Node and EWX ecosystem integration allows for various of features that are often looked for when there is a need for Blockchain use. E.g.

1. Strict governance with options like Operators Whitelisting

2. Fully private set-up and isolation of Worker Nodes execution within private network

3. Not exposing private data on public blockchain

Before your worker node is able to cast votes, your worker account needs to be linked to an operator account first. This is a one-time step only and you will not be prompted to link again in the future (unless it's being unlinked).

Prerequisites

• Connected EWX account

• Connected worker account

• solution group

1. Click Enable Solution Group either from Dashboard or Manage Subscription page

1. Read through the important information regarding participating into a worker node network. Click Continue to proceed or Dashboard to cancel

1. Click Continue to proceed

1. Approve the transaction in your wallet

1. Wait for the transaction to finish execution

1. Once you see the transaction successful message, your worker account and operator account are now linked 🔗

The Operating Envelopes Partitioning is the most crucial step in the overall operating envelope passthrough process.

An "operating envelope passthrough" refers to a mechanism that allows for adjustments in the operational limits or envelopes of generating units or electrical systems. These envelopes define the safe operating conditions for various generation assets and network elements, helping ensure reliability and stability in the energy supply.

When unforeseen circumstances arise, such as significant changes in demand, generation availability, or system disturbances, the operating envelope can be exceeded. The passthrough mechanism enables market operators to make necessary adjustments to account for these situations, ensuring that the operation of the market remains secure and efficient. This process is vital for managing risks and maintaining grid reliability amidst changing conditions.

The process starts when the DNSP/DSO sends their operating envelope which needs to be partitioned accordingly, and forwarded to their respective aggregators. The partitioning process needs to take place in a fully trust-less and secured environment where data are pseudo-anonymized to protect aggregators' business interests.

OEP Solution

The OEP solution aims to test the above business case. Below are the steps which constitute the OEP solution flow:

1. Fetch OEP request from the operating envelope sender every 30 minutes

2. Parse the operating envelope into JSON Object

3. Fetch to aggregator mapping from the NMI Registry. The NMI Registry is a backend API service which simply contains the mapping between NMI and aggregator.

4. Partition the operating envelope according to the aggregator using the NMI to aggregator mapping

What is Delegated Staking?

Delegated staking allows $EWT holders to directly participate in securing the Energy Web X network by nominating (delegating stake to) active collator candidates. In return, delegators share in block production rewards and network growth rewards generated by the underlying staking system.

Delegated staking involves direct interaction with the Parachain Staking Pallet, whereby in the staking call the user must select a collator candidate and amount of $EWT.

Unlike staking through the Liquid Staking Pallet he staked balance becomes locked and non-transferable.

How Delegated Staking Works on EWX

Energy Web X uses the Parachain Staking Pallet to govern network security, growth and reward distribution.

The Delegated Staking Flow:

1. Users Delegate Stake to Collators

   • For each stake delegation, delegators choose a collator from the candidate pool with which to bond their $EWT, this is called a nomination.

   • Each nomination increases the collator's total stake.

   • Since collators are ranked by total stake before the top set (defined by the topSelected

Token holders can perform delegated staking either through the , within supported third-party wallets, or through .

The Marketplace app supports $EWT and $stEWT tokens. Below are the guides in acquiring them.

Guides available for token management:

FAQs

A solution is a representation of a business case logic within the worker node networks. It is composed of the solution metadata and a Smart Flow definition file. The Smart Flow file is stored on a publicly available decentralized file system - IPFS (Interplanetary File System).

A solution group is a collection of solutions. Operators choose which solution group they opt to run and stake EWTs with. The worker node will run all active solutions under the subscribed solution group.

Smart Flows

A smart flow is a set of logical nodes that define a business use case. In EWX, smart flows are created and configured using Node RED which provides a browser-based flow editor that makes it easier for enterprises to wire together flows. However, contents of a Node RED node may be auto generated by any third party and be available as an independent, reusable node.

Smart flows are exported to JSON files and are stored on IPFS. Worker nodes of subscribed operators can automatically fetch these files and deploy into each respective instance.

Below is the sample generic sequence diagram describing the process from fetching data from each respective business case provider system, processing the data, submitting the result to EWX, calculating the consensus, and forwarding the results back to the BC system. Business Case (BC) providers are those entities who have access to and define the logic of the Smart Flows.

Funding an operator account requires liquid tokens called $stEWT. To acquire $stEWT, please follow the steps described in the Liquid stake to get stEWTsection.

Prerequisite

• Connected EWX account

1. Click on Set Worker Account on the left panel located under Total EWT Balance in your Dashboard

1. Click Next (with default to "In this machine") to proceed

1. Click Generate account

1. Click Confirm

1. Create a password and re-enter it for verification. Click Create Worker Node Account. You will be prompted to enter this password during app start up in order to unlock your worker account

1. Click Backup Mnemonic and store the file somewhere safe before clicking on Continue

1. Verify the mnemonic based on your backup file in the next screen and click Continue

1. Congratulations, your worker account is successfully created 🎉

Prerequisites

• Connected EWX account

• Subscribed to a solution group

1. Click on Unsubscribe button in the Manage Subscription page

1. A pop-up will appear, click Continue to proceed

1. Click Confirm to submit a transaction

1. Approve the transaction in your wallet and wait for the transaction to be executed

1. You will see a success message along with the transaction URL to Polkadot explorer

Dashboard

You can manage your subscriptions from Marketplace app's Dashboard. Here you are able to view list of solution groups that you've subscribed and unsubscribed (with unclaimed rewards only).

What you can do in Dashboard:

• Check subscription amount, , current reward period and at a glance

• subscription amount

• Enable/pause/resume solution group

Manage Subscription

The features in Manage Subscription page are pretty much the same as Dashboard except for Unsubscribe and infos related to voting. Read more:

Reward Mechanism

• Reward Source: Annual inflation = 2.5M EWT newly minted

  • 80% (2.0M EWT) → Growth rewards for collators & delegators

  • 20% (0.5M EWT) → Community Fund Treasury

• Reward Calculation Flow:

  1. Performance-based allocation: Rewards per era are distributed to collators proportional to their points (blocks authored, equivocation handling, etc.).

     • total_reward_for_candidate = (collator_points / total_points) * total_staking_reward

Reward Timing

• Era length: 7,200 blocks (~24 hours).

• Growth period length: 28 eras (~28 days).

• Reward payout delay: 2 eras after the end of reward period.

• Unstaking delay: 2 eras

Transaction Fees

• Collected fees form an additional reward pot.

• Distributed per era using the same points → stake → commission logic as growth rewards.

Validator / Collator Parameters

• MaxCandidates: 100 (max collators in the pool).

• TotalSelected: 20 active collators selected per era (configurable).

• MaxTopNominationsPerCandidate: 300 (top delegators by stake per collator are counted).

• MaxNominationsPerNominator: 100. Number of collators a delegator can nominate.

Validator Onboarding Token Requirements

• EWX self-stake: ≥5,000 EWT (+ ~10 EWT gas buffer).

• EWC: ≥1 EWT (to sync with Tier-1 chain).

• Ethereum: ≥0.15 ETH (to support bridge syncing ops)

Energy Web X (EWX) operates on a Proof-of-Stake (PoS) consensus mechanism, where participants secure the network and earn rewards by staking the native Energy Web Token ($EWT). Staking aligns the incentives of token holders with the long-term stability and performance of the network, ensuring that those who contribute resources and maintain uptime are rewarded proportionally.

On EWX, collators produce blocks and maintain parachain consensus, while delegators support them by staking their $EWT. Rewards are distributed at the end of each growth period based on collator performance and the relative amount of stake.

Validators (collators) must meet minimum self-stake and performance requirements to remain active, while delegators can nominate trusted collators to share in their rewards. The network automatically adjusts staking pools and reward allocations to maintain fairness and decentralization.

Staking on EWX not only helps secure the network but also powers the economic engine behind its Verified Compute (formerly Worker Node Network) ecosystem, ensuring reliable, transparent, and incentive-aligned participation across Energy Web’s decentralized infrastructure.

Energy Web X supports two methods for token holders to stake their $EWT and contribute to network Security:

1. and;

2. .

With delegated staking, users stake their $EWT directly with the Parachain Staking Pallet by selecting one or more collator candidates. The staked tokens are locked and non-transferable, and users earn rewards proportional to their share of each nominated collator’s total stake.

Liquid staking allows users to deposit $EWT into a pooled staking system managed by the Liquid Staking Pallet, which stakes the combined funds across a curated set of collators. In return, users receive stEWT, a liquid, transferable voucher token whose value increases over time through the exchange rate as staking rewards compound.

Overview

The Block Reward contract manages block reward payouts to validators. Block rewards are issued as native Energy Web tokens that are minted by the engine.

Two entities are rewarded by each created block:

1. The block author (validator)

Energy Web has deployed This contract is identical to OpenEthereum's original contract, with the exception that it was made Ownable by Energy Web Foundation. Only Energy Web can reserve a name or drain funds from this contract.

There are two reasons for making this contract Ownable:

1. OpenEthereum's name registry might be needed for other OpenEthereum related system contracts later: e.g. , or .

2. We will have the official system set up on the chain, so this contract is only needed for internal purposes and will not be used publicly.

The name registry is a placeholder for now. The contract can be found in our repo:

The block explorer interface provides the most important on-chain information about blocks, transactions, accounts and . Below is an overview of what information you can view on the Block Explorer.

Note that there is a separate site for the Volta Testnet Block Explorer.

• Volta Testnet Block Explorer:

• Main Network Block Explorer:

As part of the 2025 technology and governance upgrade approved by the Energy Web Chain (EWC) validators (for more see and ), an ERC-20–compatible representation of the Energy Web Token (EWT) has been implemented. This functional upgrade enables EWT to move between EWC, Energy Web X and Ethereum, expanding the platform’s interoperability and enhancing the EWT token utility. This documentation section serves to inform EWT holders on the impact of the 2025 upgrade but it should not be construed as an offer, recommendation, invitation, or inducement, to subscribe for or purchase the Energy Web Token. It does not constitute and is not intended to be financial or other advice and is not to be relied upon as the basis for any investment or other decision. Please be informed of all , and always verify all information presented here directly at the primary source, such as exchanges.

The functional conversion of EWT token ERC-20–compatible representation operates on a 1:1 basis,

Note: If you currently hold a native representation of EWT in a self-custodial wallet or on an exchange, no immediate action is required. Your existing tokens remain valid and can continue to be held, transferred, and used in applications that use the native representation of EWT. You may choose to convert, stake, or bridge your EWT at your own convenience. No deadline or mandatory conversion has been imposed.

In case you hold EWT in a hard or soft wallet, you can

Business case

Today worker nodes are implemented as independent off-chain computing nodes that communicate with a smart contract deployed on the Energy Web Chain. This approach is effective, but it is complex and labor-intensive to configure custom business logic, synchronize nodes, and apply appropriate governance such as defining eligibility requirements and service level agreements that worker nodes must adhere to. A more efficient solution is to implement worker nodes within a common environment where they can run independently but follow a unified set of rules. That is where Energy Wb X comes in.

In contrast to the Energy Web Chain, which is Ethereum based, Energy Web X is built with . Its sole purpose is to coordinate, secure and make public the results of work performed by worker node networks.

🎬 Video Walkthrough

Flow 1: Delegating Stake

1. Connect your wallet (e.g. SubWallet, Nova Wallet, or Polkadot.js) to the EWX Staking App.

Understanding the terms in the display

Before unstaking, it is important to get acquainted and be familiar with the terms used in the Unstake page.

• Available to Unstake - The amount of $EWT that can be unstaked from your stakes without pending unstakes.

What are Worker Nodes?

To learn more about worker nodes, see .

Types of Worker Nodes

Overview

The Holding Contract holds tokens for initial investors. These tokens are "pre-mined", and do not enter the pool through block validation. Tokens are held for affiliates until a specific point of time that is specified in the contract, at which point they can be released to the specified address. The constructor of the holding contract and its initial balance is part of the chainspec file. This allows the investors' tokens to be locked at the first block.

The mapping between the account address and the token amount is hard coded into the contract and cannot be changed after deployment. After a block that has a later timestamp than the holding timestamp of an address is created, the tokens for that address can be transferred to the address by calling the realeaseFunds method. This method can be called by anyone, not only by the address that holds that balance.

Documentation and Source Code

Check a Balance and Withdraw Funds

If you're an investor and want to see your balance, you can use the Balance Viewer interface:

You will need MetaMask pointed to a local or a remote node

• To learn how to connect via remote RPC, go

• To learn how to run a local node go

1. Enter your address in the lookup field to see your holding balance

2. If the release period has ended, press the "Withdraw" button to release the funds to the address it belongs to. Make sure you trigger the withdraw function with an account that has some ethers to cover transaction costs

Mapping Between Address and Tokens

The mapping between addresses and tokens/release timestamp is kept in the storage of this contract. This mapping data structure was filled at the deploy time of the contract and cannot be changed.

Interacting with the Holding Contract

Contract Address and ABI

Callable Functions

Ensure that your wallet supports the Energy Web X chain

To ensure that your wallet supports the Energy Web X chain, please check if it is one of the supported networks in your wallet.

If not, please refer to below details to add Energy Web X as a custom network in your wallet:

• RPC URL:

• Name: Energy Web X

• Token Symbol: EWT

• Network Type: Substrate

• Block Explorer:

Connect EWX wallet account

View account details on explorer

Click on the View on Explorer button to check the wallet account in the official EWX Explorer.

This action will open a new tab to show wallet account details on .

Switch accounts

In order to be able to switch accounts, ensure that accounts are enabled for connection to the EWX Staking Web App in your wallet. Below are examples on how to do so.

Click on the Switch Account button to switch wallet accounts.

Choose the account to switch to and automatically the web app connects the selected account.

Disconnect

Simply click on the Disconnect button.

Operator account

Marketplace app requires an operator account to make the most of the features it offers. Connect your EWX account, fund your account and sign it up as an operator by following these guides:

Worker account

A worker node account is used mainly for running worker node logic(s). Though you can earn base rewards by subscribing to a solution group, participating into worker node network allows you to earn extra rewards.

Discover more guides for this topic:

FAQs

This document lists frequently asked questions and brief answers in relation to the Energy Web 2025 Technology and Governance Upgrade. Further information is available in other sections of the GitBook documentation and the related , as well as the ,

1. What Does the Energy Web 2025 Upgrade Entail?

The 2025 upgrade marks Energy Web platform’s transition from the legacy Energy Web Chain (EWC), a public but permissioned Proof‑of‑Authority (PoA) network, to Energy Web X (EWX), a public, permissionless, nominated Proof‑of‑Stake (NPoS) parachain on Polkadot.

The upgraded Energy Web technology platform consists of:

A DID is an identifier that is user-generated and not coupled to any centralized authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization.

Unlike traditional forms of identification, DIDs are not generated by a central authority, such as a government-issued driver’s license, or a bank-issued account number, and they are not stored in a centralized database. A user can create a DID for themselves or an asset using cryptographic or other means.

A DID for a given system resides in a decentralized . DID Registries, like VCs and DIDs themselves, are developed according to W3C standards. Most DID registries live on a decentralized ledger, or a blockchain. In the case of EW-DOS, the DID registry is on the .

How are DIDs Created?

Prerequisites

Before using Ledger on the Marketplace App, the Polkadot app needs to be installed in the hardware wallet device. To do so, open the Ledger Live application in your computer and go to "My Ledger" section of the sidebar. Make sure your Ledger device is connected to the computer and unlocked when doing this.

In the "App Catalog" section, search for the Polkadot app and install it.

Confirm that the Polkadot app is correctly installed.

FAQ section is ever-growing, to accomodate frequently asked questions gathered by users. If you have some ideas for further information to be included here, please let us know!

Understanding the terms in the display

Before staking, it is important to get acquainted and be familiar with the terms used in the Stake page.

• Total Staked - The total amount of $EWT you have actively staked across all collators.

Before you start using your Worker Node and be able to control blockchain set-up fully using Marketplace app, there is a set-of one-time actions that needs to be done as a prerequisite.

Types of EWX Accounts

1. Operator Account - an EWX account which serves as the main account of the operator to be used in EWT management (lifting/lowering), subscriptions, rewards, etc

2. Worker Node Account - an EWX account with the sole purpose of casting votes on behalf of the operator (interacting with blockchain).

Prerequisites

1. Public Address of the Worker Node Account - the worker node account must already be created using any of .* *Disclaimer -> If you use Launchpad Managed Worker Node offer, there is an option to automatically generate Worker Account along with Worker set-up.

2. Operator Account with enough EWT balance - create an account from and make sure to enough EWT for signing-up as operator, linking worker account to operator, , etc