Climate Warehouse Simulation III FINAL REPORT | SEPTEMBER 2022 ACKNOWLEDGEMENTS DISCLAIMER This report was prepared by Gen Shiraishi, Gemma Torras © 2022 The World Bank Vives, Lucas Belenky, Chandra Shekhar Sinha, Harikumar 1818 H Street NW, Washington, DC 20433 Gadde, and Seoyi Kim of the World Bank’s Carbon Markets and Phone number: +1-202-473-1000 Innovation unit, under the leadership of Wendy Hughes and Website: www.worldbank.org Venkata Ramana Putti, with support from the Partnership for Market Implementation Facility. This work is a product of the staff of The World Bank with external contributions. The findings, interpretations, and The underlying technology system of the Climate Warehouse conclusions expressed in this work do not necessarily reflect Simulation III prototype was developed by the Chia Network. the views of The World Bank, its Board of Executive Directors, The core team included Niel Cohn, Ken Griggs, Craig Cornick, or the governments they represent. Lars Kvale, Bram Cohen, Gene Hoffman, and Vishal Kapoor. The World Bank does not guarantee the accuracy of the data In addition, special thanks to the support of the governments of included in this work. The boundaries, colors, denominations, Spain, Sweden, and Switzerland, as well as the government of and other information shown on any map in this work do not Singapore and the International Emissions Trading Association imply any judgment on the part of The World Bank concerning (IETA) for their active engagement in moving forward the Climate the legal status of any territory or the endorsement or Warehouse initiative. Further, thank you to Susan David Carevic acceptance of such boundaries. and the Information and Technology Solutions Technology and Innovation Lab team at the World Bank, including Stela Mocan, RIGHTS AND PERMISSIONS Rachel Alexandra Halsema, Olushola Ibironke Joanne Martins, The material in this work is subject to copyright. Because The Mert Ozdag, Yujuan Sun, and Mahesh Chandrahas Karajdi, all of World Bank encourages dissemination of its knowledge, this whom supported the Climate Warehouse initiative throughout work may be reproduced, in whole or in part, for noncommercial this and previous simulations. purposes as long as full attribution to this work is given. The following organizations contributed as participants and Attribution – Please cite the work as follows: observers of the Climate Warehouse Simulation III: World Bank. 2022. Climate Warehouse Simulation III Final • National governments: Chile, Japan, Peru, Rwanda, Report. World Bank, Washington, DC. Senegal, Singapore, Spain, Sweden, Switzerland, Uganda, and United Kingdom. All queries on rights and licenses should be addressed to the • Independent standards: American Carbon Registry, Publishing and Knowledge Division, The World Bank, 1818 H Climate Action Reserve, Global Carbon Council, Gold Street NW, Washington, DC 20433, USA; fax: 202-522-2625; Standard, and Verra. email: pubrights@worldbank.org. • Multilateral organizations: European Bank for Reconstruction and Development, International Finance Editing and design by Clarity Global Strategic Communications Corporation, United Nations Development Programme, (www.clarityglobal.net). United Nations Framework Convention on Climate Change, World Bank Carbon Assets Tracking System, and World Bank Carbon Markets and Innovation unit. • Other public and private carbon market stakeholders: Climate Ledger Initiative, ClimateCheck, EcoRegistry Colombia, IHS Markit, IETA, Open Earth Foundation, SK Certification Center, and Temasek. I | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT ABO UT T H IS R E PO RT About this report The purpose of this report is to provide detailed documentation on the context, design, and outcomes of the Climate Warehouse Simulation III, in order to contribute to the Climate Warehouse’s ongoing development as a carbon metadata layer and support the new governing body’s efforts to launch the operational Climate Warehouse. Section 1 of the report provides an executive summary of Simulation III’s project context, design, and outcomes. Section 2 describes the key elements of Simulation III’s project context, including the Paris Agreement framework, findings from previous Climate Warehouse simulations, and the Climate Warehouse’s use of blockchain technology. Section 3 details the key features of the Simulation III prototype, which include the technical architecture, technical requirements, and user interface. Section 4 summarizes Simulation III’s testing approach, including the testing timeline, list of participants, testing areas, deployment models, testing process, technical support, feedback management strategy, and prototype maintenance and development process. Section 5 presents summary statistics on Simulation III participants, including the number of participating organizations and testers by group, breakdown of testers by role and selected deployment model, and number of testers who completed each testing area. Section 6 details participants’ feedback on the Climate Warehouse by each of Simulation III’s 11 feedback categories. Section 7 outlines the lessons learned from each of the same feedback categories, summarizes Simulation III’s limitations, and details the testing and simulation team’s recommendations for the new governing body. Section 8 provides an outlook on the Climate Warehouse’s next steps, summarizing the key elements of the ongoing transition to the operational Climate Warehouse. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | II TABL E O F CO NT E NTS Table of contents ACKNOWLEDGEMENTS I ABOUT THIS REPORT II TABLE OF CONTENTS III LIST OF FIGURES V LIST OF TABLES VI ABBREVIATIONS AND ACRONY MS VI PARTICIPANT HIGHLIGHTS VII SECTION 01 – EXECUTIVE SUMMARY 1 SECTION 02 – PROJECT CONTEXT 2 2.1 THE PARIS AGREEMENT FRAMEWORK 2 2.2 THE CLIMATE WAREHOUSE SIMULATION I 4 2.3 THE CLIMATE WAREHOUSE SIMULATION II 5 2.4 THE CLIMATE WAREHOUSE SIMULATION III 5 2.5 DESIGN AND SIMULATION APPROACH 6 2.6 STAKEHOLDER ECOSYSTEM 6 2.7 TECHNICAL BACKGROUND – BLOCKCHAIN TECHNOLOGY 7 SECTION 03 – SIMULATION III PROTOT Y PE 9 3.1 TECHNICAL ARCHITECTURE 9 3.2 TECHNICAL REQUIREMENTS 12 3.3 USER INTERFACE 13 3.4 ITMO TRANSFERS 15 3.5 THREAT MODEL 15 SECTION 04 – SIMULATION III TESTING APPROACH 16 4.1 TESTING TIMELINE AND PARTICIPANTS 16 4.2 TESTING AREAS 18 4.3 DEPLOY MENT MODELS 19 4.4 TESTING PROCESS 19 4.5 TECHNICAL SUPPORT 20 4.6 FEEDBACK COLLECTION AND DOCUMENTATION 20 4.7 PROTOT Y PE MAINTENANCE AND DEVELOPMENT 21 III | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT TABL E O F CO NT E NTS SECTION 05 – OVERALL TESTING STATISTICS 23 5.1 SIMULATION III PARTICIPANTS 23 5.2 COMPLETED TESTING AREAS 24 5.3 SELECTED DEPLOY MENT MODELS 25 SECTION 06 – PARTICIPANT FEEDBACK 27 6.1 OVERVIEW 27 6.2 OVERALL HIGHLIGHTS AND LEARNINGS 27 6.3 OVERALL SATISFACTION 28 6.4 INSTALLATION 31 6.5 DATA MODEL 33 6.6 USER INTERFACE 35 6.7 API 37 6.8 EXCEL IMPORT/EXPORT 38 6.9 TECHNICAL ARCHITECTURE 40 6.10 GOVERNANCE 41 6.11 RECOMMENDED ADDITIONAL FEATURES 42 6.12 PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY 42 SECTION 07 – LESSONS LEARNED 45 7.1 OVERVIEW 45 7.2 OVERALL HIGHLIGHTS AND LEARNINGS 45 7.3 OVERALL SATISFACTION 46 7.4 INSTALLATION 46 7.5 DATA MODEL 47 7.6 USER INTERFACE 51 7.7 API 52 7.8 EXCEL IMPORT/EXPORT 53 7.9 TECHNICAL ARCHITECTURE 53 7.10 GOVERNANCE 54 7.11 RECOMMENDED ADDITIONAL FEATURES 55 7.12 PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY 55 7.13 LIMITATIONS 55 7.14 RECOMMENDATIONS FOR THE NEW GOVERNING BODY 56 SECTION 08 – CLIMATE WAREHOUSE OUTLOOK 59 8.1 OPERATIONAL CLIMATE WAREHOUSE 59 APPENDIX 61 USER INTERFACE SCREENSHOTS 61 CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | IV TABL E O F CO NT E NTS List of figures Figure 1: Climate Warehouse in the end-to-end digital ecosystem for carbon markets 3 Figure 2: Climate Warehouse as a metadata layer 4 Figure 3: Benefits of using blockchain technology to build a carbon metadata layer 8 Figure 4: Technical architecture of the Simulation III prototype 10 Figure 5: Simulation III data model 11 Figure 6: User interface 13 Figure 7: Testing timeline and participants 17 Figure 8: Testing activities 19 Figure 9: Feedback management tools 21 Figure 10: Participating organizations, testers, and testing sessions 23 Figure 11: Tester roles 24 Figure 12: Completed testing areas 25 Figure 13: Selected deployment models 26 Figure 14: Overall satisfaction levels 29 Figure 15: Installation satisfaction levels 31 Figure 16: Data model satisfaction levels 33 Figure 17: User interface satisfaction levels 35 Figure 18: Excel import/export satisfaction levels 39 Figure 19: Additional features recommended 42 Figure 20: Perspectives on blockchain technology 43 Figure 21: Updates to the Simulation III data model 49 Figure 22: Updated Simulation III data model 50 Figure 23: Interim governance structure of the operational Climate Warehouse 60 Figure 24: User interface – projects list 61 Figure 25: User interface – units list 61 Figure 26: User interface – audit 62 Figure 27: User interface – conflicts 62 Figure 28: User interface – my projects (create project window) 63 Figure 29: User interface – my units (create unit window) 63 V | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT TABL E O F CO NT E NTS List of tables Table 1: Key potential attacks and mitigations identified in threat model 15 Table 2: Key columns in the action items tracker 22 Table 3: Summary of participants’ overall highlights and learnings 28 Table 4: Summarized commentary on participants’ overall satisfaction with the documentation received 29 Table 5: Summarized commentary on participants’ overall satisfaction with the technical support received 30 Table 6: Summarized commentary on participants’ overall likelihood of integrating their registry with the Climate Warehouse based on their testing experience 30 Table 7: Summarized feedback on the installation process 32 Table 8: Summarized feedback on the data model 34 Table 9: Summarized feedback on the user interface 36 Table 10: Summarized feedback on the API feature 37 Table 11: Summarized feedback on the Excel import/export feature 39 Table 12: Summarized feedback on the Climate Warehouse’s technical architecture 40 Table 13: Summarized feedback on the governance of the Climate Warehouse 41 Table 14: Summarized commentary on participants’ agreement with blockchain statement 1 43 Table 15: Summarized commentary on participants’ agreement with blockchain statement 2 44 Table 16: Summarized commentary on participants’ agreement with blockchain statement 3 44 Table 17: Summary of completed data model development actions 48 Table 18: Summary of completed user interface development actions 51 Table 19: Summary of completed API development actions 52 Table 20: Summary of completed technical architecture development actions 54 Table 21: Recommendations for the new governing body 56 Table 22: Summary of development actions logged as suggestions to the new governing body 58 ABBREVIATIONS AND ACRONYMS API application programming interface ISO International Organization for Standardization AWS Amazon Web Services IT information technology CATS Carbon Assets Tracking System ITMO internationally transferred mitigation outcome CDM Clean Development Mechanism MRV monitoring, reporting, and verification CMI Carbon Markets and Innovation NDC nationally determined contribution EBRD European Bank for Reconstruction and Development SQL Structured Query Language GHG greenhouse gas UNDP United Nations Development Programme IETA International Emissions Trading Association UNFCCC United Nations Framework Convention on Climate Change IFC International Finance Corporation CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | VI PART I CI PANT H IGH L IGH TS “The Climate Warehouse brings a concrete response to the challenges of Article 6 requirements, using an innovative implementation, and explores new ways of envisaging the new climate regime where more sovereignty and flexibility should be left with the individual parties and cooperative approaches.” United Nations Framework Convention on Climate Change “The Climate Warehouse enables users to see what is being done to mitigate climate change around the world and can help to achieve better coordination and access to the available information in carbon markets.” Ministry of the Environment, Government of Chile VI I | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT S ECT IO N 01 01 The Climate Warehouse is a public and open-source platform that aims Executive Summary expertise, each tester completed at least one of four testing areas to contribute to the integrity, transparency, and robust accounting of that each corresponded to a key feature of the operational prototype internationally transferred mitigation outcomes (ITMOs), in accordance (installation, user interface, application programming interface, and with article 6.2 of the Paris Agreement. More specifically, the Climate Excel import/export). Warehouse is a peer-to-peer metadata layer that uses blockchain Throughout Simulation III, the 75 testers collectively completed 58 testing technology to harmonize carbon registry data under a common sessions, over 40 weekly office hour sessions, and over 30 kick-off and taxonomy and demonstrate interoperability among carbon registries, onboarding meetings and provided 514 individual points of feedback, which is currently complicated by carbon registries’ usage of different which were each categorized and logged in the testing and simulation data management systems and taxonomies. team’s feedback management tools. Participants’ feedback also helped Starting in 2019, the Climate Warehouse was developed through the testing and simulation team identify 156 development actions, 139 of an iterative process across three phases of testing, which produced which were implemented during Simulation III and reflected in the final and tested developmental prototypes of the Climate Warehouse version of the operational prototype at the end of the simulation. with a wide range of participants including national governments, In addition to the specific development actions that were identified, independent standards, multilateral organizations, and other public participants’ feedback also provided multiple lessons on key aspects of and private carbon market stakeholders. Simulation III was the final the Climate Warehouse, including its technical architecture, governance, testing phase and tested an operational prototype of the Climate data model, and user interface. These lessons were shared with the Warehouse with 30 participating organizations on a public blockchain governing body of the operational Climate Warehouse at the end of network between March and August 2022. Simulation III in August 2022, along with a transition package that The 30 organizations that participated in Simulation III included included a complete log of all participant feedback, a booklet of profiles 11 national governments, five independent standards, six multilateral for each participant, a transition plan, and the Simulation III onboarding organizations, and eight other public and private carbon market package (including an updated technical guide and data model). stakeholders, representing a wide range of regions including East and The conclusion of Simulation III marked the beginning of the transition West Africa, Europe, the Middle East, North America, Latin America to the operational Climate Warehouse, expected to launch in October and the Caribbean, and South and East Asia. 2022. The Climate Warehouse is continuing to make progress on its In order to collect comprehensive feedback on all dimensions of the aim to improve the environmental integrity, transparency, and robust operational prototype, Simulation III engaged 75 individual testers in a accounting of ITMOs, under the leadership of the International Emissions wide range of relevant roles (e.g. policy setters, registry administrators, Trading Association as the interim Secretariat, in close collaboration and information technology specialists). Depending on their role and with the World Bank and the government of Singapore. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 1 S ECT IO N 0 2 02 Project Context THE PARIS AGREEMENT FRAMEWORK environmental integrity, transparency, and robust accounting are challenging to implement given the current state of global On December 12, 2015, 196 parties adopted the Paris Agreement, carbon markets. These markets are characterized by collectively committing to a goal of limiting global warming to well below 2°C decentralized, disconnected, and heterogeneous registries that each compared to pre-industrial levels.1 The underlying mechanism of have different governance systems and technological infrastructure. the Paris Agreement is to reduce greenhouse gas (GHG) emissions This heterogeneity in the management of mitigation outcome unit through nationally determined contributions (NDCs), which are information across registries increases the complexity of tracking individual emissions reduction commitments that are set by each and recording ITMOs. The Paris Agreement does not provide party. As such, the Paris Agreement follows a bottom-up and guidance on how to develop the interoperability among registries. decentralized approach to achieving its climate goals. To address these challenges, the World Bank developed the To enable parties to reduce GHG emissions in a cost-effective Climate Warehouse, which is a public metadata layer that uses manner and to encourage parties to increase their NDCs over time, blockchain technology to facilitate peer-to-peer connections among Article 6 of the Paris Agreement promotes voluntary international decentralized registries to link, aggregate, and harmonize underlying cooperation on mitigation outcomes, which is the Paris Agreement’s data, and enable the transparent accounting of ITMOs. The concept term for actions to mitigate GHG emissions. Specifically, articles 6.2 and framework of the Climate Warehouse was developed by the and 6.4 enable parties to use internationally transferred mitigation World Bank’s Carbon Markets and Innovation (CMI) unit under the outcomes (ITMOs) to achieve their NDC targets, leading to the Climate Change Group with the support of the governments of introduction of market-based mechanisms. Concurrently, articles Spain, Sweden, and Switzerland. 6.2 and 6.3 require parties to “ensure environmental integrity and transparency” and “apply robust accounting to ensure, inter The Climate Warehouse is a component of the end-to-end digital alia, the avoidance of double counting” when they engage in ecosystem underpinning the development of post-2020 carbon international transfers of mitigation outcomes.2 markets under the Paris Agreement by digitizing the generation, reporting, and transfer of carbon assets. Figure 1 shows this The Paris Agreement’s requirements for carbon markets to ensure ecosystem and how the Climate Warehouse fits in. 1 For more information, see https://unfccc.int/process-and-meetings/the-paris-agreement/the-paris-agreement. 2 United Nations. 2015. Paris Agreement. Paris: United Nations. https://unfccc.int/sites/default/files/english_paris_agreement.pdf. 2 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 2 : P ROJ ECT CO N TEX T FIGURE 1: Climate Warehouse in the end-to-end digital ecosystem for carbon markets Digital MRV SECURITY BASED TOKENS Digital assets REFERENCE Program/project level MRV TOKENS NATIVE OR PERMISSIONED COMPLIANCE Direct API access TOKEN REPORTING Level 1: Meter WALLETS EXCHANGE A ## FORECASTING Level 2: Cloud ## Inverter, string, BENCHMARKING combiner box Data capture SERVICE LAY ER Level 3: Weather sensors ## RATINGS Level 4: ## Data DUE DILLIGENCE Switchgear, CENTRALIZED transformers, aggregation ## CHECKS fuses DATABASE/ MRV REGISTRY ## SYSTEM RESOLUTION CONFLICT EXCHANGE X CERTIFICATIONS Facility level MRV Verification of units Reporting for markets, UNFCCC Note: Figure displays the World Bank’s latest conceptualization of the end-to-end digital carbon ecosystem for carbon markets as of this report’s publish date and is subject to change. ISO = International Organization for Standardization, MRV = monitoring, reporting, and verification. The Climate Warehouse functions as a metadata layer in the carbon market ecosystem, which can be characterized by four layers (see Figure 2): • Transaction layer: Carbon exchanges and transaction • Metadata layer: A data layer that uses a common taxonomy platforms that enable participants to transact carbon units. to harmonize data across different registries and facilitates carbon data monitoring across registries. • Registry layer: Carbon registries that hold records of climate action projects, their generated units (e.g. mitigating • Service layer: Public and private sector entities that use outcomes), and transactions under a market mechanism harmonized carbon metadata to offer carbon market services (e.g. country registries, independent standard registries, and (e.g. auditing, certifications, due diligence, conflict resolution, regional registries). benchmarking, forecasting, compliance reporting, and ratings). CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 3 SECT I O N 2 : P ROJ ECT CO N TEXT FIGURE 2: Climate Warehouse as a metadata layer TRANSACTION LAYER EXCHANGE EXCHANGE INTER-REGISTRY A B TRADES INDEPENDENT REGISTRY LAYER COUNTRY A COUNTRY B STANDARD REGISTRY REGISTRY REGISTRY REGIONAL REGISTRY METADATA LAYER COMPLIANCE DUE DILLIGENCE BENCHMARKING CERTIFICATIONS SERVICE LAYER REPORTING CHECKS CONFLICT FORECASTING RATINGS RESOLUTION The World Bank developed and tested the Climate Warehouse needed visibility for climate activities, and enhance the through three simulations that successively built on the lessons transparency of overall market activity. learned previously. • There was valuable joint learning between the World Bank and participants, which demonstrated the utility of blockchain technology and enhanced understanding of the potential THE CLIMATE WAREHOUSE requirements that need to be in place for the Climate SIMULATION I Warehouse to operate. Simulation I of the Climate Warehouse was conducted in 2019 to • The Climate Warehouse should support data analysis and examine the prerequisites and requirements of Article 6.2 as well different ways of using data. as assess the viability of using blockchain technology to connect heterogeneous registries to track carbon credit units and avoid • The user interface and data visualizations are important to double counting. Simulation I was led by the World Bank’s Carbon enable users to observe audit and lifecycle information for Markets and Innovation unit and the World Bank’s Information and climate projects and units. Technology Solutions Technology and Innovation Lab, and engaged • Enough time needs to be allocated to onboard participants. two governments (the government of Chile’s Ministry of Energy and This includes allowing participants to coordinate internal the government of Japan’s Ministry of the Environment) and two resources, such as information technology (IT) staff or independent certification standards (Gold Standard and Verra). consultants, who are needed to integrate systems and test functionality. The key lessons from Simulation I were the following: 3 • All participants indicated interest in participating in possible • The Climate Warehouse’s decentralized metadata layer further development phases, including potentially hosting a can provide an inclusive platform to connect different blockchain node to connect with the Climate Warehouse in country and institutional registry systems, deliver much- the future, given adequate time and resources. 3 World Bank. 2019. Summary Report: Simulation on Connecting Climate Market Systems. Page 8. Washington, DC: World Bank. https://documents.worldbank.org/en/publication/documents-reports/documentdetail/128121575306092470/summary-report-simulation-on-connecting-climate-market-systems. 4 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 2 : P ROJ ECT CO N TEX T THE CLIMATE WAREHOUSE • The Climate Warehouse’s ability to use blockchain to trace and audit carbon credit units that are traded between SIMULATION II organizations was demonstrated. Simulation II of the Climate Warehouse, conducted between November 2019 and December 2021, built on the findings from Simulation I to develop and test an updated Climate Warehouse THE CLIMATE WAREHOUSE prototype with more participants. Over 40 stakeholders participated, SIMULATION III including country registry operators, independent standards, and Simulation III was the final testing phase of the Climate Warehouse multilateral organizations. Concurrently, Simulation II provided project. Launched in March 2022, Simulation III tested an operational participants with practical insights on registry interoperability to prototype of the Climate Warehouse, which was delivered to the inform ongoing Article 6 negotiations. governing entity of the operational Climate Warehouse at the end of the simulation in August 2022. The Simulation III prototype had an Specifically, Simulation II was aimed at achieving the following goals:4 updated data model and features that reflected the learnings from • Define the minimum technical infrastructure standards simulations I and II, and was open source, interoperable, and hosted that registry systems would need in order to participate in on a public blockchain. the Climate Warehouse. Specifically, Simulation III pursued the following goals: • Harmonize various registry data formats into a common data model. • Simulate how participating registry systems can integrate with the Climate Warehouse and synchronize data updates • Test each of the common data model’s data fields and through application programming interface (API) assess each field’s importance to enable data sharing connections, Excel import/export, or manual data entry. and harmonization. • Define minimum technical requirements for participation. • Provide participants with access to the harmonized registry data and enable participants to view and assess project and • Provide capacity-building support and understand potential carbon unit data in real time. barriers to participation that need to be overcome in the operational phase. • Test the feasibility of blockchain as an underpinning architecture technology. • Test and enhance the Climate Warehouse data tables and picklist values that are codified in the data dictionary The key outcomes of Simulation II were as follows:5 document. • Sufficient participant feedback was received to further refine • Test and enhance the Climate Warehouse user interface, the data model and inform the development of an updated including its core registry function. Climate Warehouse for Simulation III. • Explore how a public blockchain meets the Climate • Participant testing demonstrated the minimum technical Warehouse’s requirements and allows functions to identify infrastructure needed to synchronize registry data with the double counting and update information. Climate Warehouse. • Prepare and test a Climate Warehouse prototype that can • The simulation built the capacity of participants on the be operationalized as a decentralized and peer-to-peer Climate Warehouse’s registry functions and data elements carbon metadata layer leveraging blockchain technology. to facilitate the exchange process of ITMOs. 4 World Bank. 2022. Climate Warehouse Simulation 2 Report. Page 8. Washington, DC: World Bank. https://ik.imagekit.io/mtozw1gojis/world-bank/Climate_Warehouse_Simulation_II_Report_eb939eebe6_ylGMWEArX.pdf. 5 Ibid. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 5 SECT I O N 2 : P ROJ ECT CO N TEXT DESIGN AND SIMULATION APPROACH6 STAKEHOLDER ECOSYSTEM 7 Throughout simulations I, II, and III, the Climate Warehouse followed The Climate Warehouse interacts with a wide range of stakeholders in a design thinking approach, which focused on identifying stakeholder the carbon market ecosystem to enable the interoperability of registry needs, defining the problems to address, conceptualizing potential data. This project identified eight core stakeholders, as outlined below: solutions, and creating and testing prototypes. In Simulation I, • Governments serve as national aggregators of climate the World Bank conducted a comprehensive literature review projects and carbon credit units, responsible for the and consulted subject matter experts to design a metadata comprehensive and accurate tracking of carbon data within layer that addresses the concerns of stakeholders in the carbon their national jurisdictions. They also participate in the market ecosystem. This process focused on designing the Climate carbon market to track and report their progress against Warehouse architecture in alignment with the Paris Agreement their NDCs. Governments benefit from the Climate framework. In addition, the World Bank engaged a wide range of Warehouse because it increases the visibility, credibility, stakeholders—including governments, registry providers, carbon and accountability of their climate activities; provides an credit trading platforms, and the United Nations Framework aggregate view of climate activities that can help Convention on Climate Change (UNFCCC)—to understand how identify duplicated projects; and enables them to view emerging technologies, such as blockchain, can address their needs carbon credit units outside of their national jurisdiction that and concerns. they can potentially purchase. Furthermore, synchronizing national registry data with the Climate Warehouse Building on Simulation I’s progress, simulations II and III continued the facilitates government partnerships with the private sector design thinking approach by focusing on testing and improving the (e.g. through the service layer). Climate Warehouse prototype through an iterative process. Specifically, • Independent certification standards develop and manage the testing approaches in simulations II and III were developed and project cycle protocols and monitoring methodologies for executed in accordance with the following design principles: carbon offset projects. They primarily benefit from the • The Climate Warehouse will improve transparency, accuracy, Climate Warehouse because its harmonized and completeness, comparability, and consistency. aggregated carbon unit data reduces the burden of • The Climate Warehouse has a specific emphasis on the monitoring heterogeneous external systems. transfer of mitigating outcomes under Article 6.2. • UNFCCC induces parties to comply with their NDC targets • The Climate Warehouse data fields will facilitate harmonization, by providing expertise and direct discussions at United search and filtering, traceability, and audit features. Nations Climate Change Conference meetings, which is a core component of its organizational mandate. The UNFCCC • Data in the Climate Warehouse mirrors the registry benefits from the Climate Warehouse because it can easily information of partners participating in the warehouse access harmonized and aggregated climate registry data. (i.e. data quality is the responsibility of connected registries). • Exchanges facilitate trades and transactions and create • The Climate Warehouse data can be relied on as a record of carbon asset-based financial products. Exchanges benefit registry data for accuracy, auditing, and reporting purposes. from the Climate Warehouse because it decreases market • The Climate Warehouse aims to ensure a flexible architecture fragmentation, eases integration, promotes standardization and data model in anticipation of changing rules. and asset integrity, and improves reliable access to the registry data needed to process transactions. 6 Ibid. Pages 9–12. 7 Ibid. Pages 12–13. 6 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 2 : P ROJ ECT CO N TEX T • Project developers develop and implement emission transactions and are cryptographically linked in chronological order. reduction or removal activities (e.g. renewable energy or This blockchain is immutable and secure because altering a block land-use projects). They benefit from the Climate Warehouse retroactively changes all subsequent blocks and does not pass the because it improves the transparency and accountability of consensus mechanism, which prevents any node from altering the their carbon assets. history of transactions.8 • Verification bodies verify carbon assets issued by emissions In 2018, the World Bank conducted internal testing on the viability of reduction projects, in accordance with the standards set by using blockchain to build the Climate Warehouse and demonstrated independent certification standards. These bodies benefit that blockchain has the capability to simplify data-sharing among from the Climate Warehouse because it eases access to different carbon registries.9 The primary findings were as follows: harmonized and aggregated carbon registry data, improving verification bodies’ auditing and reporting capabilities. • The decentralized and immutable nature of blockchain technology makes it resilient against attacks and ensures • Buyers and traders transact in carbon assets, driving data integrity, enabling mitigating outcomes to be reliably demand and creating incentives for project developers to traced from their origins to retirement. develop additional emissions reduction projects and issue more carbon assets. Buyers and traders benefit from the • The decentralized and peer-to-peer design guarantees Climate Warehouse because it provides a platform to search autonomy and accountability to participating registries, through available carbon assets and improves the each of which retain full control over their own data and transparency of carbon asset details (e.g. a transaction history). can flexibly choose their approaches in line with their own requirements and institutional frameworks. • Public and private market players from the service layer that offer carbon market services (e.g. auditing, certifications, • The storage and accounting of harmonized registry data due diligence, conflict resolution, benchmarking, forecasting, on a public, open-source, and permissionless blockchain compliance reporting, and ratings) benefit from the Climate improves transparency and inclusiveness and can reduce Warehouse because its harmonized carbon metadata allows the risks of double counting. them to develop and expand their service offerings. • A blockchain-enabled, peer-to-peer carbon metadata layer follows the decentralized and bottom-up ethos of Article 6 of the Paris Agreement. TECHNICAL BACKGROUND – BLOCKCHAIN TECHNOLOGY To test these findings, simulations I and II prototyped the Climate Blockchain is a data storage and accounting technology that enables Warehouse on a private and permissioned platform called Kaleido the decentralized storage and management of data among network – a blockchain-as-a-service provider on the Ethereum network. participants (i.e. “nodes”) without relying on a central intermediary. Simulations I and II implemented a private and permissioned It achieves this by using distributed ledger technology, which blockchain architecture to limit complexity and focus on testing distributes a ledger of all transactions to each node and validates the key features of the prototypes (e.g. the data model).10 A private new transactions through a democratic consensus mechanism (i.e. all and permissioned testing environment also enabled the timely nodes validate new transactions). The distributed ledger is designed participation of highly regulated carbon market stakeholders. as a chain of time-stamped “blocks” that each carry a collection of 8 Blockchain technology was first implemented by a person (or persons) using the pseudonym “Satoshi Nakamoto” in 2008 to launch Bitcoin, a peer-to-peer electronic currency that enables online payments to be transferred without a financial intermediary. For more information, see https://bitcoin.org/bitcoin.pdf. 9 World Bank. 2018. Blockchain and Emerging Digital Technologies for Enhancing Post-2020 Climate Markets. Washington, DC: World Bank. https://openknowledge.worldbank.org/handle/10986/29499. 10 World Bank. 2019. Summary Report: Simulation on Connecting Climate Market Systems.; World Bank. 2022. Climate Warehouse Simulation 2 Report. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 7 SECT I O N 2 : P ROJ ECT CO N TEXT Simulation III subsequently prototyped the Climate Warehouse code, and submitted a variety of questions on the Chia Network’s as a public and open-source platform on the Chia Network’s technical architecture, economic model, sustainability, functionality, blockchain network. Simulation III’s blockchain architecture and accessibility. The Chia Network addressed the reviewers’ enabled the Climate Warehouse to be tested in its operational questions and documented the answers in its Climate Warehouse capacity as a decentralized and peer-to-peer carbon metadata white paper.11 The collaboration with the Chia Network is based on layer. The World Bank selected the Chia Network as the blockchain the principles of non-exclusiveness and open-source public goods, network provider for Simulation III after confirming its suitability bearing no costs or intellectual property rights from the World through a comprehensive technical assessment that involved a Bank, and aims to promote interoperable and inclusive solutions. consortium of over 20 carbon experts and technology industry The World Bank continues to support the effort to provide open- leaders. During the technical assessment, reviewers conducted source infrastructure for climate market activities. a detailed examination of the Chia Network’s documents and FIGURE 3: Benefits of using blockchain technology to build a carbon metadata layer TRANSPARENCY INTEGRITY • Fully auditable and secure • Fully immutable and record of transactions traceable ACCOUNTABILITY INCLUSIVENESS • Decentralized governance • Public, fully open-source, and peer-to-peer support THE BLOCKCHAIN LAY ER and permissionless • Only registries can edit their • Anyone in the network own data, allowing countries to can access both the data flexibly choose their approaches layer and a blockchain • Follows the Article 6 bottom-up approach node and add blocks 11 For more information, see https://ik.imagekit.io/mtozw1gojis/world-bank/Chia_as_the_Blockchain_Technology_for_the_Climate_Warehouse_3f553aff80_p_RQYX_Ie0g_f9da253e1a_n6RklkGfZ.pdf. 8 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT S ECT IO N 0 3 03 Simulation III Prototype TECHNICAL ARCHITECTURE • API: Dynamic and automated data integration through a direct API connection. The technical architecture of the Simulation III Climate Warehouse • Excel import/export: Bulk registry data imports and exports prototype consists of the metadata layer and the blockchain layer. through the user interface. Registries and observers interact with this technical architecture by publishing or extracting data and hosting blockchain nodes (see • Manual entry: Manual registry data input through the user interface. Figure 4). Registries can select their integration method based on their Registries and observers technical capability (e.g. ability to set up an API connection) and Registries and observers interact directly with the Climate preferred integration model. Warehouse’s technical architecture. Registries are databases and ledgers that hold records of climate action projects, their generated Hosting a Climate Warehouse blockchain node involves storing a units (e.g. mitigating outcomes), and transactions under a market copy of the Climate Warehouse metadata and the Chia Network mechanism (e.g. country registries, independent standard registries, blockchain ledger (i.e. history of blockchain transactions). This and regional registries). Observers are entities that have an interest allows registries to validate and secure updates to the Climate in the Climate Warehouse’s publicly available, harmonized metadata Warehouse’s metadata through the blockchain layer’s peer-to- and include auditors, buyers, traders, verification bodies, project peer consensus mechanism, following the bottom-up approach of developers, exchanges, and regulatory bodies. the Paris Agreement. Registries benefit from hosting a blockchain node because it enables them to ensure that updates to the Climate Registries engage with the Climate Warehouse by publishing their Warehouse’s metadata agree with their local records. In addition, registry data and by hosting a Climate Warehouse blockchain node. hosting a blockchain node enables registries to control their data Registries can integrate their data with the Climate Warehouse in integration with the Climate Warehouse and avoid relying on a third three ways: party-operated node to extract and publish carbon data. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 9 SECT I O N 3 : S IMU LATIO N III P ROTOT Y P E FIGURE 4: Technical architecture of the Simulation III prototype BLOCKCHAIN LAYER PUBLIC BLOCKCHAIN DATA MODEL DATA MODEL METADATA LAYER User User User interface API interface API interface Mirrored database REGISTRIES & OBSERVERS Registry data Node Registry data Node Harmonized metadata Node REGISTRY A REGISTRY B OBSERVERS Observers engage with the Climate Warehouse by extracting taxonomy, and the Climate Warehouse’s data integration and the Warehouse’s harmonized metadata and by hosting a Climate extraction features, which include the API feature, user interface, Warehouse blockchain node. They can extract the harmonized and mirrored database feature. The Simulation III data model is metadata either by using the mirrored database feature (Climate an extended version of the model that was developed during Warehouse data mirrored into a traditional Structured Query simulations I and II and has two main tables: the projects table and Language (SQL) database) or by downloading a static Excel file in the units table (see Figure 5). the user interface’s Warehouse view. The mirrored database feature is particularly useful for observers interested in using Climate The projects table captures information on GHG mitigation projects Warehouse data to provide related services (e.g. auditing, market and includes data fields such as project name, developer, sector, reports, or double counting checks) because it enables dynamic NDC information, status, and description. The projects table is data access and can be linked to “live” dashboards and reports. As connected to ancillary tables such as issuances, locations, ratings, with registries, observers host blockchain nodes to participate in co-benefits, estimations, and labels. Each project is tagged with a the peer-to-peer data validation process, ensure that data updates unique identification number and linked to the unique organization agree with local records, and control their data integration with the identification number of the registry that submitted the project data. Climate Warehouse. The units table captures information on the carbon credit units that Metadata layer are issued from projects and includes data fields such as unit count, The metadata layer is the first layer of the Climate Warehouse’s issuance location, vintage year, status, and tags. Each unit is also technical architecture and consists of the data model, which tagged with a unique identification number and is linked to the harmonizes data fields across different registries using a common project from which it was issued. 10 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 3 : S IMU LATIO N III P ROTOT Y P E The Simulation III data model’s data fields and picklist options are governance node also maintains the organizations list, which is the specified by the Climate Warehouse governance node, which is list of participating registries to which each new node in the Climate managed by the governing body of the Climate Warehouse. The Warehouse will automatically subscribe. FIGURE 5: Simulation III data model PROJECT LOCATION PROJECTS RELATED PROJECTS UNITS GOVERNANCE (PICKLIST VALUES) Warehouse Project ID* (FK) Warehouse Project ID* (PK) Warehouse Project ID* (FK) Issuance ID* (FK) Registry values Project Location ID* (PK) Current Registry* Related Project ID (PK) Warehouse Unit ID* (PK) Project Sector values Country* Project ID* Relationship Type Unit Issuance Location* (FK to project loc ID) Project Status values In-country Region Registry of Origin* Registry Label ID* (FK) Project Type values Geographic Identifier* Program ISSUANCES Unit Owner* Methodology values Project Name* Country Jurisdiction Unit Metric values PROJECT RATING Project Link* Warehouse Project ID* (FK) of Owner* Validation Body values Project Developer* Warehouse Project ID* (FK) Issuance ID* (PK) In-country Jurisdiction Country values Sector* of Owner Project Rating ID (PK) Issuance Start Date* Rating Type values Project Type* Serial Number Block* Rating Type* Issuance End Date* Unit Type values Project Tags Serial Number Pattern Rating Range Lowest* Verification Approach* Unit Status values Covered by NDC* Unit Block Start* (derived) Rating Range Highest* Verification Report Date* Corresponding Adjustment NDC Information Unit Block End* (derived) Rating* Verification Body* Declaration values Project Status* Unit Count* (derived) Rating Link* Corresponding Adjustment Project Status Date* Vintage Year* Status values LABELS Unit Metric* Unit Type* Related Project CO-BENEFITS Methodology* Warehouse Project ID* (FK) Relationship Type values Marketplace Warehouse Project ID* (FK) Validation Body Label ID (PK) Label Type values Marketplace Link Co-benefit ID (PK) Validation Date Label Type* Verification Body values Marketplace Identifier Co-benefit Label* Unit Tags Crediting Period Start Date* Unit Status* ESTIMATIONS Crediting Period End Date* Unit Status Reason Validity Start Date* Unit Registry Link* Warehouse Project ID* (FK) Validity End Date* Corresponding Adjustment Estimations ID* (PK) Declaration* Unit Quantity* Crediting Period Start* Corresponding Adjustment Label Link* Crediting Period End* Status* Unit Count* Fields with an * are required form fields PK denotes primary key for a specific table FK denotes foreign key which links tables together Each ID is globally unique, meaning no organizations will generate the same ID for any table CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 11 SECT I O N 3 : S IMU LATIO N III P ROTOT Y P E Blockchain layer This is the second layer of the Simulation III prototype’s technical architecture, which secures the data submitted by participants on an immutable blockchain. The blockchain layer is secured by a network of validators in a public and permissionless blockchain through a decentralized and peer-to-peer governance system. This layer has the following key characteristics: • Transaction validation model: To validate the addition of new blocks to the blockchain, the blockchain layer uses proof of space and time (validators prove that their storage space is allocated to the blockchain and compute a verifiable delay function), which differs from existing validation models including proof of work (validators solve complex and energy- intensive cryptographic puzzles) and proof of stake (validators prove a financial stake in the blockchain). • Ledger model: The blockchain layer uses the unspent transaction outputs ledger model (also used by Bitcoin), in which data records on the blockchain are stored as coins and each transaction involves canceling and creating new coins. In contrast, the account ledger model (used by Ethereum) stores data records on the blockchain in accounts and each transaction involves debiting one account and crediting another. • Native data storage: The blockchain layer offers a native capability to store data on the blockchain, using data tables. Each data table is represented by a unique coin, which is stored on the public blockchain, while the contents of each data table are stored by the nodes that subscribe to the data tables (i.e. Climate Warehouse registries and observers). • Transaction fees: Each data table update incurs a transaction fee to compensate the validators that secure the new data on the blockchain. The transaction fee does not depend on the volume of data updated, since only the coin representing the updated data table is stored on the blockchain. • Autonomous: The blockchain layer is publicly owned by its nodes and runs autonomously. TECHNICAL REQUIREMENTS The Climate Warehouse Simulation III prototype’s technical requirements include software requirements, device specifications, IT security permissions, and data mapping. Software requirements Registries that participate in the Climate Warehouse must install three types of software – the Climate Warehouse back-end software, user interface, and Chia software. The Climate Warehouse back-end software and user interface both run as standard applications in Windows and Mac operating systems and do not require any other software to be installed to run. Installing Chia software enables participants to host a blockchain node by creating a wallet and downloading a copy of the public blockchain and data layer. All required software is publicly available on the Climate Warehouse repository on GitHub.12 12 For more information, see https://github.com/Chia-Network/climate-warehouse. 12 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 3 : S IMU LATIO N III P ROTOT Y P E Device specifications on the participating registry’s integration model. If a registry chooses to integrate its data using Climate Warehouse APIs, it will need to To host a node, participants need to have devices with specifications create middleware that converts the submitted registry data into the that are equivalent to or above those of a Raspberry Pi 4 computer, format of the Climate Warehouse data model. If a registry chooses including: to use the Excel import/export function in the user interface, it will • Processor: Quad core 1.5 gigahertz central processing unit need to map its data fields in the predefined Excel upload template. (must be 64-bit) If a registry chooses to manually enter its data on the user interface, • Random access memory: 4 gigabytes (GB) the data field requirements will ensure that submitted registry data • Programming language: Python 3.7–3.9  fits the Climate Warehouse data model. • Disk space: 100 GB USER INTERFACE IT security permissions Participants must also have sufficient local IT security permissions The user interface is a tool that helps participants access and to download and run the Climate Warehouse software described update their data in the Climate Warehouse (see Figure 6). In prior above. They specifically need permission to hold and transact simulations, the user interface was also referred to as the “auxiliary cryptocurrencies, since hosting a node and submitting data updates application”. The primary purpose of the user interface is to enable require transactions using a cryptocurrency wallet. easy access to the Climate Warehouse for participants that may not have the capacity to create their own integration tools that are Data mapping tailored to their workflows. As such, participants are not required Finally, participants must map their data fields to the fields of the to use the user interface. The user interface has two sections: the Climate Warehouse data model. The nature of this mapping depends warehouse section and the registry section. FIGURE 6: User interface WAREHOUSE SECTION REGISTRY SECTION Note: All data displayed is sample data for testing and simulation purposes only. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 13 SECT I O N 3 : S IMU LATIO N III P ROTOT Y P E Warehouse section This function was added to the user interface to demonstrate the opportunity for third-party organizations in the service layer to use The warehouse section visualizes the Climate Warehouse’s the data in the Climate Warehouse to develop innovative methods to harmonized metadata and can be accessed by participating registries, detect instances of double counting, flag units or projects with higher observers, and members of the public. The public observer node, or lower double counting risks, and increase the overall transparency available on the Climate Warehouse website, enables members of and efficiency of the market. The function uses a simple algorithm that the public to easily access the warehouse view through an internet screens units based on time period, sector, geography, and registry in browser.13 The warehouse section includes four subsections: “projects order to flag units with double issuance risk. The Climate Warehouse list”, “units list”, “audit”, and “conflicts”. Simulation III prototype’s double issuance risk detection function was developed for simulation purposes only, in order to demonstrate The “projects list” subsection includes a table of all projects submitted the potential of service layer double counting mitigation tools, and by participating registries that are part of the Climate Warehouse was not in scope for continued development. This subsection was governance node. Each row corresponds to a single project and the table columns detail project-specific information such as the project removed at the end of the Climate Warehouse Simulation III. identification number, project name, project developer, sector, project type, and project status. Selecting a specific project leads to the Registry section project detailed view, which includes further details on the project, its The registry section mimics simple registry functions (i.e. creating issuances, location information, and estimations. Project data can be and editing projects and units) and provides a basic data integration filtered using the full text search feature or by using the organization capability for registries that do not have the capacity to develop drop-down bar. Additionally, a static copy of the project data can be their own integration tools. Participants can use the registry section downloaded to the local device using the Excel download feature. to add registry data to the Climate Warehouse, either through the Excel import/export function or by manual entry. The registry section The “units list” subsection includes a table of all carbon units that comprises four subsections: “my projects”, “my units”, “my files”, and have been submitted by participating registries that are included in “my organization”. the Climate Warehouse governance node. Each row corresponds to a single unit and the table columns detail unit-specific information The “my projects” subsection enables users to view and edit the including unit owner, unit count, unit type, unit status, and projects they have created and to create new projects. Users can corresponding adjustment status. Selecting a specific unit leads to manually create projects using the create project function, which the unit detailed view, which includes further details on the unit, its helps users populate each of the project data fields through a step- issuances, and any labels (e.g. eligibility for the Carbon Offsetting and by-step process. Alternatively, users can add project data to the Reduction Scheme for International Aviation). Unit data can also be Climate Warehouse by using the Excel import/export function and filtered using the full text search feature or by using the organization uploading a project data Excel file in the specified format. drop-down bar, and a static copy of the unit data can be downloaded to the local device using the Excel download feature. The “my units” subsection follows a similar format, enabling users to view and edit all created units and add unit data by either manually The “audit” subsection displays the full blockchain transaction history creating a unit or by uploading a unit data Excel file. Notably, the “my of any organization that the user subscribes to if the organization is units” tab also enables users to split a single created unit into multiple selected from the drop-down list. Users can select a specific blockchain units using the split unit function. transaction to view further details regarding the transaction (such as when the data was added or deleted, or what project or unit data was The “my files” subsection is a repository that enables users to added or deleted). upload, share, and securely download files from other participants. This feature can specifically be used to share geographic information The “conflicts” subsection lists units in the Climate Warehouse, system shapefiles, which track project location details. Users can submitted by participant registries, that were flagged by the manage the amount of data that is being stored by selecting the files user interface’s sample double issuance risk detection function. that they want to receive from other participants. 13 For more information, see https://app.climatewarehouse.chia.net/#/projects?orgUid=all. 14 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 3 : S IMU LATIO N III P ROTOT Y P E The “my organization” subsection displays key details on the transferred from registry A, and mark the status of the unit as “held”. user’s organization, which include organization name, identification number, public blockchain address, and quick response code. In In the future this ITMO transfer process could be consolidated into addition, the organization subscriptions feature enables users to a single step, in which a blockchain “smart contract” triggers the monitor the registries that they choose to follow by subscribing sending and receiving registries to simultaneously record the ITMO or unsubscribing to other registries’ data. This allows participants transfer in the Climate Warehouse once they have updated their to flexibly adjust the registry data that they follow based on their respective internal registry systems to reflect the transfer. preferences (e.g. follow as many registries as possible to minimize double counting risk or only follow the registries listed by the governance body) and is in line with the bottom-up approach of THREAT MODEL the Paris Agreement. To provide guidance on the security considerations for participating in the Climate Warehouse, a comprehensive threat model was developed for the Simulation III prototype. The development process ITMO TRANSFERS included isolating the elements of the Climate Warehouse that are The Simulation III prototype enables registries to reflect ITMO susceptible to attacks, simulating threats to individual blockchain transfers, which occur outside of the Climate Warehouse, in the nodes and the overall blockchain network, prioritizing the identified Climate Warehouse by updating their unit data. For example, in the threats by severity, and outlining countermeasures to mitigate each case that registry A transfers a carbon unit to registry B outside of threat. Table 1 summarizes the key potential attacks that were the Climate Warehouse and wants to reflect this transaction in the identified in the Climate Warehouse threat model. The final version Climate Warehouse, registry A would first change the status of the of the threat model, including a complete list of identified threats transferred unit to “exported” by editing the unit record. Registry B and countermeasures, was shared with the governing body of the would then create a new unit, corresponding to the unit that was operational Climate Warehouse at the end of Simulation III. TABLE 1: Key potential attacks and mitigations identified in threat model POTENTIAL ATTACK MITIGATION DESCRIPTION A threat actor attempts to change Climate Warehouse data Changing data Blockchain immutability without permission A threat actor attempts to prevent legitimate users from Denial of service Decentralization accessing the Climate Warehouse Security-optimized cloud A threat actor attempts to cause the Climate Warehouse to Malicious code injection architecture distribute malicious payloads Keys secured by multiple Stealing cryptocurrency A threat actor attempts to steal users’ cryptocurrency assets layers A threat actor attempts to change data that was previously Blockchain attack Nakamoto Consensus confirmed on the blockchain or to stop the blockchain entirely CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 15 S ECT IO N 0 4 04 Simulation III Testing Approach TESTING TIMELINE AND Participating organizations were sorted into three groups, depending on the testing phase that they participated in (see Figure 7). Simulation III PARTICIPANTS testing engaged with 30 participating organizations consisting of 22 full Simulation III testing was completed in four phases over a six- participants and eight observers across the three participant groups: month period between March and August 2022 and engaged a • Group 1: Included two full participants and two observers. diverse range of stakeholders, including governments, independent Full participants included the World Bank’s CMI unit and standards, multilateral organizations, and other private and public Carbon Assets Tracking System (CATS). Observers included carbon market stakeholders (see Figure 7). Phases I, II, and III focused the International Emissions Trading Association (IETA) and on testing and simulation activities with participants, and phase IV Open Earth Foundation. focused on consolidating participant feedback and preparing for the Climate Warehouse’s transition to the operational governing body. • Group 2: Included 11 full participants and four observers. Full participants included the governments of Chile, Japan, Simulation III participants broadly fell into two categories: Singapore, Sweden, and Switzerland, as well as IHS Markit, • Full participants: Carbon market stakeholders that were Verra, the Climate Action Reserve, the American Carbon willing and able to simulate publishing registry data to the Registry, Gold Standard, and Global Carbon Council. Observers Climate Warehouse and test key features of the prototype, included the government of Spain, the UNFCCC, the European including installation, the user interface, API, and Excel Bank for Reconstruction and Development (EBRD) and the import/export. United Nations Development Programme (UNDP). • Observers: Carbon market stakeholders that were interested • Group 3: Included nine full participants and two observers. in learning about the Climate Warehouse (e.g. through Full participants included the governments of Peru, prototype demonstrations or uploading test data), as part Rwanda, Senegal, Uganda, and the United Kingdom, as well of their role in helping to scale up compliance or voluntary as EcoRegistry Colombia, Temasek, International Finance carbon markets. Corporation (IFC), and SK Certification Center. Observers included the Climate Ledger Initiative and ClimateCheck. 16 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 4 : S IMU LATIO N III TESTIN G AP P ROACH Simulation III engaged testers within participating organizations • Registry administrator: Manages the participating with three types of roles in order to collect comprehensive feedback organization’s registry and can provide specific feedback on on all dimensions of the Climate Warehouse: the Climate Warehouse’s data model and data fields. • Policy setter: Sets the participating organization’s policies, • IT specialist: Manages the participating organization’s guidelines, and strategies and can provide high-level feed IT systems and can provide specific feedback on the back on the Climate Warehouse (e.g. value proposition Climate Warehouse’s IT requirements. in the carbon market ecosystem and long-term trends that should inform the current design). FIGURE 7: Testing timeline and participants PHASE I PHASE II PHASE III PHASE IV GROUP 1 Feedback consolidation GROUP 2 GROUP 3 (Internal testing) and documentation • World Bank Carbon Assets • Chile • Verra • Rwanda • EcoRegistry Capture feedback in six tools: Tracking System Colombia • Japan • Climate Action • Senegal • Test scripts Reserve* • Temasek • World Bank Carbon Markets • Singapore • Peru • Feedback notes and Innovation unit • American • IFC • Sweden • Uganda • Feedback survey Carbon Registry* • SK Group • Switzerland • United • Gold Standard • Feedback tracker Kingdom • HS Markit • Global Carbon • Action items tracker Council** • Participant & feedback profiles Observers: Observers: • International Emissions Produce documentation: Observers: Trading Association • Climate Ledger Initiative • Simulation III final report • Spain • EBRD • Open Earth Foundation • ClimateCheck • Transition plan • UNFCCC • UNDP • Simulation III onboarding package March – April 2022 April – May 2022 May – July 2022 July – August 2022 CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 17 SECT I O N 4 : S IMU LATIO N III TESTIN G AP P ROACH TESTING AREAS Simulation III testers completed at least one of four testing areas, based on their role and expertise. The four Simulation III testing areas were installation, user interface, API, and Excel import/export. Installation The installation testing area focused on installing and running the software required to participate in the Climate Warehouse. This involved downloading the Climate Warehouse, user interface, and Chia software; setting up a wallet; and syncing a blockchain node. Installation was tested by members of participating organizations who would manage the Climate Warehouse software once the warehouse was operational and had an interest in learning how to install and maintain the Climate Warehouse. This testing area helped participating organizations understand the Climate Warehouse’s technical requirements and prepare to manage new releases of the Climate Warehouse software in the future. User interface This testing area focused on viewing, entering, and modifying Climate Warehouse data through the user interface. This involved accessing the downloaded user interface application, creating an organization, creating projects, creating units, reviewing other organizations’ data, and simulating a unit lifecycle. The user interface was tested by most members of participating organizations since it enabled participants to easily access and review the Climate Warehouse’s main functionalities, data model, and data fields. This testing area helped participants simulate the integration of registry data with the Climate Warehouse and identify specific functionalities and data fields that they wanted to modify. API The API testing area focused on testing the Climate Warehouse’s API endpoints and examining the Climate Warehouse’s ability to support API-enabled automatic registry data integration. This involved identifying an optimal configuration to integrate the participating organization’s registry data with the Climate Warehouse and considering how middleware could be built to support automatic integration. This testing area was completed by participating organizations that had the technical capabilities to support automatic registry data integration with the Climate Warehouse through an API. Excel import and export This testing area focused on using the Excel import/export feature in the user interface to upload registry data to the Climate Warehouse in bulk. This involved populating the Excel upload template with registry data (to ensure alignment with the Climate Warehouse’s data model) and uploading the populated template in the user interface. The testing area helped participants understand how they can upload bulk volumes of registry data to the Climate Warehouse without API integration. 18 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 4 : S IMU LATIO N III TESTIN G AP P ROACH DEPLOYMENT MODELS participating organization. This model was used by participants who preferred to install and test the Climate Warehouse in a Simulation III participants were offered a choice between four different virtual workspace, hosted by their own organization. deployment models, depending on their needs: • Local installation: Involved directly installing the Climate Warehouse software onto a device owned by the participating TESTING PROCESS organization. This model was used by participants who had Each Simulation III participant completed a series of activities, including: sufficient disk space and security permissions to install the • Pre-testing activities: Complete a kick-off meeting, receive Climate Warehouse software onto their own device. a demo of the Climate Warehouse, select a deployment model, • Cloud – Amazon Web Services (AWS) workspace: Involved select testing areas, and prepare the local IT environment to conducting testing activities in a blank AWS workspace. enable testing (e.g. confirm IT security protocols). This model was used by participants who could not meet • Testing activities: For each selected testing area, complete the requirements for local installation but were still interested in the steps included in the corresponding test script, simulating testing the installation and/or API testing areas. key activities that integrated registries would complete • Cloud – hosted instance: Involved conducting testing activities (e.g. creating a project or retiring a unit). in an AWS workspace with pre-installed Climate Warehouse • Post-testing activities: Complete the Climate Warehouse software. This model was used by participants who focused feedback survey to provide comprehensive feedback on the their efforts on testing the user interface. testing experience. • Cloud – own organizational cloud: Involved conducting testing activities in a virtual workspace set up by the FIGURE 8: Testing activities 1 RUN THE CLIMATE WAREHOUSE 5 REVIEW ORGANIZATION AND PROJECTS • Run through local install • Review own organization and projects scripts • Run through docker • Subscribe to external organization table • Run through hosted environment • Unsubscribe from external organization table 2 ORGANIZATION CREATION SCRIPTS 6 REPORT ON CW PROJECTS • Create from API • Import XLSX project • Create from user interface • Create from API • Create from user interface 3 PROJECT CREATION SCRIPTS 7 UNIT TRANSACTIONS • Import XLSX project • Retire units • Create from API • List of units on external marketplace • Create from user interface • Transfer units within same country jurisdiction 4 UNIT CREATION SCRIPTS • Transfer units outside country jurisdiction (internationally transferred mitigation outcomes) • Import XLSX project • Create from API • Apply new label to units • Create from user interface • Add new issuance Note: Testing activities varied by participant based on selected testing areas. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 19 SECT I O N 4 : S IMU LATIO N III TESTIN G AP P ROACH TECHNICAL SUPPORT Specifically, six feedback management tools were developed and implemented (see Figure 9): The World Bank and Chia Network team members provided Simulation • Test scripts: Participants used the feedback column in the III participants with comprehensive technical support throughout the step-by-step test scripts to compare the expected and actual testing process to ensure a smooth testing experience. Technical outcome of each step and note any comments. support included kick-off sessions, joint testing sessions, office hours, email support and check-ins, and technical documentation as follows: • Feedback notes: Detailed notes were taken from joint testing sessions and office hours, capturing participants’ • Kick-off sessions: Introduced participants to the Climate questions, suggestions, requests, concerns, errors, and Warehouse through a demo and confirmed technical proposed development actions. requirements, preferred deployment model, and testing areas. • Feedback survey: Participants completed the survey • Joint testing sessions: Guided participants through each after testing to holistically provide qualitative (e.g. views testing step, answering questions and documenting any on blockchain technology) and quantitative (e.g. level of feedback or suggestions. satisfaction) feedback on their testing experience. • Office hours: Held open-ended, one-hour office hour • Feedback tracker: An Excel tracker was used to log and sessions twice per week to answer any questions as categorize all participant feedback from test scripts, testing participants completed testing. sessions, office hours, feedback survey responses, and • Email support/check-ins: Engaged in regular check-ins and email exchanges. communication over email to track participants’ testing • Action items tracker: A “live” tracker of all prototype progress and ensure sufficient support. development actions was used to facilitate the development • Technical documentation: Provided detailed information action decision-making process, track completion statuses, on the technical architecture of the Climate Warehouse, and maintain a log of proposed and completed development testing approach, technical requirements, testing steps, actions during Simulation III. data model, definitions of data fields, and more. Simulation III • Participant and feedback profiles: Participant and feedback participants were given technical documentation including an profiles were created for each participant, documenting their onboarding presentation, a technical guide, test scripts for testing timelines, team member roles, completed testing each testing area, and a data dictionary areas, selected deployment models and IT configurations. The profiles also included a comprehensive log of all feedback received from each participant in testing sessions, FEEDBACK COLLECTION AND completed test scripts, office hours, emails to the testing DOCUMENTATION and simulation team, and feedback survey responses. Participant feedback was collected and consolidated systematically Participant and feedback profiles were compiled into a throughout Simulation III testing to maintain a comprehensive record testing participant profiles booklet at the end of Simulation III of feedback and inform improvements to the Climate Warehouse. and shared with the new governing body. 20 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 4 : S IMU LATIO N III TESTIN G AP P ROACH FIGURE 9: Feedback management tools CAPTURE SY NTHESIZE 1 4 FEEDBACK TRACKER TEST SCRIPTS Tracker logging and categorizing Detailed feedback by step all feedback received from participants 2 5 FEEDBACK NOTES ACTION ITEMS TRACKER Log of all feedback from office “Live” tracker of all action items hours and testing sessions PARTICIPANTS 3 6 PARTICIPANT & FEEDBACK SURVEY FEEDBACK PROFILES Survey on testing experience One-pagers on each participant’s IT configuration and key feedback Updates and improvements to the Climate Warehouse throughout PROTOTYPE MAINTENANCE with the testing and simulation team for a development decision. AND DEVELOPMENT Confirmed actions were then submitted to the prototype development team for completion through the publicly available Climate Warehouse The Climate Warehouse Simulation III prototype was improved repository on GitHub, which logged all updates made to the Climate throughout the testing period based on feedback from participants. Warehouse during Simulation III.14 The prototype was developed through a structured decision-making process, which involved first identifying potential updates to the Climate Table 2 provides a description for each of the key columns in the action Warehouse, based on participant feedback. Potential updates were items tracker that facilitated this prototype development process. then added to the action items tracker and raised in weekly meetings 14 For more information, see https://github.com/Chia-Network/climate-warehouse. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 21 SECT I O N 4 : S IMU LATIO N III TESTIN G AP P ROACH TABLE 2: Key columns in the action items tracker KEY COLUMN DESCRIPTION Unique identification number tagging each new potential action that was added to the action Action item # items tracker based on participant feedback Date requested Date the action item was requested Organization name Name of the participating organization that requested the action item Action category Category of the action item (user interface, data model, installation, API, documentation, or other) Action item Detailed description of the requested action item Timeline within which the action item was to be addressed. Each action was categorized into one of three timelines: – Short-term: Actions with a relatively low burden on the prototype development team’s capacity (e.g. fixing an identified bug), which were completed as soon as possible – Before end of Sim III: Actions with a relatively high burden on the prototype development Timeline team’s capacity, which were in scope for Simulation III (e.g. building a glossary page of key definitions on the user interface) – Suggestion to operational entity: Actions that were out of scope for Simulation III and logged as suggestions for the new governing body of the operational Climate Warehouse (e.g. substantial changes to the data model) Unique GitHub ticket number, corresponding to the unique issue number on the “issues” tab of GitHub ticket # the Climate Warehouse GitHub repository15 Status of the action item. Each action was tagged as one of five statuses, depending on its completion status: – Not yet confirmed for development: All potential actions were given this tag when they were initially added to the action items tracker – Discuss with operating team: Potential actions that required testing and simulation team input for confirmation were given this tag and raised during weekly meetings – Not started: Potential actions that the testing and simulation team categorized as “suggestions to operational entity” in the “timeline” column or decided not to pursue were Status given this tag – In progress: Actions that the testing and simulation team confirmed were tagged as “in progress” and submitted to the prototype development team – Completed: Actions that were implemented and reflected as updates to the Climate Warehouse were given this tag. All actions that were categorized as “short-term” or “before end of Sim III” in the “timeline” column were tagged as “completed” in the final version of the action items tracker that was shared with the new governing body of the operational Climate Warehouse at the end of Simulation III 15 For more information, see https://github.com/Chia-Network/climate-warehouse/issues. 22 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT S ECT IO N 0 5 05 SIMULATION III PARTICIPANTS Overall Testing Statistics The Climate Warehouse Simulation III prototype was tested with 30 participating organizations and 75 testers across 58 testing sessions (see Figure 10). In addition to the 58 testing sessions, over 40 weekly office hour sessions and over 30 kick-off and onboarding meetings were completed. FIGURE 10: Participating organizations, testers, and testing sessions 40 38 36 30 20 18 19 15 12 11 10 10 4 0 # of participating organizations # of testers # of testing sessions Group 1 Group 2 Group 3 CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 23 SECT I O N 5 : OV E RAL L TESTIN G STATISTICS The testers in each of the three groups included members of the Climate Warehouse software upon integration), or both roles (see participating organizations with business or research roles (including Figure 11). Each participating organization was asked to engage a team policy setters, registry administrators, and professionals with expertise of testers that included business or research roles and IT roles to ensure in carbon markets, the environment, and other relevant areas), IT roles that they could provide comprehensive feedback on the Simulation III (including members of participating organizations who would manage prototype from a diverse range of perspectives and expertise. FIGURE 11: Tester roles 18 38 19 100% 2 4 4 14 80 1 2 # of testers 60 40 13 22 13 20 0 Group 1 Group 2 Group 3 Business/research IT IT & business/research COMPLETED TESTING AREAS them to examine and provide feedback on the Climate Warehouse’s data model. The number of testers who completed each testing area varied by • API: The API feature was tested by seven testers. The number testing area (see Figure 12): of testers was relatively low because testing the API required • Installation: The installation process was tested by substantial time and technical expertise to simulate 21 testers who were interested in examining the Climate automated integration to the Climate Warehouse. Warehouse’s technical architecture and learning how to install • Excel import/export: The Excel import/export feature was and run the Climate Warehouse software. tested by 11 testers who were interested in examining the • User interface: The user interface was tested by 68 testers. Climate Warehouse’s ability to accept data updates in bulk Most testers completed this testing area because it enabled using the Excel template provided. 24 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT SECT IO N 5 : OV E RAL L TESTIN G STATISTICS FIGURE 12: Completed testing areas 40 35 30 # of testers 20 18 15 12 10 9 7 6 2 2 1 0 Installation User interface API Excel import/export Group 1 Group 2 Group 3 SELECTED DEPLOYMENT MODELS Four group 2 testers selected the Cloud – own organizational cloud deployment model and deployed the Climate Warehouse on cloud A majority of Simulation III testers selected the Cloud – hosted computers that were set up by their local organization and hosted instance deployment model because it was the quickest way to by Microsoft Azure Kubernetes Service. After resolving some minor test the user interface and the Climate Warehouse data model (see troubleshooting, which involved one of the testers being unable to Figure 13). The second most frequently selected was the Cloud sync their blockchain node to the blockchain layer on first attempt, – AWS workspace deployment model, which was selected by these testers were able to successfully demonstrate that the testers with technical expertise and interest in testing the Climate Climate Warehouse can be deployed in cloud computers that are Warehouse’s installation process or the API integration feature. set up by participating organizations and hosted by cloud service Both deployment models were implemented successfully and providers other than AWS. smoothly by most testers, demonstrating their viability as options for participants to quickly deploy the Climate Warehouse. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 25 SECT I O N 5 : OV E RAL L TESTIN G STATISTICS Three group 3 testers selected the local installation deployment blockchain nodes to transact cryptocurrency). Furthermore, the locally model and deployed the Climate Warehouse on cloud computers that hosted virtual computers’ relatively low internet speeds doubled were set up and hosted by their local organization. Given the need the duration of the blockchain node synchronization process from for the testers’ organization to deploy the Climate Warehouse in its the standard two-week period to a four-week period. Ultimately, local IT system in this model, the testers had to attain security and the testers were able to deploy the Climate Warehouse, which legal approvals to ensure compliance with local requirements (e.g. the successfully demonstrated that participating organizations can testers had to attain specific approval to allow their Climate Warehouse deploy the Climate Warehouse in their local IT networks. FIGURE 13: Selected deployment models 18 38 19 100% 4 3 3 80 11 4 60 # of testers 15 40 12 23 20 0 Group 1 Group 2 Group 3 Cloud - hosted instance Cloud - AWS workspace Cloud - own organizational cloud Local installation 26 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API S ECT IO N 0 6 EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK 06 Participant Feedback OVERVIEW overall highlights and learnings from participating in Simulation III. Over the five months of Simulation III testing between March and In terms of overall highlights, many participants highlighted the July 2022, 514 points of feedback were received in completed test critical value of the Climate Warehouse’s fundamental value scripts, testing sessions, office hours, feedback survey responses, proposition to integrate the carbon market ecosystem under a and email exchanges. All participant feedback was recorded in the common data model. Participants also noted that the Climate feedback tracker, participant profiles, and feedback profiles, which Warehouse’s open-source design and use of blockchain technology were shared with the Climate Warehouse’s governing body at the will contribute to greater transparency and security in global end of Simulation III. carbon markets. Furthermore, participants shared support for the Climate Warehouse’s iterative approach to engage and build As part of the process to synthesize participant feedback into consensus among a diverse range of carbon market stakeholders. development actions, each point of feedback was categorized into one of 11 categories: overall highlights and learnings, overall In terms of learnings, participants noted that simulating integration satisfaction, installation, data model, user interface, API, Excel with the Simulation III prototype helped build operational import/export, technical architecture, governance, recommended capacity to integrate with the operational Climate Warehouse additional features, and perspectives on blockchain technology. This and manage data updates. Participants also noted that examining section details participants’ feedback in each of these categories. the Climate Warehouse data model clarified their understanding of how carbon registries with different taxonomies could align on a unified data model. Table 3 summarizes participants’ overall OVERALL HIGHLIGHTS highlights and learnings. AND LEARNINGS In the feedback survey, participants were asked to share their CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 27 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK TABLE 3: Summary of participants’ overall highlights and learnings CATEGORY PARTICIPANT FEEDBACK The proactive engagement of a diverse range of carbon market stakeholders, responsiveness to participant feedback, iterative process to seek buy-in, and willingness to innovate are helping to develop a system with significant potential to contribute to global carbon markets The Climate Warehouse fulfills a very relevant function by aggregating and harmonizing different registry systems and is critical for the successful implementation of Article 6 Overall highlights The Climate Warehouse will help make market systems more transparent and contribute to greater accuracy of information on carbon projects and units The Climate Warehouse’s use of blockchain technology brings immutability and security to carbon markets The Climate Warehouse has the potential to fill substantial capacity gaps in registry systems, especially for least developed countries Participating in Simulation III provided a clearer understanding of how carbon markets could align on a unified data model Simulating integration with the current prototype helped develop operational capacity to Overall learnings integrate with the operational Climate Warehouse and manage data updates Examining the Climate Warehouse’s data model helped identify potential improvements to the taxonomies of existing carbon registries OVERALL SATISFACTION The feedback survey solicited respondents’ overall satisfaction levels with participating in Simulation III. Specifically, respondents were asked to indicate the extent to which the documentation and technical support that they received met their expectations, and share how likely they are to integrate their registries with the Climate Warehouse based on their testing experience. Figure 14 displays survey respondents’ overall satisfaction levels. 28 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK FIGURE 14: Overall satisfaction levels 26 26 26 100% 5 6 80 # of survey respondents 18 8 60 40 20 9 20 8 1 3 0 The documentation that I The technical support How likely are you to integrate received to understand the that I received throughout your registry into the Climate purpose and functionalities the simulation . . . Warehouse, based on your of the Climate Warehouse . . . testing experience? Neutral . . . met my expectations . . . exceeded my expectations Very likely Unlikely Likely Very unlikely Table 4 summarizes participants’ commentary on their overall satisfaction levels with the documentation that they received to understand the purpose and functions of the Climate Warehouse. TABLE 4: Summarized commentary on participants’ overall satisfaction with the documentation received SATISFACTION LEVEL PARTICIPANT COMMENTARY The modular design of the documentation was easy to navigate and digest Exceeded my expectations The documentation provided clear guidance on each step of the testing process The documentation was rich, clear, and complete The presentations and explanatory meetings provided a clear understanding of the information Met my expectations included in the documentation The documentation was self-explanatory and could be followed without additional assistance CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 29 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK Table 5 summarizes participants’ commentary on their overall satisfaction levels with the technical support that they received throughout the simulation. TABLE 5: Summarized commentary on participants’ overall satisfaction with the technical support received SATISFACTION LEVEL PARTICIPANT COMMENTARY The responsiveness, willingness to make changes, and hands-on nature of the technical support was excellent Exceeded my The technical support team was always available expectations When probed on the rationales behind certain features, the team provided very clear supporting information and clarification The numerous calls conducted to provide technical assistance were very helpful Met my expectations The team was always very fast in providing assistance The team provided very clear guidance and was always supportive Table 6 summarizes participants’ commentary on their overall likelihood of integrating their registry with the Climate Warehouse based on their testing experience. TABLE 6: Summarized commentary on participants’ overall likelihood of integrating their registry with the Climate Warehouse based on their testing experience LIKELIHOOD PARTICIPANT COMMENTARY Integrating with the Climate Warehouse is critical to contribute to the transparency, interoperability, and integrity of the global carbon market Very likely Integrating with the Climate Warehouse will generate positive synergies with existing registries’ or likely ongoing efforts The Climate Warehouse is the best alternative out there to provide a one-stop platform for all information pertaining to registries Integrating with the Climate Warehouse will depend on additional features to be developed (e.g. smart contract-enabled inter-registry carbon credit transfers) Neutral The decision to integrate with the Climate Warehouse depends on multiple other internal stakeholders and requires significant deliberation and consensus building Unlikely or very The decision to integrate with the Climate Warehouse depends on multiple other factors unlikely 30 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK INSTALLATION consider participants’ local IT security and legal requirements. Most participants highlighted that the installation process was user- Feedback on the installation process of the Climate Warehouse friendly and straightforward given the complexity of the system, while was primarily collected from the 21 testers who completed the a subset suggested that the process should be further streamlined installation testing area. Most testers who completed the Climate and simplified (e.g. consolidate steps, provide a virtual machine Warehouse installation process were able to successfully install with pre-installed software, or reduce the time required to sync the the Climate Warehouse, user interface and Chia software; set up a blockchain node). Troubleshooting was limited to a few participants cryptocurrency wallet; and sync their blockchain node. A handful who experienced challenges due to the 100GB hard disk space of testers were unable to complete the installation process on requirement, their local security requirements or were unable to sync devices hosted by their local organizations because some of the their blockchain nodes on first attempt. steps conflicted with their local IT security or legal requirements (e.g. virtual machine connections were limited to a known list of Overall, 69 percent of feedback survey respondents who tested internet protocol addresses or the AWS desktop application could the installation process indicated that the installation process not be downloaded). met their expectations, 23 percent indicated that it exceeded their expectations, and 8 percent indicated that it did not meet their Participants noted that it will be particularly critical for the operational expectations (see Figure 15). Table 7 summarizes participants’ Climate Warehouse to ensure that the required installation steps feedback on the installation process. FIGURE 15: Installation satisfaction levels 13 100% # of survey respondents who tested installation 3 80 . . . did not meet my expectations 60 . . . met my expectations 9 40 . . . exceeded my expectations 20 1 0 The Climate Warehouse installation process . . . CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 31 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK TABLE 7: Summarized feedback on the installation process CATEGORY PARTICIPANT FEEDBACK For integration to the operational Climate Warehouse, it is critical that the Climate Warehouse can meet participating organizations’ security and legal requirements Based on existing security and legal protocols, the Climate Warehouse’s requirement for participants to transact cryptocurrencies is particularly challenging to accommodate The governing body should provide participants with a laptop or virtual desktop to Technical requirements facilitate integration with the operational Climate Warehouse due to the 100GB hard disk space requirement The security and threat model of the Climate Warehouse is a crucial document required in the process of installing the software in the local IT system The 100GB hard disk requirement could be challenging to accommodate when installing and maintaining the Climate Warehouse in the local IT system The installation process was fast, smooth, and user-friendly Considering the complexity of the system, the installation process was straightforward Installation was not straightforward due to the many components to install, but with the available documentation and support it was manageable User experience It would be great if the back-end and front-end installation steps were consolidated into one installation step It would be great if the Climate Warehouse could provide a virtual machine with pre-installed Climate Warehouse software The Climate Warehouse should make sure that the duration of the blockchain node sync process remains feasible as more organizations and data are added to the Climate Warehouse Some participants could not complete the installation process due to conflicts with their local IT requirements Troubleshooting For one tester, the Climate Warehouse application did not sync with the data layer on their first attempt. The tester had to restart the sync process to resolve 32 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK DATA MODEL of participants also proposed new data fields that would help enhance the Climate Warehouse data model (e.g. a “cooperative Feedback on the Climate Warehouse data model was primarily approach” data field). collected from the 68 testers who tested the user interface, which visualizes the data model through interactive steps to create a project More broadly, participants suggested that the Climate Warehouse and a unit. Participants’ feedback on the data model fell into one of data model could introduce more data validation rules (e.g. reject seven categories: data field modifications, picklist options, new data unrealistic dates) and picklist options to improve data quality and fields, data harmonization, data mapping, definitions, and highlights. harmonization. While comparing the Climate Warehouse data model with their own taxonomies, multiple participants also noted The most common data field modification request was to convert specific required data fields in which they would have to submit specific data fields from required fields to optional fields (e.g. many “null” or “N/A” values due to confidentiality, lack of data, or other participants requested that the “unit owner” field should be made issues. Finally, multiple participants requested improvements to optional because this information is frequently confidential). In the Climate Warehouse’s definitions of specific data fields and addition, participants suggested that certain free text data fields picklist options to help clarify and standardize the use of key should be converted to “select from picklist options or add a terminologies. new option” data fields, to improve data harmonization (e.g. the “verification body” data field). Overall, 77 percent of feedback survey respondents who tested the user interface indicated that the Climate Warehouse data model With regards to picklist options, multiple participants suggested met their expectations, 15 percent indicated that the data model that users should be able to add new picklist options to certain did not meet their expectations, and 8 percent indicated that the data fields that require more flexibility, in order to accommodate data model exceeded their expectations (see Figure 16). Multiple registries’ different taxonomies (e.g. the “project type” and participants highlighted that the Climate Warehouse data model “methodology” data fields). Participants also suggested that is sufficiently comprehensive and that the data harmonization the picklist options should be streamlined in certain data fields it enables will contribute significantly to global carbon markets. (e.g. the “project status” and “unit status” data fields). A subset Table 8 summarizes participants’ feedback on the data model. FIGURE 16: Data model satisfaction levels 26 100% # of survey respondents who tested the user interface 2 80 . . . did not meet my expectations 60 . . . met my expectations 20 40 . . . exceeded my expectations 20 4 0 The Climate Warehouse data model and data fields . . . CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 33 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK TABLE 8: Summarized feedback on the data model CATEGORY PARTICIPANT FEEDBACK The “unit owner” data field should be made optional because the unit owner cannot be disclosed in many cases The “country jurisdiction of owner” data field should be made optional because this information cannot be disclosed in many cases Convert the “unit type” data field to an optional field or allow users to input “unknown”, since many registries do not currently track this information Data field The “covered by NDC” data field should be converted from a required data field to an optional data field, since modifications Article 6 of the Paris Agreement no longer requires this information to be tracked for carbon units Convert the “verification body” data field and the open-ended tag and label fields to require users to either select from existing picklist options or add new picklist options in order to improve data harmonization The “unit metric” data field should cover non-GHG metrics The Climate Warehouse should allow registries to submit “null” or “N/A” values for a subset of required data fields due to confidentiality, lack of data, or other issues Users should be able to add new picklist options for the “validation body”, “project sector”, “project type”, “methodology”, and “rating type” data fields, as needed The picklist options for the “current registry” data field should include additional placeholders for reporting mechanisms under development The data field “marketplace” should include picklist options such as “tokenized” The “project sector” data field should use the International Standard Industrial Classification of All Economic Activities (ISIC) for its picklist options The picklist options for the “project status” data field should be streamlined (e.g. add options for “de-registered” and “withdrawn”) Picklist options A “partially NDC” picklist option should be added to the “covered by NDC” project data field, since some projects include both units that are covered by an NDC and units that are not covered by an NDC The picklist options “exported” and “pending export” in the “unit status” data field can be misleading in terms of the status or ownership of the carbon credit The “project type” data field should use benchmark databases such as Clean Development Mechanism (CDM) pipeline, Berkeley’s Offsets database and Institute for Global Environmental Strategies CDM project database for its picklist options The picklist options of the “unit type” data do not reflect all the types of units. This data category will need to be revisited as the market keeps evolving The picklist options of the “methodology” data field should include the version number of the specific methodology as these are constantly evolving Geographic information system data should be added to the Climate Warehouse data model to enable data to be mapped spatially New data A new data field should be created for users to note cooperative approaches fields A new data field should be created for users to note how they plan to use the carbon credit (e.g. offset or contribution claim) Data The Climate Warehouse should introduce more data validation rules and picklist options in data fields to harmonization encourage greater data standardization and harmonization (e.g. project locations and project sectors) The Climate Warehouse should provide clearer definitions for certain data fields and picklist options. Participants specifically requested clearer definitions for the “project status”, “unit status”, “rating type”, “rating Definitions value”, “label”, “label type”, “unit type”, “verification approach”, “country jurisdiction of owner”, “corresponding adjustment declaration”, “project status date”, “NDC information”, and “unit metric” data fields 34 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK TABLE 8: Summarized feedback on the data model (continued) CATEGORY PARTICIPANT FEEDBACK The data model is comprehensive and demonstrates the progress from three years of testing The data model has a clear taxonomy and is sufficiently comprehensive considering that carbon market rules and consensus are evolving in parallel Highlights The data harmonization that the Climate Warehouse has the potential to achieve will make a significant contribution to carbon markets The Climate Warehouse is well advanced in navigating the complexity of getting to a shared data model USER INTERFACE Similarly, participants shared a wide variety of suggestions to optimize the user experience, ranging from alphabetizing long Feedback on the Climate Warehouse user interface was primarily picklist options to streamlining the steps to create a project and collected from the 68 testers who completed the user interface testing a unit. Extensive testing also helped identify and troubleshoot area. These testers received a demonstration of the interface’s key multiple bugs, such as malfunctioning of the “date selector” feature features; created an organization, projects, and units; and simulated and users not being able to upload their organization logos. a unit lifecycle by editing created project and unit data. Participants’ feedback on the user interface fell into one of four categories: Overall, 69 percent of feedback survey respondents who tested the additional features, user experience, troubleshooting, and highlights. user interface indicated that the Climate Warehouse user interface met their expectations, 15 percent indicated that it did not meet Based on their experiences with testing the user interface, their expectations, and 15 percent indicated that it exceeded their participants suggested a wide range of additional features that expectations (see Figure 17). Multiple participants highlighted that would help enhance its functionalities. These suggestions ranged the user interface is user-friendly and seamless, and some indicated from very detailed suggestions, such as to add scroll bars to long that they would like to see improvements to the user experience in picklists, to more global suggestions, such as to build a glossary the operational version. Table 9 summarizes participants’ feedback page that includes definitions for all data fields and picklist options. on the user interface. FIGURE 17: User interface satisfaction levels 26 # of survey respondents who tested the user interface 100% 4 80 . . . did not meet my expectations 60 18 . . . met my expectations 40 . . . exceeded my expectations 20 4 0 The Climate Warehouse user interface . . . CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 35 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK TABLE 9: Summarized feedback on the user interface CATEGORY PARTICIPANT FEEDBACK Add a dynamic search function that enables users to filter long picklists by typing  Add a glossary page to which users can refer for the definitions of data fields and picklist options Add a confirmation notification to inform users that their updates have been saved Enable users to input more than one location for a single project Add a scroll bar feature to help users navigate long picklists Enable users to split units into more than two blocks Additional features Add an ability for users to merge units Add more sorting and filtering options to enhance the user experience Add a capability to facilitate carbon unit transactions between registries and track each unit’s “paper trail” Allow users to customize the “projects list” and “units list” tables Add a global dashboard that enables users to easily view key metrics (e.g. total quantity of emissions mitigated) Enable more than one user to access the same instance of the Climate Warehouse Make it optional for users to submit a logo when creating their organization Streamline the order of forms when creating a project or a unit and allow users to complete each form in any order Introduce an easier way to exit from drop-down lists (e.g. add an “X” to exit) Improve the linkages among projects, issuances, and units User experience Improve tooltips to help users better navigate the user interface Alphabetize picklist options, especially in data fields with long picklists Enable users to edit project and unit data directly from the staging tables Save inputted data automatically so that users can exit the project and unit creation windows without losing their data Convert dates to international date format Multiple users struggled to create their organization logos in scalable vector graphics format Some users were only able to create projects after they had cleared their browser caches Troubleshooting Some users encountered an error when unsubscribing from organizations The “date selector” feature did not function properly for multiple users The user interface is easy to use and has basic functionality Highlights The user interface is user-friendly and reflects a focus on optimizing the user experience The user interface allows flexible data entry 36 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK API Although there was a relatively lower number of testers who had the technical expertise to interact with Climate Warehouse APIs using API Feedback on the Climate Warehouse’s API feature was primarily tools, it should be noted that the design of the Climate Warehouse is collected from the seven testers who completed the API testing such that the user interface is a static electron application that makes area. These testers examined the Climate Warehouse’s API feature calls to specific APIs. This means that the 68 testers who completed by calling various API endpoints from API platform tools like the user interface testing area also indirectly tested the Climate Postman and were able to improve their understanding of how to Warehouse’s API feature on the back-end, while the seven testers build a middleware integration between their local registry systems who completed the API testing area specifically tested the ability for and the Climate Warehouse. the Climate Warehouse’s API endpoints to be called by API tools. TABLE 10: Summarized feedback on the API feature CATEGORY PARTICIPANT FEEDBACK Create an option for users to publish only a subset of projects and units When users insert units with issuances that do not yet exist, automatically and instantaneously Additional features generate an update to the relevant project to add the necessary issuance Enable users to submit “null” values through the API Add more API endpoints to enable users to access the audit feature and their home organization Provide the warehouse project identification number when publishing a new project or new unit Provide a more detailed response for “insert validation” failures indicating the type of failure and User experience the specific fields that failed validation Do not change API keys from the testing phase when the Climate Warehouse is operationalized In some cases, calling API endpoints from participants’ local applications led to “503 service not Troubleshooting available” errors Participants experienced occasional network errors when back-end services were not running Provide a list of ports that need to be open for incoming and outgoing requests. In addition, provide Documentation details on their protocols Update the API-related documentation on the Climate Warehouse’s GitHub repository The API is a critical feature since it enables automated integration with the Climate Warehouse Highlights The API is a necessary alternative to the user interface for integration with the operational Climate Warehouse, to avoid manual and onerous data input through the user interface CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 37 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK Participants’ feedback on the API feature fell into one of five categories: the Excel import/export testing area. These testers mapped their additional features, user experience, troubleshooting, documentation, own organization’s data fields to the Climate Warehouse’s data and highlights. fields, populated the Excel upload template with sample registry data, published the populated sample data using the Excel import Participants who tested the Climate Warehouse’s API identified feature, edited published data using the Excel upload template, multiple additional features that would help enhance participating and exported published data in Excel format. Participants’ feedback organizations’ automated integration with the Climate Warehouse. on the Excel import/export feature fell into one of three categories: Many of these suggestions included requests for the Climate user experience, troubleshooting, and highlights. Warehouse to add specific endpoints (e.g. to access the audit feature), which would improve the system’s accessibility. Furthermore, testers Regarding the user experience, participants suggested that the noted that it would be helpful if they could submit “null” values Excel upload template should be more easily accessible on the through the APIs and had an option to publish only a subset of project user interface and that any displayed error messages should and unit data. be displayed for longer and logged. Participants also proposed specific improvements to the Excel upload template itself, including In terms of the user experience, participants’ suggestions included a request to add more automatic references to help avoid repetitive adding further detail to error responses when data uploads fail. user input. Troubleshooting was limited to a few instances when participants were unable to connect to the Climate Warehouse API endpoints and Participants’ troubleshooting experiences with the Excel import/ experienced network errors. Finally, participants requested updates to export feature helped identify multiple development actions on the API-related documentation on the Climate Warehouse’s GitHub the feature’s initial release. This led to an updated release of the repository, including further details on the data ports that need to be feature, which successfully enabled participants to publish registry open for incoming and outgoing requests. data to the Climate Warehouse in bulk. Participants continued to help identify improvements to the back-end system of the updated Overall, all five feedback survey respondents who tested the API release (e.g. data inputs should not be required in optional fields). feature indicated that it met their expectations. Multiple participants highlighted the critical importance of the API feature as an automated Overall, 83 percent of feedback survey respondents who tested the alternative to the user interface’s relatively manual data input process. Excel import/export feature indicated that the Climate Warehouse Table 10 summarizes participants’ feedback on the API feature. user interface met their expectations, while 17 percent indicated that it exceeded their expectations (see Figure 18). Multiple testers highlighted the importance of the Excel import/export feature to EXCEL IMPORT/EXPORT enable users to publish data to the Climate Warehouse in bulk. Feedback on the Climate Warehouse’s Excel import/export feature Table 11 summarizes participants’ feedback on the Excel import/ was primarily collected from the 11 participants who completed export feature. 38 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK FIGURE 18: Excel import/export satisfaction levels 6 100% # of survey respondents who tested the Excel 1 80 import /export feature . . . met my expectations 60 . . . exceeded my expectations 5 40 20 0 The Climate Warehouse user interface . . . TABLE 11: Summarized feedback on the Excel import/export feature CATEGORY PARTICIPANT FEEDBACK The Excel template for uploading data should be easier to access on the user interface The error messages that are displayed in the user interface should be displayed for longer User experience Users should be able to access a record of past error messages Add automatic references in the Excel template to avoid repetitive user input Multiple participants were unable to upload data to the Climate Warehouse using the Excel import/export feature in the initial release of the Simulation III prototype Bugs in the back-end system treated the asterisks in the Excel upload template as invalid data Troubleshooting inputs and required optional fields to include data inputs In some instances, the Excel export feature did not export the latest data that was previously uploaded by the user The Excel import/export feature was easy to use and useful for publishing and editing a large Highlights quantity of data at once CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 39 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK TECHNICAL ARCHITECTURE from a wide range of computers. Participants also suggested that the Climate Warehouse should be compatible with a range of cloud Multiple participants provided feedback on the Climate Warehouse’s service providers and that multiple users should be able to access a overall technical architecture as they completed their respective single hosted instance. testing areas and identified system-level feedback on the Climate Warehouse. Participants’ feedback on the technical architecture fell Most points of feedback on the technical architecture were requests into one of three categories: technical requirements, deployment, for documentation that further clarifies key elements of the and documentation. technical architecture (e.g. long-term transaction fee projections, a comprehensive threat model, or a detailed user manual). Table 12 Regarding the technical requirements, participants’ feedback summarizes participants’ feedback on the Climate Warehouse’s included requests that the Climate Warehouse’s transaction fees technical architecture. remain affordable and that users are able to host blockchain nodes TABLE 12: Summarized feedback on the Climate Warehouse’s technical architecture CATEGORY PARTICIPANT FEEDBACK Transaction fees to publish data to the Climate Warehouse should remain affordable and not disincentivize data updates Technical requirements Users should be able to host a blockchain node in a Linux box (e.g. Red Hat Linux) The Climate Warehouse should be compatible with other cloud service providers (e.g. Microsoft Azure Kubernetes Service) Deployment Enable multiple users to access the same hosted instance of the Climate Warehouse Provide further guidance on how and why participants need to hold and transact in cryptocurrencies to publish data to the Climate Warehouse Provide guidance on the expected long-term trends of the Climate Warehouse transaction fees Provide a comprehensive threat model that shares guidance on the security considerations for participating in the Climate Warehouse Outline the specific technical requirements that participants will need to meet when the operational Climate Warehouse is launched Documentation Clarify further how the Climate Warehouse stores data in its blockchain layer Provide further guidance on how the Climate Warehouse’s governance node interacts with the blockchain nodes that are hosted by Climate Warehouse participants Provide further guidance on how the Climate Warehouse can help detect instances of double counting and facilitate carbon unit transfers Provide a detailed user manual that participants can refer to 40 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK GOVERNANCE data updates, optimizing the Climate Warehouse’s data validations, and managing the governance node’s list of known organizations. Participants provided feedback on the governance of the Climate Warehouse as they completed their testing areas and identified Participants also provided multiple suggestions for how the governing aspects of the Climate Warehouse that will be particularly critical body can optimize the operational support that it provides to Climate for the governing body to coordinate. Participants’ feedback on Warehouse participants (e.g. provide online technical support through a governance fell into one of three categories: governance protocols, live chat feature). Multiple participants that did not have carbon registries operational support, and documentation. also requested additional operational support to help build a carbon registry and enable their integration with the Climate Warehouse. Participants identified multiple governance protocols that the Finally, participants requested documentation that further clarifies governing body of the Climate Warehouse will need to develop and how participating organizations are expected to meet the Climate implement to optimize the functionality of the Climate Warehouse. Warehouse’s transaction fee requirements. Table 13 summarizes These protocols included standardizing the timelines of participants’ participants’ feedback on the governance of the Climate Warehouse. TABLE 13: Summarized feedback on the governance of the Climate Warehouse CATEGORY PARTICIPANT FEEDBACK Introduce a standard protocol for the timeline and frequency of data updates among participating organizations to mitigate the “staleness” of registry data in the Climate Warehouse Provide guidance on how participants are expected to reflect ITMO transfers in the Climate Warehouse (e.g., coordination between unit-sending and unit-receiving registries) Governance protocols Review and optimize the Climate Warehouse’s data validation protocols to maximize data accuracy while ensuring sufficient flexibility and autonomy Develop and implement a protocol for how the governing body will maintain the governance node’s public list of known organizations Provide hands-on technical support (e.g., online technical support through a live chat feature) when the Climate Warehouse is operationalized Provide detailed guidance on operational requirements for participating organizations (e.g. the expected operating costs of integrating with the Climate Warehouse) Operational support Provide additional operational support to help build a carbon registry and enable integration with the Climate Warehouse Provide new participants with tutorial recordings to facilitate the onboarding process Share guidance on how participants are expected to meet the Climate Warehouse’s transaction Documentation fee requirements CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 41 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK RECOMMENDED ADDITIONAL FEATURES In the feedback survey, respondents were asked to select additional features that they would recommend for the operational Climate Warehouse. Respondents were provided with four additional features to consider: add geospatial data, add a global dashboard, add more sorting and filtering features to the user interface, and offer greater language support. Figure 19 displays the percentage of survey respondents who recommended each additional feature. FIGURE 19: Additional features recommended 100% % of survey respondents who recommend the feature 80 62% 60 50% 46% 40 38% 20 0 Add more sorting Add a global Add geospatial Offer greater and filtering features dashboard data language support to the user interface PERSPECTIVES ON BLOCKCHAIN • Statement 1: Blockchain technology improves security and enables registry autonomy while assuring trust for TECHNOLOGY shared climate registry metadata. The feedback survey also solicited participants’ perspectives on the • Statement 2: Carbon market data layers should be public, Climate Warehouse’s use of blockchain technology. Specifically, with permissionable data edit functionality, and operate respondents were asked to indicate the extent to which they agree or under a decentralized governance system. disagree with three statements regarding the Climate Warehouse’s • Statement 3: The specific blockchain technology used for use of blockchain technology: the Climate Warehouse matters a lot. Figure 20 displays survey respondents’ levels of agreement with each statement. 42 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT IO N 6 : PARTICIPAN T FE E DBACK FIGURE 20: Perspectives on blockchain technology 26 26 26 100% 5 5 7 80 # of survey respondents 10 9 60 8 15 15 15 40 7 8 20 10 2 2 3 0 1 1 “Blockchain technology “Carbon market data layers should “The specific blockchain improves security and enables be public, with permissionable technology used for registry autonomy while data edit functionality, and the Climate Warehouse assuring trust for shared operate under a decentralized matters a lot” climate registry metadata” governance system” Strongly disagree Disagree Neither agree nor disagree Agree Strongly agree Table 14 summarizes participants’ commentary on their levels of agreement with statement 1: Blockchain technology improves security and enables registry autonomy while assuring trust for shared climate registry metadata. TABLE 14: Summarized commentary on participants’ agreement with blockchain statement 1 AGREEMENT LEVEL PARTICIPANT COMMENTARY The Climate Warehouse’s use of blockchain technology is an ideal fit for the bottom-up approach of the Paris Agreement Strongly agree or agree Blockchain technology enhances the traceability and transparency of carbon market data To ensure the transparency of carbon credits, blockchain technology must be used to record transactions It is critical for blockchain technology to be used to facilitate transactions between registries It would be helpful to better understand how the use of blockchain technology improves on a centrally Neither agree managed system nor disagree Blockchain has multiple applications and can help support security and transparency if designed with a holistic approach Disagree or strongly It is better to directly apply blockchain technology to registry systems, rather than to the metadata layer disagree CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 43 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE | API EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES | PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY SECT I O N 6 : PARTICIPAN T FE E DBACK Table 15 summarizes participants’ commentary on their levels of agreement with statement 2: Carbon market data layers should be public, with permissionable data edit functionality, and operate under a decentralized governance system. TABLE 15: Summarized commentary on participants’ agreement with blockchain statement 2 AGREEMENT LEVEL PARTICIPANT COMMENTARY Blockchain technology will help improve transparency and interoperability in carbon markets Strongly agree Publicly auditable data will be critical to enable interoperability among different carbon frameworks or agree The governing body of the Climate Warehouse will need to ensure that the Climate Warehouse complies with existing legal frameworks and produces actionable data for the service layer  The Climate Warehouse will need to ensure that it strikes the right balance between efficiency and complexity to maximize adoption Neither agree Although participants should be able to edit their own data, there should also be a decentralized nor disagree mechanism for all users to flag data discrepancies, augmented by web-crawling or artificial intelligence, and a centralized team to resolve or confirm any changes. This will be critical to ensure that stakeholders can trust the Climate Warehouse as a credible and accurate source of registry data Disagree or strongly Decentralized systems add complexity and are not suitable for a metadata layer that connects climate disagree registries that are not anonymous Table 16 summarizes participants’ commentary on their levels of agreement with statement 3: The specific blockchain technology used for the Climate Warehouse matters a lot. TABLE 16: Summarized commentary on participants’ agreement with blockchain statement 3 AGREEMENT LEVEL PARTICIPANT COMMENTARY The blockchain technology provider must be responsive, reliable, and willing to support the Climate Warehouse on a public good and open-source basis The technology should be future-proof, environmentally sustainable, and secure  Strongly agree The environmental impact and security considerations of the blockchain technology matter a lot or agree It is important to adopt a technology that preserves the integrity and utility of the Climate Warehouse’s carbon metadata. There should be safeguards in place to ensure that there are no loopholes, caused by the blockchain technology, that undermine the accuracy and transparency of the Climate Warehouse’s data management The specific technology is not very important as long as it enables interoperability and is Neither agree environmentally sustainable nor disagree The specific technology matters to the extent that it is accessible and can be installed quickly Disagree or strongly The differentiation among alternative blockchain technologies is limited disagree The specific technology does not matter as long as it does not introduce any critical risks to the system 44 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE S ECT IO N 0 7 API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY 07 Lessons Learned OVERVIEW This section first summarizes the lessons and development actions that were identified from participant feedback in each of the Based on internal testing and the 514 points of feedback received 11 feedback categories that were presented in section 6: overall from participants during Simulation III, the testing and simulation highlights and learnings, overall satisfaction, installation, data model, team identified 156 development actions, which were added to user interface, API, Excel import/export, technical architecture, the action items tracker. The team considered each action through governance, recommended additional features, and perspectives its structured prototype development decision-making process, on blockchain technology. This section then summarizes Simulation allocated a timeline for completion (“short-term”, “before end of Sim III’s limitations and details the testing and simulation team’s III”, or “suggestion to operational entity”), and tracked the status of recommendations for the new governing body. each action to completion, as explained in Section 4. Among the 156 development actions that were identified in OVERALL HIGHLIGHTS Simulation III, 114 were categorized as “short-term”, 25 were AND LEARNINGS categorized as “before end of Sim III”, and 17 were categorized as Participants’ overall highlights and learnings, which they shared in “suggestion to operational entity”. All development actions that their feedback survey responses, helped identify specific aspects were categorized as “short-term” or “before end of Sim III” were of the Climate Warehouse that are particularly compelling for completed by the end of Simulation III. The development actions that participants. Participants’ overall highlights helped show that were categorized as “suggestions to operational entity” were logged participants view the Climate Warehouse’s efforts to proactively in the final version of the action items tracker, which was shared with engage diverse stakeholders, integrate the carbon market ecosystem the governing body of the operational Climate Warehouse at the under a common data model, and contribute to the implementation end of Simulation III. of Article 6 as the most critical aspects of the Climate Warehouse’s value proposition. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 45 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D Furthermore, participants’ overall learnings confirmed the importance most commonly noting as their rationale the need to involve more of the Climate Warehouse’s iterative and multistakeholder approach, internal stakeholders before making a decision. As such, it will be based on multiple participants’ responses that participating critical for the new governing body to facilitate consensus building in Simulation III enhanced their understanding of registry data within organizations that are considering integration with the harmonization and capacities to integrate with the Climate Warehouse. Climate Warehouse in order to successfully expand the number of participating organizations. Going forward, it will be critical for the new governing body to ensure that the Climate Warehouse maintains the aspects of its value proposition that are most important to participants and INSTALLATION that the Climate Warehouse continues to follow an iterative and The 21 testers who completed the installation testing area were multistakeholder approach. able to successfully install the Climate Warehouse software and sync their blockchain nodes with the blockchain layer, confirming that participants who meet the Climate Warehouse’s technical OVERALL SATISFACTION requirements can host a blockchain node and participate in the Participants’ overall satisfaction levels on the documentation Climate Warehouse. Furthermore, most of the feedback survey and technical support that they received during Simulation III respondents who tested the installation process noted that it and their likelihoods of integrating with the Climate Warehouse met or exceeded their expectations, indicating that Simulation III based on their experience, which they shared in their feedback participants were generally satisfied with the Climate Warehouse’s survey responses, helped identify key lessons that inform the installation process. new governing entity’s efforts to provide operational support and expand the number of participants. Most testers were able to complete the installation process within the standard two-to-three-week period, while a subset of testers All survey respondents indicated that the documentation that they experienced delays due to a variety of factors including the Climate received during Simulation III met or exceeded their expectations, Warehouse’s current 100GB hard disk requirement, restrictive particularly highlighting the documentation’s modular and self- local IT security and legal requirements, and slow internet speeds. explanatory design. This suggests that the current documentation As such, a key learning on the installation process was that new sufficiently meets participants’ needs and that the new governing Climate Warehouse participants need to be provided with ample body should continue to design additional documentation in a time and operational support (e.g. through recorded tutorials and similar manner. online support) to navigate the installation steps, attain any required security and legal approvals, sync their blockchain nodes, and Participants’ satisfaction levels with the technical support that complete their integration with the Climate Warehouse. In addition, they received during Simulation III were even higher than their participants will need further information and guidance on how to satisfaction levels with the documentation, with 69 percent of manage the current 100GB hard disk requirement, which is likely participants indicating that the technical support exceeded their to increase as more data is uploaded in the Climate Warehouse. expectations. Participants’ commentary suggests that the new Furthermore, as a larger number of participants complete the governing body should continue to provide responsive, hands-on, installation process and provide feedback, it will be important for and knowledgeable technical support to maintain participants’ the governing body to regularly revisit the installation process and levels of satisfaction. implement updates that further simplify the process. In terms of participants’ likelihoods of integrating with the Climate Development actions on the installation process that were identified Warehouse, 50 percent of survey respondents indicated that they from participant feedback and completed during Simulation III are likely or very likely to integrate, suggesting that a majority of focused primarily on updating and maintaining documentation on participants are in favor of integration with the operational Climate the installation process, as well as actions that addressed a handful Warehouse. On the other hand, 35 percent of respondents indicated of troubleshooting cases (e.g. solving a bug in the back-end system that they are neither likely nor unlikely to integrate and 15 percent that prevented one user from connecting to the Climate Warehouse indicated that they are unlikely or very unlikely, with both groups metadata layer). 46 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT IO N 7 : L ES S O N S L EAR N E D DATA MODEL Most Simulation III participants provided substantial feedback on the Climate Warehouse data model that confirmed the critical importance of the Climate Warehouse’s effort to establish a common carbon data taxonomy, especially in the context of continuously evolving carbon market terminologies and definitions. Most participants were satisfied with the Climate Warehouse data model, as shown by the finding that over 80 percent of feedback survey respondents indicated that the data model met or exceeded their expectations. Most points of feedback on the data model led to incremental improvements (e.g. converting data fields from required to optional fields, streamlining picklist options, clarifying definitions, or converting free text data fields to “select from picklist” fields), rather than fundamental revisions (e.g. adding or removing data fields). This validated the progress that was made on the data model during simulations I and II and demonstrated that the Climate Warehouse is progressing towards an operational data model that meets the needs of carbon market stakeholders. Going forward, it will be critical for the new governing body to continue refining the Climate Warehouse data model, especially as new participants provide additional feedback and carbon market terminologies evolve. When implementing updates to the data model, it will be important for the governing body to leverage a multistakeholder approach that reconciles any points of disagreement (e.g. the data contained in certain fields may be confidential for some registries and public for others) and ensures that updates reflect consensus among carbon market stakeholders. Future data model updates will also need to strike an optimal balance between data harmonization and flexibility. This tradeoff was illustrated through requests from multiple participants to convert free text fields to “select from picklist option” fields while also allowing users to add new picklist options if the existing options do not meet their needs. For such “select from picklist option or add a new option” data fields, the governance body will need to implement a standard protocol to regularly review new picklist options that are introduced by participants and decide whether they should be added to the standard list that is supplied by the governance node. Table 17 summarizes the development actions on the data model that were identified and completed during Simulation III. In addition, Figure 21 visualizes the updates made to the initial data model at the start of Simulation III and Figure 22 visualizes the updated data model at the end of the simulation. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 47 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D TABLE 17: Summary of completed data model development actions CATEGORY COMPLETED DEVELOPMENT ACTION Converted the “unit owner” data field from a required to an optional field, based on multiple participants’ feedback that the unit owner is often confidential information that cannot be shared publicly Converted the “registry of origin”, “current registry”, “validation body”, “project tags”, “unit tags”, and “co- Data field benefit” data fields from free text fields to “select from picklist options or add a new option” fields modifications Modified the “methodology” and “project type” data fields to allow users to add new picklist options Converted the “unit count” data field from a system-generated field to a user-input field Modified the “methodology” data field to allow users to add up to two methodologies for a single project Created an optional “project description” data field to enable users to add descriptive details regarding each New data fields project (e.g. how the project is differentiated from other projects) The picklist options of the “project sector” data field were updated to align with the International Standard Industrial Classification of All Economic Activities The “project type” data field was updated with the option “REDD+” as a prefix to the “reduced emissions from deforestation and degradation” picklist option The picklist options of the “current registry” and “registry of origin” data fields were updated with the following changes: Replaced the “Japan national registry” picklist option with “Joint Crediting Mechanism”, and added “CDM registry”, “Article 6.4 mechanism registry”, and “Article 6.2 mechanism registry” as new picklist options The “methodology” data field was updated to include the Joint Crediting Mechanism and Gold Standard Picklist options methodologies to the picklist options The picklist options of the “unit status” data field were updated with the following changes: Removed “for sale” and “purchased” from picklist options, updated “transferred” to “exported” and “pending transfer” to “pending export”, and added “imported” as a new picklist option The “country” data field includes “Chile” and “Saudi Arabia” as new picklist options The “project status” data field includes “validated”, “approved”, “authorized”, “withdrawn”, and “de- registered” as new picklist options The “label type” data field includes “letter of authorization” and “letter of approval” as new picklist options Updated the slides visualizing the Climate Warehouse data model and the Excel data dictionary to reflect the latest updates based on participant feedback Documentation Revised definitions in the Excel data dictionary for data fields that participants noted were unclear (e.g. the “label” and “verification approach” data fields) Added definitions for each picklist option to the data dictionary  48 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT IO N 7 : L ES S O N S L EAR N E D FIGURE 21: Updates to the Simulation III data model PROJECT LOCATION PROJECTS RELATED PROJECTS UNITS GOVERNANCE (PICKLIST VALUES) Warehouse Project ID* (FK) Warehouse Project ID* (PK) Warehouse Project ID* (FK) Issuance ID* (FK) Registry values Project Location ID* (PK) Related Project ID (PK) Warehouse Unit ID* (PK) Current Registry* Country* Relationship Type Unit Issuance Location* Project Sector values Project ID* (FK to project loc ID) Project Status values In-country Region Registry Registry of Origin* Label ID* (FK) Project Type values Geographic Identifier* Program ISSUANCES Unit Owner Methodology values Project Name* Country Jurisdiction PROJECT RATING Unit Metric values Project Description Warehouse Project ID* (FK) of Owner* Validation Body values Warehouse Project ID* (FK) Project Link* Issuance ID* (PK) In-country Jurisdiction of Owner Country values Project Rating ID (PK) Project Developer* Issuance Start Date* Serial Number Block* Rating Type values Rating Type* Sector* Issuance End Date* Serial Number Pattern Unit Type values Rating Range Lowest* Project Type* Verification Approach* Unit Block Start* (Derived) Unit Status values Rating Range Highest* Project Tags Verification Report Date* Unit Block End* (Derived) Rating* Verification Body* Corresponding Adjustment Covered by NDC* Unit Count* (Derived) Declaration values Rating Link* NDC Information Vintage Year* Corresponding LABELS Project Status* Adjustment Status values Unit Type* CO-BENEFITS Project Status Date* Warehouse Project ID* (FK) Related Project Marketplace Relationship Type values Warehouse Project ID* (FK) Unit Metric* Label ID (PK) Marketplace Link Methodology* Label Type values Co-benefit ID (PK) Label Type* Marketplace Identifier Validation Body Label* Verification Body values Co-benefit Unit Tags Validation Date Crediting Period Start Date* Tag values Unit Status* ESTIMATIONS Crediting Period End Date* Co-benefit values Unit Status Reason Validity Start Date* Unit Registry Link* Warehouse Project ID* (FK) Validity End Date* Corresponding Estimations ID* (PK) Adjustment Declaration* Unit Quantity* Key: Crediting Period Start* Corresponding Label Link* • No change Crediting Period End* Adjustment Status* • New field Unit Count* • Updated picklist values • Converted from required to optional • Removed Fields with an * are required form fields PK denotes primary key for a specific table FK denotes foreign key which links tables together Each ID is globally unique, meaning no organizations will generate the same ID for any table CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 49 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D FIGURE 22: Updated Simulation III data model PROJECT LOCATION PROJECTS RELATED PROJECTS UNITS GOVERNANCE (PICKLIST VALUES) Warehouse Project ID* (FK) Warehouse Project ID* (PK) Warehouse Project ID* (FK) Issuance ID* (FK) Registry values Project Location ID* (PK) Current Registry* Related Project ID (PK) Warehouse Unit ID* (PK) Country* Relationship Type Project Sector values Project ID* Unit Issuance Location* In-country Region Registry (FK to project loc ID) Project Status values Registry of Origin* Geographic Identifier* Label ID* (FK) Project Type values Program ISSUANCES Unit Owner* Methodology values Project Name* PROJECT RATING Project Description Country Jurisdiction Unit Metric values Warehouse Project ID* (FK) of Owner* Project Link* Validation Body values Warehouse project ID* (FK) Issuance ID* (PK) In-country Jurisdiction Country values Project Developer* Issuance Start Date* Project Rating ID (PK) of Owner Sector* Issuance End Date* Rating Type values Rating Type* Unit Block Start* Project Type* Verification Approach* Unit Type values Rating Range Lowest* Unit Block End* Project Tags Verification Report Date* Unit Status values Rating Range Highest* Unit Count* Rating* Covered by NDC* Verification Body* Corresponding Adjustment Vintage Year* Declaration values Rating Link* NDC Information Unit Type* Corresponding Adjustment Project Status* LABELS Marketplace Status values CO-BENEFITS Project Status Date* Warehouse Project ID* (FK) Related Project Marketplace Link Unit Metric* Relationship Type values Warehouse Project ID* (FK) Label ID (PK) Marketplace Identifier Methodology* Label Type* Label Type values Co-benefit ID (PK) Unit Tags Validation Body Label* Verification Body values Co-benefit Unit Status* Validation Date Crediting Period Start Date* Tag values Unit Status Reason Crediting Period End Date* Co-benefit values ESTIMATIONS Unit Registry Link* Validity Start Date* Warehouse Project ID* (FK) Validity End Date* Corresponding Adjustment Declaration* Estimations ID* (PK) Unit Quantity* Corresponding Crediting Period Start* Label Link* Adjustment Status* Crediting Period End* Unit Count* Fields with an * are required form fields PK denotes primary key for a specific table FK denotes foreign key which links tables together Each ID is globally unique, meaning no organizations will generate the same ID for any table 50 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT IO N 7 : L ES S O N S L EAR N E D USER INTERFACE Nevertheless, most of the feedback points related to making the user interface as self-explanatory as possible (e.g. by adding Most of the 68 testers who completed the user interface testing screenshots to the instructions), clarifying definitions (e.g. by adding area created their organization and published data through the user a glossary page), making the data entry process as efficient as interface, which demonstrated that the user interface successfully possible (e.g. by allowing users to search for picklist options rather enables users to integrate with the Climate Warehouse. Although than scroll through long lists), and adding features that enhance the these testers shared multiple suggestions to further enhance the utility of the user interface (e.g. by adding an audit section). Going user interface, most survey respondents noted that the user interface forward, any efforts to further enhance the user interface should met or exceeded their expectations, indicating that participants were focus on these four aspects, which were most commonly requested generally satisfied with the user interface. by Simulation III participants. As explained in Section 6, participants’ requests for additional Table 18 summarizes the development actions on the user interface features and improvements to the user experience ranged widely. that were identified and completed during Simulation III. TABLE 18: Summary of completed user interface development actions CATEGORY COMPLETED DEVELOPMENT ACTION Added a read-only mode to enable observer nodes to view the Climate Warehouse’s metadata without being able to edit Added an organization subscription feature to enable users to easily select which organizations they subscribe to Added a dynamic search function that enables users to filter long picklists by typing Additional feature Added an audit section to the user interface, where users can select an organization and view all updates made by the selected organization Added a glossary page including definitions for data fields and picklist options Added a function for users to note comments when they publish new data to the Climate Warehouse Enabled users to submit organization logos in portable network graphics format and made the logo submission optional to make it easier for users to create their organizations Enabled users to edit staged data without having to delete and recreate Converted date format data fields from United States date format to international date format User Updated the workflows in the user interface to directly tie units to their related issuances and projects experience Updated the sorting order of picklist options to alphabetical order, where appropriate Consolidated the “my organization” and “registry” sections under a single “my registry” section and added a new “my files” subsection Implemented multiple visual updates, which included adding color shading to rows in tables, increasing the space between data fields, and removing infrequently referenced columns from the data tables Updated the full text search function to search across all relevant pages Removed overlaps between long text entries in adjacent data fields Trouble- Fixed the language selector tool and date picker feature shooting Corrected the displayed locations of the “country jurisdiction of owner” and “in-country jurisdiction of owner” data fields Solved errors experienced by users when unsubscribing from organizations and clicking “create project” Added an easier way for users to exit from drop-down lists CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 51 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D API to undergo an iterative process of mapping their local system to the Climate Warehouse APIs. As such, it will be critical for the new Each of the participants that completed the API testing area governing body to ensure that new participants have sufficient were able to successfully interact with the Climate Warehouse time and capacity to build their automated integration with the APIs from their API platform tools, demonstrating that the Climate Warehouse. Climate Warehouse’s API feature enables automated integration. Furthermore, all five survey respondents who tested the API In terms of development actions, the testing and simulation team feature noted that it met their expectations, indicating that testers implemented multiple improvements to the API feature based with sufficient API expertise were generally satisfied with the on participant feedback, including adding new features (e.g. Climate Warehouse’s API feature. added multiple API endpoints to enable a wider range of actions) and optimizing the user experience (e.g. added a more detailed A key overall lesson learned from participants’ experiences with response for “insert validation” failures). Table 19 summarizes the testing the API feature is that building a middleware integration development actions on the API feature that were identified and will require an IT counterpart within the participating organization completed during Simulation III. TABLE 19: Summary of completed API development actions CATEGORY COMPLETED DEVELOPMENT ACTION Added multiple API endpoints to enable a variety of actions, including subscribing to organizations, unsubscribing from organizations, and resetting users’ home organizations Created an option for users to only publish a subset of projects and units Additional features Added a function for users to note comments when they commit new data to the Climate Warehouse  Enabled users to submit “null” values through the API Updated the API feature to provide the warehouse project identification number when staging a new project or new unit User experience Removed repetitive steps in the project data update process Added a more detailed response for “insert validation” failures, indicating the type of failure and the specific fields that failed validation Troubleshooting Fixed a bug that was incorrectly allowing users to submit any inputs for the “sector” data field Updated all API-related documentation on the Climate Warehouse’s GitHub repository Documentation Added API examples to the Climate Warehouse’s GitHub repository to help guide users on how to format and push data using APIs 52 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT IO N 7 : L ES S O N S L EAR N E D EXCEL IMPORT/EXPORT Warehouse, multiple participants emphasized the importance of the Climate Warehouse’s transaction fees and their affordability. All 11 testers who completed the Excel import/export testing area As such, it will be critical for the governing body to closely monitor were able to successfully publish bulk volumes of registry data transaction fee trends and implement mechanisms to ensure that to the Climate Warehouse using the Excel import/export feature, they remain affordable (e.g. by establishing a donation-funded demonstrating the feature’s ability to enable users to add or edit resource pool) and do not become a disincentive for participants more than one data record at once. Furthermore, all six survey to publish data. respondents who tested the Excel import/export feature noted that it met or exceeded their expectations, indicating that participants Although most participants selected the cloud – hosted instance were generally satisfied with this feature. deployment model because it was a convenient way to access the Climate Warehouse for testing and simulation purposes, without A key lesson learned from participants’ experiences with testing the having to host the Climate Warehouse in their local IT networks, Excel import/export feature was that, although the feature enables participants’ deployment model preferences for integration with users to publish data to the Climate Warehouse more efficiently the operational Climate Warehouse varied significantly, based than inputting data manually on the user interface, the process primarily on their IT capabilities and organizational requirements. to populate the Excel upload template with registry data can be As such, it will be important for the new governing body to continue time-consuming, especially if the data is not readily available in a to offer a variety of deployment models to ensure that a broad format that is easily transferrable to the Excel upload template. As range of carbon market stakeholders can successfully deploy the such, it will be important for the new governing body to provide Climate Warehouse. participants with specific support to help optimize and automate the ways in which they populate the Excel upload template with Finally, multiple participants requested further documentation local registry data. on different aspects of the technical architecture, frequently to circulate the documentation internally, build consensus, and attain Most development actions on the Excel import/export feature that necessary approvals. As such, the new governing body should were completed during Simulation III were related to improving continue to develop detailed technical documentation (e.g. a the feature’s initial release in order to launch an updated version comprehensive user manual) to facilitate participants’ consensus- that successfully enabled users to publish bulk volumes of registry building processes and integration with the Climate Warehouse. data to the Climate Warehouse. Development actions related to the technical architecture that were identified and completed during Simulation III included TECHNICAL ARCHITECTURE improvements to the deployment process (e.g. enabling more than In addition to demonstrating that the Climate Warehouse’s one user to access a single instance of the Climate Warehouse), technical architecture successfully enables carbon data to be stored back-end updates (e.g. increasing the duration of time allowed for on a public and decentralized blockchain network, Simulation III a user to create an organization before a failure is recorded), and participants’ testing experiences also helped identify multiple the preparation of new documentation (e.g. a comprehensive threat system-level lessons related to the technical architecture. model). Table 20 summarizes the development actions related to the technical architecture that were identified and completed In terms of the technical requirements to participate in the Climate during Simulation III. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 53 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D TABLE 20: Summary of completed technical architecture development actions CATEGORY COMPLETED DEVELOPMENT ACTION Added an ability for users to use their API key and access the Climate Warehouse through their internet browsers Technical requirements Enabled multiple users to be able to access the same instance of the Climate Warehouse Completed various back-end updates to optimize the Climate Warehouse’s technical architecture. These back-end updates included adding logic to prevent transactions from being processed Back-end updates without a synced wallet, automating data updates from users’ subscribed organizations, and increasing the time allowed for a user to create an organization before a failure is recorded  Prepared additional documentation on multiple aspects of the Climate Warehouse’s technical Documentation architecture, which included the blockchain layer’s data storage mechanism, the transaction fee requirements for users to publish data, the threat model, and the deployment models GOVERNANCE In terms of operational support, participant feedback helped to identify that the governing body should consider providing Participants’ feedback on the governance of the Climate operational and technical support in a variety of formats (e.g. Warehouse throughout Simulation III helped identify multiple recorded tutorials and online “live chat” support), because the key lessons regarding the governance protocols and operational optimal format will vary by participant. Simulation III participants support that the new governing body should provide to optimize that did not have carbon registries also helped to indicate that participants’ experiences and the overall functionality of the the governing body should be able to provide support for the Climate Warehouse. carbon registry development process, in order to enable carbon market stakeholders without registry systems to integrate with the In terms of governance protocols, participant feedback helped Climate Warehouse. identify the need for the governing body to coordinate the timeline and frequency of participating organizations’ data updates in The development actions related to the governance of the order to mitigate the potential “staleness” of registry data in the Climate Warehouse that were completed during Simulation III Climate Warehouse. In addition, participant feedback also helped mostly involved adding a governance node feature to the user identify the need for the governing body to develop and implement a protocol for maintaining the governance node’s public list of interface and preparing documentation that improved participants’ known organizations, which would require the governing body to understanding of the Climate Warehouse’s governance model establish transparent criteria for inclusion and a reliable process to (e.g. preparing an onboarding guide and documentation on the validate the identities of new organizations. governance node’s functionalities). 54 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT IO N 7 : L ES S O N S L EAR N E D RECOMMENDED Over 50 percent of survey respondents also agreed or strongly ADDITIONAL FEATURES agreed that “the specific blockchain technology used for the Climate Warehouse matters a lot”, most commonly mentioning environmental Based on participants’ recommendations for the operational Climate sustainability and security as the two most important characteristics of Warehouse in their feedback survey responses, the new governing an optimal blockchain technology. This finding suggests that it will be body should prioritize adding more sorting and filtering features to particularly important for the new governing body to regularly review the user interface, as this was the most frequently recommended the blockchain technology that is used for the Climate Warehouse additional feature. Furthermore, the new governing body should and ensure that it meets participants’ environmental sustainability consider adding geospatial data and a global dashboard to the and security criteria, among others. Climate Warehouse, since approximately half of the survey respondents recommended that these features be added. Offering greater language support was only recommended by just over a third LIMITATIONS of respondents, suggesting that most participants were satisfied with Although Simulation III successfully tested the latest Climate the user interface’s language capabilities. Warehouse prototype with multiple carbon market stakeholders in preparation for its operationalization as a carbon metadata layer, the PERSPECTIVES ON lessons that were identified need to be considered in the context of the BLOCKCHAIN TECHNOLOGY simulation’s limitations. These include Simulation III’s limited range of participants and the nascent stage of the Climate Warehouse’s Participants’ perspectives on blockchain technology, which they shared underlying blockchain technology. in their feedback survey responses, helped identify multiple lessons regarding the Climate Warehouse’s use of blockchain technology. Simulation III engaged 30 participants in total, including 11 national governments, five independent standards, six multilateral A majority of Climate Warehouse participants appear to support organizations, and eight other public and private carbon market the use of blockchain technology and decentralized governance stakeholders. Although this represents a significant range and was to improve carbon data systems, based on the feedback survey’s an improvement on Simulation II’s scope of participants, it does not finding that more than 50 percent of respondents agreed or strongly reflect the full diversity of carbon market stakeholders. As such, it will agreed that “blockchain technology improves security and enables be critical for the new governing body to continue testing the lessons registry autonomy while assuring trust for shared climate registry from Simulation III as it operationalizes the Climate Warehouse and metadata” and that “carbon market data layers should be public, onboards new participating organizations. with permissionable data edit functionality, and operate under a decentralized governance system”. Simulation III confirmed the finding from prior simulations that blockchain technology can be used to build a decentralized and peer- Concurrently, the finding that 30 to 40 percent of respondents to-peer metadata layer that improves the transparency and security neither agreed nor disagreed with the same statements suggests of carbon market data. Nevertheless, the blockchain technology that that many Climate Warehouse participants are indifferent on the use underlies the Climate Warehouse’s technical architecture is still in a of blockchain technology and decentralized governance. The most nascent stage and continues to evolve rapidly, while the availability common rationales behind these respondents’ indifference were either of empirical data and successful use cases remains limited. As such, because they believe blockchain technology and decentralization it will be critical for the new governing body to interpret Simulation bring tradeoffs (e.g. increased complexity) or because they would III’s lessons on the use of blockchain technology, in the context of like to learn more about the innovations before stating a perspective. the specific time period in which Simulation III testing was executed. As such, it will be critical for the new governing body to continue Furthermore, the new governing body will need to regularly review assessing blockchain technology as it evolves and disseminating the the Climate Warehouse’s technical architecture to ensure that it findings among participants to maintain a shared understanding of optimally leverages the latest blockchain trends and innovations. the Climate Warehouse’s underlying technology. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 55 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D RECOMMENDATIONS FOR THE NEW GOVERNING BODY Table 21 outlines the testing and simulation team’s overall recommendations for the new governing body, based on the lessons learned from participant feedback. TABLE 21: Recommendations for the new governing body CATEGORY RECOMMENDATION Provide participants with ample time and operational support (e.g. through recorded tutorials and online support) to navigate the installation steps, attain any required security and legal approvals, manage the disk space requirement, sync their blockchain nodes, and complete their integration with Installation the Climate Warehouse Regularly revisit the installation process and implement updates that further simplify the process  Continue refining the Climate Warehouse data model, especially as new participants provide additional feedback and carbon market terminologies evolve When updating the data model, leverage a multistakeholder approach that reconciles any points of disagreement (e.g. picklist options of “project status” and “unit status” data fields, the data contained Data model in certain fields may be confidential for some registries and public for others) and ensures that updates reflect consensus among carbon market stakeholders, especially among independent standard registries For “select from picklist option or add a new option” data fields, implement a standard protocol to regularly review new picklist options that are introduced by participants and decide whether they should be added to the standard list that is supplied by the governance node Focus future development efforts on making the user interface as self-explanatory as possible, clarifying definitions, making the data entry process as efficient as possible, and adding features that enhance the utility of the user interface User interface Add more sorting and filtering features to the user interface and consider adding geospatial data and a global dashboard Ensure that new participants have sufficient time and capacity to build their automated integration with API the Climate Warehouse Excel import/ Help participants optimize and automate the ways in which they populate the Excel upload template export with local registry data  56 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT IO N 7 : L ES S O N S L EAR N E D TABLE 21: Recommendations for the new governing body (continued) CATEGORY RECOMMENDATION Continue to track the developments related to the UNFCCC infrastructure offering to ensure that the Climate Warehouse evolves to meet the emerging regulatory guidance and reporting requirements Closely monitor transaction fee trends and implement mechanisms to ensure that they remain affordable (e.g. by establishing a donation-funded resource pool) and do not become a disincentive for participants to publish data  Revisit how the ITMO transfer process could be consolidated into a single step in the blockchain layer Continue to offer a variety of deployment models to ensure that a wide range of carbon market Technical stakeholders can successfully deploy the Climate Warehouse architecture Continue to develop detailed technical documentation (e.g. a comprehensive user manual) to facilitate participants’ internal consensus building processes and integration with the Climate Warehouse Conduct regular assessments of the latest blockchain technology trends and disseminate the findings among participants to maintain a shared understanding of the Climate Warehouse’s underlying technology  Conduct regular evaluations of the specific blockchain technology that is used for the Climate Warehouse and ensure that it optimally leverages the latest innovations and meets participants’ key criteria, which include environmental sustainability and security Coordinate the timeline and frequency of participating organizations’ data updates, to mitigate the potential “staleness” of registry data in the Climate Warehouse Develop and implement a protocol for maintaining the governance node’s public list of known organizations, which requires establishing transparent criteria for inclusion and a reliable process to validate new organization’s identities Provide operational and technical support in a variety of formats (e.g. recorded tutorials and online “live chat” support) to meet participants’ diverse needs Provide support for the carbon registry development process in order to enable carbon market Governance stakeholders without registry systems to integrate with the Climate Warehouse Continue using modular and self-explanatory designs when developing additional documentation  Continue providing responsive, hands-on, and knowledgeable technical support to maintain participants’ high levels of satisfaction with the Climate Warehouse’s technical support Facilitate consensus building within organizations that are considering integration with the Climate Warehouse in order to successfully expand the number of participating organizations Continue testing the lessons from Simulation III as the Climate Warehouse is operationalized and new participating organizations are onboarded CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 57 OVERVIEW | OVERALL HIGHLIGHTS AND LEARNINGS | OVERALL SATISFACTION | INSTALLATION | DATA MODEL | USER INTERFACE API | EXCEL IMPORT/EXPORT | TECHNICAL ARCHITECTURE | GOVERNANCE | RECOMMENDED ADDITIONAL FEATURES PERSPECTIVES ON BLOCKCHAIN TECHNOLOGY | LIMITATIONS | RECOMMENDATIONS FOR THE NEW GOVERNING BODY SECT I O N 7 : L ES S O N S L EAR N E D In addition, Table 22 summarizes the specific development actions that were identified during Simulation III and logged in the action items tracker as suggestions to the governing body of the operational Climate Warehouse. TABLE 22: Summary of development actions logged as suggestions to the new governing entity CATEGORY SUGGESTED DEVELOPMENT ACTION Convert the “unit type” data field from a required to an optional field, based on feedback from participants that some registries will find it difficult to map all units to this data field’s picklist options  Broaden the “unit metric” data field to accommodate non-GHG metrics Add an optional “cooperative approach” data field to enable users to indicate alignment with Data model Article 6.2 cooperative approaches Expand the picklist options for the “label type” data field to ensure that the options are comprehensive Convert the “country jurisdiction of owner” data field from a required to an optional field, based on feedback from participants that this information is often confidential Enable users to split units into more than two blocks in a single transaction Add a scroll bar feature to help users navigate long picklist options Add a “merge units” feature to enable users to consolidate multiple units into a single unit  User interface Utilize a professional translation service to optimize the user interface’s language offerings Remove the Excel import/export icons from pages where they are not relevant (e.g. the staging tab in the “my units” view) Update the API feature to automatically generate the needed issuance from the related API project when users insert units that are attached to an issuance that does not yet exist 58 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT S ECT IO N 0 8 08 Climate Warehouse Outlook OPERATIONAL CLIMATE WAREHOUSE secretariat. Figure 23 visualizes the interim governance structure of the operational Climate Warehouse. The conclusion of Simulation III in August 2022 marked the beginning of the transition to the operational Climate Warehouse, To facilitate this transition, the testing and simulation team provided which is expected to launch in mid-October 2022. IETA is leading the new governing body with the final versions of the feedback this transition as the interim secretariat in close collaboration with tracker (including all 514 points of participant feedback), action the World Bank and the government of Singapore based on the items tracker (including all 156 development actions identified), recommendations produced in a 70-stakeholder consultation on 30 participant profiles and 30 feedback profiles for each Simulation governance and finance, which was finalized in early 2022. This III participant, feedback notes document (including detailed notes includes creating an independent legal entity in Singapore and from the 58 completed testing sessions and over 40 completed convening an Interim Council of public and private members to serve office hour sessions), and the Simulation III onboarding package a two-year term as the main governing body of the operational (including an updated technical guide and data model). Climate Warehouse, supported by further advisory bodies and a CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 59 SECT I O N 8 : CL IMATE WAR E H O U S E O U TLO O K FIGURE 23: Interim governance structure of the operational Climate Warehouse INCEPTION INTERIM PERIOD PERMANENT GOVERNANCE June 2022 January 2023 January 2025 COUNCIL (~10 MEMBERS) Leads strategy/policy mandate SECRETARIAT TECHNICAL COMMITTEE USER FORUM • Data specification development • Open to registered and approved • IT development Warehouse community participants • Community consultation forum • Potentially: Council recruitment In addition, the new governing body was provided with a comprehensive 9. Develop transaction fee plan: Develop a plan to transition plan, which included detailed guidance on a sequential and ensure that participating organizations can meet the prioritized list of 12 transition recommendations: Climate Warehouse’s cryptocurrency-based transaction fee requirements. 1. Select hosting service: Select a cloud hosting service for 10. Determine support structure: Determine and implement the governance and observer nodes. the operational and technical support that needs to be 2. Review data model: Review the Climate Warehouse data provided to onboarded Climate Warehouse participants. model and data dictionary. 11. Create development process: Create and implement a 3. Review Simulation III feedback: Consider the complete log structured process for how the governing body evaluates and implements new features that are requested by of participant feedback received during Simulation III. participating organizations. 4. Select administrators: Select and add administrators to the 12. Create data model update process: Create and implement Climate Warehouse repository on GitHub. a structured process for how the governing body evaluates 5. Launch development team: Build and launch a and implements proposed updates to the data model. development team for the operational Climate Warehouse. Moving forward, the World Bank will continue to provide technical 6. Develop website maintenance plan: Develop a plan to support with product development as well as onboarding assistance update and maintain the Climate Warehouse’s public website. through a capacity-building program with a priority to the Partnership 7. Develop organization validation process: Establish and for Market Implementation countries. The capacity-building program implement a process for validating new participating will provide support to approximately 15 developing countries for a period of two to three years. In addition, the World Bank may identify organizations and adding their details to the governance service layer functions that could be valuable to market participants node’s organizations list. and, in particular, to the World Bank client countries. These may 8. Create onboarding plan: Create a comprehensive plan include enhanced functionalities for compliance monitoring and and process to onboard new participating organizations to reporting and measures to improve transparency and integrity of the the operational Climate Warehouse. carbon markets. 60 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT APPE NDIX Appendix USER INTERFACE SCREENSHOTS The following figures are screenshots of the Climate Warehouse user interface, as of the end of Simulation III in August 2022. Each screenshot displays a subsection of the user interface. Refer to Section 3 for descriptions of each subsection. FIGURE 24: User interface – projects list Note: All data displayed is sample data for testing and simulation purposes only. FIGURE 25: User interface – units list Note: All data displayed is sample data for testing and simulation purposes only. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 61 APPE NDI X FIGURE 26: User interface – audit Note: All data displayed is sample data for testing and simulation purposes only. FIGURE 27: User interface – conflicts Note: All data displayed is sample data for testing and simulation purposes only. 62 | CLIMATE WAREHOUSE SIMULATION III FINAL REPORT APPE NDIX FIGURE 28: User interface – my projects (create project window) Note: All data displayed is sample data for testing and simulation purposes only. FIGURE 29: User interface – my units (create unit window) Note: All data displayed is sample data for testing and simulation purposes only. CLIMATE WAREHOUSE SIMULATION III FINAL REPORT | 63 © 2022 The World Bank | www.worldbank.org