Climate Warehouse Simulation 2
Report
Thursday, July 14, 2022
Page 0 of 38
Contents
Executive Summary............................................................................................................................4
Context for the Climate Warehouse Prototype 2.0 ..............................................................................5
Background - Warehouse 1.0 Simulation .........................................................................................7
Warehouse 2.0 Simulation Objectives .............................................................................................8
Simulation – Anticipated Partner Participation................................................................................8
Design & Simulation Approach ...........................................................................................................9
Design Questions ......................................................................................................................... 10
Design Scope & Considerations ..................................................................................................... 11
Stakeholder Ecosystem................................................................................................................. 12
Technical Background – Blockchain Rationale ............................................................................... 13
Warehouse Prototype Results .......................................................................................................... 15
High-Level Technical Architecture ................................................................................................. 16
Warehouse Auxiliary Application .................................................................................................. 17
Blockchain Watcher...................................................................................................................... 18
Database...................................................................................................................................... 18
Modular Components using Docker .............................................................................................. 18
Aux App Blockchain Connectivity .................................................................................................. 18
Warehouse Blockchain ................................................................................................................. 18
Warehouse Data Model................................................................................................................ 19
Warehouse Key User Features ...................................................................................................... 19
Double Counting Context.............................................................................................................. 20
Double Counting Logic .................................................................................................................. 21
Simulation Participates .................................................................................................................... 23
Lessons Learned & Outlook .............................................................................................................. 23
Architecture ................................................................................................................................. 23
Features ....................................................................................................................................... 24
Stakeholder Participation to Date ................................................................................................. 24
Simulations Results for Group 1 & 2 Summaried Results ................................................................... 25
Group One (Internal Testing): ....................................................................................................... 25
Results ......................................................................................................................................... 25
Page 1 of 38
Feedback on the Simulation Process ............................................................................................. 26
Group 2 (Participant Testing): ...................................................................................................... 27
2. Future thinking and Participate Recommendations. ............................................................... 27
Limitations ................................................................................................................................... 28
Warehouse Outlook ..................................................................................................................... 29
Appendix I: Contributors .................................................................................................................. 32
Project Sponsors & Unit................................................................................................................ 32
Project Technical Team ................................................................................................................. 32
Community Design & Technical Experts ........................................................................................ 33
Sponsor Organizations and External Collaborators ........................................................................ 33
Appendix II: World Economic Forum Framework .............................................................................. 35
Appendix III: Acronyms & Key Definitions ......................................................................................... 36
Page 2 of 38
"The task at hand is of such a
magnitude that simultaneous action
by the business and finance sectors,
local and regional governments, and
other civil society actors.. is
imperative…
Multilateral discussion of creative, and
even controversial, ideas to
supplement the current toolkit of
measures would also be appropriate…
Governments need to determine
where intergovernmental effort can
best be placed to facilitate action and
help achieve real impacts." 1
Richard Kinley, Michel Zammit Cutajar, Yvo de Boer & Christiana Figueres,
former leaders of the UNFCCC (Dec. 2020)
Page 3 of 38
Executive Summary
This paper provides in interim update on the status of technical prototyping activities that were
conducted by the World Bank’s Carbon Markets & Innovation (SCCMI) unit under the Climate Change
group and the World Bank Group ITS Technology and Innovation Lab / Unit (ITSTI) in 2020 to support the
World Bank Climate Warehouse concept, a meta-registry to demonstrate the potential of a
decentralized IT approach to link climate market registry systems.
Building on the 2019 Climate Warehouse simulation, that was conducted with governments and
standards-setting organizations, the current version of the prototype incorporates new double counting
logic, statistical methods for identifying double counting issues, and an updated user interface that
clarifies the relationship between greenhouse gas emissions reduction projects and units under Paris
Article 6 (with specific focus on Article 6.2). While engagement activities with potential and committed
partners are still underway, the paper provides its audience with a description of the technical design,
assumptions, and building blocks of the upgraded Climate Warehouse 2.0 prototype. This prototype is
anchored in the long-term vision of the Climate Warehouse, as well as a revised grounding in the
evolving technological and business context for the operationalization of the Paris Agreement.
Figure 1: Climate Warehouse Long-Term Vision
Page 4 of 38
Context for the Climate Warehouse Prototype 2.0
The United Nations Framework Convention on Climate Change (UNFCCC)1 was adopted in 2015 with
almost 200 national Parties to the Convention (Parties hereafter) committed to the goal of reducing to
well below 2 °C. This goal is based on a bottom-up approach in which all Parties pledge individual
commitments through Nationally Determined Contributions (NDCs). To enable cost-effective mitigation
of greenhouse gas (GHG) emissions and increase the Parties' ambitions over time, Article 6 of the Paris
Agreement promotes voluntary international cooperation approaches. These cooperative approaches
introduce market-based mechanisms, specified in the draft rulebook texts of Articles 6.2 and 6.4, to
enable the use of internationally transferred mitigation outcomes (ITMOs) to achieve NDC targets.
However, the bottom-up and decentralized market approach of the
Paris Agreement stands in stark contrast to the past and present
“the bottom-up and centralized climate market structures. The Kyoto market
decentralized market mechanisms, as well as the UNFCCC International Transaction Log
approach of the Paris (ITL), voluntary standards, and national registries, are all individually
Agreement stands in stark centralized and collectively dispersed and unlinked 2. At present,
contrast to the past and there are 28 different emission trading systems (ETSs) in regional,
present centralized climate subnational, and national jurisdictions alone 3. The Article 6
market structures” mechanisms cannot be seen in a vacuum but will only work with
solutions that provide the conditions for a well-functioning and
transparent market, where assets can be tracked and there is good
price discovery 4. To enforce robust accounting, aggregate records at
the global level and safeguard environmental integrity in a
decentralized system, it will be required to connect international climate markets and their respective
registries, such as those under CORSIA or Article 6.
The Paris Agreement does not provide guidance on conducting this connection of registries and the
interoperability of emission reduction units under a common mitigation outcome (MO), which is the
term implying usage under the Paris framework. The term registry is used in this report as a more
general term for databases and ledgers that hold records of climate action projects, their generated
units (e.g., CERs, VER, MOs etc.), and transactions under a market mechanism. The diverse set of
registries has led to significant heterogeneity of governance systems and technological infrastructure
across national, regional, and international jurisdictions, from simple spreadsheets to institutional
registries with diverse information and data structures regarding MOs. This heterogeneity of MO unit
1
UNFCCC, “Paris Agreement, United Nations Framework Convention on Climate Change.,” 21st Conference of the
Parties (Paris, 2015), https://www.tandfonline.com/doi/full/10.1080/14693062.2020.1860567.
2
Martin E Wainstein, “Open Climate. Leveraging Blockchain for a Global, Transparent and Integrated Climate
Accounting System,” Yale Open Innovation Lab (Openlab), 2019, 1–23. Available online: https://collabathon-
docs.openclimate.earth/openclimate/docs-open-climate-platform.
3
World Bank Group, State and Trends of Carbon Pricing 2019, State and Trends of Carbon Pricing 2019
(Washington, DC: © World Bank, 2019), https://doi.org/10.1596/978-1-4648-1435-8.
4
Andrei Marcu and Virender Kumar Duggal, “Negotiations on Article 6 of the Paris Agreement: Road to Madrid,”
ADB Sustainable Development Working Paper Series (Manila, Philippines, November 1, 2019),
https://doi.org/10.22617/WPS190559-2.
Page 5 of 38
information may constrain market integration and add to the complexity of tracking and recording
transactions, particularly those qualifying as internationally transfered mitigation outcomes (ITMO) 5.
The present uncertainty surrounding Article 6.2 rulebook negotiations, dealing with the issuing and
transferring of ITMOs, further magnifies the challenges associated with a decentralized assessment of
international transactions 6. Despite these accounting challenges, Parties are unilaterally required to
"ensure environmental integrity and transparency" and "apply robust accounting to ensure, inter alia,
the avoidance of double counting" as per Articles 6.2 and 6.3 7.
To address these challenges, the World Bank is designing
and developing the concept of a Climate Warehouse, a “The diverse set of registries has led to
common meta-registry facilitating peer-to-peer
significant heterogeneity of governance
connection among decentralized registries to link,
systems and technological infrastructure
aggregate, and harmonize the underlying data to enable
transparent accounting of Article 6 transfers. The across national, regional, and
Warehouse is developed by the World Bank's Carbon international jurisdictions, from simple
Markets and Innovation unit (SCCMI) under the Climate spreadsheets to institutional registries
Change group, collaborating with the World Bank's with diverse information and data
Information Technology Services Technology and structures regarding Mitigation
Innovation (ITSTI) Lab. The Warehouse project explores Outcomes (MOs)”
the use of emerging decentralized information
technologies such as blockchain, a type of Distributed
Ledger Technology (DLT), and statistical methods of data
processing automation with compatibility to leverage
machine learning in future iterations. These technologies are leveraged to surface publicly-available
information on MOs from registries and databases, and facilitate transparent accounting in the broader
Article 6 context (https://unfccc.int/sites/default/files/resource/parisagreement_publication.pdf).
5
World Bank Group, “Summary Report: Simulation on Connecting Climate Market Systems (English),” The World
Bank Group (Washington D.C., USA, 2019). Available online:
http://documents.worldbank.org/curated/en/128121575306092470/Summary-Report-Simulation-on-Connecting-
Climate-Market-Systems.
6
Marco Schletz, Laura Franke, and Søren Salomo, “Blockchain Application for the Paris Agreement Carbon Market
Mechanism – A Decision Framework and Architecture,” Sustainability 12, no. 5069 (2020): 1–17,
https://doi.org/https://doi.org/10.3390/su12125069.
7
UNFCCC, “Paris Agreement, United Nations Framework Convention on Climate Change.,” 21st Conference of the
Parties (Paris, 2015). Available online: https://doi.org/FCCC/CP/2015/L.9.
Page 6 of 38
Figure 2 - Climate Warehouse in the Article 6 Context
Background - Warehouse 1.0 Simulation
In the first phase 8, the project identified potential prerequisites and requirements of Article 6.2 and
conducted a pilot simulation of a prototype to test blockchain's utility as the underpinning platform
technology to connect heterogeneous registries to track units and avoid double counting issues across
those registries. Four partners collaborated on the simulation, including two governments and two non-
governmental, standards-setting organizations: the Government of Chile, Ministry of Energy;
Government of Japan, Ministry of the Environment; The Gold Standard Foundation; and Verra.
The first simulation resulted in the following key lessons:
1. The Climate Warehouse decentralized meta-registry system showed potential to provide an
inclusive platform to connect the different country and institutional registry systems and
support much-needed visibility to climate activities, and enhance overall market activity
transparency.
2. Joint learning between the World Bank and participants was a valuable experience, which
demonstrated the utility of blockchain technology and enhanced understanding of the potential
requirements that need to be in place for future iterations of the Climate Warehouse concept.
8
World Bank Group, “Summary Report: Simulation on Connecting Climate Market Systems (English),” The World
Bank Group (Washington D.C., USA, 2019). Available online:
http://documents.worldbank.org/curated/en/128121575306092470/Summary-Report-Simulation-on-Connecting-
Climate-Market-Systems.
Page 7 of 38
3. The ability to conduct data analysis and different ways of using data, and user experience and
data visualization will be important in the future to be able to observe and audit and lifecycle
information for climate projects and units.
4. Setting up and connecting blockchain nodes requires technical support and collaboration if
technologists have little blockchain experience.
5. Overall, participants agreed that the Climate Warehouse concept could increase trust and
transparency and stimulate action and provided useful feedback on considerations for future
concept development.
Warehouse 2.0 Simulation Objectives
This interim viability report presents the second phase of the Climate Warehouse prototype
development, which builds on the previous findings. In this phase, the project focuses on the simulation
of the meta-registry with a higher number of expected participants and an updated system architecture
exploring new Climate Warehouse features.
The Climate Warehouse is conceived as a demonstration exercise to enable a diverse set of participants
to understand the potential obstacles and opportunities for data harmonization. One of the project's
key objectives is to provide practical insights for participants that can then be leveraged to inform
ongoing Article 6 negotiations. This key objective is achieved through the following two activities:
REGISTRY INTEGRATION
Developing data structures to aggregate and harmonize data from heterogeneous registries.
• Define minimum standards for the technical infrastructure of registry systems for
participation based on participants' current understanding of Article 6 or other climate
markets requirements;
• Testing which fields will be most important for information sharing at the metaregistry level
in the Warehouse;
• Harmonizing of heterogeneous registry data formats into a common Warehouse data
model, to the extent practical and feasible;
• Synchronizing and surfacing of registry information in the Warehouse to enable real-time
information updates so that project information, the status of MOs, and traceability of MOs
between partners can be assessed and viewable by all participants;
• Testing the feasibility of blockchain as an underpinning architecture technology.
DOUBLE COUNTING RISKS OF ITMOs
Developing features to surface and track mitigation outcomes while safeguarding environmental
integrity.
• Developing robust accounting procedures and highlighting double-counting risks;
• Supporting the information flow to conduct corresponding adjustments in the involved
registries.
Simulation – Anticipated Partner Participation
The purpose of the simulation is to develop the Climate Warehouse prototype in close collaboration
with the simulation partners. A variety of partners have been consulted with support from A6
Advisory/Multilateral Development Bank (MDB) Working Groups. The World Bank completed the 2nd
Page 8 of 38
simulation phase with more than 40 stakeholders, including country registry operators, independent
certification standards, multilateral institutions, and industry partners. Additionally, the World Bank
Group leveraged its internal experience developing the Carbon Asset Tracking System (CATS) and the
country registries for Jordan and Sri Lanka to inform the development of the Climate Warehouse.
The purpose of the simulation focused on understanding how the views of stakeholders from different
backgrounds and contexts can be reconciled with respect to identifying and removing common barriers
to improve ITMO quality. To this end, partners in the simulation fell into three broad categories:
1. Full participants – stakeholders that are willing and able to hold a copy of data and participate
in shared software governance to ensure the quality and control over that data in a distributed
environment;
2. Data providers – stakeholders that may not have the ability or interest to participate in a
shared, distributed software architecture but that are willing to contribute data to further a
shared understanding of MO data and associated compatibility issues across domains;
3. Observers – stakeholders that have a direct responsibility to ensure the integrity of mitigation
outcomes and associated international transfers, or who are interested to view data and
analysis as part of their role in furthering the scaling up of compliance or voluntary carbon
markets.
The simulation audience included a variety of stakeholders in these carbon markets, including national
government ministries, sub-national or intra-governmental bodies, trading platform operators (e.g.
market facilitators, exchanges), multilateral development banks, and the UNFCCC. The diversity of this
stakeholder group underscores the need for a participatory design process.
Design & Simulation Approach
The project followed a design thinking approach to upgrade the Climate Warehouse prototype to
version 2.0. In the first phase of the project, a comprehensive literature review was conducted, followed
by subject matter expert consultations, to design and create a prototype that is rooted in stakeholder
concerns and viewpoints. The literature review comprised academic and private-sector research on
emerging technologies consistent with use case requirements. The subject matter expert consultations
were used to validate the literature findings and receive feedback on and insights into the climate
market and Article 6.2 accounting challenges, and the proposed Climate Warehouse architecture.
Furthermore, potential partners, such as governments, registry providers, trading platform providers,
and the UNFCCC, were initially consulted to understand their requirements and the potential challenges
that emerging technologies such as blockchain might address.
The second phase of the project will focus on the prototype evaluation in the form of the simulation,
where partners test the Warehouse prototype and provide iterative design feedback. The first step of
the evaluation phase is the integration and synchronization of the partner registry systems. The partners
then use the inserted registry data to surface and transfer ITMOs among the Climate Warehouse partner
accounts. These ITMO transfers only occur as part of the simulation and does not have any binding
implications outside the simulation.
Page 9 of 38
Once partner consultations are completed, the simulation will be divided into three consecutive phases
(Figure 2).
Figure 3 - Climate Warehouse Simulation Phases
Design Questions
In designing the second version of the Climate Warehouse prototype, the Lab was faced with the
specific problem of needing to constrain the problem space to a limited number of questions to be
answered using emerging technology. While the broader challenge of connecting and harmonizing
diverse data formats from different registries is a rich area for exploration, the key question the Lab
attempted to answer with its design was " How can data from heterogeneous registries be aggregated
and harmonized to assess MOs and identify double-counting risks?"
This design question does not obviate the need to consider the challenges of operationalizing a
distributed ledger concept for Article 6 – such as shared software governance models, access
management, private transactions – but rather prioritizes the question of double counting – specifically,
double claiming and double use. While this work took place prior to COP26 where there were further
developments regarding the legal framework of the Paris Agreement, the issue of double claiming and
Page 10 of 38
doube use are largely the same. These issues – and how the prototype specifically addresses them – are
discussed in greater detail in subsequent sections.
Design Scope & Considerations
Given the ambiguity in this problem space, the Lab made some specific design assumptions to reach a
more targeted and well-defined viewpoint for the development of the Climate Warehouse prototype. In
addition to focusing specifically on Article 6.2, the Climate Warehouse 2.0 prototype assumes the same
design principles as those outlined in Article 4.13: transparent, accurate, complete, comparable,
consistent. For the sake of simplicity, only publicly available data was sought from participating
institutions, though the design team acknowledged that support for private project data and
transactions would be necessary for operationalization.
A recurring question for the Lab has been how to reconcile the
differing views on the definition of environmental integrity with the “the Climate Warehouse 2.0
intent of blockchain-based systems, which cannot resolve this prototype assumes the same
definitional problem. In order to manage this hurdle, the prototype design principles as those
design acknowledges that these definitional issues may exist. Finally,
outlined in Article 4.13:
while recognizing the importance of digital and automated
transparent, accurate,
monitoring, reporting, and verification (MRV) in the success of the
Climate Warehouse, the Lab does not seek to demonstrate that complete, comparable,
capability through the Climate Warehouse itself. In summary, the consistent”
Climate Warehouse is part of a larger set of building blocks that
support the conceptual implementation of Article 6.
The Climate Warehouse prototype development and simulation took place within the following design
scope:
• Participants surfacing information to the Climate Warehouse will surfaced public data;
• The Climate Warehouse has a specific emphasis on the transfer of MOs under Article 6.2;
• The data in the Climate Warehouse meta-registry was only public data surfaced by the
participants;
• The data fields in the meta-registry was limited and facilitated search and filtering, traceability
and audit features; and
• Each organization surfacing information has detailed publicly available information about its
projects and issuances in their registry, which is reachable via links from the meta-registry.
In keeping with the previously stated design principles of transparency, accuracy, completeness,
comparability, and consistency, the Climate Warehouse includes the following design considerations:
• Data in the Warehouse mirrors the registry information of partners participating in the
Warehouse (data quality is the responsibility of connected registries). Warehouse data can be
relied on as a record of registry data for accuracy, auditing, and reporting purposes;
• The information in the Warehouse about projects and assets is considered reliable for reporting;
• The Warehouse concept aims to ensure a flexible architecture and data model in anticipation of
rule changes as they evolve;
Page 11 of 38
• A distributed database was used for the prototype. The prototype was hosted by the World
Bank and was not viewable by anyone except for participating partners and project team
members. The World Bank did not public access to the Warehouse user interface or any
backend information. Each participant had a login, including participants with read-only roles
(MDBs and Climate Warehouse contributors).
• Each participating organization could establish system-to-system integration between their
registry and the Warehouse. The rationale for node integration was to simulate real-time data
updates, data auditability, and system redundancy. The node established by the partnering
organizations' IT resources, and the Bank Group supported this effort. The Bank Group
administered network access rights and provided procedures and code for setting up nodes.
Stakeholder Ecosystem
In order to better understand the audience for the Climate Warehouse, the project team analyzed the
ecosystem landscape. This section presents the Article 6 ecosystem participants, their roles and
capacities, and their motivations in participating in Article 6 and the Warehouse.
Figure 4 - Selected Ecosystem Participants
As the next step in the design process, the project team developed a journey map, to understand how
the Climate Warehouse fits within the broader set of activities needed link the development of GHG
emission reduction projects to the anticipated Global Stocktake exercise, set to take place in 2023. A key
insight from the development of this journey map was the need for automation of data collection and
Page 12 of 38
synthesis at all stages of the journey, to reduce the level of effort required to conduct multilateral
progress assessments.
Figure 5 - Journey Map
Technical Background – Blockchain Rationale
Blockchain was specifically selected as a technology to underpin the Climate Warehouse prototype 2.0
to support this diverse stakeholder ecosystem, which is comprised of participants that need to share
related and potentially overlapping data sets. Blockchain is an emerging data storage and accounting
technology that enables the decentralized distribution of data across participant networks (i.e., nodes).
The data is distributed across all nodes of the system so that each participant holds a copy of the data,
i.e. the digital ledger. Depending on the implementation, participating nodes have full access to the
entire history of transactions, they can verify and publish new "blocks" of transactions to the existing
"chain" of existing transaction blocks that are cryptographically linked in chronological order. Due to this
interlinked structure, the transaction history becomes immutable and tamper-resilient, as an altering of
a block requires the changing of all subsequent blocks. In this project, the blockchain serves as a data-
repository to aggregate and harmonizes the registries in one system, accessible for all users to eliminate
information asymmetry.
Page 13 of 38
The first Warehouse simulation round indicated a promising application of blockchain to address key
concerns in decentralized climate markets 9:
• A blockchain-based system is decentralized. Each participating institution has a node that holds
a copy of the data held in the system.
• The decentralized and immutable nature of the system also provides resilience against attacks
and confidence that information has not been tampered with.
• Blockchain provides capabilities to increase transparency and trustworthiness of data recording,
reducing the risk of double counting.
• The peer-to-peer arrangement could give participating entities the flexibility to interact through
their blockchain node and manage their access rights based on their requirements and
institutional framework.
• Use of blockchain for the Climate Warehouse information system could ensure that mitigation
outcomes can be traceable from their origin through to their eventual retirement (assuming
relevant registries are connected).
For the first and this current simulation, the prototyped Warehouse stores data on a private
permissioned Ethereum network blockchain-as-a-service – Kaleido - which was configured to use an
Istanbul Byzantine Fault-Tolerant (IBFT) consensus algorithm.10 According to Consensys, "IBFT (Istanbul
Byzantine Fault Tolerant) is a consensus mechanism which is an alternative to Proof of Work in an
Ethereum network. Like other algorithms, IBFT ensures a single, agreed-upon ordering for transactions
in the blockchain, and provides added benefits for enterprises, including settlement finality."11 ITSTI is
technology-agnostic, and identified this suite of technologies and providers for their suitability for the
use case in question.
A permissioned blockchain was selected to ensure the simulation was cost-effective while also limiting
the complexity of implementation to focus the learning exercise on the key features of the prototype,
including the user experience and double counting logic. A permissioned blockchain also supports the
9
World Bank Group, “Summary Report: Simulation on Connecting Climate Market Systems (English),” The World
Bank Group (Washington D.C., USA, 2019). Available online:
http://documents.worldbank.org/curated/en/128121575306092470/Summary-Report-Simulation-on-Connecting-
Climate-Market-Systems.
10
Blockchains can be private or public. A private blockchain contains data that is not available to the general public
to use. A public blockchain can be used by anyone. If the public blockchain is permissionless, anyone can interact
with the blockchain or set up a node. If the blockchain is permissioned, the ability to transact or host a node is
controlled. For more information on blockchain types, see OECD, OECD Blockchain Primer, available at:
https://www.oecd.org/finance/OECD-Blockchain- Primer.pdf.
11
More information available at: https://consensys.net/blog/enterprise-blockchain/scaling-consensus-for-
enterprise-explaining-the-ibft-
algorithm/#:~:text=IBFT%20(Istanbul%20Byzantine%20Fault%20Tolerant,for%20enterprises%2C%20including%20s
ettlement%20finality
Page 14 of 38
needs of a governmental ecosystem containing highly regulated actors. The precise distribution needs to
be specified through consultation with the ecosystem stakeholders. In order to ensure that the system
remains decentralized and tamper-resilient, as many ecosystem stakeholders can acquire and maintain
full nodes of the system. This shared software governance structure can pose challenges in a situation
where registry owners have outsourced their IT work to external companies.
By sharing data transparently across a network of decentralized actors, blockchain can create new forms
of governance. The Warehouse enables users to share their registry data to coordinate and collaborate
on global efforts towards the targets of the Paris Climate Agreement while, at the same time, leaving
the data sovereignty with each registry owner. This model for data sovereignty is critical for complying
with the bottom-up and decentralized ethos of the Paris Agreement 12. Understanding the stakeholder
interests through a proactive and iterative development approach is essential for creating an inclusive
system that reflects governance requirements and creates a sense of ownership among the stakeholders
that can bring practical learnings to ongoing Article 6 negotiations.
Warehouse Prototype Results
The Warehouse connects country, regional, and institutional record-keeping registries to surface
publicly available information on MOs and enhance transparency and trust among market participants
through enabling the tracking of MOs across jurisdictions. This architecture enables the collective
tracking of all ITMO transactions by distributing and validating the repository across the network of
verified participants, ensuring data harmonization, robust accounting, and reducing information
asymmetry between buyers and sellers (Figure 3).
Figure 6 - The Climate Warehouse Concept
12
Schletz, M., Franke, L., & Salomo, S. (2020). Blockchain Application for the Paris Agreement Carbon Market
Mechanism – A Decision Framework and Architecture. Sustainability, 12(5069), 1 –17.
https://doi.org/https://doi.org/10.3390/su12125069
Page 15 of 38
Following the challenge of connecting heterogeneous centralized registries into a decentralized
international ecosystem of bottom-up climate markets, the Warehouse connects registry systems to
reflect information on all MOs. Its goals are:
1. Establishes a common data model among registries to aggregate and harmonize data across registry
systems to reduce information asymmetry;
2. Enables the tracking and assessment of MO information to improve robust accounting and identify
double counting risks;
3. Creating a decentralized and bottom-up meta-registry for the effective implementation of the
Article 6.2 market mechanism.
High-Level Technical Architecture
The Warehouse acts as a meta-registry across multiple registries. Participants connect their data to the
Warehouse via an "Auxiliary App," a web application designed to ease the technical requirements for
integration. As described previously, there are three types of participants in the Warehouse simulation
process: Integrated Participants, Node Participants, and Observers. Integrated participants have read
and write access to the warehouse blockchain via their integration through the Auxiliary App. Node
participants also have read and write access but also hold a full copy of the ledger and provide trust in
the network. Observers have read-only access.
The Warehouse web application has two primary interfaces with the blockchain. The first is via the
Auxiliary App, which helps integrated participants manage their data sync and entry point into the
Warehouse. The second is a tab that showcases all the data in the Warehouse blockchain. Figure 7
showcases the high-level architecture where registries, either from countries or independent standards,
sync with the blockchain via the "Aux App."
Figure 7 - Climate Warehouse High Level Architecture
Page 16 of 38
Warehouse Auxiliary Application
The Warehouse Auxiliary App (Aux App) is a web application solution designed using modular
microservices running on Docker. It provides three key services: Database, Blockchain Watcher, and
Backend API. It has two configuration files: a Data Model Mapping Configuration File and a Blockchain
Connection Settings file. Details of these components are specific for each participant, which is why
every participant should be running their own Aux App. Figure 8 lays out the different components of
the Aux App, and its key services are described below.
Figure 8 - Auxiliary App. Participants integrate to the Warehouse blockchain via an Auxiliary App, which provides multiple
microservices for a more simplified user experience
Page 17 of 38
Blockchain Watcher
The purpose of this service is to replicate blockchain data into the database for faster processing. This
service continually watches for events (i.e. any record changes and transactions) on the blockchain.
When an event is triggered, this service captures the event, extracts the event data, and puts it on the
database.
Database
A NoSQL (MongoDb) database is used to store, query warehouse data, and keep data serialized. Data is
synched from the blockchain using the "Blockchain Watcher" service. This data model is an extended
version of the one used in the prior phase and provides the essential elements of the data needed to
support the analysis of double counting issues. It is not built on a traditional relational database; it uses
a NoSQL approach to combining data elements. Traditional SQL databases have relational data tables
with predefined schemas (i.e. the set of field names). In contrast, NoSQL allows for dynamic schemas
that can scale horizontally to encompass heterogeneous data models.
Combining a database with a blockchain was one of the important insights in the lead up to the
Warehouse design. Our analysis had previously suggested that blockchains are not suitable for storing
large amounts of attribute information about climate action. The MRV process needed to verify project
and MO information currently rely on extensive audit reports, detailed project information, and
imagery. More extensive information should reside within a different type of data storage component
built for storing this type of information.
For the integrated data from participating registries to link into the Aux App database and the
Warehouse blockchain, a data mapping configuration file is needed, and its setup should reside in each
participant's Aux App instance. See the data model below.
Modular Components using Docker
All services within the Aux App run as Docker containers. Docker is a software product that enables the
creation of digital platforms using a modular approach, where each component is hosted in a separate
container, but where all containers talk to each other through distinct channels. Docker is a kernel
shared Virtual Machine (VM) solution; therefore, it is more performant than traditional VM solutions.
The Aux App provided to Warehouse participants can be run using Docker. A docker compose file is used
to start the Aux App.
Aux App Blockchain Connectivity
The participant server that runs the Aux App should have access to the Warehouse blockchain network
with credentials stored in a 'Blockchain Connection Settings File'. Aux App connectivity provides all
needed REST API features for the front-end to surface data. This connectivity service is also responsible
for converting registry data into warehouse data using the data mapping configuration file. Once the
registry data is converted, it is pushed into the blockchain.
Warehouse Blockchain
This second iteration of the Warehouse simulation adopts an Ethereuem private network using an
Istanbul Byzantine Fault Tolerant (IBFT) consensus protocol. However, to simplify the ease of blockchain
connectivity and user experience for participants, the architecture uses a blockchain-as-a-service
Page 18 of 38
software product called Kaleido. While multiple blockchain services exist, and could provide suitable
support for decentralized Climate Markets, the comparative evaluation of the Warehouse architecture
across different blockchain platforms was not a key learning objective of this round of prototyping and
simulation.
Warehouse Data Model
Registry Data Snapshot - To create a safe sandbox environment for the simulation, the Aux App was
designed to retrieve data from a copy/snapshot of the registry database. This snapshot can be a recent
database backup, csv-excel export of the registry.
Mapping Configuration File - The Aux App allows users to map the fields of partner registry systems to
the fields of the Warehouse using this configuration file. It tells the Aux App how to link fields between
the Warehouse and registry.
Figure 9 - Warehouse Data Model
Warehouse Key User Features
In order to improve the user interface for the second round of Warehouse simulation, the project team
developed a series of clickable wireframes addressing three main user needs: the ability to explore,
manage, and transfer mitigation outcomes. These clickable wireframes helped the project team coalesce
around the substance of the data model needed to support the Warehouse prototype 2.0, as well as the
double counting logic that was needed behind the scenes.
Page 19 of 38
Figure 10 - Exploring Projects and Units, Managing Integration
Figure 11 - Tracking ITMOs
Double Counting Context
A key feature of the Climate Warehouse prototype 2.0 is the double counting logic. There are different
forms of double counting: double issuance (issuing multiple units for the same emission reduction),
Page 20 of 38
double claiming (counting the same unit towards multiple targets), and double use (using a unit multiple
times towards a mitigation target).
When the mitigation outcome is entered into the meta-registry, the prototype’s double counting logic
assesses and flags whether a double counting risk exists. In the present situation, accounting systems
are fragmented and it is difficult to track and compare mitigation outcomes in national accounting
systems with non-state actor accounting systems (e.g. CORSIA). This is why it is important to have an
aggregation method and approach whereby all fragmented accounting systems have a path to
harmonization. This will become an increasingly important issue as countries track and report on their
NDCs.
While the double counting logic does reduce risk, it is important to note that it is not exhaustive.
Principally, the Warehouse protoype 2.0 has limited ability to flag double issuance risks. This is because
double issuance is not related to the transfer accounting procedures (like double claiming and use) but
takes place at a national or sub-national level when the mitigation outcome is generated. Accordingly,
this issue lays outside the blockchain-architecture, that currently depends on the data derived from
national accounting systems. Here, digital MRV procedures have great potential to deliver value as they
transparently document how the mitigation outcome is generated. Of specific interest are technologies
such as Geographic Information Systems (GIS), Internet of Things (IoT) and Artificial Intelligence (AI) &
Machine Learning (ML).
In the current outline of the warehouse architecture, the system acts as "aggregation and transaction
layer" and is not dependent on digital MRV. However, it is highly desirable to include digital MRV
procedures as soon as feasible as they helps to enhance transparency and thus unit quality.
Double Counting Logic
The specific double counting logic for the Warehouse 2.0 prototype is described below. Throughout the
logic, the quality of data, as well as the availability of granular data such as geographic coordinates, are
important considerations for the effective performance of the logic.
Prerequisites:
• The data fields (registry, country Location, unit identifier, vintage start and end date, etc.)
are given, and are non-repetitive and identifiable
Double Issuance Risk (Identification of timeframe, quarterly or annual reporting is necessary):
Scenario 1: Project ID Match & Project Name Match
• 2+ project IDs are the same and units are actively being issued under both projects at
the same location and vintage period
• 2+ project names are same with different project IDs and related project ID, related
project type, origin registry, origin project ID (for transfers) do not indicate any
relationship between the projects
Scenario 2: Project Location Match
Page 21 of 38
• Project IDs are different, but project location (Country Location or more
granular location), sector, project type, project developer for 2+ projects is same but
current registry is different (Accuracy depends on how precise the location is)
Scenario 3: Unit Match
• 2+ unit block identifiers (Serial Number Block) excluding transfers are the same
• Unit issuance locations (e.g. GPS coordinates) are the same but different unit IDs exist
• Total units issued for a given year is greater than the estimated annual project emission
units for the specific year
• Different unit identifiers with same Vintage start and end date for annual block of units
for the same project
Double Use Risk
Scenario 1: Transaction Type Conflict
• Two different registries (identified by name or ID) have same unit block identifier with
statuses that do not reflect a transaction (e.g. transfer in progress and transaction type -
international transfer).
• Sub-scenario – 1: If Registry A and Registry B have the same unit block id then check
status of unit (what the unit is being used for, NDC, ITMO, canceled
etc. (reference data model)
• Sub-scenario – 2 If Registry A and Registry B have same unit id and status indicates it may
be an ITMO, then check whether the transaction type indicates an international transfer
Scenario 2: Transaction Status Conflict
• Two different registries (identified by name or ID) have the same unit issuance
location (based on GPS coordinates) with statuses that do not reflect a transaction
(e.g. sold).
Double Claiming
Scenario 1: Retired For NDC
• Two different registries have same unit block identifier with status indicating they
contributed to NDC ("NDC - Retired")
• Two different registries (identified by name or ID) have the same unit issuance
location and same vintage with status indicating they contributed to NDC ("NDC -
Retired")
Scenario 2: ITMOs Do Not Match
• If the sum of exchanged ITMOs (identified by unit block identifier, transaction type and
unit status) between two registries that were involved in the exchange doesn't equal
to 0
Miscellaneous Issue (Typo) Risk:
• Flagging typos: Given the possibility of typo during providing the fields manually, the
typos should be checked and flagged. This could be performed before double-counting
checks (fields same except one)
Duplicate Risk: All fields are same
Page 22 of 38
Simulation Participants
• The Simulation participants included 15 active participants (mostly country registries and
standards agencies); and more than 15 observers from multilateral development banks and
organizations, country ministries, industry partners, exchanges, and regulators, among others.
• Simulation testing involved partners trying out processes using the Climate Warehouse
prototype that involve interaction with other participants, such as transferring issued units from
one registry to another.
• The Simulation kicked off with internal registries developed by the World Bank to test out the
functions.
• The Simulation included three groups of partners that were involved in simulation activities at
staggered times. This enabled more partners to join later phases and gave us time to assist them
with any setup steps.
Internal Testing Group Group 1 Group 2 Group 3
- World Bank Carbon - American Carbon - Chile - Kengen
Asset Tracking System Registry* - Costa Rica - Energy Efficiency - Services
(CATS) - Climate Action Reserve - Japan Limited (EESL)
- Sri Lanka - Global Carbon Council** - Mexico - Global Green Growth
- Jordan - Gold Standard - Singapore Institute
- Verra - Switzerland - Eco-registry Colombia
Observers: Observers
- IETA - UNFCCC, UNFCCC ITL, African Development Bank, Asian
- Open Climate Development Bank, European Bank for Reconstruction
and Development, Inter-American Development Bank,
Singapore Exchange, CBL Markets, AirCarbon Exchange,
TMX, Climate Ledger Initiative, Climate Change Coalition,
Temasek, Intercontinental Exchange, Foundation for
Climate Protection and Carbon Offset (Klik)
*APX participated as the registry provider for ACR, CAR and Verra
**IHS MarkIT participatedasas the registry provider for GCC and Peru
Lessons Learned & Outlook
Architecture
The Warehouse aggregates project and unit data from the integrated registries and harmonizes their
source data models and schemas into a common Warehouse data model. The prototype architecture
should allow for the data integration of all participating registries in the simulation. The configuration
file enables the dynamic integration of each participating registry's data and the adjustment of data
fields and terms to harmonize all data inside the Warehouse. Such a data harmonization is important
given the heterogeneity of participating registries. Through this common data model among
participating registries, the Warehouse acts as a meta-registry that mirrors registry information,
improves robust accounting, and reduces information asymmetry. In compliance with the former
Page 23 of 38
UNFCCC leaders' statement13, the Warehouse supplements the current toolkit of climate action
measures by providing a conceptual vehicle to learn about the practical arrangements needed to
support internationally-coordinated climate markets to facilitate new alliances, agreements, and
intergovernmental efforts.
The prototype simulation 2.0 demonstrates the potential of using emerging technologies, particularly
blockchain, to support climate market processes. One notable observation is that the blockchain space,
in general, is maturing, and the technical effort to participate in blockchain-based infrastructures will
likely decrease over time. That being said, a key constraint for blockchain adoption, especially in the
context of Climate Markets, continues to be one of shared governance. As Article 6 and related guidance
is not finalized, it is important to reevaluate the current technology approach with an eye towards new
technological developments, particularly given the existence of multiple blockchain platforms and the
changing nature of converging technologies. When designing the infrastructure for the "new post-2020"
climate market mechanisms, emerging technologies are essential to consider to address present
transparency system challenges and limitations. Equally important are ensuring a direct line of sight to
the “problem to solve”, which has considerable nuance given the scope and ambition of the Paris
Agreement.
Features
Based on the data from the meta-registry, the Warehouse facilitates the surfacing and analysis of MOs
through the dashboard filter feature. This feature allows the public filtering of the relevant unit and
project information to assess unit quality, providing initial unit ratings and indications of doublecounting
risk. The prevention of double counting is essential for an effective implementation of Article 6.2, as
Parties are unilaterally required to safeguard environmental integrity through robust accounting to
ensure, inter alia, the avoidance of double counting.14 To enhance the double counting feature, the
data coverage needs to expand both horizontally and vertically. Horizontally, the Warehouse needs to
cover all existing registry systems and carbon trading systems (e.g., CORSIA15) to prevent double
claiming and double use.
Stakeholder Participation to Date
Generally, there was interestin the Warehouse project, with many stakeholders stating an interest in
participating or learning from the results. Simultaneously, there was a need to provide strong technical
partnership, while specifying the technical and data requirements for integrating the registries into the
new blockchain-based infrastructure. The Technical Guide proved a valuable resource to specify the
technical requirements for participation and facilitate the onboarding. As was found in the previous
13
Kinley et al., “Beyond Good Intentions, to Urgent Action: Former UNFCCC Lea ders Take Stock of Thirty Years of
International Climate Change Negotiations.”
14
Schneider, L.; Füssler, J.; Kohli, A.; Graichen, J.; Healy, S.; Cames, M.; Broekhoff, D.; Lazarus, M.; La Hoz Theuer,
S.; Cook, V. Robust Accounting ofInternational Transfers under Article 6 ofthe Paris Agreement; German Emissions
Trading Authority, German Environment Agency: Berlin, Germany, 2017; p. 69. Available online:
https://www.dehst.de/SharedDocs/downloads/EN/project-
mechanisms/Differences_and_commonalities_paris_agreement_discussion_paper_28092017.html.
15
More information available at: https://www.icao.int/environmental-protection/CORSIA/Pages/default.aspx
Page 24 of 38
simulation, detailed documentation enabled collaborators to onboard faster, but technical resources
need to be available during the onboarding. At the time of this interim viability report, partner
consultations were still ongoing, with a key constraint being the effort required to perform the mapping
of data from partner registries to the Warehouse data model.
At this stage, the focus of the participants remained on the technical implementation and design
choices, rather than on governance considerations and practicalities of a decentralized metaregistry
concept. With a growing number of participants and general awareness in the Article 6 ecosystem
increasing, these Warehouse governance considerations will become increasingly important. While a
decentralized architecture may seem to solve the specific challenge of connecting disparate registries,
the effort to create shared platform rules and procedures for such a concept is not insignificant.
As part of this prototype design round, the project team consulted with multiple UNFCCC teams. In
these consultations, it became evident that the Warehouse concept provides complementary
components to the existing and evolving UNFCCC systems and processes. The primary value of the
Warehouse prototype is to further joint learning by participating institutions. The Warehouse can
improve the understanding of the information flow between the present non-state actor, national, and
international transparency accounting systems to support the UNFCCC processes. At the time of this
report, the UNFCCC intended to participate in the prototype simulation 2.0 as an observer, to provide
design feedback to enhance multilateral learning.
Simulations Results for Group 1,2 & 3 Summaried Results
Group One (Internal Testing):This was carried out by our Information Techology Service VPU ( ITS), teams
that had recently facilited the build of new registers for two of our member countries. The goal of was to
leverage this group of participants to test the proposed simulation approach and process, to highlight
challenges and iron out any potential complications. The results are as follows below.
Simulation Goals
Simulation testing focused on:
• Traceability of units moving from one registry to another, so that traceability can be achieved
over disparate registry systems;
• Tracking of labels and other unit attributes as they move from one registry to another; and
• Lifecycle tracking of projects and units to ease due diligence and reporting purposes.
Results
The simulation exercises helped partners understand the data requirements from their systems.
• Data Commonalities: What the common and core data sets required to participate in the
Climate warehouse.
Page 25 of 38
• Data Gaps: Registries can use the simulation process to learn what functions and data fields
need to be added to their registry systems.
• Carbon Asset Tracking System: Tracking that will be needed to show where units are transferred
to if moved outside of CATS.
• Each registry is different, and information is tracked in different ways. It is important for
registries connecting to understand the logic needed to transform their data into the
Warehouse data model.
o Example: units taken out of circulation: the reasons for this are important for tracking
purposes, but each registry uses different terminology.
o Example: Project and unit status tracking can be very program specific. Partners need to
understand and learn how their status tracking information maps to broader categories
of tracking within the Warehouse.
Feedback on the Simulation Process
The following key feedback was documented from participants during the simulation exercise:
1. There were too many scenarios in the simulation given to participants at once. The workload
was too much for some to handle and it was difficult keeping the momentum going while hand-
holding those that needed it. Many participants did not have the time to read the amount of
material provided, so bite-sized scenarios or documents would probably be more effective. It
was also difficult to keep lengthier documents updated, in case there were mistakes or a
function needed to be redone.
2. The Collaboration Agreement was a major deterrent for participation. It took more than one
year for Chile’s legal department to authorize the agreement to be signed. Prototyping should
be a quick process, and the risk mitigation of the collaboration agreement for what little risk the
simulation posed did not equal the amount of effort on our partners’ side to get the agreement
approved.
3. Corporate collaboration platforms are not suitable for communicating with our array of
stakeholders who all have different engagement requirements. Some partners were never able
to access MS Teams. Some were not able to access embedded forms within the scripts. Future
simulations with this many people need a site that is easier to access for information, such as
theclimatewarhouse.org and a discussion forum, such as Whatsapp or an email group.
4. Participants did not engage with each other as indended through MS Teams – this could be due
to the difficulty of accessing the platform.This type of engagement could be done over
WhatsApp or potentially a slack channel or discussion forum in theClimateWarhouse.org in the
future.
5. Using an externally developed prototype that is open sourced may also make the tool more
accessible to participants and their IT departments may have more access to the computer code
to understand how the application works. If we want to share the knowledge and want others
to build on top of what we have, by sharing the code base, documentation and having an open
Page 26 of 38
API, may encourage others to build adjoining services or their own version of the Climate
Warehouse.
6. There is a need to assign specific responsibility for onboarding support to a well-resourced
organization that can work with participants to address their technical and business questions
regarding participation
Group 2 and 3 (Participant Testing): These were the groups of external participants, a mix consisting of
countries, exchanges, traders, standards agencies, and regulators, among others. The general feedback
received included:
1. The simulation provided a platform to discuss the workflow, processes and information that
need to be shared.
2. It enabled conversation on the usage of blockchain technology for auditing and traceability and
extending the boundaries of an organization’s data to reflect how the data from the entire
ecosystem could be used.
3. The participants could begin to learn how tokenized units could be reflected in the Warehouse,
and what would need to be in place to ensure traceability.
4. Participants were promptedto think outside of their current processes to reflect on how the
processes would need to evolve in the future to scale carbon markets.
5. Units transferring outside of a registry for other purposes, such as tokenizing are viewed as a
threat and an opportunity. Regardless of the usage, a system such as the warehouse could
ensure transparency of transfers, ownership and retirement/cancellation that can lead to
additional business models.
6. Most did not understand how ratings information will eventually get inputed into the
Warehouse, although all understand how useful it could be. This might be another area where a
data provider reflects information from a registry and provides the additional information from
fields that they own – such as country or a project developer.
7. From multiple country participants:
o Access to the data helped them understand what data will be needed in a registry, how
a registry will function, more about the lifecycle process of assets, and is being used for
internal capacity building.
o The Aux App shows the minimum functions needed for a registry system
o Partners did not have difficulties with the installation of docker or the prototype in their
environment. The utilization of blockchain as a service from Kaleido made the actual
technology deployment very easy for our partners and showed how their systems could
connect and build a decentralized infrastructure for data sharing in a prototype, non-
production setting.
2. Future thinking and Participate Recommendations.
The suggestions below were provided by participants for future development of the Warehouse:
Page 27 of 38
• It would be useful to have a working group on the data model and definitions, so as feedback
comes in, changes can be incorporated, and eventually pushed to the prototype.
• The next testing period should concentrate heavily (at least in the beginning) on governance,
onboarding organizations, subscribing to their data, potentially making groups of different
organizations, or working with stakeholders on the way to do this.
• Reconsider how the data from registries that is reflected in the Warehouse is partitioned. For
example, which organization owns what data updates, and potentially the ability of
organizations to only upload partial datasets for the data that they own.
• For conflicts (flaggd instances of potential double counting) the following suggestions were
provided:
o Review the types of conflicts again so that we can discern which could be data quality
issues vs. potential double counting;
o Need to test how algorithms can be based on all of the org data that is being submitted
and how can this best be shown and how can an organization best access this
information if they aren’t subscribing to all of the data; and
o Evaluate potential ways to resolve conflicts.
• Regarding reporting functionalities, future versions could add a mockup of a simple dashboardto
test out reports based on the data in the warehouse to provide examples and learn more about
reporting requirements.
Limitations
Although the second round of the Warehouse prototype development provides important insights,
there remain several limitations under which the insights need to be considered. This report is compiled
based on the experiences of the prototype development and limited participant onboarding. Therefore,
the main focus is on the technical aspects, with limited information of the participant feedback of the
actual simulation with partners.
In the second simulation round,we tested with 15 active participants including mostly country registries
and standards agencies; and with more than 15 observers from multilateral development banks and
organizations, country ministries, industry partners, exchanges, and regulators, among others. Despite
the growing number of participants, these groups do not reflect the heterogeneity of the Parties to the
Paris Agreement or the diverse groups of NSAs. These group sizes are ideal for defining initial technical
requirements but need to expand to reflect Non-Annex I countries with low technical capacities and
define Warehouse governance considerations towards decentralization and bottom-up ownership.
Despite the general feasibility of blockchain in this prototype and the rapid evolution, it remains a
nascent technology with limited use cases and little empirical data available. Most blockchain
propositions are currently only at a conceptual stage and mainly considering incremental improvements
to existing infrastructures. Blockchain may possibly enable entirely new economic and governance
models similar to the internet, and which are impossible to predict at this early stage. The Warehouse
provides valuable learning experiences to familiarize Article 6 stakeholder ecosystem with different
emerging technologies. The insights reported should only be seen in this context and not as the ultimate
technology solution, but might need multiple further iterations and different technology components
Page 28 of 38
and designs. However, the present Warehouse design provides an initial outline of technological and
governance innovation, which is desperately needed to implement an efficient bottom-up Article 6.2
market mechanism.
Figure 12 - Potential Building Blocks Needed to Further the Warehouse Concept
Warehouse Outlook
As developed, the Warehouse prototype 2.0 illustrates the concept of how heterogeneous registries can
be connected, in order to aggregate and harmonize the underlying data to enable transparent
accounting of Article 6 transfers. Looking forward, the project team identifies the expansion of partners'
horizontal and vertical integration of automatically connected and independently verified data as a key
objective to achieve this vision.
Vertical integration through digital MRV was a key area of interest during the stakeholder consultations.
The maturing of emerging technologies such as blockchain and IoT sensors holds the potential to lower
technical and financial requirements while significantly improving data quality and availability. These
developments are driven by several promising initiatives such as Open Climate 16, the Climate Ledger
Initiative 17, Digital MRV 18, and Climate TRACE. The Warehouse seeks to incorporate these
developments to enable the availability of more granular data to address the issue of double issuance
and increase the flow of data to reduce information asymmetry.
16
Wainstein, “Open Climate. Leveraging Blockchain for a Global, Transparent and Integrated Climate Accounting
System.”
17
CLI, “Navigating Blockchain and Climate Action. 2019 State and Trends,” Climate Ledger Initiative, no. December
(2019): 72, https://www.climateledger.org/en/News.3.html?nid=33.
18
More information available at: https://www.digitalmrv.earth/
Page 29 of 38
Figure 13 - The Nested Digital MRV Concept (Courtesy of Open Earth Foundation)
As part of the stakeholder consultations, it also became evident that certain countries lack the
infrastructure and know-how to set up and run a national registry system. For these countries, the
current Article 6.2 negotiation text19 proposes implementing an "international registry for participating
Parties that do not have a registry or have access to a registry." The current Aux App already provides
the features to enable participants to collect and modify their data. In this way, the Aux App and the
possible integration of digital MRV processes could together demonstrate capability that enables Parties
currently lacking registry infrastructure to adopt a new system with lower technical requirements. This is
an area for further exploration outside of the Lab, as the Aux App represents a demonstrative, limited
view of what is eventually possible.
Horizontal integration can be pursued by connecting with additional interested partners and existing
carbon markets. At present, there exists a considerable number of fragmented systems. There are 57
existing carbon pricing initiatives, with 96 Parties planning or considering carbon pricing 20, as well as the
Kyoto market mechanisms and NSA systems like, for example, CORSIA. Connecting these systems is
critical to prevent the risk of double claiming and double use when the same MO is included in multiple
fragmented market and accounting systems.
By aggregating all MO information in one platform, the Warehouse concept can facilitate the
matchmaking between ITMO buyers and sellers by facilitating the expression of transfer interests. The
aggregation of ITMOs in one pool can significantly increase the visibility of ITMO transfer interests, as
currently, transfers are dependent on individual connections between interested actors. To support the
transfer process, the Warehouse prototype developed the idea of an "intention ticket feature" that
compiles the transfer-relevant information and leads the trade participants to a third-party trading
19
UNFCCC. (2019). Draft CMA decision on guidance on cooperative approaches referred to in Article 6, paragraph
2, of the Paris Agreement. DT.CMA2.I11a.V3, 12, 1–31. Retrieved from https://unfccc.int/documents/204687
20
World Bank Group. (2019). State and Trends of Carbon Pricing 2019. State and Trends of Carbon Pricing 2019.
Washington, DC: © World Bank. https://doi.org/10.1596/978-1-4648-1435-8
Page 30 of 38
platform provider to conduct and settle the ITMO trade. This feature is currently not fully developed but
could become relevant in future iterations based on participant feedback.
The Warehouse further seeks to develop UNFCCC reporting features that facilitate the reporting of all
ITMO transfers conducted. Parties participating in Article 6.2 are required to report the following
information 21:
"29. Each participating Party shall include the following annual information report, consistent
with chapter III.B above (Application of corresponding adjustments), in each biennial
transparency report submitted pursuant to decision 18/CMA.1, and in the Article 6 database
and shall include any updates to information submitted for previous years in the NDC
implementation period:
(a) Annual and cumulative emissions and removals [from the sectors and greenhouse gases]
covered by its NDC;
(b) Annual and cumulative quantity of ITMOs first transferred;
(c) [Annual and cumulative quantity of mitigation outcomes authorized for use, for other
international mitigation purposes;]
(d) Annual and cumulative quantity of ITMOs used towards its NDC […]"
For this, the Warehouse concept could provide each Party with a reporting function that allows for the
filtering and analyzing of all respective transfers conducted and export them as common reporting
format tables 22, which summarize quantitative information on GHG emissions and removals.
The automatic synchronization of registries through the Auxillary App with the Warehouse could
potentially reduce information asymmetry and enable closer to real-time tracking of MOs and ITMOs.
This would be a significant improvement compared to the current reporting system to keep track of the
global climate action developments. Currently, reporting is dependent on the national biennial
transparency report (submitted by all Parties no later than 31 December 2024, every two years) and the
global stock-take (after 2023, every five years) reporting 23, which leads to significant feedback delays in
the assessment of the global emission trajectory. However, a key challenge is – and will remain – the
ability of stakeholders to work through practical issues of data mapping.
21
UNFCCC. 2019. “Draft CMA Decision on Guidance on Cooperative Approaches R eferred to in Article 6, Paragraph
2, of the Paris Agreement.” DT.CMA2.I11a.V3 12: 1–31. Available online: https://unfccc.int/documents/204687.
22
Rocha, Marcia. 2019. “Reporting Tables-Potential Areas of Work under SBSTA and Options Part I-GHG
Inventories and Tracking Progress towards NDCs.” Climate Change Expert Group Paper No. 2019(1) 2019.
www.oecd.org/environment/cc/ccxg.htm.
23
Further informatino available at: https://unfccc.int/enhanced-transparency-framework#eq-10
Page 31 of 38
Figure 14 - Warehouse Context - Future Directions
Appendix I: Contributors
Project Sponsors & Unit
• Chandra Shekhar Lead, Climate Change Group(SCCDR)
• Keisuke Iyadomi, Carbon Markets & Innovation
• Susan David Carevic, Carbon Markets & Innovation
• Rachel Chi Kiu Mok, Carbon Markets & Innovation
• Gemma Torras Vives, Carbon Markets & Innovation
• Lucas Gregory Belenky, Carbon Markets & Innovation
Project Technical Team
• Stela Mocan, Business Lead, ITS Technology & Innovation Lab
• Olushola Joanne Ibironke Martins, Business Lead, ITS Technology & Innovation Lab
• Yusuf Karacaoglu, Technical Sponsor, Technology & Innovation Lab
• Emmanuel Ayanfe Crown, Technical Co-Lead, ITS Technology & Innovation Lab
• Mert Ozdag, Technical Co-Lead, ITS Technology & Innovation Lab
• Yujuan (Sunny) Sun, ITS Technology & Innovation Lab
Page 32 of 38
•Reina Lemorchan Ntonifor, ITS Technology & Innovation Lab
•Ani Popiashvili, ITS Technology & Innovation Lab
•Hussain Alkazemi, World Bank Digital Development Global Practice
•Rachel Alexandra Halsema, ITS Technology & Innovation Lab
•Patricia Miranda, World Bank Legal
Community Design & Technical Experts
• Martin Wainstein, Open Earth Foundation
• Marco Schletz, UNEP DTU Partnership
• Ritesh Sanan, ITS Rapid Development
• Soumalya De, ITS Rapid Development
• Greg Robberechts, ITS Business & General Services
• Atul Gupte, ITS Business & General Services
Sponsor Organizations and External Collaborators
World Bank Carbon Markets and Innovation
Aligned with the overall World Bank Group's approach, the Carbon Markets and Innovation (CMI) team's
strategy emphasizes the need to enhance global ambition by advocating policies and measures that
facilitate the development of carbon markets and pricing, build the capacity to design and develop those
markets, and mobilize capital for resilient and low-carbon growth.
ITS Technology & Innovation Lab
Since 2017, the World Bank Group ITS Technology & Innovation Lab has explored, experimented with
and provided technology advisory around emerging technologies' potential for innovative problem-
solving, and operationalization approaches in WBG internal and external operations. The Lab serves as a
catalyst, enabler and accelerator for WBG staff to learn about and build expertise around emerging
technologies' potential to support the WBG development agenda. We operate as a rapid prototyping
and learning hub, where we experiment with emerging technologies' capabilities to understand their
applicability to address development challenges, along with scaling and operationalization approach in
both our internal and external operations. The Lab collaborates with staff and engages with internal and
external partners to foster a "learning by doing" modus operandi.
Open Earth Foundation
About the Open Earth Foundation: The Open Earth Foundation is a research and deployment nonprofit
using cutting-edge digital technologies and multi-stakeholder collaborations to advance open source
platforms that help increase planetary resilience. One of its core projects, Open Climate, is focused on
the design and development of a digitally integrated climate accounting system.
Technical University of Berlin & UNEP DTU Partnership
TU Berlin has a long and rich tradition and is recognized globally as an excellent research university. The
TIM research group, established in 1999 and has grown to become the nucleus of Germany's most
extensive Technology and Innovation Management research environment.
UNEP DTU Partnership (UDP) is a leading international research and advisory institution on energy,
climate, and sustainable development. UDP was established in 1990 and operates under a tripartite
Page 33 of 38
agreement between the Ministry of Foreign Affairs of Denmark, the Technical University of Denmark
(DTU), and the UN Environment (UNEP).
Page 34 of 38
Appendix II: World Economic Forum Framework
As part of its exploration, ITSTI leveraged the World Economic Forum's blockchain framework:
http://www3.weforum.org/docs/WEF_Building_Value_with_Blockchain.pdf
Page 35 of 38
Appendix III: Acronyms & Key Definitions
Acronym Definition
API Application programing interface
BTR Biennial Transparency Report
BUR Biennial Update Report
CDM Clean Development Mechanism
CER Certified Emission Reduction
CMI World Bank Carbon Markets and Innovation Team
DLT Distributed Ledger Technology
ETS Emissions Trading System
GST Global Stocktake
GHG Greenhouse Gas
IoT Internet of Things
ITL International Transaction Log
ITMOs Internationally Transferred Mitigation Outcomes
ITSTI World Bank Information Technology Services, Technology and Innovation Lab
LDC Least Developed Countries
LoA Letter of Authorization
MDB Multilateral Development Bank
MO Mitigation outcome
MRV Measurement, reporting, and verification
NDC Nationally Determined Contributions
OECD Organization for Economic Cooperation and Development
SIDS Small Island Developing States
TERT Technical Expert Review Team
UN United Nations
UNFCCC United Nations Framework Convention on Climate Change
WEF World Economic Forum
Page 36 of 38
Key Definitions Global Stocktake (GST)
Article 14 of the Paris Agreement requires the
Nationally Determined Contribution (NDC) CMA to periodically take stock of the
Embody efforts by each country to reduce implementation of the Paris Agreement and to
national emissions and adapt to the impacts of assess collective progress towards achieving
climate change. The Paris Agreement (Article the purpose of the Agreement and its long-
4, paragraph 2) requires each Party to prepare, term goals.
communicate and maintain successive
nationally determined contributions (NDCs) Greenhouse Gases (GHG)
that it intends to achieve. Greenhouse gases are those gaseous
constituents of the atmosphere, both natural
Mitigation Outcome (MO) and anthropogenic, that absorb and emit
The unit in which national Parties document radiation at specific wavelengths within the
their mitigation activities towards their Paris spectrum of thermal infrared radiation emitted
Agreement NDC. by the Earth's surface, the atmosphere itself,
and by clouds.
Internationally Transferred Mitigation
Outcome (ITMO) Clean Development Mechanism (CDM)
MOs can be transformed into ITMOS Under the Clean Development Mechanism,
(“internationally transferred mitigation emission-reduction projects in developing
outcomes”) if they are transferred under countries can earn certified emission reduction
Article 6.2 to another national Party. If they are credits. These saleable credits can be used by
transferred under Article 6.4, they would be industrialized countries to meet a part of their
called A6.4ER. emission reduction targets under the Kyoto
Protocol.
Biennial Transparency Report (BTR)
Parties’ progress in the implementation and Emissions Trading System (ETS)
achievement of its NDC is tracked through In an emissions trading scheme (ETS), a
submission of the national BTR, including regulator defines an upper limit (cap) of
through a structured summary of information. greenhouse gas (GHG) emissions that may be
emitted in clearly defined sectors of an
Biennial Update Report (BUR) economy (scope and coverage). Emission
BURs are reports to be submitted by non- permits or allowances are given out or sold
Annex I Parties, containing updates of national (allocated) to the entities that are included in
Greenhouse Gas (GHG) inventories, including a the ETS.
national inventory report and information on
mitigation actions, needs and support Letter of Authorization (LoA)
received. Reporting of the BR/BUR under the Domestic legal instrument for the direct
Convention will be superseded by reporting of authorization of Non-State Actors. Under
the biennial transparency report (BTR) for PA Article 6, each transfer of emission reductions
Parties. must be approved through an LoA, which offer
the opportunity for countries to share with, or
even shift, the reporting requirements to
proponents.
Page 0 of 38
Project Small Island Developing States (SIDS)
Greenhouse-gas emission reduction or 38 states characterized by remoteness, narrow
removal projects developed and implemented resource and export base, and exposure to
by private actor (Non-State Actor - NSA), global environmental challenges and external
generating Article 6 emission reduction units, economic shocks, including to a large range of
and authorized through Letters of impacts from climate.
Authorization by national Parties.
Least Developed Countries (LDC)
Unit The 49 Parties classified as least developed
The unit of 6.4 is called A6.4ER (ER= Emission countries (LDCs) by the United Nations are
Reductions). These are issued by the given special consideration under the
“Supervisory Body”. The unit of Art6.2 is called Convention on account of their limited
an ITMO. It is likely that there will be at least capacity to respond to climate change and
two different metrics under 6.2; tCO2e for adapt to its adverse effects.
GHG emissions and non-GHG metric (for e.g.
energy efficiency or renewable energy targets).
Technical Expert Review Team (TERT)
The TERT assesses BTR and drafts technical
review report.
Article 6 Database
Enables recording of corresponding
adjustments and adjusted emissions balances
for and information on ITMOs first transferred,
transferred, acquired, held, cancelled, etc.
Non-Annex I Parties
Non-Annex I Parties are mostly developing
countries. Certain groups of developing
countries are recognized by the Convention as
being especially vulnerable to the adverse
impacts of climate change, including countries
with low-lying coastal areas and those prone to
desertification and drought.
Annex I Parties
Includes members of the OECD as well as
economies in transition. Annex I countries are
subject to additional obligations under the
UNFCCC, obliging them to take the lead in
combating climate change.
Page 1 of 38