Versions Compared

Key

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

Join our Peer Programming Call-In

We have a bi-weekly Peer Programming Zoom call for developers on Mondays at 9 AM US Pacific time (UTC-07:00 America/Los Angeles.)

...

If you're interested, please check the calendar for the next call

This Minimum Viable Product will use these key concepts from the Multi Channel Data Architecture to build applications described in Carbon Accounting and Certification Working Group

  1. Access data from several permissioned channels.
  2. Use standard model-factors to calculate emissions from the data.  
  3. Record the emissions results on a permissioned channel for the next entity to consume.
  4. Minimalist apps which
    1. run as serverless micro services, for example on Amazon Lambda or Cloud Functions from Google or IBM;
    2. pass through customer authentication keys to the permissioned channels

In each process, it will simulate the roles of:

  • Data source, which provides product use data
  • CO2 emissions auditor, which calculates CO2 emissions from the product use data
  • Data consumer, which uses the CO2 emissions data to calculate their own emissions, purchase offsets, etc.

The MVP will allow self-contained carbon emissions calculators for different purposes, as well as simulate how carbon emissions data could be shared across a supply chain with multiple parties.

Potential data sources include:

  • Utility bills 
  • Shipping data
  • Travel data
  • Vehicle trip data
  • Renewable Energy Certificates
  • Carbon offsets 

Think of each of these data source as a "programming primitive."  On their own, they're just data.  But combined together, we could build a variety of interesting applications, such as:


...

An Operating System for Climate Action

An operating system like Linux is a set of resources for building applications.  There's a low level tier that connects to hardware and devices, a middle tier of services for building applications, and a user interface tier at the top.  Similarly, blockchain services could be combined to empower climate action:

Audited Emissions Channels

These are permissioned ledger (Hyperledger Fabric) data channels used by auditors to record audited emissions data.  Like the hardware and devices tier of an operating system, these channels store data gathered from the real world and recognized emissions factors.  The data could be audited emissions from emissions auditors, or they could be data from MRV auditors to record data for verifying carbon emissions reduction or sequestration.  In both cases, the data could then be used to create tokens.  For example, the Utility Emissions Channel takes utility bills, applies energy emissions factors, and calculates the emissions from utility energy usage.  

By following the Multi Channel Data Architecture, data from different sources could be stored immutably to improve trust in the integrity of climate and emissions data.    

Token Networks

Once data for emissions and offsets are tokenized, they allow transactions to take place: paying for emissions reductions and offsets with tokens and smart contracts.  These transactions are like the middle tier of services in an operating system.

For example, the Net Emissions Tokens Network could be deployed as a permissioned or Layer 2 Ethereum network where carbon offsets and renewable energy certificates (REC’s) are traded and retired against audited emissions (from Audited Emissions Channels above.)  As a “gated” network, only audited emissions, offsets, and REC’s from accepted sources are allowed to transact in this network.  

This network could form the basis of organized climate action at a variety fo scales, from supra-national and national carbon emissions cap and trade to community energy projects to nature-based offset projects. 

Distributed Autonomous Organization (DAO)

Finally, the DAO connects the climate action services to end users – consumers, members of the public, monitoring agencies, etc. who are vested in their outcomes.  A DAO allows members of a network to vote on governance issues, such as whether to accept certain emissions offsets or auditors, accept the data from an audited emissions channel, and upgrade the models for emissions accounting.  

For example, they can decide if a particular certifying entity's offset tokens would be accepted as a valid offsets.  They can decide the relative value of different offsets by voting on exchange rates or bonding curves.  They could validate the MRV results on an audited emissions channel before issuing offset tokens.  They could vote on whether emissions factors or emissions calculation methodologies should be updated on the emissions channels.  

Because many of the topics are technical, we need to balance experts vs. community members.  At the same time, though, it's important to create an inclusive model of collaboration, just like in open source software, to avoid the dangers of being locked into obsolete models and ineffective climate action.

Minimum Viable Product

The first Minimum Viable Product is the Utility Emissions Channel, which will illustrate: 

  1. Access data from several permissioned channels.
  2. Use standard model-factors to calculate emissions from the data.  
  3. Record the emissions results on a permissioned channel.

Building on it is the Virtual Community Renewable Energy Network, which will illustrate:

  1. Creating tokens from emissions data
  2. Offsetting emissions with transactions between tokens
  3. Certifying net emissions

Further Product Ideas

...

Each of these applications could empower a group of people to work together and take positive climate action, without waiting for a central authority to step up and regulate things.  

What we need is more ideas, both of where to obtain emissions data and what kind of applications could be built with them, so please write if We need more ideas!  Please comment below you have any suggestions.

...

Coding Standards

Even though, or perhaps because we're building open source software, code quality is very important.  We're writing code that others would see long after we're finished, so we'd better leave them something they could actually understand and work with.  We'd also like to avoid being featured in an "Anti Pattern" book or blog post.

...