✈️Sustainable Aviation Fuel

Background

The SAFc Registry was the first production Green Proofs registry launched in Q4'2023 as a collaboration between Energy Web, SABA, RMI, and EDF to decarbonize the aviation industry.

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.

The SAFc Registry follows the "book-and-claim" 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 SAFc Registry offers the following to its users:

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