Summary Report: Simulation on Connecting Climate Market Systems Copyright © 2019 International Bank for Reconstruction and Development / The World Bank 1818 H Street NW, Washington DC 20433 Telephone: 202-473-1000 Internet: www.worldbank.org This work is a product of the staff of The World Bank with external contributions. The findings, interpretations, and conclusions expressed in this work do not necessarily reflect the views of The World Bank, its Board of Executive Directors, or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Rights and Permissions The material in this work is subject to copyright. Because The World Bank encourages dissemination of its knowledge, this work may be reproduced, in whole or in part, for noncommercial purposes as long as full attribution to this work is given Attribution Please cite the work as follows: The World Bank, “Summary Report: Simulation on Connecting Climate Market Systems,” by The World Bank, Washington, DC. Any queries on rights and licenses, including subsidiary rights, should be addressed to World Bank Publications, The World Bank Group, 1818 H Street NW, Washington, DC 20433, USA; e-mail: pubrights@worldbank.org Acknowledgements The simulation was jointly supported by the World Bank ITS Technology and Innovation (ITSTI) Lab and the Carbon Markets and Innovation Practice (CMI). The team from the ITSTI Lab included (in alphabetical order): Hussain A. Alkazemi, Susan David Carevic, Rachel Halsema, Mahesh Chandrahas Karajgi, Stela Mocan, and Mert Ozdag. The team from SCCMI included: Harikumar Gadde, Seoyi Kim, Rachel Mok, Stephanie Rogers, Florencia Leticia Sanchez Zunino, Chandra Shekhar Sinha, Sandhya Srinivasan, and Kensuke Suda. Patricia Miranda provided legal counsel. We would like to thank the following organizations and persons who collaborated with the World Bank on this simulation exercise and provided feedback incorporated in this report. Without their support this simulation would not have been possible: Ministry of Energy, Government of Chile: Francisco Dall’Orso León, Cristián Mosella, and Juan Pedro Searle; SGLMS: Javiera Silva Arroyo, Linco Ñanco Mercado, and Jaime C. Rubin-de-Celis; Ministry of the Environment, Government of Japan: Masayuki Fujioka, Kazuhisa Koakutsu; JCM Secretariat: Takayuki Ishikawa; The Gold Standard Foundation: Keith Black and Owen Hewlett; Verra: Sam Hoffer and Anna Mortimer. Page 1 of 10 SECTION 1 – Objectives and Rationale 1. Context The Paris Agreement introduced a bottom-up approach for addressing climate change by enabling countries to pledge individual commitments through nationally determined contributions (NDCs). Furthermore, Article 6 of the Paris Agreement recognizes that Parties may engage in bilateral cooperative approaches, including through the use of internationally transferred mitigation outcomes (ITMOs), to achieve their NDCs. Heterogeneous climate markets may have different governance systems and technological approaches. Information about mitigation outcomes (MOs) or emission reductions is currently collected in a variety of repositories, including spreadsheets and registries, with different levels of information. The differences in these processes may constrain market integration and add to the complexity of tracking and recording transactions. Against this backdrop, there is a need to create a new architecture to support transparency and enhance the tradability of climate assets across jurisdictions while ensuring the integrity of trades. The Kyoto Protocol utilized an International Transaction Log (ITL), operated by the United Nations Framework Convention on Climate Change (UNFCCC), to facilitate communication between registries and maintain a transaction log to ensure accurate accounting and verification of transactions proposed by connected registries. However, under the Paris Agreement, which may rely on a decentralized approach to markets under Article 6.2, climate negotiators are still determining whether a centralized infrastructure should continue, the functions it could perform, and to which market mechanisms or transactions it would apply. Consistent with the bottom-up ethos of the Paris Agreement, there is value in demonstrating an approach to link registry systems in a peer-to-peer arrangement. 2. Climate Warehouse Vision The World Bank’s Carbon Markets and Innovation team (CMI) has a mandate to pilot options to contribute to the understanding of the opportunities of Article 6 and build client capacities to engage in the next generation of climate markets. As part of this mandate, CMI is exploring a Climate Warehouse ecosystem to demonstrate a decentralized information technology approach to connect climate market systems. In the Climate Warehouse ecosystem, a meta-registry system would connect to country, regional, and institutional databases and registries to surface publicly-available information on MOs and record status changes to provide information on how MOs are used. The objective of this meta-registry would be to reduce double counting risks1 by enhancing transparency and 1 While negotiations are still ongoing, according to the International Emissions Trading Association, double counting in the context of Article 6 could mean double claiming, double issuance, double registration, and double use. Double claiming occurs if the same unit is used by more than one Party to achieve their mitigation pledges. Double issuance occurs if more than one unit is issued for the same emission reductions. Double registration means that the same unit is registered under more than one mechanism. Double use occurs when a unit has been used more than once towards achieving a Party’s mitigation pledge. International Emissions Trading Association, Double counting in the Paris Agreement (2018), available at: https://www.ieta.org/resources/Aviation/IETA%20IATA%20Workshop%2024%20July%202018/IETA%20Stefano- Session%203%20Item%20B%20Double%20Counting.pdf Page 2 of 10 trust among market participants and tracking MOs across jurisdictions. Figure 1, below, depicts how national registries and databases could surface information in a Climate Warehouse meta-registry. Figure 1: Climate Warehouse Ecosystem 3. Objectives of the Simulation CMI partnered with the World Bank’s Information Technology Services Technology and Innovation (ITSTI) Lab to explore how emerging technologies, such as blockchain, can be used to develop the Climate Warehouse meta- registry and to demonstrate the technical feasibility of the concept. From August to November 2019, CMI and ITSTI implemented a simulation of the meta-registry to test how registry systems can be connected in a peer-to- peer arrangement2 using blockchain technology and how information changes in the meta-registry could potentially be used to track MOs to avoid double counting. 4. Rationale for the Application of Blockchain to the Meta-Registry Blockchain is a decentralized, distributed digital ledger that records information across many computers so that no record can be altered retroactively without the alteration of all subsequent blocks. The World Bank published a report on blockchain and climate markets in March 20183 and conducted internal testing to examine the potential and viability of using blockchain to build the Climate Warehouse meta-registry. The World Bank’s 2 A peer-to-peer arrangement occurs when two or more systems are connected with each other without the use of an intermediary. The accumulative and immutable nature of the blockchain enables multiple parties to securely connect their systems directly without a central “trusted” authority. 3 World Bank Group, Blockchain and Emerging Digital Technologies for Enhancing Post-2020 Climate Markets (2018), available at: https://openknowledge.worldbank.org/handle/10986/29499 Page 3 of 10 analyses demonstrated that blockchain has the capabilities to simplify data sharing among diverse registries using different technology approaches. The decentralized and immutable nature of the system also provides resilience against attacks and confidence that information has not been tampered. In doing so, MOs can be traceable from their origin to their eventual retirement. Furthermore, the peer-to-peer arrangement gives participating entities the flexibility to interact through their own blockchain node4 and manage their access rights based on their own requirements and institutional framework. However, the analyses suggested that blockchain is not a suitable repository for storing large amounts of attribute information about climate actions. More extensive information, such as audit reports and detailed project information, should reside within a different type of data storage component. Furthermore, blockchain by itself does not assure data quality or integrity, and data entering the system needs independent quality assurance to ensure that it is reputable before entering the system. There should be processes and governance in place that dictate the format of information and its flow into the meta-registry. However, if duplication, error, or fraudulent action does occur, at the very least, blockchain provides a record of the occurrence, and corrections will be fully traceable and auditable among participating parties of the connected registry systems. 5. Architecture The Climate Warehouse is an umbrella platform for countries and institutions to surface information on their mitigation activities and assets, referred to as MOs. The Climate Warehouse is a hybrid solution, comprised of (1) decentralized blockchain storage and (2) centralized services to support a responsive user interface and the ability for participants to upload data. Participants connect to the Climate Warehouse to share data either by hosting a node, through application programming interface (API), or by uploading data through spreadsheets or manual entry. Once data is shared by a partner, the Warehouse stores the data on the blockchain for full transparency. The storage of data on the blockchain allows users to record and track changes to the data over time. For the simulation, the prototyped Warehouse stores data on a blockchain implemented as a private permissioned Ethereum network which uses a Proof of Authority (PoA) consensus algorithm.5 Further details on the architecture is provided in the Appendix. 4 According to Deloitte, Distributed Ledger Technology (blockchain) is defined as a type of database that is spread across multiple sites, countries, or institutions. It is decentralized in nature, eliminating the need for an intermediary to process, validate, or authenticate transactions. Each party (e.g., individual, organization, or group) is represented by their computer, called a node, on the network. Each node keeps its own copy of all transactions on the network, and nodes work directly with one another to check a new transaction’s valid ity through a process called consensus. Each of these transactions is encrypted and sent to every node on the network to be verified and grouped into time-stamped blocks of transactions. Deloitte Consulting Pte. Ltd., The future is here: Project Ubin: SGD on Distributed Ledger (2017), available at: https://www2.deloitte.com/content/dam/Deloitte/sg/Documents/financial-services/sg-fsi-project-ubin-report.pdf 5 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. Organisation for Economic Co-operation and Development, OECD Blockchain Primer (2018), available at: https://www.oecd.org/finance/OECD-Blockchain-Primer.pdf Page 4 of 10 a. Functionalities and Assumptions The meta-registry prototype allowed users to add project and unit information via data entry, file upload, API, or node integration; update project and unit information; and search for information. Per the screenshot in Figure 2 below, the meta-registry surfaces publicly available information from registries, and consists of three panels: (1) filtering, (2) project information, and (3) associated unit information. The filtering is dynamic and values listed reflect project and unit information stored in the meta-registry. The meta-registry surfaces publicly available information from registries. Because blockchain is not a suitable repository for storing large amounts of information, the data fields reflecting project and unit information were limited to 26 fields.6 Some data fields, such as “Covered by NDC” and “Authorization Letter for Transfer,” reflect information that is expected to be required under the Paris Agreement, but the participants’ registry systems do not currently collect this data. Other data fields reflect fields that are commonly included in existing registries. Part of the simulation was to receive feedback on the proposed data fields. Figure 2: Screenshot Showing Project and Unit Information The following assumptions were made for the Climate Warehouse architecture: • The data in the Climate Warehouse meta-registry will be only public data surfaced by the participants; • The data fields in the meta-registry will be limited and facilitate search and filtering, traceability and audit functions; and • Each organization surfacing information has detailed publicly available information about their projects and issuances in their registry, which is reachable via links from the meta-registry. 6 The Appendix contains a list of the data fields included in the prototyped meta-registry. Page 5 of 10 SECTION 2 – Climate Warehouse Simulation Experience 6. Meta-Registry Simulation a. Simulation Participants CMI discussed the concept of the simulation with 16 potential collaborators, including 8 national governments. While all potential collaborators expressed interest in participating in the simulation, not all groups were able to participate in the given timeframe of the simulation. Four participants agreed to collaborate on this phase of the simulation, including two governments and two non-governmental, standards-setting organizations: (a) Government of Chile, Ministry of Energy; (b) Government of Japan, Ministry of the Environment; (c) The Gold Standard Foundation; and (d) Verra. b. Onboarding Process Simulation participants signed a uniform Collaboration Agreement in support of the simulation. On average, collaborators required a month of time to review, obtain internal clearances, and sign the Agreement. The Climate Warehouse prototype simulated the integration of registries or databases via different integration options. Participants chose the approach that worked best for them to test the simulation and integrate their data on MOs within the simulation time period. Three out of four participants chose to use the Excel integration option, which involved uploading an Excel file with pre-defined columns and values for project and unit-related data. One participant participated in the blockchain network by introducing its own Ethereum node. Participants agreed to have staff available to support the simulation exercise. During the simulation, the ITSTI Lab provided training and technical support on the use of the prototype. The level of support varied depending on participants’ capacity. Participants were provided with a testing script7 to guide them through the Warehouse functionality so that each participant tested out every feature. Upon completion of the simulation, participants were asked to fill out a questionnaire on their experience and feedback was further discussed in teleconferences. The World Bank shared a use case viability report with participants to describe key lessons learned. c. Limitations • The entire simulation, including drafting and signing of collaboration agreements, was limited to a 12-week time period.8 The actual simulation with participants took place over two weeks. • Ideally, all participants would opt for a system-based integration to maximize learning and provide hands-on experience on what it takes to participate in a blockchain-based system. However, given the limited timeframe, only one participant opted to test the node integration. • Information surfaced into the Climate Warehouse was a combination of active and historical records. Bulk uploads performed by collaborators did not mimic the number of transactions that would take place in an 7 The script contained the minimal steps that the ITSTI Lab asked partners to complete in the simulation to test out the functionalities of the Climate Warehouse. 8 The time period was limited to 12 weeks to provide quick learning and receive initial feedback from partners before further piloting. Page 6 of 10 operational setting, in which the volume of transactions over time would likely be smaller. In the future, the Climate Warehouse is expected to receive bulk uploads during onboarding of participants and a lower flow of transactions once the upload of the legacy data in the registries had been completed. • Integration with participants during the simulation was only to surface data into the Climate Warehouse. Participants did not build integrations to sync record changes into their own systems. • The focus of the simulation was to test a blockchain-based approach to a Climate Warehouse with a focus on understanding the onboarding process to a common data model for a Climate Warehouse. The simulation therefore did not address the suitability of potentially complementary technologies, such as artificial intelligence and machine learning, that could play a role in identifying potential duplicate data and provide visual representations of the data. SECTION 3 – Simulation Outcomes The assumptions and evaluation results from the simulation are listed in the table below: Assumptions Evaluation Results The architecture provides a means to During the simulation, participants were able to integrate four different simplify integration between dispersed registry systems together over a 1.5-week time period, demonstrating how climate market systems. different systems can be accommodated. The data shared within the Climate For the purpose of the meta-registry, all participants agreed on the benefits Warehouse can and should be made and usage of public data. In future phases to support transactional processes, publicly available. the team learned that privacy for buyers and sellers will be important. For example, the General Data Protection Regulation (GDPR) of the EU requires that digital systems obtain consent from system users on how their data will be utilized and shared. The Warehouse will need to provide control to participants to determine what information they want shared or made publicly available, and how this data will be used. A simple data model that supports a The simulation showed that there needs to be agreement on data fields, but variety of unit types, methodologies, defined fields can support the variety of assets types needed. and other field types can provide the flexibility needed to support bottom-up cooperation under Article 6. It will be possible for a variety of Through active support and capacity building, one partner was able to participants to host a blockchain node establish a node and integration between the node and their registry system. and develop code to build This required learning and collaboration with an engineer with blockchain communication channels between their expertise. The node and integration were established within three days. registry system and their own hosted node. Utilizing blockchain technology and a All participants agreed that blockchain technology provided the visibility and searchable database will provide audit processes needed for climate units. However, the simulation did not backbone architecture that can support provide any data checks to ensure against double reporting of projects and transparency, audit trails, and control their climate units. These checks were out of scope for this simulation. These over the lifecycle of climate units from supplementary features would increase the utility of the Climate Warehouse issuance to their eventual retirement and would need to be sequenced into future development phases. against a country’s nationally determined contribution. Page 7 of 10 It was also suggested through participant feedback that participation in the meta-registry provides visibility on the international stage for countries to showcase their climate initiatives. This can open countries to new networks that can assist them with capacity building and help to identify partners for cooperation and transactions. Table 1: Simulation Evaluation Results 7. Lessons Learned and Potential Next Steps Key lessons learned from the simulation are: • The Climate Warehouse decentralized meta-registry system can provide an inclusive platform to connect different country and institutional registry systems and can support much-needed visibility to climate activities and enhance transparency of overall market activity. • 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 an operational Climate Warehouse meta-registry. • The system should support 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 audit and lifecycle information for climate projects and units. • Enough time needs to be allocated to onboard participants. This includes putting legal agreements in place and for participants to coordinate internal resources, such as information technology staff or consultants needed to integrate systems and test functionalities. • All participants indicated interest in participating in possible further development phases, including potentially hosting a node to connect with the Climate Warehouse in the future, given adequate time and resources. Feedback received from the simulation partners is being reviewed to inform the future direction of the Climate Warehouse. Moving forward, the CMI team intends to engage with additional partners to gain further experience and learning. Issues that will be further explored include what data should be included in the meta- registry, whether complementary technologies such as artificial intelligence and machine learning can be applied to identify data discrepancies, and what governance, privacy, and security requirements should apply. Continuing negotiations on Article 6 mean that focused piloting efforts are more important than ever. The World Bank is well-placed to demonstrate innovative solutions to address key challenges and build client capacities through collaborative pilots. Building on this successful simulation, the World Bank will facilitate regular exchange with governments, non-governmental standards setting organizations, the private sector, and other expert groups to explore opportunities to leverage emerging technologies for post-2020 climate markets. Learn more about the Climate Warehouse at: www.worldbank.org/en/programs/climate-warehouse. Page 8 of 10 Appendix 1. Meta-Registry Data Fields Figure 3, below, depicts the architectural components utilized to build the Climate Warehouse meta-registry. Figure 3: Climate Warehouse Simulation Architecture The green box within the diagram shows the blockchain network. This network was created using Azure cloud services and consists of 2 sealing (voting) nodes and 1 transaction node. All nodes within this network are part of a virtual network. Participants integrating using blockchain nodes connect to the network through a Virtual Private Network (VPN) through a VPN gateway. The participant nodes are shown in the red square and connected via the gateways. On the right side of the diagram, the Azure Key Vault in the diagram is a component used to securely store participant private keys for those who integrated with the Climate Warehouse through the API, web and excel integrations. The Blockchain Service is a component service that signs blockchain transactions9 and submits them to the transaction node. This service is only used for climate information manually entered into the user interface or uploaded via an excel file. The Message Queue is used by the Application Programing Interface (API) service and the blockchain service. This service orders the information that will be added to the blockchain sequentially. Utilizing this service 9 This does not refer to carbon market transactions, but blockchain transactions. Each transaction refers to data additions on the blockchain. Page 9 of 10 reduces the dependency between services and enables the usage of additional Blockchain Services in case the solution needs to be scaled up. The Warehouse API Service provides the backend for the web application interface. It can also be used by participants who want to use API integration for integrating their system via an API. This service handles authentication, retrieving and filtering data from the database and sends information to the message queue. The database in the diagram is a NoSQL database, used to cache the climate data in the system, and supports fast filtering and reporting analytics. Lastly, the Contract Watcher Service is used to copy the information sent to the blockchain into the database, in essence caching the data records on the blockchain to speed up data retrieval and analytics. 2. Meta-Registry Data Fields Data Field Definition Project information Current Registry (X) Current Registry for the project Registry of Origin Source of project record / what database or registry from which it surfaced Project ID (X) ID number provided to project from origin registry or database Project Name (X) Name of Project Project Entities Companies, organizations or other entities involved with the project; entity responsible for all communication Project Type Sub-category within a sector Estimated Annual ERs Estimated MOs a project will produce annually once it is operational Country (X) Country where project is being implemented Location Location where project is being implemented Sector (X) Sector Project Status (X) Current stage or status of a project implementation (under development, rated, validated, operational, cancelled, verified, closed) Project Link URL value of project information from origin database Unit Information Amount of Issued Units Number of emission reductions issued for the reporting period / vintage Unit Measure Unit of measure for units issued; most likely tCO2e Unit Type Type of MO, such as a CER (Certified Emission Reduction) Vintage Start This is the beginning of the auditing / monitoring period Vintage End This is the end of the auditing / monitoring period Serial Number Block Standard serial number block assigned to units issued Unit Status Date Date the status of a block of units was updated Unit Status Current status of a block of units Methodology MRV methodology used to determine number of units a project produces Standard Version Methodology version number used during the audit Verification Date Date the units were certified (date on report) Additional Assessment URL of page where project info on benchmark is available, i.e., Mitigation Action Assessment Protocol, SDVista, SustainCERT, etc. Covered by NDC If unit is linked to a country’s NDCs, show type Authorization Letter for Indication of whether the country has issued a letter of authorization for transfer Transfer Table 1: Data Dictionary used for the simulation. [Note: “X” refers to required data fields] Page 10 of 10