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.

CONTENTS OVERVIEW

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.

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 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.

• Operate worker nodes: to become a trusted party to run worker nodes, individuals and/or businesses will be required to stake EWT. Staking requirements and reward schedules are mass customizable - enterprises launching worker node networks can configure different thresholds and award schedules at their discretion.

• Validate Energy Web X: Energy Web X validators will need to stake a significant number of Energy Web Tokens in order to become validators on Energy Web X.

For clarity, instead of launching a new token with the Energy Web X blockchain, Energy Web X will be powered by the existing EWT. Users have the ability to “lift” Energy Web Tokens from the existing Energy Web Chain onto Energy Web X. Lifted Energy Web Tokens can then be used for the functions described above. With this mechanism in place, EWT holders will be able to “lower” Energy Web Tokens back to the main Energy Web Chain at their discretion. Over time, token holders will be able to lower EWT to other layer one blockchains (for example, main net Ethereum) making Energy Web solutions interoperable with any blockchain ecosystem.

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.

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 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.

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:

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 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.

The blockchain performs three key functions in EW-DOS:

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.‌

The blockchain provides trust in several ways that allow for a decentralized system that is self-executing and without central authority or oversight of on-chain transactions:

Persistence on the Energy Web Chain

The Energy Web Chain stores the following information:

• Smart contracts that contain logic and functionality specific to applications deployed on the Energy Web Chain and the utility packages that connect them and their users to the Energy Web Chain.

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.

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.

Transactions

• Transferring tokens between accounts

• Deploying new smart contracts or accounts

• Calling or Interacting with existing smart contracts

Once confirmed by the initiator, transactions can be in two states: pending and validated.

Pending Transactions

Notice that the transaction fee of a pending transaction is not determined yet and the "Block Number" is pending.

Validated Transactions

After a transaction is validated by a validator, it is added to a block. The block is designated by a block number, shown in the image below. Each block in a blockchain is made up of strictly ordered, consecutive, validated transactions.

Notice that the transaction fee of a validated transaction is no longer 0, it has a value in EWT.

Determining Transaction Cost

Every transaction that updates the chain has a transaction cost (transactions that are "read only" - meaning they do not update the state of the blockchain - do not have a cost.) It’s important to keep in mind that all transactions are not created equal: some are more computationally intensive than others, some are more urgent, some require greater degrees of privacy.

For example, an interaction with a smart contract that has complex functionality and many internal variables to store will be more computationally intensive than a simple transfer of tokens from one account to another.

As we’ll soon see, these differences from one transaction to the next can have an impact on ultimate transaction cost.

Transaction Cost Variables

There are three key variables that influence transaction cost:

1. Gas Cost

2. Gas Price

To derive a concrete fee requires a gas price as well. Every user that initiates a transaction chooses a gas price they are willing to pay for that particular transaction, at that particular time. It is essentially a bid the user makes to have their transaction validated and added to the chain. Users that want to have their transaction expedited, for example, might bid a higher gas price to ensure that it’s included as soon as possible in the next available block.

You can specify a gas price in a transaction through MetaMask:

3. Token Value

Finally, token value—usually expressed in a fiat currency equivalent—translates virtual transaction cost into ‘real’ transaction cost. And when token value varies widely, perhaps due to token market volatility, resulting transaction costs can vary too.

Calculating Transaction Cost

Using the three variables above, you can calculate the total transaction cost:

TxCost(unit:fiat$) = GasCost(unit:gas) x gasprice(unit:token/gas) x tokenvalue($/token)

Here’s how a fee would be calculated for a hypothetical transaction on the Energy Web Chain:

50,000 gas x 1 gwei per gas = 50,000 gwei = 0.00005 EWT

If the market price of EWT was $1 at the time of the transaction, this would equate to $0.00005 fee. If the price of EWT was $10, this would equate to $0.0005.

Gas Price, Gas Limits and Block Size

Gas cost, as we've mentioned, represents the computational effort that validators undertake when validating transactions and sealing blocks. The gas price is denominated in EWT, which is paid to the validators for their work.

Each validator may set their own minimum gas price that they are willing to accept in order to include a transaction in their blocks. Currently on the EWC, the default is 0.1 gwei, but the overall range is between 0.01 gwei and 1 gwei. When initiating a transaction on the EW Chain, you should make sure that your gas price is at least 0.01 gwei, and if you want to ensure that your transaction is executed within the next 1-3 blocks (roughly 15 seconds), you should choose a higher gas price.

Because each transaction uses different amounts of gas, the number of transactions that fit on a block will vary.

Each block on the Energy Web Chain has a size limit of 8 million units of gas. Hypothetically, a single extremely computationally intensive transaction could consume 8M gas, but a simple transfer of EWT between two accounts (the most basic transaction type there is) consumes 21,000 gas. This is why a simple metric of “transactions per second” is misleading; not all transactions are created equal in terms of complexity (i.e. gas cost.) If many of the transactions that are waiting in the memory pool have low computational cost, you can fit more transactions in the block. If they are larger, the block will hold less transactions.

Take a look at the details of a block added to the Energy Web Chain:

From this we can see that:

• This block includes 43 transactions

• The gas limit for the block is 8,000,000 (this limit remains constant for every block)

• Only 1,553,623 units of gas were used to create the block (less than 20% of its limit)

• If there were more transactions waiting in the memory pool to be added to the block, this block could have processed ~6,446,377 units worth of gas.

Keeping Public Blockchain Transaction Costs Low

The same three variables above that define transaction cost also present opportunities to manage those costs and keep them low.

1. Lean smart contracts can help keep gas costs down: App developers and other smart contract writers are incentivized to write lean, efficient code—writing smart contracts and initiating transactions that are as computationally efficient as possible.

2. Gas price bids should remain low on networks with high transaction capacity: Of the three variables that contribute to transaction costs, gas prices are arguably the most powerful lever, since the bidded prices are solely at the discretion of the user submitting a transaction to the network. For reasons we’ll explore below, in the absence of sustained block “congestion”, gas prices can remain low and stable.

3. “Just in time” gas price calculations mitigate some risks of token value volatility: For a variety of reasons, some token markets are more volatile than others. But just because a token’s value relative to a fiat currency changes, it doesn’t mean that transaction fees similarly change without warning. Users calibrate gas price bids at the time of the transaction, and thus will bid a denomination of tokens relative to the token’s value at the time. While it is possible that a past transaction fee could end up being significantly more or less expensive relative to current (or future) token value, transaction fees at the time they are incurred should remain relatively stable as a function of fiat currency.

If users desire a low-cost network, why do transaction costs rise in the first place?

So why would anyone bid a high price for any transaction? Shouldn’t transaction fees remain very low, as rational users consistently attempt to minimize their costs? In reality, transaction fees vary precisely because of competition among users to get transactions confirmed.

At any given moment there may be hundreds or thousands of transactions waiting to be confirmed and formally added to the blockchain. These pending transactions sit in a memory pool, or "mempool", where they are ultimately selected by validators (miners in the case of proof-of-work blockchains) to be included in a block. But each block has a finite gas limit, meaning not all transactions can be confirmed at once. As a result, validators will typically give preference to the most-lucrative (or expensive, depending on perspective) transactions in the mempool. Transactions with lower fees may end up having to wait for their transaction to get confirmed.

Ultimately, fees are about transaction prioritization. The higher the gas price you pay, the faster your transaction will be confirmed. If you don’t care about the amount of time it takes to confirm your transaction, you can offer a very low (or no) gas price. However, with this strategy you run the risk that your transaction never gets confirmed, and just sits in the mempool queue indefinitely.

Lessons from what we know about the Energy Web Chain

At the most basic level, transaction fees on the EWC are determined as a function of supply (e.g., computational capacity of the network, as defined by block gas limit and block speed / time) and demand (i.e., number of pending transactions). Volatility comes into the equation because supply, namely block time and block gas limit, is essentially fixed, whereas demand fluctuates as a function of the number of users and and the volume and complexity of transactions in the memory pool at any given time. Occasionally, transaction fee trends diverge from transaction volume, but generally the two are correlated.

Looking at historical data since the launch of the EWC in June 2019, it’s fair to say that transaction fees are usually extremely low - with average block utilization (in terms of gas consumption) around 15-20% the minimum gas price of 0.1 gwei is almost always sufficient to ensure a transaction is validated within 2 blocks. Based on the historical market price of EWT, transaction fees expressed in terms of fiat currency are typically in the range of $0.0001 (or less).

Additional Resources

• Ethereum documentation on

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.

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.

How are DIDs Created?

Public-Private Key Pairs

DID Format

DID Documents

Copy

Additional Resources on DIDs

Medium Series on private keys and their relevance in the Ethereum Network:

Ethereum

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).

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.

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.

Additional Resources

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.

Implementing Client Protocol

In order to adhere to the expected protocol, the Energy Web Chain’s system contracts must implement the interfaces that are expected by the AuRa consensus engine, so that it can conform to the client’s protocols.

The OpenEthereum documentation specifies that “A simple validator contract has to have the following interface”

[
    {
        "constant": false,
        "inputs": [],
        "name": "finalizeChange",
        "outputs": [],
        "payable": false,
        "type": "function"
    },
    {
        "constant": true,
        "inputs": [],
        "name": "getValidators",
        "outputs": [
            {
                "name": "_validators",
                "type": "address[]"
            }
        ],
        "payable": false,
        "type": "function"
    },
    {
        "anonymous": false,
        "inputs": [
            {
                "indexed": true,
                "name": "_parent_hash",
                "type": "bytes32"
            },
            {
                "indexed": false,
                "name": "_new_set",
                "type": "address[]"
            }
        ],
        "name": "InitiateChange",
        "type": "event"
    }
]

You can see that this smart contract implements all of the functions of the Validator-Set protocol interface that was specified above.

pragma solidity 0.5.8;

import "../misc/Ownable.sol";
import "../interfaces/IValidatorSetRelay.sol";
import "../interfaces/IValidatorSet.sol";
import "../interfaces/IValidatorSetRelayed.sol";


/// @title Validator Set Relay contract
/// @notice This owned contract is present in the chainspec file. The Relay contract
/// relays the function calls to a logic contract called Relayed for upgradeability
contract ValidatorSetRelay is IValidatorSet, IValidatorSetRelay, Ownable {

    /// System address, used by the block sealer
    /// Not constant cause it is changed for testing
    address public systemAddress = 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE;
    
    /// Address of the inner validator set contract
    IValidatorSetRelayed public relayedSet;

    /// Emitted in case a new Relayed contract is set
    event NewRelayed(address indexed old, address indexed current);

    modifier nonDefaultAddress(address _address) {
        require(_address != address(0), "Address cannot be 0x0");
        _;
    }

    modifier onlySystem() {
        require(msg.sender == systemAddress, "Sender is not system");
        _;
    }

    modifier onlyRelayed() {
        require(msg.sender == address(relayedSet), "Sender is not the Relayed contract");
        _;
    }

    constructor(address _owner, address _relayedSet)
        public
    {
        _transferOwnership(_owner);
        _setRelayed(_relayedSet);
    }

    /// @notice This function is used by the Relayed logic contract
    /// to iniate a change in the active validator set
    /// @dev emits `InitiateChange` which is listened by the Parity client
    /// @param _parentHash Blockhash of the parent block
    /// @param _newSet List of addresses of the desired active validator set
    /// @return True if event was emitted
    function callbackInitiateChange(bytes32 _parentHash, address[] calldata _newSet)
        external
        onlyRelayed
        returns (bool)
    {
        emit InitiateChange(_parentHash, _newSet);
        return true;
    }

    /// @notice Finalizes changes of the active validator set.
    /// Called by SYSTEM
    function finalizeChange()
        external
        onlySystem
    {
        relayedSet.finalizeChange();
    }

    /// @notice This function is used by validators to submit Benign reports
    /// on other validators. Can only be called by the validator who submits
    /// the report
    /// @dev emits `ReportedBenign` event in the Relayed logic contract
    /// @param _validator The validator to report
    /// @param _blockNumber The blocknumber to report on
    function reportBenign(address _validator, uint256 _blockNumber)
        external
    {
        relayedSet.reportBenign(
            msg.sender,
            _validator,
            _blockNumber
        );
    }

    /// @notice This function is used by validators to submit Malicious reports
    /// on other validators. Can only be called by the validator who submits
    /// the report
    /// @dev emits `ReportedMalicious` event in the Relayed logic contract
    /// @param _validator The validator to report
    /// @param _blockNumber The blocknumber to report on
    /// @param _proof Proof to submit. Right now it is not used for anything
    function reportMalicious(address _validator, uint256 _blockNumber, bytes calldata _proof)
        external
    {
        relayedSet.reportMalicious(
            msg.sender,
            _validator,
            _blockNumber,
            _proof
        );
    }

    /// @notice Sets the Relayed logic contract address. Only callable by the owner.
    /// The address is assumed to belong to a contract that implements the
    /// `IValidatorSetRelayed` interface
    /// @param _relayedSet The contract address
    function setRelayed(address _relayedSet)
        external
        onlyOwner
    {
        _setRelayed(_relayedSet);
    }

    /// @notice Returns the currently active validators
    /// @return The list of addresses of currently active validators
    function getValidators()
        external
        view
        returns (address[] memory)
    {
        return relayedSet.getValidators();
    }

    /// @dev The actual logic of setting the Relayed contract
    function _setRelayed(address _relayedSet)
        private
        nonDefaultAddress(_relayedSet)
    {
        require(
            _relayedSet != address(relayedSet),
            "New relayed contract address cannot be the same as the current one"
        );
        address oldRelayed = address(relayedSet);
        relayedSet = IValidatorSetRelayed(_relayedSet);
        emit NewRelayed(oldRelayed, _relayedSet);
    }
}

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

System Components

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

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

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

What is the Energy Web Token?

EWT on the Energy Web Chain

EWT on Energy Web X

Energy Web X will leverage and complement 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. In order to attract entities to run worker nodes, enterprises will need to include rewards, paid in EWT, that compensate worker node operators for their work.

• Operate worker nodes: in order to become a trusted party to run worker nodes, individuals and/or businesses will be required to stake EWT. Staking requirements and reward schedules are mass customizable—enterprises launching worker node networks can configure different thresholds and award schedules at their discretion.

• Validate Energy Web X: Energy Web X validators will need to stake a significant number of Energy Web Tokens in order to become validators on Energy Web X.

For clarity, instead of launching a new token with the Energy Web X blockchain, Energy Web X will be powered by the existing or EWT. Users have the ability to “lift” Energy Web Tokens from the existing Energy Web Chain onto Energy Web X. Lifted Energy Web Tokens can then be used for the functions described above. With this mechanism in place, EWT holders will be able to “lower” Energy Web Tokens back to the main Energy Web Chain at their discretion. Over time, token holders will be able to lower EWT to other layer one blockchains (for example, main net Ethereum) making Energy Web solutions interoperable with any blockchain ecosystem.

Get EWT

Additional Resources:

There are two reasons for making this contract Ownable:

Interacting with the Name Registry Contract

Contract Address and ABI

Callable Functions

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 Energy Web Chain uses the Proof-of-Authority (PoA) consensus mechanism.

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)

Documentation and Source Code

Block Reward Payouts

Block Authors

Block authors are rewarded each time they seal a block. The amount issued to block authors decreases over time, as depicted by the Discreet S Curve.

Energy Web Community Fund

A portion of block rewards goes to the Community Fund. Unlike the amount awarded to block authors, the amount that goes to the Community Fund remains constant over time.

The amount is chosen to add up to roughly 37.9 million tokens over a 10 year period. The community fund can change its own address and set a payout address too.

With 5 second step size: Payout-per-block = 600900558100000000 wei

Visual representation of the community reward distribution is depicted below in Fig. 3.

Interaction with Block Reward Contract

Contract Address and ABI

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

Block Explorer Overview

Blocks

• • Block Height

  • Num transactions

  • Hash

  • Parent Hash

  • Difficulty

  • Total Difficulty

  • Gas Used

  • Gas Limit

  • Block Rewards

  • Miner (validator)

  • Transactions

Transactions

• • Transaction address

  • Status

  • Block Number

  • Nonce

  • Transaction fee

  • Transaction Speed

  • Raw input

  • Gas

  • Internal Transactions

• • Transaction address

  • Nonce

  • Gas limit

  • Internal Transactions

Account details for all external and smart contract account addresses with balances and associated transactions

• Address

• Token balance

• Num. transactions

• Last balance update

• Gas used

• All transactions

• Coin balance history

Tokens

APIs

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.

Current Challenges

Worker nodes in the Energy Web ecosystem today function as independent off-chain computing units. They communicate with smart contracts deployed on the Energy Web Chain (EWC), which uses Ethereum-based technology. While this design has been effective in facilitating off-chain computation, it has significant challenges:

1. Complexity in Configuration: Setting up custom business logic for each independent worker node requires substantial effort, making the process cumbersome for enterprises.

2. Synchronization: Ensuring consistent operation and data synchronization between worker nodes and the smart contracts is labor-intensive.

3. Governance Enforcement: Defining and monitoring adherence to eligibility requirements, service-level agreements (SLAs), and reward mechanisms require careful management, adding to operational overhead.

Energy Web X as a Unified Solution

Energy Web X addresses these challenges by providing a substrate-based platform that integrates worker nodes into a unified environment. Substrate’s modular framework allows for highly customizable blockchains tailored to specific use cases, making Energy Web X a robust alternative to the Ethereum-based EWC.

Key Benefits:

• Streamlined Governance: Worker nodes operating under Energy Web X follow predefined governance rules encapsulated in “pallets.” These pallets function like enhanced smart contracts, offering more flexibility and power to manage worker nodes collectively.

• Enhanced Efficiency: A common environment reduces the complexity of synchronization and management, enabling easier scalability for enterprises.

• Interoperability with EWC: Energy Web X is designed to complement EWC, enabling seamless interaction where worker nodes can migrate (“lift”) to Energy Web X for enhanced capabilities and revert (“lower”) to EWC as needed.

Worker Nodes in Energy Web X

Worker nodes remain essential as software packages operated by individuals or businesses. Energy Web X introduces features to make this ecosystem more appealing:

• Reward Systems: To attract operators, worker nodes are incentivized through rewards in EWT (Energy Web Token). These reward mechanisms can be customized based on performance metrics, such as quality and timeliness of work.

• Stake-Based Trust: To run a trusted worker node, operators are required to lock EWT, aligning their incentives with network reliability. This ensures that only committed entities contribute to critical computations.

Role of Solutions and Solution Groups

Energy Web X structures worker nodes into solutions and solution groups, providing a hierarchical approach to management:

• Solutions: Represent specific business applications or use cases powered by worker nodes.

• Solution Groups: Group similar solutions together and define shared governance rules, including operational criteria and reward structures.

Configurable Lifetimes and Rewards: Solution groups provide flexibility:

• Their lifetimes can be predefined but extended based on evolving business needs.

• Reward mechanisms can be dynamically adjusted to incentivize participation and ensure the alignment of worker nodes with enterprise objectives.

On-Chain Consensus for Off-Chain Work

The configurations within solutions and solution groups dictate how worker node outputs are validated on-chain:

• Eligibility Requirements: Define who can participate.

• Service-Level Agreements: Set performance benchmarks for the worker nodes.

• Consensus Mechanisms: Establish thresholds for accepting the results of off-chain computations as correct.

By formalizing these parameters, Energy Web X ensures:

• Accuracy: Only valid results from worker nodes are anchored on the blockchain.

• Trust: Enterprises and stakeholders can rely on a secure and tamper-resistant consensus process.

This structured and dynamic system makes Energy Web X a powerful platform for managing distributed worker nodes while reducing operational complexity and enhancing enterprise scalability.

Overview

Validator Set contracts provide information on current validators and private functionality to add and remove validators.

Documentation and Source Code

Components

For upgradeability purposes, the contracts are divided into 2 parts. See below Fig. 1.

RelaySet Contract

RelayedSet Contract

This contract implements the logic and manages the validator list. The owner of the validator set interacts with this contract for managing the validators. This contract maintains two validator sets:

1. The current validator set (the validators who are actively sealing)

2. The migration validator set, which is the new set we migrate to in case of a change (validator addition or removal).

Validator States

Validators and potential validators have four states in these contracts:

1. Active validator: Validator is in the active validator set, sealing new blocks

2. Not a validator: The address nothing has to do with validation.

3. Pending To Be Added Validator: Validator is already added by the owner and their acceptance is pending, but not active yet until it is finalized. This implies that the validator cannot report, be reported, or produce blocks yet.

4. Pending To Be Removed Validator: Validator is pending to be removed (removed by the owner), but it is not finalized, and so is still active as a validator. This implies that as long as the removal is not finalized, the validator is actively producing blocks, can report and can be reported on.

Reporting

The RelayedSet contract logs malicious or benign reports by emitting corresponding log events that can be seen by anyone. Reporting can only be on and about active sealing validators.

The events contain the reporter- and reported address, and the block number which the validator was reported on.

Interaction with RelayedSet (logic) Contract

Callable functions

Events you can listen to, in addition to report events:

Interaction with Relay Contract

Callable functions

Events you can listen to:

The Worker Node Pallet provides essential functionalities for managing solution groups, solutions, and votes as outcomes of off-chain computation, along with mechanisms to ensure fair reward distribution.

Key functionalities:

• Solution Group Management: Enables registrars to create, register, and deregister solution groups. Funds are locked upon registration and become available for distribution once specific criteria are met.

• Solution Management: Each solution is an off-chain business unit requiring computation by worker nodes, with consensus achieved on computed results to ensure their validity.

• Operators and Workers: Operators join solution groups by locking their tokens, subscribing to groups, and running worker nodes. These nodes process and compute solutions off-chain and participate in on-chain voting to reach consensus on results, which in turn determines rewards eligibility.

• Reward Calculation & Distribution: Manages reward calculations for each solution group, including the handling of reward periods for distribution.

• On-Chain Voting (Consensus): Implements an on-chain voting system to reach consensus on solution results computed off-chain and submitted by workers. The consensus outcome determines eligibility for operator rewards, aligned with each solution group’s configuration to ensure fair reward distribution.

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

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.

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:

Data Collection Process Overview

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

   • CPU usage

   • Memory usage

   • Disk usage

   • Number of connected peers

   • List of visible P2P peers

   • Current block

   • Network latency to 3 different and major locations (e.g. cloudflare, google, amazon)

   • Network throughput

   • Network error rate

   • Number of SSH keys

   • Service status for SSH, docker and the parity container

   • SHA256 hashes of key system components/binaries

   • Current chain specification file (or hash)

2. Telegraf collects relevant metrics from the host machine and the custom-built OpenEthereum metrics collector. The metrics collector allows Telegraf to receive the metrics from the OpenEthereum client

3. The collected metrics are stored in an InfluxDB database and can be visualized using Grafana

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.

Energy Web X’s purpose is to introduce new technical capabilities, leverage and complement the existing Energy Web Chain. To maximize the security of every Energy Web solution using worker nodes, EWT wis required to interact with worker nodes and Energy Web X that can be “lifted” from EWC to EWX and “lowered” back to EWC from EWX.

Worker Nodes are sofware packages that need to be run by individuals and/or businesses. In order to attract entities to run worker nodes, enterprises need to include rewards that pay worker node operator for performing their work. All worker node rewards are paid out in EWT.

Worker Nodes are sofware packages that need to be run by individuals and/or businesses. In order to attract entities to run worker nodes, enterprises need to include rewards that pay worker node operator for performing their work. All worker node rewards are paid out in EWT.

In order to become a trusted part and run worker nodes, individuals and/or businesses require to lock EWT. Enterprises launching worker node networks can configure different thresholds and award schedules at their discretion.

In Energy Web X, solutions represent business applications or use cases that are implemented through worker node networks. These solutions can be grouped into solution groups, which define shared governance parameters, reward structures, and operational criteria. Solution groups are crucial for aligning the behavior of worker nodes across similar or related solutions.

The lifetime of a solution group is configurable, allowing enterprises to set specific timeframes during which worker nodes can participate and earn rewards. Solution groups also allow flexibility: their lifetimes can be extended to accommodate ongoing or evolving business needs, and their reward structures can be raised to incentivize higher performance or attract more participants. This dynamic lifetime and reward management ensure that worker nodes are continually aligned with the goals of the enterprises that rely on them.

Solutions and solution groups establish the configuration that governs how worker node submissions are evaluated and consensus is reached on-chain. This configuration includes eligibility requirements, service-level expectations, and thresholds for agreeing on the correctness of off-chain computed results. By leveraging these configurable parameters, Energy Web X ensures a robust and secure consensus mechanism that validates and anchors the outputs of decentralized off-chain computations. This process is critical to maintaining trust and accuracy across all solutions powered by worker nodes.

EnergyWebX SmartFlow: The First Truly Decentralized SLA

SLAs today rely on trust, manual verification, and centralized enforcement—leading to disputes, inefficiencies, and unnecessary costs. Worse, they ignore sustainability. EnergyWebX SmartFlow is the first truly Decentralized SLA. Enterprises can now automate, enforce, and verify SLAs in a way that is trustless, transparent, and climate-conscious:

• Set performance, uptime, and honesty thresholds—enforced on-chain

• Unlock payments ONLY when SLAs are met

• Eliminate disputes—SLA compliance recorded & validated on-chain

• Define a Carbon SLA—setting a maximum carbon footprint for ESG reporting

With EnergyWebX SmartFlow there is no middlemen, no disputes, no unverifiable claims. Just real-time, automated, and verifiably green SLAs.

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.

• Locks and Imbalances: Introduces runtime locks to temporarily restrict access to balances during specific operations (e.g., governance or staking) and handles imbalances through secure issuance or burning of tokens to maintain economic integrity across the system.

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.

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.

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.

• Instruction Execution: Provides an instruction set for executing operations on remote chains, such as account creation, staking, or governance participation.

• Fee Payment and Weight Management: Handles fee payments for executing XCM instructions, ensuring proper incentivization of involved parties.

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.

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.

• Priority and Weight Control: Assigns priorities to scheduled tasks to determine execution order in case of conflicts and manages weight allocation to prevent overloading blocks with scheduled calls.

• Rescheduling and Cancellation: Provides mechanisms to modify or cancel scheduled tasks before execution.

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.

• Penalty Enforcement: Imposes penalties on validators or network participants based on the severity and frequency of their offenses. Penalties can include slashing, staking disqualifications, or temporary bans to maintain network integrity.

• Historical Tracking: Maintains a history of offenses and their resolutions to enable governance or runtime modules to make informed decisions regarding actors’ reliability. Supports configurable retention policies to manage storage efficiently while preserving essential historical data.

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 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.

• Preimage Validation: Includes a framework to validate and verify the integrity of preimages against hashes before use and ensures that the preimage data corresponds accurately to its referenced hash.

• Access and Ownership Control: Supports fine-grained access controls, ensuring only authorized entities can submit or clear preimages and allows multiple modules and users to leverage preimages securely without conflict.

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.

• Lowering Operations: Supports “lowering” tokens from tier2 to tier1, interfacing with an Ethereum contract. This operation can be executed directly or scheduled for later execution. Lowering operations require confirmations and signatures, with proof requirements verified before sending transactions, ensuring secure, authenticated transfers.

• Proof and Transaction Management: Handles proofs for token transfers, including the ability to regenerate proofs for pending or failed lower transactions. Stores and retrieves data about lower transactions in various states: ready-to-claim, pending, and failed, providing robust tracking and error recovery mechanisms.

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.

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.

What are Worker Nodes?

Types of Worker Nodes

Currently, EWF provides two (2) implementations of Worker Nodes:

How does a Worker Node work?

In a nutshell, a Worker Node is a single processing unit in a network of nodes which has the ability to execute enterprise calculations, and submit votes to derive consensus-based, transparent results.

A general worker node typically involves below processes:

1. Sync operator subscriptions

2. Download and install solutions

3. Run solutions and cast votes

Sync operator subscriptions

The worker node periodically syncs on-chain data for operator subscriptions. The syncing process informs the worker node that either a set of solutions is available to be installed (new subscriptions) or uninstalled (unsubscription or subscription expiry).

Download and install solutions

When the worker node is enabled to run the flows, it downloads the actual Node RED flow JSON files from IPFS using the CID. Subsequently, the flow files are installed in the local Node RED server bundled in the worker node itself.

Run solutions and cast votes

An enterprise use-case is considered executing when the flow files get installed and are running in the Node RED server of the worker node. Each solution flow determines when and how the solution flow produces a result, and when to use the result to cast a vote.

Casting a vote simply follows below steps:

1. A solution is triggered to process the flow

2. The flow gets executed to produce a result

3. The result is transformed in to a Merkle Tree Root Hash

4. The flow requests for the worker to submit the hash as a vote

5. The worker enqueues the voting request

6. The worker submits the vote to EWX

Why does the result gets transformed into a Merkle Tree Root Hash? EWX nor the Worker Node never stores raw or calculated data unless the solution flow created by the enterprise themselves are designed and approved to do so after an extensive audit. EWX as a chain only stores the result hash for optimum performance and data security.

The Merkle Tree Root Hash can represent the actual calculated data as a single, unique vote. However, an adversary can never reverse-engineer the hash to derive the calculated or raw data. This ensures that the entire EWX ecosystem is secure and robust.

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

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

Sign up as an operator

Prerequisites

1. Select any of the solution group that is available for subscription and click Opt-in

1. Enter the name you desired for your operator account in the text field, select country of residence and then hit Continue

1. Confirm the transaction in your wallet

1. Once approved, wait for the transaction to be executed

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

1. Choose your preferred wallet to connect (SubWallet/Ledger)

Option 1: Using SubWallet

1. Scan the displayed QR code using your SubWallet app, select an account that you wish to connect and click on Approve

1. You will see "Account connected successfully" message on the Marketplace app screen. Click Continue to proceed

Option 2: Using Ledger

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:

Prerequisites

• Connected EWX account

• Worker account seed phrase

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 Import Seed Phrase

1. Open your mnemonic backup file and copy the contents. Then, click on Paste from clipboard and click Continue

1. Enter password and re-enter it again for verification before clicking on Import Worker Node Account

1. Once completed, a success message will be shown

Funding an operator account requires token "lifting" from an EWC account. The opposite of this is called "lowering" where tokens are being transferred back to an EWC account from the operator account. We covered those topics in a different section of this guide:

• Lifting tokens: Lifting tokens

• Lowering tokens: Lowering tokens

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

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

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

• Connected EWX account

• Linked worker account

1. Click on Unlink menu on the left panel of the Dashboard

1. Click Unlink to proceed or Cancel

1. Approve the transaction in your wallet

1. Wait for the transaction to finish execution

1. A successful message with transaction URL will be displayed when unlinking is successful

There are 2 types of tokens being used in Marketplace namely EWX and EWC tokens. Listed below are the differences between them:

Guides available for token management:

FAQs

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

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

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.

Now the device is ready to interact with the Polkadot chain, including the EWX chain.

Ledger Live app does not display EWX account and its balance as it is not yet supported. EWF is already including this in the roadmap.

The Marketplace App directly communicates with your Ledger device without the need to use Ledger Live as long as Polkadot is installed.

Connect Operator Account using Ledger Device

The first step to use Ledger with the EWX Marketplace application is to connect your hardware wallet. In this case, the process is very similar to connecting any other browser or mobile-based wallet. The user needs to click on the “Connect” button that appears both in the top-right corner of the screen.

A dialog will pop up, and the user can choose its preferred method to connect the wallet - in this case, choose Ledger.

The user will be prompted to continue the connection process in the hardware device.

By default, the Ledger device will look like this when unlocked:

After starting the connection process, the user needs to open the Polkadot application on the Ledger device.

After opening the Polkadot app (pressing both buttons at the same time), this will appear on the device:

That means there is an ongoing operation that needs to approve. To do that, press the right button until the “Approve” screen is displayed.

After approval, below shows the confirmation that the user is connected to the Ledger account successfully.

After successful connection, the EWX Account will be displayed on the upper right corner of the screen.

Funding the EWX Account

Executing a transaction

The process is very similar to the browser-based wallet, and applies to all the different transactions available on the app: lowering, sign up as operator, subscribe, link worker account, unsubscribe, top-up stake and claim rewards. After initiating a transaction, for example - lowering, the user will see a ‘Pending confirmation’ screen. The user needs to confirm the operation using the same method used to connect to the wallet.

When this screen appears, open the Polkadot account on the Ledger device, just like before.

After opening the app, review and approve the operation.

The details of the transaction are displayed on the device just like on the next sample screens.

Proceed to approve the operation.

The progress screen on the app immediately changes, displaying the “Executing transaction” title. At this point, the transaction has been sent and is being processed on the blockchain.

If the transaction finished successfully, the success screen and the corresponding tx hash are displayed. This concludes the entire transaction process.

Prerequisite

• Connected EWX account

Adding an EWC account

1. Click on Add EWC Account + button that is available on the left panel

1. Enter a valid EWC account address and press +. You may add multiple accounts and they will appear as a list

Removing an EWC account

1. Click on ⋮ icon next to the EWC account balance, and choose Manage Accounts

1. There's a - icon right next to each of the added accounts. Click on it to remove

Prerequisites

• Connected EWX account

• Minimum balance of 1 EWT (not including gas fee) in EWX account

1. Find the Lower menu in the account popover menu on top-right of the screen. You may also click on ⋮ icon located next to your EWX balance then click Lower Tokens

1. Enter lowering amount and click Approve

1. Enter an EWC address and/or select an EWC account for which the lowering amount will go to. Make sure that the chosen account is highlighted before clicking Next

1. Review the transaction and click Confirm

1. Approve the transaction in your wallet

1. Wait for the transaction being executed

1. You will see a "Transaction scheduled" message along with the transaction URL to Polkadot explorer

Prerequisites

• Connected EWX account

• Minimum balance of 10 EWT (not including gas fee) in EWC account

1. Find the Lift menu in the account popover menu on top-right of the screen. Or, if you have added an EWC account previously you may also click on ⋮ icon then Lift Tokens

1. Select your preferred EWC Wallet (WalletConnect/Ledger)

1. Check your wallet and select an account to connect

1. Enter lifting amount, click Approve

1. Review the transaction and click Confirm

1. Approve the transaction in your wallet & wait for the transaction being executed

2. You will see a "Transaction scheduled" message along with the transaction URL to Polkadot explorer

Your total EWT balance of currently connected EWX account and added EWC account(s) are available on left panel of the Marketplace app. You may Lift, Lower and Manage tokens by clicking the ⋮ icon located next to each of the account balance.

All of your lifting and lowering transactions can be tracked in the Transactions list. Its menu is located at the top of the page, next to notifications.

There are 3 tabs for viewing namely All, Lifting and Lowering. You may search for a specific transaction by using the search feature. Some useful transaction information available are:

• Date and time

• Type (Lifting/Lowering)

• From and to addresses with EWX and EWC indicators

• Token amount lifted/lowered

• Status

• Transaction hash

• Explorer url

Prerequisites

• Connected EWX account

• Subscribed to a solution group

• Maximum subscription limit have not reached

1. Find the Top-up button either in Dashboard or Manage subscription

1. A pop-up will appear, enter your top-up amount in the text field

1. Review your top-up amount before clicking on Confirm

1. Approve the transaction in your wallet

1. Wait for the transaction being executed

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

1. Your subscription amount will be displayed as + <value> as an indicator that the top-up amount will be added to the total subscription in the next reward period

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:

FAQs

Prerequisite

• Operator account with funds more than the minimum subscription amount

1. Click Opt-in to subscribe to a solution group

1. A pop-up will appear for you to enter your subscription amount. Once you're satisfied with the value, click Continue

1. Review your subscription amount and click Confirm