🚀
Energy Web X Ecosystem
  • Documentation Overview
  • Core Concepts
    • Energy Web Chain
    • Energy Web X
    • Energy Web Tokens
      • Token Lifting
      • Token Lowering
    • Worker Nodes and Worker Node Networks
      • Server-based Worker Node
      • Marketplace App (desktop-based)
    • Worker Node Operator
    • Smart Flows and Groups
    • Subscription
    • Reward Period
    • Voting and Consensus
    • Ethereum
      • Transactions and Transaction Costs
    • Decentralized Identifiers (DIDs)
  • EWC ECOSYSTEM
    • Energy Web Chain
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contract
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Energy Web Chain Governance & Validators
    • Energy Web Tokens
  • EWX ECOSYSTEM
    • Energy Web X
    • EWX: Architecture
    • Pallets
      • Worker Node Pallet
      • Balances Pallet
      • Proxy Pallet
      • XCM Pallet
      • Assets Pallet
      • Multisig Pallet
      • Scheduler Pallet
      • Preimages Pallet
      • Offences Pallet
      • Eth-Bridge Pallet
      • Token-Manager Pallet
      • Ethereum-events pallet
      • Avn Pallet
    • Worker Nodes
      • 🖥️The Marketplace App
        • Operator and Worker Accounts
          • Creating an operator account
          • Funding an operator account
          • Connecting to operator account
          • Disconnecting an operator account
          • Creating a worker account
          • Importing worker account
          • Exporting worker account
          • Linking a worker account to an operator account
          • Unlinking a worker account from an operator account
        • How to use Ledger on Marketplace App
        • Token Management
          • Creating an EWC account
          • Managing EWC accounts
          • Lifting tokens
          • Lowering tokens
          • Tracking lifting and lowering transactions
          • Checking EWT balance
        • Subscriptions
          • Subscribing to a solution group
          • Topping-up subscription amount
          • Managing subscriptions
          • Unsubscribing from a solution group
          • Unsubscribing delay
        • Worker Node and Rewards
          • Configuring remote worker node
          • Switching worker node location to remote
          • Participating into worker node network
          • Votes casted per Period
          • Reward Period
          • Checking rewards
          • Claiming rewards
        • FAQ: Marketplace App
        • Location Services
      • 🗄️Server-based Worker Nodes
        • Deployment Guide
        • Bootstrapping Server-based Worker Node Accounts
        • FAQ: Server-based Worker Nodes
      • Worker Node use cases
        • Sample Enterprise Use-Cases
          • Operating Envelopes Partitioning
          • ZEL Request Partitioning
          • Green Proofs
            • SAFc
            • Green Proofs for Bitcoin (GP4BTC)
            • Green Proofs as a Service (GPSaaS)
            • Green Proofs for Electrical Vehicles (GP4EV)
  • ENERGY SOLUTIONS
    • Green Proofs by Energy Web
      • Green Proofs Overview
      • Green Proofs Architecure
      • Green Proofs Software Stack
      • Use Cases and Reference Implementations
        • 24x7 Renewable Electricity
        • Sustainable Aviation Fuel
        • Green Proofs for Bitcoin
          • GP4BTC Miner Guide
        • Decarbonizing Shipping
        • Green Proofs for Electrical Vehicles
        • Green Proofs as a Service (GPSaaS)
    • Digital Spine by Energy Web
      • Design and Architecture
      • Component Guides
        • Energy Web Name Service (ENS)
        • Self-Sovereign Identities
          • SSI-Hub
          • Technical Guide
            • Organizations
            • Applications
            • Roles and IAM
          • Deployment Guide
            • Deploy Identity Cache Server
            • Deploy Switchboard
        • DDHub Message Broker
          • Technical Guide
            • Authentication and Authorization
            • Topics
            • Messaging
          • Deployment Guide
            • Deploy DID Auth Proxy
            • Deploy Message Broker
        • DDHub Client Gateway
          • Technical Guide
            • Authentication and Authorization
              • Key Vault
            • Client Gateway Identity and VCs
            • Address Book
            • Topics
            • Channels
            • Integration Options
            • Messaging
          • Deployment Guide
            • Launchpad SaaS
            • Azure Marketplace
            • Self-Hosted
              • Deploy with Kubernetes
              • Deploy with Docker
            • Key Vault
              • Deploy with HashiCorp Key Vault
              • Deploy with Azure Key Vault
              • Deploy with AWS Secrets Manager
            • Rebranding and Whitelabelling
Powered by GitBook
On this page
  • Background
  • Worker Nodes
  1. ENERGY SOLUTIONS
  2. Green Proofs by Energy Web
  3. Use Cases and Reference Implementations

Sustainable Aviation Fuel

Previous24x7 Renewable ElectricityNextGreen Proofs for Bitcoin

Last updated 5 months ago

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 key feature of SAFc is its decentralized worker verification mechanism. When a SAF certificate is issued, it is shared with a network of workers who validate the issuance process. These workers independently verify the legitimacy of the certificate by checking whether it complies with predefined rules, such as accurate SAF production data and alignment with regulatory requirements. Workers rely on cryptographic proofs and pseudonymized data to perform their validations securely. Through a consensus process, the workers collectively decide whether the SAF certificate is valid. This ensures that only authentic certificates are issued, preventing fraud and maintaining trust in the SAFc ecosystem.

Background

Sustainable aviation fuel (SAF) is jet fuel produced from renewable feedstocks that emits significantly less carbon than petroleum-based jet fuel. For SAF producers, it is important to track the origin and attributes of the SAF to create new revenues by selling these attributes to environmentally conscious airlines and corporations. For airlines and consumers of air transport services, having a verifiable audit trail of SAF origin and attributes helps them implement credible decarbonization strategies.

  • Organizations and individuals can easily join the platform and create accounts with specific abilities based on the type of company they represent

  • "Fuel Providers" are special organizations - that produce SAF and hold 3rd party certifications - that can provide generation / production data to the platform for to issue SAF certificates (SAFc)

  • All data fields represented on the platform stem from 3rd-party verified information and certifications, and SAFc may only be issued by accounts holding the proper credentials

  • The Registry's web-interface is very user-friendly and familiar to corporate users; power users may interact with the platform via API

  • Worker nodes on Energy Web X provide transparency into the inner-workings of certificate issuances, transfers, and redemptions. This allows registry users, stakeholders, and the public to trust that the registry is operating with integrity.

Worker Nodes

The role of workers in a SAF registry is to govern the lifecycle of SAF certificates, which are linked to each tonne of SAF produced.

Certificate Issuance:

  • The volume of SAF certificates must precisely match the actual volume of SAF produced in the real world. Accordingly, to issue certificates a Fuel Provider must first prove that they are an accredited producer and then prove that it really produced some volume of SAF. Workers need to verify both elements, and then introduce the correct number of certificates to the system.

  • First, workers establish a registry of accredited producers using pseudonymous identifiers. In this architecture, each worker only “knows” the list of approved IDs, not the real-world information about the company.

  • Fuel Providers submit requests to issue a volume of SAF certificates using a “Proof of Sustainability” document, which contains all of the important data about the SAF (e.g., number of tonnes or 'units' of SAF, origin, LCA GHG value...). Workers first check if the requestor’s ID matches an active ID in the accredited registry. Then, workers query the POS document and share the production volume via precise proof to check if the request to issue certificates matches the volume in the POS document.

  • Workers vote to determine if the requestor is valid and the volume is correct; if consensus is reached, the approval triggers a workflow to issue certificate(s). When issuing a certificate the merkle tree root hash of the worker node voting round becomes part of that certificate hash so the consensus of the worker voting is inherently tied to the issuance of the certificate.

Selling & Transfer of Certificates:

  • Once certificates are issued to Fuel Providers, they want to sell them to buyers like airlines. To transfer a certificate to a buyer, a producer sends a request to the worker pool with the volume to be transferred and the recipient (buyer) ID.

  • Workers first check to verify that the volume requested in the transfer is equal to or less than the balance held by the producer. For example Producer A has 100 units and wants to sell 50 to Buyer B; workers check that the transfer request is 100 or less and submit votes on the result to approve (or deny) the transfer.

  • Once the transfer is executed, the workers then vote to update the balance of the producer and buyer. Using pseudonymous IDs, workers can prove that the sum balance of transfers is correct without revealing parties involved (just like one can create many addresses from a public key, you create a bunch of random IDs for participants that link back to a core identifier).

  • Each issued SAFc has a unique identifier, like an NFT; so the transfers always link back to original issuance. Transfers aren't reflected on-chain though the results of worker votes are.

Certificate Retirement:

  • Eventually, a buyer wants to publicly claim the use of a SAFc and take credit for its avoided emissions. Buyers can claim either whole or fractional portions of SAFc units. Upon executing a process to claim a certificate, workers reference the unique identifier of the certificate and remove it out of the pool of transfers of “active” certificates. Through this process the certificate remains visible but it’s “frozen” and linked to a specific ID and consumption event.

  • Similar to the selling and transfer process, the role of workers in retirement is to validate that the volume requested is equal to or less than the current balance of the requestor, and then establish consensus on precisely which certificate(s) are being retired.

There are two primary benefits of using worker nodes for SAFc:

  • Providing full transparency on the total volume of SAFc in the system (keeping track of volumes that are issued, “active”, and retired) without revealing the real-world identities of the entities holding them, or their individual balances.

  • By linking the voting events to the issuance, transfer, and retirement of each certificate (which itself has a unique identifier) the system provides real-time, continuous auditing of a cohesive balance sheet with double-entry accounting.

The was the first production Green Proofs registry launched in Q4'2023 as a collaboration between , , , and to decarbonize the aviation industry.

The follows the "" chain of custody model, once the SAF is "booked" in the registry, its environmental attributes are may move separately from the physical fuel. The registry tracks key information about the underlying SAF production, including who produced the fuel, what sustainability certifications they hold, the fuel's feedstock (e.g., waste cooking oil), how much SAF was produced (measured in tonnes), its estimated carbon savings per unit of fuel, when the SAF was blended with conventional aviation fuel, etc.

The offers the following to its users:

SAFc Registry
Energy Web
SABA
RMI
EDF
SAFc Registry
book-and-claim
SAFc Registry