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:
This is the first layer of trusted data which is the foundation of all climate action.
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.
Click here for a video of the audited emissions chanel.
This is the middle layer that gives financial value to climate activities and allow smart contracts to execute transactions and coordinate different parties' actions.
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.
Click here for a video of the emissions token network.
This is the user engagement layer that connects the users – consumers, members of the public, monitoring agencies -- with climate action.
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.
Click here for a video of the DAO.
The first Minimum Viable Product is the Utility Emissions Channel Project, which will illustrate:
Building on it is the Virtual Renewable Energy Network Project, which will illustrate:
We want your ideas! Please comment below with your suggestions or Tell Us Your Climate Idea.
Here are some good first issues to get started with:
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.
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.