Clean Commodities

Building a registry for clean commodity certificates: Today many commodities from liquid fuels, to steel, to digital assets, are adopting technologies to reduce their carbon footprint. Commodities that are produced in a sustainable manner can be differentiated from conventionally produced alternatives if they can be digitally tracked throughout their lifecycles.

Currently, there are no established EAC registries specifically for commodities such as Sustainable Aviation Fuel (SAF), green hydrogen, green steel, sustainable shipping fuel, and other similar products. Green Proofs can be used to create a digital platform with the following functionalities:

· Digital onboarding of all parties, including issuance of appropriate roles and credentials

· Collection of generation / production data from multiple parties

· Verification of the sources of data by checking the DID of the data provider

· Onchain issuance, transfer and redemption of EACs

· UI reporting analytics

Example: Operating a Registry for Sustainable Aviation Fuel

Sustainable Aviation Fuel (SAF) is more sustainable compared to conventional jet fuel because it is produced with biofeedstocks and has significantly less carbon emissions when burned. For SAF producers, it is important to track the origin and attributes of the fuel to create new revenues by selling these attributes to environmentally conscious airlines and corporates. For airlines and consumers of air transport services, having a verifiable audit trail of SAF origin and attributes helps them implement credible decarbonization strategies. In the current SAF registry implementation, tracking attributes is separate from the physical fuel movement. 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 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 Producer 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.

  • Producers 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 producers, 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.

Last updated