Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The net emissions data channel is a data channel representing tokens network represents the net emissions of an entity, which could be an organization, a building, or even a person.  It is the sum of all the emissions from different channels such as the utility emissions channel, plus offsetting Renewable Energy Certificates and carbon offsets.  It could be on a public or permissioned ledger network.  The net emissions could be recorded as tokens or Fabric assets, such as the Carbon Emissions tokens developed by the Interwork Alliance.  The tokens/assets should be issued by the auditors who are members of the network, on behalf of their customers which could be utilities, businesses, or individuals. Note that the   Each token represents either an emissions debt, which you incur through activities that emit greenhouse gases, or an emissions credit, which offset the debt by removing emissions from the atmosphere.

The carbon emissions token is a fungible token, whereas data on the utility emissions channel are just immutable data (not tokens), as they represent the emissions from a particular meter tied to a particular utility during a particular period of time.  Following examples from capital markets, we can link this kind of data to the fungible tokens by:

  1. The underlying data, such as the utility emissions records, should be updated to link to the particular fungible token. 
  2. The fungible token should contain a manifest of all the underlying data which went into it. 

We propose to implement a carbon emissions token based on the eThaler project from the CMSIG.  eThaler is a Central Bank Digital Currency (CBDC) implemented on a private Ethereum network running Hyperledger Besu.  It supports a central bank which creates and mints tokens and transfers them to member banks, who would then distribute them to retail customers of the banks.  In the case of carbon emissions, it could support a registry authority, which could be a network operator or supranational/national/regional carbon authority, which authorizes a number of issuers of tokens.  The issuers could be auditors of carbon emissions or project developers of renewable energy or carbon offsets, who issue tokens based on audits of companies' or projects' operations.  eThaler's features can be mapped to emissions tokens like this:

  • Add new token definition – Multiple types of emissions tokens can be supported on the network, such as emissions, Renewable Energy Certificates (REC's), and offsets.
  • Mint – Authorizes a supply of tokens to be issued in the future, based on results of operations from audited companies and renewable/offsets projects.
  • Register/Unregister dealer – In our case, it would be registering and unregistering auditors or project developers authorized to issue tokens.
  • Transfer – In eThaler, the central bank transfers tokens to dealer banks.  In our case, we would allow an auditor or project developer to create a token based on audited results and then transfer it to a party, which could be a business or individual.  After that, the token would be flagged as "used" and cannot be transferred again. 
  • Burn – this would not be implemented.

The Carbon Emissions token taxonomy developed by the Interwork Alliance is similar to eThaler's token taxonomy.  The differences are:

  1. Currency could be repeatedly transferred between parties, where as emissions records, offsets, and REC's should not be.
  2. Currency could be removed from circulation or "burned", but emissions records could not be, because the physical greenhouse gases stay in the atmosphere (hundreds of years at least.)

The only operation for a net emissions token/asset is Issue with the following fields:

  • issuer identifier
  • recipient identifier
  • asset token type
  • quantity 
  • UOM
  • from date/time stamp
  • thru date/time stamp
  • metadata
  • manifest
  • date/time stamp of when the asset was created

Once issued from one entity to another, the token/asset stays with the recipient.  The recipient can in turn issue tokens/assets to further recipients, such as down the supply chain, by referencing its original tokens/assets in the manifest of the new token/asset issued. 

Examples of these tokens/assets include:

  • Renewable Energy Certificate:
    • Issuer ID = Generator of REC
    • Recipient ID = Buyer of REC
    • Asset Type = REC
    • Quantity = 1
    • UOM = MWH
    • From/thru date time stamp = do we need this for REC's?
    • Metadata = Region and Time of energy enerated
    • Manifest = URL linking to the registration for the REC purchased
  • Carbon emissions offest:
    • Issuer ID = Certifier or Issuer
    • Recipient ID = Buyer
    • Asset Type = Emissions Offset
    • Quantity = amount
    • UOM = MtCO2e
    • From/thru date time stamp = do we need this for emissions offset?
    • Metadata = type of project, location, etc.
    • Manifest = URL linking to the registration of the emissions offset
  • Utility Emissions Data:
    • Issuer ID = utility or auditor 
    • Recipient ID = organization or entity
    • Asset Type = CO2 emissions
    • Quantity = amount of emissions
    • UOM = MtCO2e
    • From/thru date time stamp = time period of the net emissions
    • Meatadata = background data such as utility, billing period, amount and UOM of usage, etc.
    • Manifest = link to access the utility emissions data on the utility emissions channel 
  • Net Emissions Data:
    • Issuer ID = auditor
    • Recipient ID = organization or entity
    • Asset Type = CO2 emissions
    • Quantity = amount of emissions
    • UOM = MtCO2e
    • Metadata =
    • From/thru date time stamp = time period of the net emissions
    • Manifest = links to access all the emissions tokens/assets used to prepare this net emissions

Each token/asset represents either an emissions debt, which you incur through activities that emit greenhouse gases, or an emissions credit, which offset the debt by removing emissions from the atmosphere.

With these tokens/assetsOnce issued from one entity to another, the token stays with the recipient.  

An auditor could issue tokens to the customer of a recipient by referencing the recipient's token in a newly issued token, thus passing emissions down the supply chain.  

With these tokens, we can calculate the net emissions by first subtracting the effect of Renewable Energy Certificates (REC's.)  REC's offset the energy produced by non-renewable sources, so we'll need to get the non-renewable vs renewable energy mix in the original emissions tokens/assets from utility emissions data channel.  Then we subtract the offsets to get the net emissions.

The tokens/assets stay on the ledger forever, or at least as long as greenhouse gases stay in the atmosphere (hundreds of years at least.)

One interesting question is How to avoid double counting: My emissions are mine.  I cannot transfer them to someone else.  But if you hire me to do some work for you, a portion of my emissions should also be part of your responsbility.  Does that mean my emissions should be reduced and yours increased?  Not if you only contact my total emissions, but yes if you count the total emissions from both of us.  So rather than a simple transfer between two parties, inter-party emissions should be cancelled when they are summed up in calculations that involve both parties.

...