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.

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

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

This step-by-step guide explains how EWT holders can participate in securing the Energy Web X (EWX) network and support Verified Compute Cloud (VCC) solution accountability through liquid staking and solution group participation.

Step 1: Acquire Energy Web Tokens (EWT)

EWT can be acquired via decentralised and centralised exchanges. A list of supported exchanges is available here. If you currently hold EWT on Ethereum or EWC, before you can stake, you must first bridge your tokens to Energy Web X (EWX) using the official Energy Web Bridge.

Note: Bridging tokens from EWC to EWX is a one-way function i.e., once tokens are bridged to EWX, they cannot be bridged back to EWC. Bridging tokens from Ethereum to EWX is a two-way function i.e. tokens can be moved back and forth using lock, mint, and burn unlock mechanics.

Step 2: Set Up a Compatible Wallet

First, install an . Once installed, create a new account or import an existing one. Be mindful to securely back up your recovery phrase. Next, enable the Energy Web X network in your wallet settings to view your EWT balance and transact EWT. You can see the steps below to setup your wallet - Download the wallet of your choice either from appstore or playstore - Click the create new account tap, add your password - Write down your seed phrase safely - Verify your seed phrase - Your wallet is ready - Click the drop down button - Click Manage networks - Search Energy Web in the search bar - Toggle on the Energy Web X network - Select Manage tokens, and toggle on the EWX token You can see a visual guide on how to setup your wallet .

Step 3: Liquid Stake Your EWT (stEWT)

Liquid staking on Energy Web X allows you to stake EWT and receive a liquid token representation called stEWT. stEWT is transferable and can be used across the ecosystem, including for participation in Verified Compute Cloud solutions. Liquid staking does not mint any new EWT; the overall EWT supply cap remains unchanged.

To liquid stake, open the and select “Liquid Staking”. Then enter the amount of EWT you wish to stake, confirm and sign the transaction in your wallet. Once completed, your wallet will display a stEWT balance.

Note: The exchange rate between EWT and stEWT may change gradually over time due to auto compounding of staking rewards. Click here for or read more .

Step 4: Complete KYC to Stake on Verified Compute Solutions

Now that you have liquid staked your EWT, you can participate in Verified Compute Cloud solution groups. Some VCC solutions require participants to complete know-your-customer (KYC) identity verification before subscribing. The SAFc Registry is one example of a VCC solution that requires KYC.

To initiate KYC, open or download the . Navigate to “Discover”, and locate the relevant Verified Compute Cloud solution group. Click “Initiate KYC” and sign the transaction in your wallet. A KYC form will open in a new browser tab, which you can follow to complete the KYC. Click for a tutorial on how to initiate the KYC identity verification.

Then complete the following KYC process, implemented by a third party verification service provider:

1. Enter your email address and submit the form.

2. Check your inbox for the verification email.

3. When you receive the verification email, click Verify My Identity.

4. Complete the identity verification flow.

Once your identity has been verified, you can return to the . The solution group status will change to Opt In. Click for a tutorial on how to complete the KYC identity verification.

Step 5: Subscribe to a Verified Compute Cloud Solution Group

To subscribe, click on the “Opt In” button in the , and then complete the Sign Up as Operator flow. To sign up as an operator you need to follow the steps below: 1. Have your EWX account to the marketplace.

2. Have some in the account for transaction fee.

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

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

5. Confirm the transaction in your wallet

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

7. You will see a success message along with the transaction URL to Polkadot explorer. Your operator account is now registered.

For more information and guide you can check

Choose the amount of stEWT to allocate. Confirm and sign the transaction. Click for a tutorial on how to subscribe to a solution group.

When you subscribe to a VCC Solution Group, you commit stEWT as slashable collateral to support enforcement of the VCC Protocol. Your participation signals support for solution integrity and accountability. Rewards may accrue over time depending on successful service delivery and the relevant VCC Protocol conditions.

Step 6: Claim Your Rewards

Any applicable rewards for successful service delivery are generated automatically, subject to the VCC Protocol conditions, and are claimable via the . To claim, please follow these steps:

1. Navigate to your subscribed solution group

2. View “Available Rewards”

3. Click “Claim Rewards”

4. Confirm and sign the transaction in your wallet.

Once this claim process is completed, the generated rewards are credited to your account.

Note that awards paid in USDC may not yet be visible directly in the . Updates are in progress to enable this feature, and in the meantime USDC balances can be viewed via supported wallets (e.g. , or Subscan).

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.

Utility tokens like EWT are different from other digital assets in the blockchain sphere such as coins, non-fungible tokens, and stablecoins. To learn more about the distinctions between these assets, see this article,.

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.

Energy Web Chain (EWC) has been governed by Validators based in fifteen countries, representing publicly known and geographically diverse entities, many of whom are subject to strong domestic regulatory supervision regimes. The EWC Validators ranged from large energy-sector market participants (including utilities, grid operators, and cleantech developers) to blockchain and energy startups and had over time grown to about 40 entities. All major Energy Web platform governance motions prior to 2025 technology and governance upgrade are listed below:

Energy Web Platform Governance Motions:

June 2019

• EWC Launch and Initial Token Allocation

Following a period of research, development and testing (including support to the first Proof-of-Authority (Kovan) blockchain network and the establishment of ), EWC was officially launched on 16 June 2019 (“Launch”) when the genesis block was approved by the parties responsible for EWC governance (the “Validators”) via system contracts. At Launch, the development of the EW Chain was complete, its protocol was deployed for production, and it was fully operational. Since that time, EWF and other third parties have continued to develop software development kits (SDKs) and decentralized applications; however, it is to be noted developers and users of the EW Chain are not required to access or use the SDKs in order to interact with the EWC (or upgraded EWX), and that EWC/EWX remain operational without any further development of SDKs or deployment of additional decentralized applications.

EWC validators also approved an initial allocation of 21.2 million EWT to 102 entities (including some individuals) that provided funds for Energy Web platform development (“Participants”). Participants that purchased EWT prior to April 1, 2018 were not permitted to transfer or otherwise dispose of their EWT until at least September 16, 2019. Participants who made their purchase after April 1, 2018 were required to not transfer their EWT until at least December 16, 2019. The Validators also approved an allocation of 20.9 million EWT to the Foundation (EWF) and 10 million to its founders, with approximately 35% of the EWF allocation earmarked to pay operational expenses. Including payments to EWF staff and service providers who support and implement the decisions and directives of the Validators (see Table 1 below). The purpose was described in more detail in the and the updated , while the , the and the detailed the subsequent technical updates, leading up to the Energy Web 2025 Upgrade.

Table 1: EWT Token Allocation, June 2019

• Rough Consensus Model: Validators adopted an interim off-chain “rough consensus” approach for adding/removing validators, protocol/client updates, and governance changes, relying on EWF support to protect a transparent decision framework while the validator set was still small.

July and August 2019

• Validator Eligibility Criteria: In July 2019, Validators approved criteria requiring validators to be legally registered organizations, active EWF Members, and to have proven technical competence by having run a Volta testnet validator.

• Energy Web Token (EWT) Listing: In July 2019, Validators discussed exchanges’ listing as a key step to decentralize token supply and support utility token classification, and supported moving forward, beginning with the Liquid exchange listing, tasking EWF to administratively support the registration process, and then consider other exchanges, including the US once there is more regulatory clarity. In August a Liquid Listing Date was approved for September. Validators also discussed the risks of maintaining a default minimum gas price of zero and supported a recommendation to raise the minimum to 1 Gwei (0.000000001 EWT). This was intended to reduce exposure to spam or DDoS attacks while keeping fees low relative to Ethereum. Validators noted the need to recalibrate the minimum gas price over time in response to market conditions, balancing security with affordability for developers and users.

September 2019

• Validator Eligibility / Transition from Affiliate to Member Program: Validators deliberated on the shift from the one-time EWF Affiliate MOU to an annual EWF Membership model beginning in 2020 as a key requirement for validator eligibility. The new structure requires members to actively support EWF’s mission, contribute to the ecosystem, pay fees or provide in-kind contributions, and demonstrate commercial activity or developer engagement. Validators discussed safeguards for smaller companies, including potential staking or multi-sig payout mechanisms. They agreed that the updated criteria would apply equally to existing and new entrants.

• Transitioning from Interim Governance Model: With nearly 20 validators across 14 time zones, validators agreed that the rough consensus model based on monthly calls was no longer scalable. EWF was tasked with documenting the governance processes and introducing signaling vote tools by year-end, with formal validator votes replacing reliance on silence as tacit agreement, thereby creating a clearer audit trail for validator decisions.

October 2019

• Formal Voting Mechanism: Validators agreed to replace the rough consensus model with a formal off-chain voting process on the EW Chain Governance Forum (Discourse). Voting delegation was disallowed, participation will be monitored by EWF, one voting event (five business days) per month will be scheduled, and decisions will pass by simple majority (no incentives/penalties for now). The first vote was scheduled for the week of November 11, 2019.

• Validator Eligibility / EW Membership: Validators prioritized two mechanisms for future eligibility rules: (i) requiring small companies (<$5m annual revenue) to stake block rewards for a set period, and (ii) clearer membership criteria and transparency for EWF Members. A formal proposal to require small companies to stake mined tokens for one year, applying either to all or only to new entrants from 2020, was prepared for a November vote.

November 2019

• Validator Token Staking: Validators discussed and rejected a motion to demand from new validators to lock block rewards in escrow for 1 year to build reputation and deter malicious behavior. The decision tally was as follows: 9 Yes, 13 No, 2 abstained.

• Emergency Operating Procedures: Validators retired the legacy “Node Control” tool and established formal EOPs, authorizing temporary removal of validators or node updates by EWF in emergencies (e.g. unplanned forks, malicious/benign failures), subject to validator review within 48 hours. The decision tally was as follows: 17 Yes, 3 No. Validators also discussed the need for better visibility into node stability, with suggestions including dashboards, netstats-style pages, and sharing monitoring scripts. EWF was tasked with investigating the feasibility and resource requirements for a netstats-like monitoring tool while emphasizing that each validator remains responsible for monitoring its own node.

December 2019

• Ethereum Istanbul Hard Fork Alignment: Validators approved adoption of Ethereum’s Istanbul hard fork (EIPs 152, 1108, 1344, 1884, 2028, 2200) to align EWC with Ethereum mainnet improvements. Implemented via a 5-stage rollout plan (Volta test updates, validator client upgrades, chainspec updates, fork observation). The decision tally was as follows: 14 Yes, 2 Abstain. In two subsequent discussions in December they deliberated on the governance of the EWT Community Fund and the 2020 validator eligibility criteria but no new decisions were made.

January 2020

• Validator Eligibility 2020 and Beyond: Validators confirmed that their participation in the EWF Membership program remains the primary eligibility criterion, as it provides KYC and financial commitment required under PoA mechanism. Validators who did not renew membership were removed on 17 January 2020. Future improvements to the membership process and potentially a queue for new applicants was discussed. No minimum validator count was set, but diversity across regions and business models was emphasized. There were also additional discussions on the governance mechanism for the Community Fund, which is open to the entire ecosystem, but no specific decisions were made on that topic.

February 2020

• Nethermind Client Funding: Validators approved a community funding allocation for development of a Nethermind AuRa client (sealing mode, telemetry integration, Docker support, docs). Deliverables were funded in two phases totaling 2,877 EWT. The decision tally was as follows: 19 Yes (unanimous).

April 2020

• Update on EWT Status: EWF reported to validators on the assignment to engage with external counsel and regulators to ensure utility classification. As a result, it was agreed that EWF would proceed with the global, including US-accessible exchange listings, starting with Bitmart on 8 May 2020. The validators were also informed that the EWC-ETH bridge is now production ready, enabling listings on Ethereum-based DEXs such as IDEX. Energy Web Wallet integration with Ledger via MyCrypto was also reported.

• Technical Updates on Operating, Monitoring, and Maintaining Validator Nodes: EWF reported that it is setting up ENS on Volta and EWC, offering one free domain per member for the first year (future pricing TBD), pursuant to received directives from the validators. Validators noted the transition from Parity to OpenEthereum, with v2.7.x being the final Parity-branded update and introducing a non-backwards-compatible chain DB format. Concerns were raised about validator liability if third parties use alternative clients and it was agreed that a working group and governance forum post would be created to explore liability limitations and user terms.

May 2020

• Community Fund Governance: Validators reviewed a draft governance model for the Community Fund, prepared by EWF based on prior validator discussion. It allocates one-third of tokens respectively to (i) an EW Chain Account governed by validators for technology development, (ii) an EW Operating Account for the Foundation’s mission and development of additional open-source components, and (iii) a Decarbonization Account for grants and environmental certificates. Validators supported the model in principle, with feedback on clarifying scope between validator vs. Foundation governance, structuring grants to mitigate token volatility, and ensuring proposals are denominated in EWT. EWF was tasked with refining the document, creating a new forum section for EWC Account proposals, and incorporating all validator inputs.

June 2020

• New Member / Validator Onboarding Process: Validators reviewed a new formal application process requiring validator entities to pass KYC/AML, demonstrate legitimate business activities aligned with EWF’s mission, and provide references. The EWF NetOps team was tasked with reviewing applications and sharing them with validators for comment and approval. Validators supported a case-by-case approach for non-energy companies and suggested creating a template to categorize validators and publish public-facing information.

• Community Fund Governance: Validators deliberated and approved the updated, three-part Community Fund model in principle: (i) ⅓ reserved for EW Chain core infrastructure, governed by validators; (ii) ⅓ reserved for EWC operations and development of a utility layer, including EW-DOS development, with governance delegated to EWF; (iii) ⅓ reserved for an “Impact” fund to support wider adoption of EW technology. Grants to be denominated in EWT. Final approval was expected by July, after which funding proposals could be accepted. Validators also agreed to publish external discussion summaries for enhanced transparency, while maintaining validator-only forums for the discussions. They also noted the release of Parity 2.7.2-stable, the last Parity-branded client before OpenEthereum. Plans were approved to update Volta and EWC nodes by the end of June, with further testing required for OpenEthereum compatibility. Validators also discussed the resilience benefits of multi-client diversity and considered a future Community Fund proposal to fund Nethermind development to production grade, including telemetry and installation scripts.

July and August 2020

• Energy Web Community Fund: The three-part governance mechanism for the Community Fund was formally implemented. In July 2020, validators adopted Proposal 04 to award 2,877 EWT to Nethermind to develop a production-ready client for EWC to improve chain resiliency, funded from Chain Reserve on a deliverables-based schedule, by a vote of 20 in favor and 4 not voting. The Operations Reserve funded the Innovation Challenge, awarding 3,700 EWT to winning and runner-up teams. EWF also reported on building a monitoring tool to track balances across reserves. The new Nethermind Client Testing began mid-August 2020 when validators agreed to a soft target of at least three nodes adopting Nethermind once stable, while leaving final client choice to each validator.

• New Member / Validator Applications: Validators noted that the new formal application and KYC process for prospective members came into effect, though no new applications were received in July 2020. In August 2020, two new applicants were approved under the formal application and KYC process – Vodafone and Zytech Solar.

December 2020

• Bug Bounty Program: Validators established an EW-DOS Technical Committee, composed of representatives from validator organizations, to manage bug reports, with tiered EWT rewards (Low–Critical), with work funded from Community Fund reserves. The decision tally was as follows: 21 Yes (unanimous).

May 2021

• Upgrade OpenEthereum Client & Berlin Hard Fork for Validator Nodes: Validators agreed to align EWC with Ethereum’s Berlin upgrade by moving validator nodes to OpenEthereum v3.2.5 and activating EIPs 2565 (ModExp gas), 2718 (typed tx envelope), 2929 (state access gas increases), and 2930 (access lists). Execution followed a staged plan across Volta to EWC, with defined observation windows and rollback contingencies. The decision tally was as follows: 37 Yes (unanimous).

August 2021

• Community Fund Grant: Anyblock Analytics Validator Accounting Tool: Validators approved a funding allocation for an accounting dashboard to help validators track and verify EWT rewards (block rewards/fees) and transactions. The decision tally was as follows: 28 Yes (unanimous).

September 2021

• London Upgrade, EIP-1559 & related EIPs: Validators agreed to implement Ethereum’s London Upgrade on EWC (EIPs 1559, 3198, 3529, 3541, 3554), with a streamlined process vs. Berlin Upgrade: all validators to update within set windows; self-reporting via forms; non-compliant nodes to be temporarily removed; staged Volta observation, EWC activation with public comms. The decision tally was as follows: 37 Yes (unanimous).

November 2021

• Community Fund Grant: Trust Wallet, Bl0x: Validators approved a funding allocation (grant) to Bl0x to add native EWT to Trust Wallet (chain/address/signing logic, tests, open-source PRs), implement WalletConnect, and co-author user documentation. The decision tally was as follows: 35 Yes (unanimous).

December 2021

• Validator Code of Conduct Update : Validators amended the Code of Conduct to integrate objective enforcement including thresholds around Node health, uptime, meeting attendance, voting participation (rolling 6 months). Any violations are to trigger escalation suspensions/expulsion; compliance tracked via a public validator dashboard. The decision tally was as follows: 23 Yes, 9 No.

March 2025

• Energy Web Architecture Upgrade Proposal (Zurich Hard Fork): Validators approved the Energy Web 2025 Upgrade, transforming the Energy Web platform architecture from membership-based PoA validation on EWC to permissionless, nominated PoS validation on EWX Polkadot parachain, with the following key features: EWT migration to ERC-20 on Ethereum, on-chain treasury governance replacing exclusively validator-managed Community Fund and decentralising platform governance overall, as well as permissionless staking options (collators, liquid restaking; Verified Compute Cloud staking with stEWT facilitated by Worker Node Network pallet) and multi-asset enablement as BYOT for verified compute reward payout fees.

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.

Calculator:

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

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

This contract implements the required interface expected by the engine and it is the contract defined in the chainspec seen by the engine. It relays most of the function calls to the RelayedSet contract, which holds the actual logic. The logic contract can be replaced (upgraded), so it is possible to change the behavior of validator management without conducting a hard fork.

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.

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:

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:

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.

Complete Your KYC Verification - Step by Step Guide

Welcome! This guide will help you complete your KYC (Know Your Customer) verification. Don't worry - we'll walk you through every step.

What is KYC? KYC is a simple identity check that helps keep the platform safe for everyone. It's quick and easy to complete.

How Did You Get Here?

There are two ways you might have arrived at this page. Don't worry - we'll show you exactly what to do for both!

Option 1: You Came Here Directly

You typed in the website address yourself or clicked a direct link.

What you'll need to do:

• Choose your solution group

• Enter your email

• Connect your wallet

• Submit your information

Option 2: You Came from a Marketplace

You clicked a link from another app (like a Marketplace).

Good news! Some information is already filled in for you, and you don't need to connect your wallet - it's already done!

What you'll need to do:

• Enter your email

• Submit your information

That's it! Much simpler, right?

If You Came Here Directly

Follow these simple steps:

Step 1: Open the Page

When the page loads, you'll see a form that says "Add your details".

You'll see:

• A form with the title "Add your details"

• A dropdown menu for "Solution Group" (it will be empty)

• A box for your email (it will be empty)

• A button at the bottom that says "Connect Wallet"

Step 2: Choose Your Solution Group

Click on the "Solution Group" dropdown menu. A list will appear.

What to do:

• Look through the list

• Click on the option that matches your situation

• The list will close and your choice will appear in the box

Step 3: Enter Your Email Address

Click in the "Email" box and type your email address.

Important tips:

• Make sure you type it correctly - you'll need to receive emails at this address

• Double-check for typos before moving on

• Use an email address you check regularly

Step 4: Connect Your Wallet

Click the "Connect Wallet" button at the bottom of the form.

What happens: A popup window will appear showing different wallet options. You'll see wallets like:

• Polkadot{.js}

• SubWallet

• Talisman

• WalletConnect

How to connect:

1. Look through the list and find your wallet

2. If you don't see it, scroll down - there are more options under "More"

3. Click on your wallet

4. Your wallet app will ask you to approve the connection - click "Approve" or "Connect"

Don't have a wallet? You'll need to install one first. Look for wallet extensions in your browser's extension store.

Step 5: Submit Your Information

After your wallet is connected, you'll see a "Submit" button. Click it!

What happens:

• You'll see a message that says "Submitting Details..."

• You need to sign a message (your EWX address) - as an ownership challenge

• Please wait - this usually takes just a few seconds

• Don't close the page while it's processing

Step 6: See Your Results

You'll see one of two messages:

✅ If it worked:

• You'll see: "Details Submitted Successfully"

• The message will tell you to check your email for the next steps

• Click "Back to Home" when you're ready

• Important:

❌ If something went wrong:

• You'll see an error message explaining what happened

• Click "Retry" to try again

• If you see "Verification Already Ongoing", click "Resend Link" to get a new email

If You Came from a Marketplace

Great news - this is even easier! Follow these steps:

Step 1: Check the Form

When you arrive, some information is already filled in for you.

You'll see:

• The "Solution Group" is already filled in (you can't change it - that's normal!)

• The "Email" box is empty - you need to fill this in

• The button at the bottom says "Submit" (not "Connect Wallet")

Remember: You don't need to connect your wallet - it's already done for you!

Step 2: Enter Your Email

Click in the "Email" box and type your email address.

Make sure:

• You type it correctly

• You use an email address you check regularly

• You double-check for any typos

Step 3: Submit Your Information

Click the "Submit" button.

What happens:

• You'll see "Submitting Details..."

• Wait a few seconds - don't close the page

• You'll see a success message when it's done

Step 4: See Your Results

You'll see one of two messages:

✅ If it worked:

• You'll see: "Details Submitted Successfully"

• Click "Back to Home" when you're ready

• Important: Check your email inbox - you'll receive an email with a link to continue

❌ If something went wrong:

• You'll see an error message

• Click "Retry" to try again

• If you see "Verification Already Ongoing", click "Resend Link"

What Happens Next?

After you successfully submit your information, here's what happens:

Step 1: Check Your Email

Within a few minutes, you'll receive an email with a link to continue your verification.

What to do:

1. Open your email inbox

2. Check your spam or junk folder if you don't see it right away

3. Look for an email about KYC verification

4. Click the link in the email

Can't find the email? Don't worry - sometimes emails take a few minutes to arrive. Check again in 5-10 minutes.

Step 2: Complete Your Identity Verification

When you click the link, you'll go to a verification website called SumSub.

What you'll need to do:

1. Follow the instructions on the screen

2. You'll need to take photos of:

   • Your government ID (like a driver's license or passport)

How long does this take?

• Taking the photos: Just a few minutes

• Getting approved: Usually a few hours to a few days (they need to check your documents)

Don't worry if it takes a while - this is normal! They're making sure everything is correct.

Step 3: Get Your Approval Email

Once your verification is approved, you'll receive another email.

This email will tell you:

• That your verification was successful

• Important information about your account

• A link to go back to the marketplace

What to do:

• Click the link in the email

• You'll return to the marketplace

• You're all set! You can now use the marketplace with your verified account

Messages You Might See

Here are some messages you might see and what they mean:

"Submitting Details..."

• This means your information is being sent

• Please wait - don't close the page

• This usually takes just a few seconds

"Details Submitted Successfully"

• Great! Everything worked

• Check your email for the next step

• You're doing great!

"Submission Failed"

• Something went wrong, but don't worry

• Read the message - it will tell you what happened

• You can try again by clicking "Retry"

"Resending Verification Link..."

• A new email is being sent to you

• Check your inbox in a few minutes

"Verification Link Resent"

• Your new email has been sent

• Check your inbox (and spam folder)

Wallet Connection Messages

• Your wallet might ask you to sign something

• This is normal and safe

• Just follow the prompts in your wallet

Common Questions

Why can't I change the Solution Group?

If you came from a marketplace, the Solution Group is automatically set for you. This makes sure you're using the right settings. You can't change it, and that's okay - it's supposed to be that way!

Do I need to connect my wallet?

It depends how you got here:

• Came from a marketplace? No! Your wallet is already connected. Just enter your email and submit.

• Came here directly? Yes, you need to connect your wallet. Click "Connect Wallet" and choose your wallet from the list.

Why is the Submit button grayed out?

The Submit button only works when everything is ready:

• You've chosen a Solution Group (or it's already filled in)

• You've entered your email address

• Your wallet is connected (only if you came here directly)

Make sure all the boxes are filled in correctly!

What happens after I submit?

Here's the simple version:

1. You submit your information ✅

2. You get an email with a link to verify your identity 📧

3. You click the link and take photos of your ID and yourself 📸

That's it! The whole process usually takes a few days from start to finish.

Having Problems? We Can Help!

The form won't submit

Try these things:

1. Check your email - Is it typed correctly? It should look like: [email protected]

2. Check the Solution Group - Did you choose one? (Or is it already filled in?)

3. Check your wallet - Is it connected? (Only needed if you came here directly)

I can't connect my wallet

Try these solutions:

1. Do you have a wallet? You need to install a wallet extension first

2. Is your wallet unlocked? Make sure your wallet is open and unlocked

3. Try refreshing the page - Sometimes this helps

I see an error message

Don't panic! Here's what to do:

1. Read the message - It will tell you what went wrong

2. Look for a "Retry" button - Click it to try again

3. Look for a "Resend Link" button - Click it to get a new email

I didn't receive the email

Try these steps:

1. Check your spam folder - Sometimes emails end up there

2. Wait a few minutes - Emails can be delayed

3. Check your email address - Did you type it correctly?

I made a mistake in my email address

No problem! Here's what to do:

1. Go back to the form (either directly or from the marketplace)

2. Fill everything out again with the correct email:

   • Choose your Solution Group (or it will be pre-filled)

Tip: Double-check your email address before clicking Submit to avoid this!

Can I change my email after submitting?

Unfortunately, no. Once you submit, you can't change your email. If you need to use a different email, you'll need to start the process over with the correct email address.

I don't see the SumSub verification email

Try these steps:

1. Check your spam folder - It might be there

2. Wait 5-10 minutes - Emails can be delayed

3. Check your email address - Make sure you typed it correctly

I don't see the approval email after completing SumSub

Don't worry - this is normal!

1. Check your spam folder

2. Be patient - Approval can take a few business days

3. Make sure you finished the SumSub verification completely

How long does everything take?

Here's a realistic timeline:

• Submitting the form: Just a few seconds

• Getting the first email: Usually within a few minutes

• Completing SumSub verification: About 5-10 minutes to take the photos

Total time: Usually 1-3 business days from start to finish.

What if my SumSub verification gets rejected?

Don't worry! This happens sometimes. Here's what to do:

1. Check your email - You'll get an email explaining why

2. Read the reason - It will tell you what went wrong

3. Fix the problem - Maybe your photo wasn't clear, or your ID wasn't readable

Can I use the same email more than once?

Yes! You can use the same email address, but each time you submit, it creates a new verification process. If you need to start over, you can submit again with the same email.

Do I have to finish everything in one sitting?

Good news: No, you don't!

• The form: Try to complete this in one go

• SumSub verification: Do this when you get the email (the link might expire after a while)

• Returning to marketplace: Do this when you get the approval email

You can take breaks between steps - just don't wait too long!

I came from a marketplace but don't see the Submit button

Try these things:

1. Did you enter your email? Make sure the email box has your address in it

2. Is the Solution Group filled in? It should be - if not, try refreshing

3. Try refreshing the page - Sometimes this fixes it

Still Need Help?

If you're stuck, try these steps:

1. Read through this guide again - You might have missed a step

2. Check any error messages - They usually tell you what's wrong

3. Try refreshing the page and starting over

Remember: Everyone needs help sometimes. Don't be afraid to ask!

You've Got This! 💪

The KYC process might seem complicated at first, but it's really just a few simple steps:

1. Fill out the form

2. Check your email

3. Take some photos

4. Wait for approval

This process helps keep everyone safe on the platform. Thank you for taking the time to complete it!

Good luck, and don't hesitate to reach out if you need help! 😊

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.

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

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. Go to the Dashboard page to view or

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

Some of the solution groups have Unsubscription Delay enabled. This means that unsubscription will only take place after a certain reward period(s).

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

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!

Q: Is there an alternative way to bootstrap an operator account rather than using Marketplace App?

Yes, follow these steps to manually create an operator account:

1. Visit .

2. Select MAINNET EWX, depending on your use case.

3. Go to .

4. As the operator, call the extrinsic

Q: How many Worker Accounts can be assigned to single Operator Account ?

For now, single Operator to Worker account assignment is supported. You can always disconnect previously connected Worker Account and replace it with different one.

Q: Can I switch between Managed/Self-hosted versions of Worker Node ?

Yes, you can switch and move to new Worker any moment. If you dont want to tamper with blockchain-setup you just need to use the same Worker Account Seed in your new Worker. Keep in mind that old Worker Node instance should be stopped right after new one is set up.

Q: Where I can find blockchain explorers for EWX?

You can use or explorer.

Q: Can I move between Launchpad/Marketplace Desktop App based worker/Server Based Worker Node?

Yes, you can move to another type of worker any time you want. The only thing you need is to use the same Worker Account Seed for configuration of your new worker.

Once new worker is set-up turned on on desired platform , please always remember to turn-off previous instance to omit double-voting which can potentially lead to unintended behaviour.

Q: Where and when will I be able to check whether my Worker is voting correctly?

1. When you subscribe to any Solution Group using your Operator Account linked to Worker Account configured for your Worker, there is a max-24-hours period before any votes from your Worker will be accepted by EWX.

2. After that time, your worker will start executing Solutions WorkLogic from Solutions that are in Active state in non-expired Solution Groups that your Operator Account is subscribed to.

3. You should be able to view votes being submitted from your Worker

Q: Are there any limits on Worker Node instances that I can set up?

1. There is no limit on amount of Worker single user can set-up, but keep in mind that single Operator Account can have only single Worker Account linked

2. You can set-up multiple Worker Nodes on the same machine if resources are allowing for that.

3. Single Worker can handle multiple Solution Group subscription and therefore run multiple solutions simultaneously.

Q: Are there any tools where I can find EWX and Worker Nodes related stats?

While there is no official EW-built dashboard, there are several community/partner built dashboards that you can check.

Q: For one solution I see 50 votes while for other only 5 votes that are being casted by my Worker Node per reward period (24-hours), is that normal?

Each solution represent unique logic therefore different quantities of votes could be perfectly normal behaviour to expect.

As business process captured within solution logic is different, therefore also schedules and triggers can be also totally different.

E.g one solution can demand a steady voting every 30 min, while other can have an asynchronous triggers coming from real us of a given app.

Please keep in mind, that system does not reward quantity of voting itself, but rather quantity of votes when votes were needed - meaning it incentives your worker to run 24/7 instead of casting large amount of votes at random times.

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:

• Sustainable Aviation Fuel Certificates

• Autogreencharge

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.

Learn more

CONTENTS OVERVIEW

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.

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.

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.

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

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.

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

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

Disclaimer: Energy Web is not responsible for individual staking decisions, including staking, unstaking, or taking no action, in relation to collator onboarding, offboarding, or growth events.

1. Will delegators receive rewards from a collator they are delegating to, if said collator is deregistered before a growth event?

No. If a collator is deregistered before the growth snapshot, neither the collator nor its delegators will receive rewards for that growth period, even if the collator had already accrued points earlier in the period. Reward eligibility is determined at the growth snapshot, and collators must still be active at that point to be included.

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.

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

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

Lifting & Lowering

What is lifting?

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

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

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.

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.

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.

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

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.

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.

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.

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

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 .

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 Worker Node offering. Please refer toDocumentation for full details.

2. Alternatively If you would like to use open-sourced version, please follow instructions covered in .

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 Bridging $EWT using the Energy Web X Bridging Web App.

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 Energy Web Chain (EWC) is an open-source, public blockchain derived from Ethereum 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 decentralized identities (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.‌

You can read more about the Proof-of-Authority consensus mechanism .

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:

1. The data in each block is immutable and unchangeable. Each is linked to the previous block by a cryptographically created hash. If one block is tampered with, the hash of every subsequent block in the chain would be need to be updated. Because Validators' consensus is required to create new blocks, a block with an alternative transaction history would be rejected by Validators.

2. Smart contracts provide automated logic for on-chain actions. Transactions on the chain are governed by code called that contain explicit logic and requirements for actions to occur. When specific conditions are met, the code will self-execute. Once a smart contract is deployed on the blockchain, it cannot be changed or reversed, removing the risk that anyone can update the logic of the contract for personal gain.

Persistence on the Energy Web Chain

The Energy Web Chain stores the following information:

• Smart contracts for that are created through EW-DOS's identity and access management library.

• Smart contracts that govern validator consensus behavior and remuneration. These are known as .

• Smart contracts that implement other Ethereum network protocols, such as permissioning and protocols.

If you're not familiar with Smart Contracts, you can read Ethereum's introduction to smart contracts .

You can see a list of repositories containing EW-DOS smart contracts .

What is the Energy Web Token?

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

EWT on the Energy Web Chain

Like other public blockchains, the Energy Web Chain uses EWT as a utility token to access services and orchestrate stakeholders within its blockchain system. In the context of the Energy Web Chain, EWT compensate validators for processing transactions, and are used to pay for transactions - for example, registering a new asset or organization in .

Utility tokens like EWT are different from other digital assets in the blockchain sphere such as coins, non-fungible tokens, and stablecoins. To learn more about the distinctions between these assets, see this article, .

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 .

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

You can buy EWT on any of the exchanges listed . You can also bridge EWTB ERC20 tokens acquired on Ethereum mainnet back to EW Chain by .

Additional Resources:

• ****

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.

Enterprises are already integrating SmartFlow worker nodes into their solutions. .

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

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

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 consensus mechanism. 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 Proof-of-Work or Proof-of-Stake. 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.

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 🎉

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.

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

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

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.

🎬 Video Walkthrough

Flow 1: Delegating Stake

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

2. Select a collator you wish to delegate to from the available list.

3. Enter the amount of EWT you want to stake.

4. Review and sign the transaction with your connected wallet.

5. Once confirmed, your delegation will appear under your active staking positions.

Flow 2 – Increasing Stake

1. Select a collator you’ve already delegated to and wish to increase your stake with.

2. Enter the additional amount of EWT to increase your staking position.

3. Click Increase Stake, then confirm and sign the transaction using your wallet.

Flow 3 – Unstaking

1. Navigate to the Unstake tab.

2. Select the collator from which you want to unstake.

3. Confirm and sign the transaction in your wallet.

Sign up as an operator

Prerequisites

• account that is to Marketplace

• Some in the EWX account for transaction fee

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

1. You will see a success message along with the transaction URL to Polkadot explorer. Your operator account is now registered 🥳

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

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.

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

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)

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

Guides available for token management:

FAQs

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

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:

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.

3. Market Conditions: During high levels of generation leading to potential oversupply in the grid, generators might reduce output to maintain stability.

Market operators use these requests to manage the overall balance of the electricity supply and demand, ensuring system security and reliability.

The process starts when a retailer sends their ZEL request 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.

ZEL Request Partitioniong Solution

The ZEL Request Partitioning solution aims to test the above business case. Below are the steps which constitute its solution flow:

1. Fetch ZEL request from the request sender every 30 minutes

2. Parse the request 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.

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.

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:

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:

What are Worker Nodes?

To learn more about worker nodes, see .

Types of Worker Nodes

Prerequisites

• Connected EWX account

• Subscribed to a solution group

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