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.)
We're currently implementing the Utility Emissions Channel and Net Emissions Tokens Network use cases together.
If you're interested, please check the calendar for the next call.
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:
- Access data from several permissioned channels.
- Use standard model-factors to calculate emissions from the data.
- Record the emissions results on a permissioned channel.
Building on it is the Virtual Community Renewable Energy Network, which will illustrate:
- Creating tokens from emissions data
- Offsetting emissions with transactions between tokens
- Certifying net emissions
Further Product Ideas
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.
The most important coding standard is to keep things very modular, so separate each function as much as possible. The UI and application logic must be completely separated, to the point of being separate projects, and talk to each other only through clearly defined (REST) API's. This means that we could have several different UI's, like Linux. It also means we don't start putting our business logic in the UI, like some PHP or JSP code did. Similarly, different application domains such as user management, application logic, and standards data management must be kept apart as well.