In recent years, the Environmental Defense Fund, major oil companies and the Oil and Gas Climate Initiative, international organizations such as the United Nations Environmental Program and the World Bank, and institutional investors have made an effort to reduce methane leakage and flaring.  Nevertheless, this remains a difficult goal to achieve because of a lack of data and proper financial incentives. Many oil wells do not have equipment to record how they are handling methane, and many companies simply do not report . Even if they do this information is stuck in data silos, making it difficult to share and verify reported values. As a result, each year at least $50 billion worth of methane is flared rather than being sold as a commodity (natural gas) and extracting rents from investing in infrastructure to capture it.

Fortunately, there has been progress. EDF (2021) is urging investors to engage energy companies to improve flaring and venting transparency, requiring collaboration to establish clear metrics.  Several new data sources ranging from instrumentation at oil wells to independent satellite imagery is being made available. Converting this data into useful fuel value chain metrics requires integration with production data.  Flaring Monitor, an open source project, has made some progress. This provides a key element of the solution presented in this challenge to bridge reporting silos in order to reduce waste methane emissions. 

In this project, we will work on using blockchain technology to provide trusted data on methane and transfer that data to fuel consumers to incentivize methane reduction at the point of production. The first part of the project will integrate data from different sources to arrive at the best estimate of the methane emissions of a facility.  The second part of the project will use Value chain (scope 3) reporting standards to calculate the impact of methane emissions reduction on fuels delivered to customers.  It could then be used as part of the Supply Chain Decarbonization Project to incentivize the use of fuels with lower embedded emissions.

Through this we hope to help provide greater visibility to the oil producers, their investors, government agencies and NGO's involved in reducing methane flaring and leakage.  We also hope to create an additional lever, where fuel consumers can actively participate by purchasing emission reduction and methane performance certificates.

The Solution

We propose to use a blockchain oracle, such as Chainlink, to integrate the different sources of data from methane emissions.   Several independent sources, such as GGFRFlaring MonitorMethaneSatUNEP IMEO, flare-intel, could be combined with company reported figures to arrive at an answer.  A blockchain oracle assigns tokens for each source of data and weighs the data according to the tokens held by its source.  It could increase or decrease the tokens for each data source as the data is subsequently validated or refuted.

Using the derived methane tokens, an oil & gas facility (well) starts constructing an emission profile for its fuel production. The profile is digitally encoded as a non-fungible token (NFT) smart contract that tracks embedded methane emissions across fuel supply chain stakeholders. A carbon tracker NFT (C-NFT) has been implemented using the ERC-1155 standard as part of the Hyperledger Labs Net Emission Token (NET) network to issue, transfer, and retire carbon tokens by different accounts.

  • Voluntary Carbon Track Tokens (VCT) are issue by industry members to note the amount of emissions
    1. realized from flared/vented methane
    2. contained in oil, natural gas, and derived fuels sold to other facilities
  • Audited Emission Certificates (AEC) can be issued by independent sources to verify the realized emissions of a facility.
  • AEC are also assigned to energy consumers to communicate embedded methane emissions downstream.  Fuel consumed from high/low methane producers will carrier higher/lower embedded emissions.
  • Credits, in the form of methane performance certificates, are used to transfer the lower embedded methane emissions from one party to another, helping the receiver meet an emission reduction goal, while providing the supplier an incentive to reduce its methane emissions at the well.

In a simple example of an energy value chain, imagine an oil & gas producer that extracts fuel from a well. A power plant uses the gas to produce heat and electricity sent to a refinery to process the crude oil into fuel products, such as gasoline for cars, diesel for heavy transportation, and jet fuel for aircraft.  The C-NFT contract is used to construct a digital emission profile for accounts owned by each facility, i.e., oil and gas well,  power plant, refinery (Figure 2):

Figure 2 C-NFT illustration

Each step in the value chain (reporting "silos") consists of inputs and outputs and are transacted using the NET network in Carbon Dioxide equivalent (CO2e) of Greenhouse Gas emissions.  Based on the Value chain (scope 3) reporting standards

  • Inputs are retired NETs for direct (scope 1) emissions due to fuel burned or indirect emissions for purchased energy (scope 2) or other upstream emissions (scope 3).
  • Outputs are tokens transferred downstream to the users of the fuel, such as power plant, refinery, freight companies or airlines.
    • VCT are transferred as the CO2e of fuels sold to consumers (used in commercial trade).
    • AEC are indirect emissions, e.g., from selling electricity/heat

Emission profiles can explicitly reference a source C-NFT (arrows in Figure 2) to track embedded emissions, for example of the crude oil, or the heat and electricity supplied by the power plant, that went into the finished products. 

In practice, we envision a supplier sends emissions tokens (e.g. VCT)  to its customer from its facility's emission profile (C-NFT) with oracle-validated methane flaring.  This allows organizations to bridge the internal boundaries of traditional data silos and construct a complete view of the energy value chain.  An NFT is attached to each quantity of fuel it sells so that the consumer could correctly calculate the total emissions.

The consumer (e.g., Fuel user such as a freight carrier or airline) can identify the embedded waste methane emissions through public view functions of the NFT, such as carbon intensity (CI) metrics:

  • CI of oil & gas supplied (Fuel trade out) -> flared gas + leakage / fuel outputs
  • CI of Refined fuel trade -> other emissions (e.g., electricity/heat, flue gases) / refined fuel out 

A CI certificate is simply a transferrable claim of origin backed up by data. The NFT(s) provide a methane performance certificates for the output fuel tokens, helping producers with lower carbon intensity to obtain greater value for their products.  It is similar to a Renewable Energy Certificate (REC), but whereas a REC attests that electricity produced is from a renewable source, the CI certificate attests the total emissions of the fuel produced. The consumer can reduce their fuel CI by purchasing carbon tokens from a low methane emission supplier. Emission profile certificates tied to carbon tokens could be transferred between two users of fuel so that a user which is looking to reduce its emissions footprint could pay for a lower carbon fuel, without physically taking delivery of it. This would require simultaneously transferring, with the aid of a smart contract, fuel tokens between the certificate sender and receiver and subtracting the embedded emissions of the fuel inventory of the consumer and adding back it to the embedded emissions of the fuel inventory of the producer.  In future transactions, the producer would have to attach a higher CI to the fuel it sells as it sells certificates of lower embedded emissions.  This creates a mechanism where a producer of lower carbon fuels could monetize greater value for their output.

As an example:

  • Supplier has 1 million gallons of diesel with a carbon intensity of 9.88 kgCO2e per gallon (see EIA estimates.)
  • Customer has 100,000 gallons of diesel with a measured carbon intensity of 12.88 kgCO2e per gallon, from a high methane flaring producer. 
  • The customer wants to lower the carbon intensity of their fuel to 7.9 (20% below average), so they need to purchase -(12.88 - 7.9) * 100,000 = -498,000 kgCO2e carbon intensity from supplier through a certificate. 
  • After the transaction, the supplier still has 1,000,000 gallons of diesel, but they can no longer sell them with a carbon intensity of 9.88.  Having sold the customer -498,000 kgCO2e carbon intensity, they now have 9.88 * 1,000,000 + 78,987 = 10,378,000 million kgCO2e of carbon intensity.
  • So in future sales, the supplier must now claim carbon intensity 10.378 per gallon and pass them to its customers..

In contrast, an offset is an accounting of emissions reduction in return for an investment, such as equipment for capturing, storing, and transporting methane  This creates an incentive to make capital investments at high carbon intensity producers to reduce them.  To be valid, an offset must follow the general principles of carbon offsets, such as Additionality, Correct Baseline, Permanence, Real, and Leakage protection – In other words, the emissions reductions must not have occurred without the investment from the buyers of the offsets.  The offset would be a token which would transfer the emissions reductions to the buyers of the offsets, which again could be a fuel user. 

Investors could also purchase C-NFTs' with verified low methane emission profiles as part of their commitment to combat climate change and support the financing of additional infrastructure to reduce methane emissions.

Figure 3 Architecture for verifying waste emission. 

Figure 3 depicts an ongoing effort by the blockchain carbon accounting team to collect emission data points into a database (orbitDB) using IPFS or Fabric. These are connected to Ethereum contracts (NET/C-NFT) using a ChainLink oracle service or DAO.

The next step will involve building tools to pull in different data sources to support independent auditing and verification (MRV cycle):

Other Value chain scope 3 tools/services

According to the GHG Protocol Guidance on Upstream Transportation and Distribution, supplier provided carbon intensity is an acceptable metric for calculating GHG emissions and preferred over industry averages and model based figures.

To our knowledge there is no system focused designed to bridge the MRV systems used by organizations to directly identify value chain emissions.

The GHG Protocol provides a free tool to help measures cross-sector value-chain impacts. It provides inputs typically used in LCA practices, which may only provide historic/aggregate data from several years ago. It is more focused on providing measures for individual organizations as opposed to connecting reporting activities.    However, according to the Carbon Disclosure Project (CDP), value chain reporting has not been very successful in reducing emissions (Patchell 2018).

Value chain reporting often employs Life Cycle Assessment (LCA) practices, which can be difficult for organizations to implement on their:

  • Access the credible metrics restricted by data silos across emission measurement, reporting and verification (MRV) systems
  • Rely on historic data based that may be several years old
  • Employ of on model estimates that may be subjective and hard to validate

Standard LCA practices applied to fuel CI standards have no been very effective in mitigating emissions (Plevin et al 2017).

CarbonChain is a comparable solution to help organizations assess emission impacts across commodity supply chains. However, it operates as a centralized services, focusing on gathering data into a bigger silo, rather than connecting them.

Active Issues


Oil & Gas Methane Partnership 2.0


Methane Guiding Principles

Oil & Gas Climate Initiative Methane

Opportunities for Generating Carbon Credits from Oil & Gas Sector Projects

Report on Small-scale Technologies for Utilization of Associated Gas

Financing Solutions to Reduce Natural Gas Flaring and Methane Emissions

Responsibly Sourced Natural Gas - Project Canary article

Quantifying methane emissions from the largest oil producing basin in the U.S. from space - Science Advances

Tackling Energy Security and Climate Change with Open Source and Blockchain

Benchmarking Methane and Other GHG Emissions of Oil and Gas Production in the United States -

  • No labels


  1. Comments from pervious email thread

    >>> On Mon, Mar 14, 2022 at 3:14 PM Arezki Djelouadji <> wrote:

    I have noted in particular from our brainstorming session:

    • AUDITING If we have many inputs from many auditors:
      • They may have different GHG calculation methodologies (we could look at the top 5)
      • They all need to be able to input their data (maybe they are not using the same source)
      • We need to decide a rule (DAO vs. random vs. averaged vs. weighted average based on reputation or prior exp.)
    • DATA Which – ideally standardized - data should be inputted (open-source satellite data vs. public reports)?
      • Reports: We could see the common denominator of CO2e emissions data that we will always find in every public report of let’s say the top 20 CH4 emitters.
      • Satellite: We could compare how NASA (Flaring Monitor) and ESA data perform on a given region during a given period of time

    If you think, we should keep it more simple, I would not mind.

    Happy to continue discussing and see how we could structure the whole work. I have highlighted in blue what I consider as maybe priority.

    >>> On Mar 14, 2022, at 18:48, Si Chen <> wrote:

    I think for Auditing: a Random choice is enough for the transportation emissions.  For methane flaring which is more complex, we should have someone make a proposal of the final amount, link to the multiple sources available, and hold a DAO vote.

    For Data: For methane flaring, we would need is to integrate data so that they could be part of a DAO proposal.  This means they're really just documents or wiki pages, not data that automatically gets tokenized.

    1. In addition to our project repo there is the flaring monitor project
      and the code

      Arzeki, I will schedule a call with you before this weekend to discuss next steps and put together a project plan, both on collecting data and we can brainstorm on designing the DAO process.

      Si, regarding how the audited data is tokenized, I agree with the manual process. A next  step for our Hyperledger Challenge project (congrats it has now been selected for the next stage) is to integrate this data into the backend data architecture (i.e., Fabric, IPFS)  for auditing (e.g., as a DAO proposal).

      In the carbon traker NFT (C-NFT) contract the core tokens are for voluntary carbon reporting. These are less stringent than audited certificate, and an indusytr (e.g., oil&gas producer) could select a live data source (sat data, onsite sensors) to automatically issue tokens for a specific source.

      In the C-NFT contract multiple auditors can be selected or assigned to review the voluntary data in the emissino profile constructed by an industyr. Each auditor source broadcasts its methodology and data source (sensors, satellites, reports ... ). They can either confirm voluntary entries (verify the single data source used) or propose a revision to an entry using a pool of data (e.g., DAO propsal). The DAO closes with each auditor signing off on the revised entry.

      As C-NFT entries (multiple emission sources) are  audited, the entire emission profile gains a higher trust score and increasing its "Tradeability"..

      1. Bertrand WILLIAMSRIOUX I thought that the C-NFT would be the final, DAO voted embedded emissions which has all the data sources (voluntary company reported data, satellite, third party sources)  Once it is voted then it would be used, for example, by the Supply Chain Decarbonization to calculate the actual emissions of fuel purchases versus baseline factors.

        I don't see any benefit yet for putting voluntary carbon reporting data as a token, since they can't be traded around.

        What do you think?

        1. Si Chen I agree with you in principal - trade-able tokens associated with real world emission data need to be audited first. However, the C-NFT contract as designed will not work without a voluntary token. See below for details:

          1. Voluntary carbon tracker token transfers are essential components of how C-NFT are traded and tracked. 
          2. It is not necessary (and too complex) to require all token transfers to be audited.
          3. As you point out, the final trade-able C-NFT (emission profile) consisting of retired/transferred token balances only need to be issued after a review/revise/verify audit process.
          4. We can think of the voluntary tracker tokens as an 'invitation' to audit a claim.

          (1) The primary role of the voluntary carbon token is linking fuel sales to direct emissions as token transfers between accounts (e.g. facility of an oil producer, refiner, fuel station). This is not possible with audited emissions certificates (retired/non-transferable by default).

          (2) Auditing is not crucial for fuel transfers as the emission factor and token balances are explicit: this fuel will produce a known amount of emissions when combusted. It is important to issue/transfer voluntary carbon tokens as these are trade-able outputs of the final audited emission profile claim (C-NFT).

          (3) When voluntary tokens are declared as realized emissions (retired) as part of a C-NFT , an 'invitation' to audit is created. Voluntary claims are subject to a review/revise/verify cycle, including introducing additional tokens (audited emissions certificate, offset credits) and using a DAO to re-calculate and sign-off on the verified emission profile.

          In line with your comment, the final C-NFT written to a trade-able layer 2 network can be executed only after auditing is complete (optimizing the number of on-chain transactions). Offline signatures, or even a private side-chain, can be used to facilitate the review/revise/verify cycle without writing anything to the final network until the audit is signed-off and closed.

          1. Bertrand WILLIAMSRIOUX OK, I understand what you're saying and agree with most of it.

            No, certainly we cannot audit all token transfers.

            The C-NFT is in fact based on audited data, such as a company's methane emissions report or a third party data source.  Ideally if the data sources are different, we should have a DAO to vote on which one is the "Truth."  But for now, in the prototype phase, we can move forward with issuing it based on one source of data.

            Then the C-NFT should be an "invitation" to audit a claim, as part of the audited emissions of a shipper or airline. 

            So do you think this is the right process:

            1. Industry member (oil producer) issues a C-NFT token
            2. The C-NFT is transferred, eventually, to a fuel consumer, such as a shipping company or airline
            3. The emissions auditor of the shipping company or airline uses the C-NFT to adjust the audited emissions of the shipping company or airline.  This will be done as part of the Supply Chain Decarbonization
            1. Si Chen

              Yes this description makes sense, but a couple clarifying points.

              1. An industry member issues voluntary carbon tokens that it compiles into a C-NFT proposal/claim
              2. Voluntary carbon tokens are transferred to a fuel consumer from a C-NFT proposal. The C-NFT simply represents the net emission profile of a batch of fuel tokens.
              3. A C-NFT could be traded/transfered, but for other reasons. E.g., between trusted sources/DAO* that verify/revise the claim made by the C-NFT from trusted source (e.g., audited satellite data or corporate reports).

              *A DAO establishes uncertainty/risk tolerance when verifying the final audited emission profile "truth". 

              1. OK let's discuss further on Monday's call.  Actually I've been thinking about the right steps to issue audited emissions certificates so this would make for a good comparison of use cases.

  2. I would also add this comment in the intro which is quite interesting considering constraints in the EU: "The flaring of natural gas represents the loss of a non-renewable resource. The 150 billion cubic meters destroyed in 2019 correspond to 4% of global gas consumption, or one third of the consumption of the European Union."

  3. Bertrand WILLIAMSRIOUXDoes the CA-GREET for the California Low Carbon Fuel Standard incorporate methane emissions?  They have a CA-GREET 3.0 spreadsheet showing the calculations they use.

    1. I did a quick passover of the spreadsheet. In short yes it includes flaring/venting for some of the fuel processes.

      Specifically under the Inputs worksheet for scenario control variables 4 and 5.

  4. Si Chen Have you considered deploying the NET contract to the Energy Web proof of authority EVM?

    I looked into setting up my own PoA ethtereum network, however, it was simply to resource/time intensive. I think energy web is a good move forward to test the deployment of the claim → verity → credit cycle for the layer 2 NET/C-NFT contracts. It should be more resource/energy efficient, and based on trusted identities, aligned with the theme of tokenizing real world emission data.

    1. I looked at EWF a few years ago and again earlier this year.  I feel more comfortable with a public blockchain network, which would allow more people to use it, has more developers, and where we could integrate with stablecoins and other services.  

      I looked at the energy use issue again, and it seems the Binance Smart Chain has a low footprint versus the alternatives.  I wrote up the analysis here.

      1. Ok, I get the focus on anyone can access public network.

        Finance looks like a good approach if the focus is on public participation in the network consensus mechanism.

        However, Energy Web is also a public PoA network that allows access to anyone, only consensus is restricted to vetted nodes.

        This compromises the decentralization and therefore immutability of the network, depending on diversity and integrity of the "Authorities", but gain performance both on transaction throughput and energy use.

        I expect there will applications of NET and associated contracts that may favour consensus one more than the other, depending on how it is being used.

        Cross-chain interpretability across contracts deployed to different EVMs is worth considering... 

        Good news, looks like the Deploy Carbon Accounting Network with Bevel and Multiple Data Integration to Fabric Climate Accounting Network mentorship have been approved so far. Wondering how the the Former (Bevel) relates to the above...?

        1. The Bevel mentorship should help us deploy the Fabric network, which has been difficult in the past.  Let's talk about this more on Monday during the peer programming call.

          Meanwhile I think we should organize a comparison of all the different public blockchains - Binance Smart Chain, Telos, Hedera, EWF, etc. etc.

  5. Si Chen Arezki Dji

    I am collecting production data from EIA sources for both oil and gas (in addition to Saudi Aramco data I have already collected for 2018, 2019 and 2020). They provide regular monthly/annual state level data to strengthen our prototype.

    They also publish annual flaring and venting estimate by province as an alternate data source to flare intel. We can compare annual EIA data to Flare Intel state level data (manually selected) as a pathway to constructing NFTs.

    I am also compiling a global annual average flaring and venting NFT for total oil and gas production.

    Use cases for NFT:

    1. traded against an industry benchmark, as a difference. Companies can collect NFTs as badges supporting low emission projects, and retire them as commitment to emission reduction.
    2. to trade associated fuel (production) tokens for tracking embodied emissions in the supply chain (the original purpose of the C-NFT contract)
    1. I did some research about the GHG Protocol's carbon accounting standards, and they recommend using supplier-specific data over industry averages where available and trustworthy.  So if supplier specific fuel carbon intensity calculated from energy use and methane emissions during the production process were available, they could/should be used for calculating emissions of customers such as airlines and transportation companies.