Page tree
Skip to end of metadata
Go to start of metadata

This is a proposal.  Please leave your feedback as comments.


This project will develop an emissions ledger which could be used by multiple parties in a supply chain to record emissions data.  It could then calculate the net emissions for a product which is transported through the supply chain. The goals are:

  • Quantify the amount of greenhouse gas (GHG) emissions per unit of product delivered at the destination of the supply chain, for example per kg of fruit or unit of equipment received.  This include both the embedded emissions of the product itself, the emissions of the supply chain, and loss of product in the supply chain.   
  • Quantify the effects of leakage or spoilage or other loss in the supply chain on net emissions and compare that against the emissions of the supply chain itself.
  • Compare different supply chain options to see their emissions impact.  For example,
    • Is it better to ship produce by air or sea freight?
    • Is it better to refrigerate it during shipping to reduce the spoilage?
    • Is it better to compress CO2 captured during carbon capture and storage (CCS) during pipeline transport?
  • Make it possible to compare different products at the destination through different supply chains.  For example,
    • Is it better to transport the recycled plastics to a facility that could make new bottles from them, or use them at a local recycling facility that turns them into lower value products.  While the calculator does not include emissions from downstream usage, it could be used to calculate the emissions of different products through different supply chains at the destination to determine which option is better.

The calculator could be run as simulation for analysis and baselines or used to record actual activities to calculate real emissions.  It will integrate the upstream emissions of the products with the emissions of the supply chain, such as transportation, storage, and processing, to enable a true comparison.  The end result is the emission of the product plus its transportation and logistics divided by units of products delivered at destination.

Use Cases

The destination emissions of the products could be used for regulatory compliance, such as the EU carbon border tax, and for meeting customers' climate objectives.  They could also be used to help investors assess the risk of different products.  Finally, by comparing the actual results versus simulations of business-as-usual alternatives, these calculations could be used to prove emissions reduction, certify products as low carbon, and create carbon offsets.

Longer term, this calculator plus the Emissions Tokens Network Project could be used to solve the hard problems of reducing emissions in the supply chain:

  • Cost of carbon footprinting - We're free. (smile)
  • Creating incentives for suppliers - Customers, either big ones or a group of small ones, could set up their own "cap and trade" scheme: Declare their supply chain emissions targets which decline over time, aligning with the Paris Agreement (-50% by 2030, zero by 2050.)  Allocate tokens to suppliers based on those targets.  Suppliers can trade their emissions with each other but over time must reduce them as a whole.
  • Providing turnkey solutions - Again using tokens, major customers could either invest in emissions projects directly and provide them to their customers (like Apple and "Enabling carbon neutrality across the value chain" in this article) or provide financing or guarantees for financing for suppliers.

  • Verification - Could be done through this ledger.
  • Going deep - Suppliers could get their suppliers on the ledger, and tokens could be transferred further up the supply chain.

Sample Supply Chains

Fruit and Produce: Fruit and produce is harvested at a farm, transported by truck, processed at a distributor facility, shipped by freight (air, truck, or rail) with refrigeration, and delivered to a grocery store or supermarket.  Optionally we can consider storage at the grocery store or supermarket as an additional step in the supply chain to the final consumer.

Recycled Plastis: Recycled plastics is collected at residential homes, public places, beaches, etc.  It is could then be transported and delivered to different types of facilities, which could then enhance it into different materials.

Carbon Capture and Storage (CCS): GHG emissions are captured at the point of burning natural gas, for example at a power plant, and transported via pipeline to underground storage.  What's interesting here is that the product transported has very high GHG emissions content relative to the transport process itself.


Hyperleger Fabric with multiple members from the supply chain.  REST API for access from members.  Cactus for integration with outside ledgers (ie trade finance or supply chain ledgers.)

Ethereum tokens are used to store the embedded emissions at origin and destination of the supply chain.  This opens up the supply chain to all parties who tokenize their emissions.

Hyperledger Avalon is used to perform the emissions calculations and store them back on Fabric.  Fabric is used to record the steps of the supply chain and their emissions impact, but not to calculate the emissions.  This allows calculations to be performed by a variety of parties and models. 

The steps of the supply chain is simplified for emissions accounting purposes, so that it is a series of steps each recording:

  • Supply chain ID - a unique identifier which identifies a particular product item, which could in reality be a single physical item or a lot or batch, through the supply chain.  This could be used by a supply chain system to find the actual item.
  • Step ID - automated unique identifier for each step.  A supply chain will have many steps each with the same supply chain ID and a unique step ID.

  • Quantity of item at origin
  • Type of activity - what happened at this step of the supply chain.  Was something shipped?  By air, sea, rail, or truck?  Was a product compressed, flash frozen, stored in a warehouse?
  • Activity party - Information about who performed the activity, which would be used to find the right emissions factors.
  • Amount of activity - how far was the item shipped?  How long was it stored?
  • Previous and next node - link to the previous and next steps for this item by their step ID.  Use ORIGIN for previous step if the current step is the origin of the supply chain and FINAL for next step if the current step is the final or destination of the supply chain.
  • Emissions - calculated emissions of this step based on the type of activity, activity party, and amount of activity.  This will require standard emissions factors similar to the ones used in the Utility Emissions Channel Project, but for all the different types of steps in the supply chain.  One source could be GHG Protocol's new calculator.

In addition we will need for the supply chain itself: 

  • Per unit embedded emissions of the item at origin - This is the embedded emissions of the item at the origin of the supply chain.  It is added to the emissions of the supply chain itself to get the final emissions at destination.  This could be an audited emission specific to the item or, if not available, generic emission for this type of item.
  • Meta information about the supply chain

Services available from the implementation will be able to

  • Calculate net emissions for a supply chain by adding up all the steps' emissions, plus the emissions of the item at origin.
  • Tokenize the net emissions per unit of item
  • Issue tokens back to each segment based their relative contribution

Data sources could come from:

  • No labels


  1. I like the idea of this project and have considered similar ideas in the past.

    The reason I have not moved forward is that it requries a massive amount of data collection, calculation, and speculation.

    For example, if a product is delivered by a gasoline powered van, an natural gas powered van, a hyrdrogen powered van, or an electric van, how will you assess the GLG impacts of each?  While you can estimate the emissions from the van itself without too much difficulty, what about the emission in 

    1. drilling, refining, and transporting the gasoline
    2. drilling, refining, and transporting the natural gas
    3. creating and distributing the hydrogen
    4. generating and transmitting the electricity (which, itself might be generated using a variety of feedstocks including coal, natural gas, sunlight, wind, nuclear, etc.).

    The project quickly becomes a nightmarish input-output analysis in which it is necessary to speculate on the input parameters or else create a weighted model that considers all possible process flows.  It is doable, but daunting.

    1. It's a big project for sure.  There will be a lot of data gathering, which is what a blockchain connecting different parties on a supply chain would do.

      For your particular list of questions, however, there are in fact data already available.  Electricity emissions is published by the EPA, European EPA, and other national electricity authorities like India's.  We use them for the Utility Emissions Channel Project.

      For oil and natural gas, I think there is a "fuel carbon intensity index."  I'm not too familiar with it but there is an Oil & Gas Climate Initiative, and we should ask them.

      For hydrogen it is a new thing...full of opportunities for us! (smile)

  2. Hi, have been thinking along the same lines and agree with Jeff that the data gathering will be a nightmare. Was therefore exploring a different avenue, sketchy at the moment, that I will share with you. 

    What if we used invoices instead? 

    Say I operate a small manufacturing company -ACME. The input is electricity and raw materials the output are the products ACME sells. Say that the power company that supplies ACME power  when issuing the power bill had to include also the amount of CO2 emitted for the production of this power, as an "info" item. How? In Europe for example power companies are part of the ETS and have to calculate in a verifiable way the emissions they produce. So an average CO2/KWh sold can be established. If this info (the CO2 part) of the invoice could be captured in a blockchain it would be known that ACME has indirectly used than much of CO2 for their production.  Lets suppose that ACME does not procure any other raw material where  CO2 is involved -(impossible proposition but for the sake of example). Through accounting rules that have to be established,  ACME should include in each of their sale invoices a certain amount of CO2 so that the total amount of CO2 in their sales invoices equals to the total amount the are  "debited" by the power company. So the next entity in the value chain would be debited the CO2 amount for whatever they purchased through ACME and they would have to do the same, sort of the VAT chain.  If ACME was selling stuff to the final consumer then the consumer  could see on the receipt issued how much CO2 the product is debited with. 

    To expand the example, if ACME was also using a transportation company to move its goods around, they would be debited CO2 from the transportation company as part of he invoice thr truck co issues to ACME. How much? As much as the truck co was debited from the gas station when they filled the trucks tank with diesel (2.68kg CO₂/litre). 

    Why do I choose invoices? In Greece for example all invoices issued have to bear a unique digital stamp so this allows for data capturing directly into a blockchain -capture the stamp, the seller, the buyer and the CO2 in the invoice. The general public could view the blockchain and see how "dirty" ACME is, the authorities can set rules to verify that balances are correct -for example apart from the unique digital stamp the invoice could be made to bear the hash code of the blockchain when the data was submitted into the chain. 

    So suppose  ACME was  Volkswagen (just as an example). VW purchases power and various raw materials and spare parts. They all debit VW with CO2 emissions. Eventually VW would have to pass on the CO2  (through the accounting rules) to the cars they sell. So as a consumer other things being equal between say a VW and BMW model I could choose the one debited with less emissions. VW would be incentivized to purchase green power and their suppliers would be incentivized likewise, as other things being equal VW would purchase form the supplier with the less emissions. 

    So the main idea is to use something similar to the VAT chain to capture CO2, through the invoices that -in general, allow for: 1. digitization, 2. audit.

    Happy to entertain any thoughts you might have. 


    1. I think this comes down to a governance mechanism question.

      The same calculations would need to be made of emissions based on activities, based on probably the same emissions factors.  So which of these 2 options is better?

      • Data stays in each company.  Each company makes its own calculations, which only it sees.  The company would report it on its invoices.  Its customer would have to figure out how to integrate invoice data from many different suppliers.  An audit would involve going into all these different companies' systems.  It would probably require a government entity to do these audits.  Every jurisdiction would most likely end up having separate reporting rules and audit procedures.
      • A common distributed ledger where each company reports its activities.  Emissions calculations are made on ledger based on models and factors that everybody sees.  The resulting emissions are stored on ledger, for all to see.  To use them, you need one API to access all your partners' emissions records.  Audits could be done by regulators or customers.