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

This is the emissions token network from the Operating System for Climate Action.

A Demo

You can try it yourself at http://emissionstokens-goerli.opentaps.org/ You will need to a Goerli testnet wallet and some test eth (which you can get here.)  Then please email Climate SIG mailing list with your Goerli account address to be added to it.

How it Works

The emissions tokens network uses tokens to represent the 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.  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 Capital Markets SIG.  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, the eThaler smart contracts could support the following participants on a tokens network:

  • Token authority –  a network operator or a supranational/national/regional carbon authority (see below) which authorizes a number of issuers of tokens. 
  • Token issuers –  auditors of carbon emissions or certifiers of renewable energy or carbon offsets.  Auditors would issue tokens based on audits of companies' operations.   Certifiers would issue tokens based on projects they've certified.
  • Token consumers – businesses and individuals who buy REC's or offsets to offset their own emissions.

Token Types

  • Audited emissions - represents the actual emissions of an organization, as reported by an auditor.  
  • Carbon offsets - represents reduction of emissions through projects such as forestry, sequestration, etc.  
  • Renewable Energy Certificates (REC's) - represents energy generated from renewable sources such as wind and solar

 All 3 types of tokens are fungible.  The audited emissions tokens are "retired" (see below) as soon as they're issued from an auditor to a company or consumer.  The offsets and REC's could be traded but are eventually retired when used to count as emissions offsets.

Token Operations

  • 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.
  • Register/Unregister issuer – In our case, it would be registering and unregistering auditors or project certifiers authorized to issue tokens.
  • Register/Unregister consumer – Auditors and project certifiers would register their customers on the network.
  • Issue – Issues tokens based on results of operations from audited companies and renewable/offsets projects.  Note that each issuer would be able to only issue allowed types of tokens, so an emissions auditor can issue Audited Emissions, a carbon offset developer or certifier Carbon offset tokens, and renewables developer REC's. 
  • Transfer – Emissions audit tokens cannot be transferred: They are retired as soon as issued and stay with the organization that was audited as a record of their emissions.  Offsets and REC's can be transferred until they are retired.  The total amount that could be transferred from one account to another is the sum of the tokens in their account minus the amount that has been retired.
  • Retire - this is not in eThaler but would need to be implemented.  When a token is marked as "retired," it is counted towards the emissions reduction of the retiring organization 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 emissions tokens would have the following fields:

  • issuer identifier
  • recipient identifier
  • token type
  • quantity 
  • UOM
  • from date/time stamp
  • thru date/time stamp
  • metadata
  • manifest
  • date/time stamp of when the asset was created
  • automatic retirement date, when the token will be retired in the account of whoever holds it.  Usually the end of a calendar year.

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
  • Audited Emissions:
    • 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

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.

Integration with Hyperledger Fabric

This network would be connected with Fabric channels such as the utility emissions channel through the auditors.  The utility emissions channel is operated by an auditor on behalf of its customers.  The auditor would also be on this network and would issue audited emissions tokens to its customers' wallets.  The customers would then transact in emissions and offsets on this network using their wallets. 

Possible Use Cases

Cap and Trade:

  • The central bank could be the cap and trade authority.
  • Tokens for allowable emissions could be issued to all members of the cap and trade regime.
  • They can trade the tokens amongst themselves.
  • As emissions are counted, during an audit, cap and trade tokens should be retired.

Green Bank:

  • The central bank is a green bank, which raises funds for climate projects.
  • For approved projects, the bank would issue emissions tokens to project developers based on the projected emissions reductions of the projects.
  • When emissions reductions are verified, they are exchanged for tokens.
  • The tokens can then be redeemed for money.

Network Operator Model:

  • The network operator is a neutral, blockchain technology vendor who runs the network for a (very very very small) fee. 
  • It could mint and issue tokens in response to requests from network members, who pay a fee for the tokens to be issued.

Outstanding Issues

Transfer of emissions down the supply chain and avoiding double counting are major issues to be addressed in the future.  The problem is that emissions are counted in multiple ledgers, for example this document from Gold Standard describes how they could be counted in both offsets and national registries.  See also the Gold Standard double counting guidelines document.

Get Involved


Get Involved

This is an open source project and anyone is welcome to get involved and we will be happy to see you contribute.

1) Start by subscribing to the Climate SIG mailing list for updates and meeting notifications.

2) Join our bi-monthly Peer Programming Zoom call for developers on Mondays at 9 AM US Pacific time (UTC-07:00 America/Los Angeles.) Please check the calendar for the next call

3) Check out the good first issues from our blockchain-carbon-accounting in Hyperledger-labs and feel free to contribute a fix for one that looks interesting to you.

4) See our How to Contribute page for other ways how you could get involved. 


  • No labels

13 Comments

  1. Hi Si Chen, thanks for sharing your idea of the Net Emissions Data Channel. I like the idea of having all net emissions accounted for each individual person/organization/company etc.
    In the following, I post some questions which came to my mind:

    1. net emission = total emission - offsets?
    2. how would you gather/transfer all the data for/to this channel?
    3. When I think of tokens, I think of something positive like owning 1 Bitcoin. Having many emission tokens would be something like a climate debt, right? 
    4. Who would issue the token in the first place?
    5. Will the token stay forever or will the be deleted, e.g., once a year?
    1. Thanks for your comments:

      1. Net emissions = total emissions - renewable energy certificates - offsets.  The renewable energy certificates would offset the amount of non-renewable energy used, so we'd go back to the utility data and get the renewable vs non-renewable portions.  Other than that it is just straightforward subtracting offsets from total emissions.
      2. Moving data to/from this channel would require an Issue function.  Data is placed on the channel when you Issue a token/asset.  It is then moved off the channel by Issuing another token/asset.
      3. Yes, the token/asset is like owning something, except you don't buy it like bitcoin.  You get it issued to you based on your activity.  Emissions tokens would be a climate debt (I like that term!)  Emissions offset would be a negative to the debt.
      4. The tokens/assets would be issued by auditors, ie recognized members of the network.  So in that way it may be better to have a permissioned network?
      5. They stay for as long as the emissions stay in the atmosphere (300 to 1000 years according to NASA), so I think for our purposes "forever".  Some companies, such as Microsoft, have pledged to offset their emissions during their entire history, so they would need it going back in time.

      I'll put these answers in the main wiki page as well.

  2. Great concept Si Chen,
    I like the idea of preventing emissions tokens from being transferred once issued to the emitter,
    and issuing another token to represent the “footprint” which can be passed down supply chains.
    You mention an auditor issuing these “footprint” tokens to customers of emission token recipients. 
    It seems this would be easy upstream where transactions are high value and easily human audit-able,
    but it would be challenging downstream, say in a B2C or C2C markets.
    Why not allow these “footprint” tokens to be transferred freely without an auditor, to allow them to be passed down supply chains together with the goods and services they are linked to? Although this movement could allow them to be hidden, they remain linked to the emissions tokens from which they came, which cannot be moved.
    And if the goods and services are tokenized then the offset tokens can be packaged with those, making them hard to hide and allowing them to automatically travel around with transfer of goods and services.

    Considering carbon markets are useful for offsetting, and allowed for in the Paris agreement, why not allow issued offset tokens to be traded freely before being “retired”?
    Or could the minted tokens be traded before they are issued?

    Here is a sample scenario:
    Offset token O is minted and tradable in offset markets, it is “active”.

    Emission token E is minted and issued to recipient / emitter, it cannot be moved, it is “retired”.
    However, another “footprint” token F is issued to recipient along with E, this one is “active” indicating it has not been offset.
    F travels down supply chain together with the goods and services which the emissions are attributed to.

    Emission footprint is eventually offset by retiring F tokens with a proportional amount of offsets O tokens, which “retires” both F and O

    “offsetting” F with O issues a new token FO which represents offset emissions.
    FO is further passed down supply chain to prove carbon neutrality.

    1. Thanks for your feedback Darren Zal.  You make some good points here.  The emissions offsets and REC's could be available for trading until they are "retired," in which case they're owned by a particular party.  I'll change the page for that.

      As for the footprint token, I did some research on double counting.  It's actually a very big problem which results from all these siloed ledgers of emissions offsets.  For example,  this document from the Gold Standard talks about the problem when offsets could also be counted in a national registry of emissions reduction.  They've even published a Double Counting guideline document.  Suffice it to say, this is a bigger problem which needs to be addressed by coordinating across multiple ledgers.  I think it's better if we remove this feature for now.

    • I amended the Renewable Energy Certificate definition based upon an overview of the U.S. CLEAN Future Act draft legislation (2 March 2021). 
    • I will follow up with a second post that is an analysis of the proposed legislation 
    • Changes to the Business Systems Requirements and the POC are next steps.

    Background

    The US CLEAN Future Act was introduced into the US. House of Representatives as a draft bill on 2 March 2021.

    This proposed legislation will materially impact the business requirements analysis

    of the core Emissions Token Network within the Utility Emissions Channel. 

    Purpose

    This post is 

    1. An overview of key provisions of the bill to allow CASIG to get a head start on making changes in light of proposed legislation
    2. To build on the considerable work done already by focusing on architecture or design already fit for purpose
    3. To suggest a POC that may be among the first of its kind in US Zero Emission  Electric Credit 

    Highlights

    1. The USCFA only covers electricity sold into or within the borders of the United States
    2. The legislative intent is to create a national U.S. Energy Attribution Certificate called a Zero Emission Electric Credit
    3. The Administrator of the Environmental Protection Agency (EPA) is the relevant regulator* 
    4. A system of grants to encourage microgrid development for 'rural distressed communities' is covered in s. 225*
    5. Zero Emission Electric Credits can be exchanged for State RECS subject to the relevant state having 'tighter' standards 
    6. The percentage of ZEECs increases from a baseline starting in Year One
    7. A trading market in credits is clearly defined

    Energy Attribution Certificate or Carbon Offset? 

    An Energy Attribution Certificate is measured in MWh of electricity generated from an eligible renewable system. An EAC is termed a REC

    in the United States 

    I recommend referring to the MWh electricity attribute as the EAC Component of the Zero Emission Electricity Credit. 

    A Carbon Offset or Permit has no connection to a specific renewable generator except as a policy or legal convenience. 

    Hybrid Instrument

    The Zero Emission Electricity Credit is a hybrid EAC Offset. It is easy to understand:

    • Take an efficient biomass generator that produces 100MWh of electricity 
    • The owner of the generator is entitled to 100 EACs or Certificates Representing 100 MWh*
    • These EACs are fully transferable as RECs in most markets 
    • However, there is one more step

    1.0 -[ Average Carbon Intensity/Carbon Intensity Factor] = ZECC

    CARBON INTENSITY.—The term ‘‘carbon intensity’’ means the carbon dioxide equivalent emissions associated with the generation of 1 megawatt hour of electric energy, as determined by EPA

    This will be an external data source. 

    CARBON INTENSITY FACTOR.— 



    Year

    Carbon Intensity Factor


    Example

    20300.821-Carbon Intensity/0.82

    20310.736

    20320.652

    20330.568

    20340.484

    20350.4

      
     


  3. Here is an Executive Summary of the Business Requirements 

    1. The High Level Goal is the unification of various carbon trading regimes as set forth in the Paris Agreement (Conference of the Parties)
    2. The execution of this goal among various stakeholders is described in a diagram here  
    3. This diagram forms part of the considerable work by Martin Wainstein  , Tom Baumann  and other members that includes a roadmap for a project README. 

    Peter Clarke Peter has taken a first review of the ZEEC or Zero Emission Electricity Certificate as contemplated by the CLEAN Futures Act. 

    Si Chenhas created a prototype of the Emissions Token Network with the Utility Emissions Channel as a Fabric Project by Robin Klemens

    The workflow would now be to integrate these various streams. A subset of members have the objective of connecting this integrated platform as part of their roadmap to COP26. 

    In the meantime is Earth Day on or about 22 April and thus I will work on integration for November while sharing progress with the Earth Day MVP. 


    1. Hi David Dornyoh , thanks for your efforts towards COP26! 
      To which diagram are you referring to in 2.?

      Can you share the roadmap of the subsets of members to COP26 with us? This could help to further coordinate the efforts of the overall group. 
      Thx,
      Robin

    2. Si and Robin have created a Utility Emissions Network and Emissions Token Network on AWS and Digital Ocean respectively. 

      • When they are ready, we can 'join' one of our channels with theirs
      • I set up a BYN network (Bring Your Network) on IBM Cloud & updated it to 2.0 
      • Chaincode instantiated prior to v2.0 is incompatible with v1.4.   
      • This means for each Fabric network we have, deleting it and rebuilding it in 2.0


      Ry Jones has a template for technical material that is perfect for Hyperledger Labs READme documents. Technical material on Wiki is best moved to Github with a link from this wiki as a reference.

      Summary:

      This post is to let Robin Klemensknow that a utility blockchain is available to 'Join' and technical READme can be found on Github.     Thank you. 

      1. Hi Peter, can you share the link to the template for technical materials provided by Ry Jones, pls?

        1. Hi, Robin. I'm not sure what Peter Clarkehas in mind - however, the TSC repo is probably a good start.

          1. Hello Ry  - Best Practices Badges / Templates - Learning Materials Development Working Group - Hyperledger Confluence  

            This set of guidelines is excellent!  I had this in mind when working with developers .  TSC Repo also very valuable.

            Thank you. 


  4.   

    Part I -   Go to  How to Contribute and then Click on "Issues" 

    Part II     Build ZEEC Network or the Zero Emissions Electricity Certificate Blockchain 

    Part III    Design Offset and REC tokens based upon ZEEC definitions 

    Part IV    Choose taxonomy and cross-chain/multi channel architecture 

    Part V     Build Ethereum Dapp/Wallet . Test other technologies ( 


    Token Standards:  

    • ERC-20 - the most popular of the Ethereum token standards (used by BNB, USDT, LINK)

    • ERC-223 - incorporates token Fallback technology which ensures that should the token be sent to a smart contract that does not work with that particular type of token, the tokens are returned to the original address.

    • ERC-721 - are non-fungible tokens (NFT), that cannot be replaced or replicated, can represent ownership over an asset.

    • ERC-777 - a revised version of ERC-20 with features like offering users more control over their tokens and allowing operators to send tokens on behalf of other addresses.


    • Goals:  Build parallel network to facilitate 'trading' back and forth 
    • Choose one Pull Request issue and resolve it 

    Tear down build and clean up. Write report and publish findings to members. 

    Securitisation network stays in Fabric 1.4 and at Operating System/Multi Channel Level 

    Instructions for ZEEC network

    1.  The ZEEC network is US based ("US" is defined in the draft CLEAN Future Act o include electricity flowing into the United States) 
    2.  A ZEEC is a Zero Emissions Electricity Credit comprising part CO2e offset and part REC
    3.  We will call the Carbon Offset a ZEUA and assume a linking mechanism by and among: the ZEEC markets, AB32, RGGI and the EU-ETS 
    4.  We want to trade both RECs and ZEUA-EUA pairs
    5.  Network One:   Fabric 2.0+   
    •                  Set up Network in Fabric
    •                  Set up Gorli Wallet. Build Ethereum Network
    •                  Add to table below. 10 entries for later discussion on 29 March 2021


    This will be the project for CASIG Energy.