Please click to download↓

Smart Contract-based Carbon Credits attached to Green Bonds.pdf

Figure 1: InterOpera’s technology workflow for the proposed green bond structure explored in Genesis 2.0

The scope of InterOpera’s prototype is demarcated in the indicated area in Figure 1 above. The prototype was designed with MOIs / MOUs (carbon credits instruments) forming a part of a wider ecosystem including the MOU registry, carbon market exchanges and, potentially, national registries. This framework illustrates other essential components (not in the current prototype scope) necessary in the context of the Article 6.4 mechanism and the conceptual technology solution for the ideal state of the UNFCCC process for MOU registry, ie DLT-based as shown in Figure 15, and how it interacts with other ecosystem participants is discussed in section B.2.4. InterOpera’s solution uses a combination of blockchain technology, smart contracts, and APIs to digitalise and manage MOs / MOIs / MOUs for operational efficiency, and to potentially mitigate the loopholes of double counting (of carbon credit claims) and greenwashing.

Key benefits offered by InterOpera’s prototype for Project Genesis 2.0 include

Prototype provides efficiency gains through digitalisation of the issuance process. Through the use of this prototype, the issuer is able to fully digitise the subscription, allocation and settlement process to tokenise the green bond and MOI assets, allowing it to be delivered directly to the investors’ digital wallet. All these enable the issuer to interface directly with investors, removing redundant stages, shortening the settlement cycle and ultimately lowering the costs, risks, and capital requirements of the market.

Transparency of green impact from financed projects achieved through MO tracking, mitigating green washing. The prototype allowsfor real-time MO raw uncertified data of the green activities financed by the green bond to be monitored on demand. This improves the transparency of the projects’ green impact, the progress of its green attributes commitment (ie MOI obligations) and allows all stakeholders to make definitive decisions based on their investment objectives. It also serves to mitigate green washing by enabling investors to track the achievement of MO by the Issuer and facilitate the delivery of eventual certified green attributes directly to investors.

Automated repayment of MOIs with MOUs through smart contracts. The prototype includes a smart contract-based conversion engine that can automatically monitor, execute, and enforce the MOI redemption / repayment phase to achieve transparent, autonomous exchange of MOIs with MOUs and the subsequent delivery of MOUs to the investor upon MOI maturity. The repayment settlement occurs immediately with the atomic swap of digital assets of MOIs with MOUs, ultimately reducing overall operational burden55 and processing time.

Conceptual elimination of double counting and double issuance issues in ITMO transfers. InterOpera has modelled ITMO transfers as cross-chain MOU transfers which can conceptually be accomplished via our innovative bridging technology (elaborated further in section B.2.4.3), eliminating potential double counting and issuance problems.

Users of InterOpera’s prototype

InterOpera’s prototype is intended to serve a range of market participants for the issuance and management of the new green bonds with MOIs (and consequently MOUs) including issuers, arrangers, investors, adminstrator or operators and observers.

Issuers / Investors: The prototype design is country agnostic and applicable to serve institutional users including sovereign, financial institutions and corporate entities which are likely issuers and investors for the green bond and carbon credit instruments (MOIs and MOUs) which can be eventually used for compliance purposes under NDCs. Both issuers and investors have respective portal interfaces to manage the MOIs / MOUs process.

Arrangers: Financial institutions acting as arrangers are used to the issuance of wholesale bonds (and consequently the new green bond with MOIs) and will interact with the prototype particularly during the creation and issuance phase.

Administrator and Operators: Financial institutions to host and operate a new platform to issue and manage financial instruments, green bonds and MOs.

- Observers: Potential users are anticipated to include supervisory bodies, regulators or any relevant entities who require read-only access.

B.2.3 Workflow design

B.2.3.1 Process flow for MO green bond (under Project Genesis 2.0)

Figure 2: Green bond and MOI / MOU process operationalised under Project Genesis 2.

Green bond and MOI preparation and issuance

• The green bond is issued simultaneously with appended MOI units (to deliver certified carbon credits ie MOUs). Post issuance, the green bond and MOIs can be transferred through smart contracts independently.

• To facilitate MOI issuance, prior approvals are required, namely (i) validation of green projects to be financed and (ii) issuer country’s government approval to issue the MOIs / deliver MOUs. This ensures that green projects comply with requirements set up by the MOU certification body from the onset, before any commitment to MOI holders and green activity implementation. The issuer country’s government approval addresses potential subscription to the bond and MOIs by overseas investors that would consequently impact the issuer country’s GHG emission reduction / avoidance units and its NDC accounting with the MOUs transferred internationally at maturity. This is applicable to our assumed scenario where an issuer from Country A issues a green bond with MOI to investor from Country B requiring ITMOs at maturity.

• The amount of MOI units (in tCO2e) issued to the investor(s) is allocated on a pro-rata  basis against the bond investment amount during the subscription and allocation phase.   In exchange for MOI units received, the investor would pay to the issuer an MOI premium (upfront payment under our scenario assumption) and help reduce the overall funding of the new green bond through the pledged carbon credits (MOIs).
• 
  
• Lifecycle management (duration before maturity)

MO tracking (with green projects data feed)

Post issuance, the issuer proceeds to finance the green activities for its implementation. Upon achieving operations, the relevant stakeholders such as issuers, MOI holders and accredited validation bodies can track unverified mitigation outcome data of the validated green activities through integrating a green data feed via APIs. This brings about greater transparency on the issuer’s progress in meeting its MOI obligations and mitigates greenwashing. In the future, such data to track real-time (uncertified) mitigation outcomes digitally can facilitate/ complement the monitoring process.

MOUs (UNFCCC process for certified carbon credits) issuance(s)

MOUs can be issued multiple times before MOI maturity to accumulate or settle any shortfalls within the climate performance goals in the issuer’s investment plan. In our scenario, we have assumed periodic MOU issuance requests (eg annual) to accumulate MOUs to meet MOI obligations.

Redemption of green bond + MOIs at maturity

We have assumed a bullet repayment of MOIs with delivery of MOUs with maturity date tracking green bond maturity (see smart contracts functionality in section B.2.4.2(6)). Technologically, other scheduled amortised repayments of MOI structures can be supported.

Conceptually, if there are insufficient MOUs for the MOI obligations, the issuer can purchase MOUs from carbon markets, up to a specified limit (eg 20%) of the total MOI committed to meet MOI obligations. Such purchases would only be made available shortly before maturity to prevent purchases to cover climate performance shortfalls, as these should be generated from the financed green activities to reduce greenwashing.

1. Hypothetical scenario terms and assumptions

Investment Plan Details

• Investment plan includes both existing activities (including carbon emission emitting) and planned green activities

• Investment activities are expected to emit 2,000,000 tCO2e emissions over 10 years

• Green activities expected to generate 550,000 tCO2e emissions reductions / avoidance over 10 years with 450,000 tCO2e (ie ~80%) pledged for MOI delivery

• Net emissions over 10 years expected to be [2,000,000 – 450,000] = 1,550,000 tCO2e

Project asset type: For simplicity, our hypothetical scenario assumes the project asset type supporting the green activities to be solar power in a developing country in Southeast Asia, where the Issuer is domiciled.

This is largely driven due to (i) solar energy being one of the fastest-growing renewable energy sources (the other being wind), (ii) the Southeast region generally enjoys sunny weather conditions and has high levels of annual global horizontal irradiation (GHI), and (iii) the greater potential for growth of solar and other renewable energy given the region’s higher reliance on fossil sources.

MOI units committed: In assessing the number of MOI units to be committed for the green bond investors, the issuer would consider the (i) total MOU generation potential of the issuer’s investment plan during the lifetime of the green bond; (ii) upfront payment required by the issuer to implement green activities versus liquidity position; and (iii) the issuer’s industry inclusion in national compliance programmes.

Whether the issuer is operating in an industry covered in the national compliance programmes or in a highly scrutinised industry emitting significant carbon emissions is a potential key consideration in determining the number of MOI units that can be committed. An issuer in a covered industry would likely have to retain a portion of the generated green attributes for its own use and could commit less MOI units to a green bond issue, while an issuer in a non-covered industry or green industry (pure renewables) would have more flexibility in committing either a significant or the entire amount of MOs expected to be generated during the lifetime of the green bond.

MOI premium: For our prototype, we have assumed that the MOI premium is a lump sum upfront payment to reflect the context of an issuer (in a developing country) issuing the green bonds to finance the implementation of new green projects which are capital intensive in nature, and to separate the payments for the green bond and MOIs to reflect their independent natures. Other forms of economic benefit and structuring of the payment of MOIs that are commercially acceptable should be considered.

In principle, the MOUs thatcan be used to settle MOI obligations should have a higher quality than normal carboncredits as the new structure has enabled green activities that otherwise are not possible through filling the viability gap of green activities and through creating the potential for a developed country to claim the facilitation of climate finance for a developing country (where the MOI holder is a developed nation buying an MOI from a developing nation). This could take place in the context of the commitment from developed nations to mobilise US$100 billion annually in support of developing countries.59

Green bond and MOI technology prototype workflow

1. Green bond + MOI creation and issuance

1. Pre-issuance and creation
   
2. The prototype is first used at the pre-issuance phase where the green bond and MOI terms have been structured and settled by an appointed lead arranger(s) and the issuer, and ready for subscription by potential institutional investors. The term-sheet details are captured on the web application, including standard bond details such as maturity date, coupon rate and subscription period. Specific to the MOI instrument issued alongside the green bond, details such as the MOI units committed, MOI premium, the issuer’s government approval ID and the UNFCCC process validation ID (both approvals to be system verified) are required in the prototype creation page.
3. 
   
4. The Government Approval ID is essential to the issuance of MOIs as redemption of the instruments is made via the delivery of MOUs for which corresponding adjustments need to be made to the national GHG inventory, affecting the country’s GHG reporting under its NDCs due to international transfers of MOUs. Validation of planned green projects under the UNFCCC process in the Issuer’s investment plan must be done prior to issuance, to ensure that MOUs issued from these activities can meet the MOI obligations. The prototype ensures that this condition is fulfilled by the issuer through the input and verification of a Validation Approval ID before digitally native MOIs are issued.
5. 
   
6. InterOpera’s prototype Green Bond and MOI creation page

The prototype is intended to be a one-stop platform for all relevant market participants, such as the issuer and arranger(s), to interact and manage the end-to-end digitally native green bond and MOI placement and lifecycle process with prospective investors through a web application. Arrangers would solicit investors from their client base. Investors, once onboarded, would be tracked according to the subscription link unique to each arranger for efficient management of origination activities.

1. Subscription, allocation and settlement
2. Issuers interact with prospective institutional investors via InterOpera’s prototype at the subscription phase after client onboarding and customary KYC / AML processes.
3. 
   
4. Subscription for the green bond and MOI will be opened for the specified period. Pre-selected institutional investors who have been on-boarded onto the system can subscribe to the green bond and MOIs, allowing arranger(s) to flexibly and direct deal with their targeted clients and manage the subscription and issuance process digitally within a single platform.
5. 
   
6. Investors can place orders for the green bond and MOIs on the platform with payment being done securely and efficiently on-chain. Payments will be sent to a smart contract which will take custody of the funds that will be used for settlement with the issuer. Usage of smart contracts in the order payment process eliminates the need for custodian banks, reducing issuance costs for issuers, arrangers, and investors alike.

Figure 4: InterOpera’s prototype arranger’s allocation page for green bond and MOI

At the close of the subscription period, the arranger will be directed to key in allocation details for the bond issue (MOI units are allocated pro-rata to the share of bond allocated), which is then subject to internal approval within the arranger bank. The request for approval will be sent via email to the approving officer who will need to make the necessary approval on the green bond issuance platform. Upon approval of the allocation, the bond and MOI asset tokens will be minted and distributed by a smart contract, and any oversubscribed funds will be returned to the investor’s wallet. This completes the settlement process with an on-chain delivery versus payment (DvP) against the funds that were sent by the investors. If investors are allocated less than their subscribed amount, the remaining funds will be refunded to their on-chain wallets automatically after settlement of the bond issue. On-chain settlement allows for atomic DvP, shortening the time required for the full issuance process while eliminating delivery risk.

Figure 5: InterOpera’s prototype investor’s wallet page displaying green bond and MOI asset tokens transferred upon issuance

Upon settlement of the green bond and MOI issuance, the investor would be able to see the bond and MOI tokens in their asset holdings, along with the details of the issue. Notably, once the green bond and MOI asset tokens are issued / minted, they can be transferred independently to one another and have separate commercial terms governing each instrument.

1. Tracking of MO (uncertified) before MOI maturity
2. In our assumed scenario, the green projects funded from the green bond issue are solar power projects for which MO can be tracked based on the net electricity fed into the grid. Through InterOpera’s prototype, green data from financed green activities is fed through from an external green data provider through an API connection and tracked once the projects turn operational.
3. 
   
4. Figure 6: InterOpera’s prototype showing issuer’s MO tracking page

Figure 7: InterOpera’s prototype showing investor’s MO tracking page

MO green data (uncertified green attribute) are readily available to provide timely updates (near real-time) for both the issuer and investors, facilitating the monitoring of the issuer’s climate performance and the likelihood of MOI obligations being fulfilled. This provides greater visibility and transparency on the progress of delivering its targeted green attributes, ensuring issuer discipline to execute its investment plan proposed under the green bond financing and mitigating greenwashing. Specific to the issuer, additional details are incorporated to track specific green projects and net MO retained by the issuer post MOI obligations. Hence better management of its overall climate performance and position.

The MO tracking dashboard can be configured to show MO progress at different time intervals (eg monthly and yearly) with an export function available for users to generate and download data for their ease of use in emissions reporting under national compliance programmes which require periodic reporting of emissions data.

Our hypothetical scenario assumes a single bullet repayment of the MOIs at maturity for which the prototype will show the lifetime cumulative MOs achieved from the financed projects. In an alternative scenario with periodic scheduled MOI repayments, the MO tracking dashboard would accommodate the multiple repayments by tracking the cumulative MOs achieved towards each repayment date.

The MO tracking dashboard can be made available to the UNFCCC process with a similar view as to the issuer, potentially facilitating direct monitoring and verification in the future for MOU issuance under the Article 6.4 mechanism.

For the illustrated scenario in this prototype, climate performance shortfall is not reflected, nevertheless, conceptually the climate performance shortfall data would be captured through an API feed which may be implemented in the future if a full view of emissions data from all operating assets becomes available.

1. MOU issuances
Figure 8: InterOpera’s prototype displaying issuer’s accumulated MOU issuances certified by the UNFCCC process

A green project developer (issuer) can request for the issuance of MOUs under the UNFCCC process upon verification and certification of MO data by a Designated Operating Entity (DOE). As this process can be done multiple times over the crediting period of the project(s), we assume an annual MOUs issuance request to the registry once the green projects are operational.

Upon issuance of the underlying MOUs, the issuer should request on the prototype system to top up the MOU tokens in its wallet. Next, the issuer will transfer the underlying MOUs attributable to projects financed by the green bond to a custodian account (run by the prototype system’s operator) in the registry. The operator will then verify off-chain that the correct type and number of MOUs have been deposited into the custodian account before triggering the tokenisation of the MOUs.

For the purpose of the prototype, we are assuming that the (non DLT-based) registry is housed in a centralised database that requires MOUs to be held in a custodial account before being tokenised. With an API connection to the registry, it is possible to automate the process of verification and tokenisation of MOUs. The ideal state is for the registry to be blockchain-based, facilitating direct digitally native MOUs that can be better managed and transferred, which we have explored in our conceptual design in section B.2.4.

We have made a further assumption that all MOUs attributable to the issuer’s investment plan will be deposited into the custodian account and tokenised on the prototype to capture a full picture of the issuer’s climate performance against that which they have represented to investors when raising the green bond.

Our scenario assumes the full repayment of MOIs without any climate performance shortfalls. Notwithstanding this, the issuer’s climate performance shortfall (in relation to its carbon emissions) under its investment plan for its non-green activities can be tracked digitally with the data being fed to the prototype via a conceptual API.

On a periodic basis, the issuer can settle the climate performance shortfall on the prototype with the MOU tokens attributable to the projects financed by the green bond in its wallet. We have assumed all shortfall repayments must be done on the prototype to ensure that all shortfalls are captured by the prototype, preventing greenwashing and ensuring discipline that shortfalls are settled predominantly with MOUs generated from green activities rather than purchased MOUs.

Settlement of climate performance shortfall (Conceptual)

Figure 9: Illustrating a hypothetical deduction of issuer’s MOUs to settle issuer’s climate performance shortfall in its proposed investment plan

1. Trading of MOIs / MOUs (conceptual)
2. 
   
3. For Project Genesis 2.0, conceptually, the secondary trading could take place on an independent marketplace for MOIs / MOUs within InterOpera’s prototype, or on external existing secondary carbon market exchanges that can be connected to the prototype. The platform would envisage a trading engine to support order routing and a technical service interface.
4. 
   
5. The independent marketplace could adopt either an order book, peer-to-peer, or Automated Market Maker (AMM) system. While there are advantages and disadvantages to each of these three options, in our opinion, a peer-to-peer system would be appropriate at this juncture due to its flexible nature. It can cater for trading of heterogeneous MOU tokens until a conversion factor system is in place to homogenise MOU tokens.
6. 
   
7. To ensure pricing efficiency of MOIs / MOUs, the ability to perform price discovery should be a key feature of the marketplace. We envision this feature to be implemented on the Web2.0 layer, extracting and presenting data from transactions executed on different carbon markets (both on-chain and off-chain) for investors to make informed decisions on pricing.
8. 
   
9. The prototype has also been conceptually designed to facilitate standalone transfer and trading of MOIs and the bond, reflecting the independent nature of both digital assets once they are issued. Once MOIs are separately traded, the bond may not be labelled green due the absence of the accompanying green attribute.
10. 
    
11. Figure 10: Illustrating a hypothetical sale of issuer’s MOIs independent to bond before its maturity
12. 
    

1. Delivery of MOU and redemption of Bond and MOI

1. MOI redemption with MOU at maturity
2. 
   
3. Figure 11: InterOpera’s prototype MOI redemption with issuer’s certified MOUs

At the MOI redemption phase, the prototype has integrated a notification functionality to alert the issuer of the upcoming MOI maturity. Indeed, two weeks prior to MOI maturity, an email notification is automatically sent to the issuer prompting it to check and ensure that it has sufficient MOUs to meet its obligations. Delivery of MOUs to fulfil MOI obligations is subject to the issuer’s settlement of climate performance shortfalls in its investment plan which is conceptually reflected in the prototype. This process for settlement of climate performance shortfall is described above under section 3. MOU issuances.

When the issuer has sufficient MOUs in its wallet, it can seek internal approval for MOI redemption on the prototype. This will prompt the responsible officer in the issuer to check and approve the redemption.

Upon approval of the redemption on the prototype, the MOU tokens will be sent to a smart contract and investors will be prompted to exchange their MOI tokens for MOU tokens. Once an investor acknowledges this exchange via an interface, he / she essentially gives permission to transfer his / her MOI tokens out of his / her wallet in exchange for MOU tokens to be transferred in. Using smart contract technology, the prototype conceptually (barring legal concerns or requirements from investors) removes the need for a custodian in the redemption process, reducing associated costs and achieving instant settlement and transfer of MOUs on satisfaction of the required commitments. A further benefit of the technology is that this process can be fully automated such that the MOUs do not need to be delivered to each investor by the issuer (or their appointed agent), reducing the administrative burden.

Figure 12: InterOpera’s prototype Investor asset holding page of MOU tokens received at maturity

External purchased certified MOU top up to fulfil MOI obligations at maturity (Conceptual)

Figure 13: Hypothetical purchase of MOUs (within limits) from carbon market to meet target MOIs

While our scenario assumes that the issuer can fulfil its MOI obligations with MOUs generated under its investment plan, if the issuer has a deficit in the amount of MOUs generated under the investment plan to settle its MOI obligations, it is conceptually allowed to purchase MOUs externally to fulfil the obligations, subject to an assumed designated cap of 20% of the total MOI committed amount. This cap is set to prevent greenwashing, ensuring the delivery of the green commitments is predominantly from financed green activities, rather than through purchasing MOUs that are generated by others.

As an additional safeguard against greenwashing and to protect the integrity of the proposed green bond structure where MOI must be repaid with generated MOUs from financed green activities, the prototype restricts the time when an issuer can purchase external MOUs to a month before the maturity of the MOIs for the sole purpose of meeting any gaps in its MOI obligations. This prevents the issuer from offsetting climate performance shortfalls using external MOUs rather than those generated under its investment plans.

The process of such top ups will be similar to the regular MOU top ups given that the prototype does not have access to any MOU exchange. As such, the 20% cap is applied in the prototype by preventing the issuer from requesting a top up amount of more than 20% of its total obligations. Should there be a transfer exceeding the cap, the excess MOUs are refunded back to the issuer’s account in the MOU registry and only the maximum allowed amount will be tokenised.

1. Bond principal redemption at maturity
2. 
   
3. Similar to the MOI redemption process, the issuer will receive a notification a month before maturity of the bond. The principal amount will be transferred to the operator account before minting the transferred amount in the issuer’s wallet. A request for approval is sought internally for the issuer before bond redemption is executed.
4. 
   
5. The bond repayment is executed through a smart contract holding the fiat tokens and conducting the exchange of bond tokens held by investors. With smart contracts, the traditional role played by paying agents and registrars can conceptually be fully automated as bondholder records are tracked in real-time. This removes the need for a record date (usually 15 days prior to maturity) to determine the recipient of the bond principal repayment, conceptually allowing for trading of the bonds right before maturity.
6. 
   
7. Technical architecture
8. 
   
9. InterOpera’s technical architecture design for Project Genesis 2.0 is centred around its proprietary RDOS which can flexibly accommodate the needs of all key stakeholders while meeting the requirements of capital markets regulations in the inception and management of a new financial instrument like MOIs.
10. 
    
11. In the ideal state, there will be a DLT-based MOU global registry under the UNFCCC process that hosts and oversees MOUs while allowing MOU / ITMO transfers without compromising on double counting issues and security. The infrastructure design is intended to link up all relevant market participants and stakeholders that are able to direct and access the underlying MOUs that are hosted in the MOU registry under the UNFCCC process. The illustrated ideal state assumes a linkage between the MOU and MOI registries which is elaborated on in Figure 15.

1. Overview of InterOpera’s RDOS
2. 
   
3. RDOS acts as the ultimate registry / depository framework, enabling blockchain-based efficiency gains with DLT and smart contracts. It is designed to operate within the confines of prevailing regulatory regimes and securitisation protocols. This way, the registry, exchange operator and regulator can reserve privileged rights or access, and delegate any of those rights or authority to a licensed entity / institution at its discretion.
4. 
   
5. As the ultimate middle-layer blockchain solution facilitating issuance of, and dealing in, capital markets products (and new instruments such as MOIs / MOUs) with investor-protection and regulatory safeguards incorporated, RDOS adds swiftness and convenience to the participants of the existing system without compromising on customary investor and market protections.
6. 
   
7. Through Genesis 2.0, InterOpera introduces RDOS, which can be interoperable with carbon markets so that carbon markets and its instruments can be a part of regulated capital markets.
RDOS is an interoperable blockchain infrastructure for all capital markets, to connect blockchain networks of governments, regulators, financial institutions, and investors, across jurisdictions and/or between the public or private blockchain networks that are adopted by licensed / regulated institutions.

1. InterOpera’s blockchain infrastructure - RDOS components

1. InterOpera iWASM
2. 
   
3. The InterOpera RDOS is built on a private chain using the Cosmos SDK and iWasm. The iWasm module powers our CMP (elaborated below) which enables (i) the MOU registry to act as the single source of truth (on the   host chain), (ii) investor protection and (iii) privileged access exclusively for regulators / authorities. iWasm was designed utilising CosmWasm. iWasm allows the creation of privileged smart contracts which are reserved solely for authorised regulatory entities under the UNFCCC process to conduct privileged actions, enabled through root access to the InterOpera RDOS at the blockchain level.
4. 
   
5. (1)    Proof of Regulatory Authority (PORA)
6. 
   
7. PORA is a consensus mechanism/model created together with iWasm. It is not a radical new consensus model, but to satisfy capital markets and regulatory requirements and future-proof market participants for MOI/MOU for the advent of Web3.0. PORA is a consensus mechanism combining elements of Proof of Authority with certain aspects of Proof of Stake.
8. 
   
9. (1)    CMP for MOI/MOU
10. 
    
11. The green bond structure tested in Project Genesis 2.0 can potentially marry the carbon and capital markets through the MOI. The MOI is conceptually similar to the idea of a forward or futures contract, with the key difference being that the investor is required to pay the issuer in full at the issuance of the instrument, eliminating the typical margin associated with forward or futures contracts.
12. 
    
13. With the integration between the carbon and capital markets through the creation of new instruments such as MOIs and MOUs, traditional safeguards found in the capital markets should be brought over and applied to both MOIs and MOUs.
14. 
    
15. To this end, CMP conceptually allows the application of traditional capital markets’ customary safeguards to ensure markets can continue to function efficiently, and digitally native asset transactions can be regulatory compliant. CMP provides the following key advantages:
16. 1. nvestor protection through CMP - legitimacy in ownership
    2. 
       
    3. Investor protection is afforded through assurance of legitimacy in ownership of MOU and MOI tokens. This is provided by tying back each token to the underlying asset held in the Host Chain through interchain accounts supported by the Inter-Blockchain Communication (IBC) protocol.
    
    
17. 1. arket protection through CMP
    2. 
       
    3. Market Protection is provided by CMP by applying traditional capital markets regulations, fostering investor trust in the market, which is key to ensuring that markets continue operating smoothly. Regulations are applied through standard filters in relayers (within IBC module), namely (i) KYC / AML verification, (ii) product suitability, (iii) investor suitability, and(iv) taxation checks which will be applied to all transactions taking place on the platform. The filters ensure that only transactions that fulfil regulatory requirements can be finalised on the blockchain, reducing the need for manual checks and the risks associated with manual data verification.
    
    
18. Beyond the four standard filters outlined above, the market protection service allows for customisable filters to be applied based on the use case and other regulations that may apply (eg sanctions). Two custom filters specific to either MOI or MOU transactions are introduced below:
19. 
    
20. Custom filters for Project Genesis 2.0:
21. MOI-specific filter: a UNFCCC process project validation filter is specifically designed for MOIs. This filter checks if the projects tied to the green bond specific MOI have been validated by the UNFCCC process for issuance of MOUs under the Article 6.4 mechanism. This provides assurance to secondary market participants that the MOIs they purchase are likely to be repaid using certified MOUs under the UNFCCC process. These in turn can be used to meet their compliance obligations.

• MOU-specific filter: an ITMO transfer approval filter is applied on international transfers of MOU tokens, including in the event of repayment at MOI maturity. This theoretical filter checks if the MOUs are approved for international transfers by the host country’s government, finalising cross-border MOU transfers only if approval has been obtained. This filter mechanism is critical as cross-border MOU transfers require the host government’s approval due to the corresponding adjustments that need to be made to the country’s GHG emissions inventory.
• 
  
• (1)Front-end interface
• 
  
• InterOpera’s prototype for Project Genesis 2.0 uses a white-labelled web-based interface for various market participants of MOIs / MOUs to interact and manage. The prototype offers two different web application interfaces for issuers and investors (as seen in figure 14). The operator portal is used by issuers, and arrangers to conduct management of green bonds and MOIs and other administrative tasks. The investor portal is designed for usage by investors to perform investment functionalities directly through the platform.
• 
  
• Figure 14: Web application interfaces for operator [left] and investor portal [right]

1. 1. Technology solutions to access RDOSInterOpera’s RDOS Web2.0 and Web3.0 solutions have been designed to be inclusive to serve a range of market participants with varying technology capabilities to ensure fair access to the benefits of the technology.
   
   
2. Web2.0: The Web2.0 layer allows stakeholders to connect to RDOS via APIs, enabling blockchain transactions to be finalised without private data being sent over the network. Node validators query the centralised database maintained by the UNFCCC process to check if transactions fulfil regulatory requirements without data being transmitted over the network.

• Web3.0: This is the blockchain component and the underlying foundation of RDOS. Web2.0 interacts with Web3.0 and creates blockchain transactions by invoking smart contracts. Smart contracts are written as modularly as possible for flexibility and application to different types of digital capital market instruments. Once transactions are created, node validators will validate these transactions to create a block and the transactions will be added to the blockchain ledger.
• 
  
• (1)    Smart contracts functionality
• 
  
• The smart contracts that govern the lifecycle of the MOIs and MOUs have been designed and written to mirror those of the majority of existing capital markets instruments, with functions implementing existing Ethereum Improvement Proposals (EIP) standards.
• 
  
• In its simplest form, a single type of asset token following the EIP-20 Token Standard would implement the EIP-20 Mint, EIP-20 Transfer, and EIP-20 Burn functions within its smart contract. These functions are usually sufficient as a starting point for standard capital markets instruments, however, may not cater for certain processes that involve the atomic settlement of more than a single token type eg the atomic transfer of green bonds and MOIs upon issuance. As such, we have implemented the MOI and MOU smart contract following the EIP-1155 Multi Token Standard, which in addition to the EIP-20 functionalities, allows handling of multiple token types within the smart contract through the EIP-1155 BatchTransferFrom function.

1. Multi-chain bridging for MOU and ITMO transfers
2. Conceptual MOU and ITMO transfer supported by Inter-blockchain communication (IBC) protocol
3. With the operationalisation of the Paris Article 6.2 and 6.4 mechanisms, there is a need for a system that can ensure the integrity of both mechanisms to avoid double counting / double issuance of MOUs and that corresponding adjustments are captured for ITMO transfers. There should be a suitable technology solution that addresses a realistic and likely scenario of a multi-chain DLT ecosystem (each country using heterogeneous blockchains for their MOU registry).
4. 
   
5. nterOpera’s CMP provides interoperability between heterogeneous permissioned chains through IBC technology. The technology designates the native chain as a Host Chain and other chains as Controller Chains which have access to the Host Chain through Interchain Accounts.60
6. 
   
7. Investors on the Controller Chain can purchase non-native tokens through the IBC connection which relays the transaction information to the Interchain Account on the Host Chain where the tokens are held. Any transactions involving these tokens would therefore occur only on the Host Chain, with the Controller Chains merely mirroring the relevant information without minting “wrapper” tokens. This removes the need for a Lock-and- Mint mechanism (locking tokens on the original chain and minting “wrapper” tokens on the other chain) which potentially leads to double issuance and counting issues when investors purchase non-native tokens. We believe this technology can be useful in the scenario where a national blockchain network is created under the Article
8. 
   
9. 6.4 mechanism and when an investor purchases MOUs that are originally issued under the UNFCCC process. The CMP can support IBC-enabled permissioned chains based on Hyperledger, R3 Corda and Cosmos which would potentially cover the majority of the enterprise blockchain market.
10. 
    
11. The MOU smart contract follows the EIP-1155 Multi Token Standard, which in addition to the EIP-20 functionalities, allows handling of multiple token types within the  smart   contract  through  the   EIP-1155  Batch  Transfer   From function.
12. 
    
13. Figure 15 shows our envisioned ideal state of the integration between the MOU registry under the UNFCCC process and individual countries’ heterogeneous blockchain infrastructure.
14. 
    
15. Figure 15 - ITMOs transfer based on interoperability between permissioned chains
16. 
    
Illustrative example of ITMOs include:

1. Issuer A of country A initiates transfers of MOUs to investor B (MOI holder) of country B.
2. Relayer communicates transfer information from Controller Chain (country A) to / from MOU Registry which is acting as Host Chain for the underlying asset token if it fulfils criteria specified for in-built filters, ensuring market protection.
3. Transfer of underlying MOU takes place on MOU registry as Host Chain.
4. Relayer communicates information of successful transfer on MOU Registry to Controller Chains which finalises transfer in parallel based on information received from relayers, ensuring that the total holdings across issuer / investor sub-wallets are always equal to the holdings in the client commingled master accounts on the Host Chain (MOU Registry), thereby ensuring investor protection and mitigating double counting of carbon credits with ITMOs.
5. 
   
6. An investor from a different country to the issuer can receive MOU tokens at the maturity of the MOI in exchange for the MOI tokens through a smart contract that tracks the wallet addresses of both the issuer and investors to automate repayment transactions. The exchange of the tokens is enabled with the IBC protocol which allows for seamless transactions to be made across (assumed) heterogeneous chains without utilising wrapper tokens.

1. Green data feed integration
2. 
   
3. Green data is obtained near real-time in the form of carbon emissions avoided as a function of power generated through green power plants. As this data needs to be displayed to the users for transparency, a microservice can be implemented to pull data from different sources, either from a green data provider or directly from IoT sensors. Data collected can be stored on a centralised database or on the blockchain. For this prototype, green data was simulated hourly from solar plants and captured via API calls from an external source.
4. 
   
5. Key observations
6. 
   
7. Smart contracts functional benefits are well illustrated through this prototype to automate as many lifecycle events as possible and digitally issue, track, deliver and settle MOIs and MOUs. Nevertheless, there were situations that limited full automation and required issuer’s action and discretion. One example is when the issuer faces default risk and has insufficient MOUs to repay MOI obligations. Smart contracts should not automatically trigger immediate action to purchase external MOUs.
8. 
   
9. MOU registry under UNFCCC process could be DLT-based to issue and manage digitally native MOUs. With the operationalisation of the Article 6.4 mechanism underway, we have considered how our technology can efficiently deliver the necessary functions under the framework. Keeping in mind that any system operated for the Article 6.4 mechanism should include market and investor protections and allow for corresponding adjustments to be made to national GHG inventories seamlessly, a DLT-based system for the MOU registry would be most suitable. Utilising a DLT system would enable automated handling of corresponding adjustments while eliminating double counting / double issuance issues that are critical to the integrity of the framework. InterOpera’s multi- chain bridging solution is designed to eliminate double counting and double issuance in cross-chain transactions which enables it to handle corresponding adjustments seamlessly with a DLT-based registry.
10. 
    
11. Possible DLT-based GHG inventory to be considered. The ability to accurately capture corresponding adjustments from ITMO transfers is of prime concern given the possibility of double counting. Through Project Genesis 2.0, we have observed that it would be challenging to apply corresponding adjustments accurately in the current environment given that each country maintains separate databases housing their GHG inventory data, requiring them to manually update the inventory each time a transfer is effected. We envision that accurately capturing corresponding adjustments  from ITMO transfers would require each country to maintain its GHG inventory    on a DLT-based system which will then be bridged through our RDOS, automatically applying corresponding adjustments for any ITMO transfer.
12. 
    
13. Standardised methodology on corresponding adjustments needs to be agreed. Many countries currently have NDCs with a single year target which means that these countries can meet their NDC targets by simply ensuring that emissions levels are brought down to the promised levels in the target year. This poses a challenge to environmental integrity which can only be addressed through an internationally agreed standard on how corresponding adjustments should be applied over the NDC period (ie multi-year average or otherwise).
14. 
    
15. Potential to facilitate digitising measurement, reporting, and verification processes. The InterOpera prototype includes the functionality to track real-time uncertified MOs and this presents an opportunity to integrate and allow UNFCCC to digitise and directly manage its monitoring and verification process to certify MOUs on the platform - this is fitting for an ideal state for the MOU registry to be DLT-based hosting digitally native MOUs.
16. 
    
17. Future considerations
18. 
    
19. The following are considerations for different market participants, that when sufficiently addressed help to encourage further market adoption and commercialisation of MOI and MOU instruments in the context of the proposed green bond structure.
20. 
    
21. Technology considerations
22. 
    
23. Standardised MOI / MOU tokens while addressing different capital intensity. While our scenario terms have assumed a homogeneous carbon credit, in reality there are different levels of capital intensity (amount of capital per ton of CO2 abated during the lifetime of the financed green activities) of MOI owing to the underlying green activities implemented. This limits the liquidity of the MOI / MOU by their level of capital intensity and adoption. Capital intensity standards should be established before technology can be implemented efficiently. Conceptually, a possible solution is a conversion factor to align different capital intensity levels of MOI to one consistent metric before MOI tokens are minted (similar to how different GHG emissions are converted into CO2 equivalents).
24. 
    
25. Regulatory considerations
26. 
    
27. Regulatory safeguards of capital markets products to be applied to MOI. MOI is a newly formed financial instrument with the underlying being MOU (ie certified carbon credits), and as with all capital markets instruments, similar customary regulatory safeguards on existing capital market products could be applied to MOI to encourage adoption.
28. 
    
29. Carbon market considerations
30. Potential blockchain-based carbon market interconnectivity. Connectivity to carbon markets (DLT and non- DLT based) is key to encouraging more market activity and could potentially achieve higher liquidity and adoption of both MOI and MOU instruments. Having blockchain-based carbon markets that can seamlessly connect, transfer, and manage digitally native assets of MOI / MOU is ideal.
31. 
    
32. Large scale issuance
33. Optimal structure of MOI premium / payment. One potential consideration in supporting large-scale issuances is to consider the perspectives of both issuers and investors in structuring the MOI premium payment in exchange for issuer to receive MOI units. While our scenario has assumed an upfront lump sum payment to reflect the issuer’s requirements due to the capital-intensive nature of project implementation and a cleaner structure to separate out both the bond and MOIs, other payment structures may need to be considered.
34. 
    
35. C.   Project participants
36. BIS Innovation Hub
37. Bénédicte N Nolens, Head of Hong Kong Centre 
38. Musheer Ahmed, Project co-lead
39. Teresa Lin, Project co-lead
Goldman Sachs, Allinfra, Digital Asset consortium

Goldman Sachs

Mathew Mcdermott – Managing Director – Global Head of Digital Assets 

Rebecca Wong – Managing Director – Debt Capital Markets

Felix Yip – Executive Director – Global Head of Digital Assets Engineering 

Rosie Hampson – Executive Director - Digital Assets

Brijesh Gupta – Executive Director – Digital Assets Engineering 

Pratul Varshney – Executive Director – Digital Assets Engineering 

Andrew Chan – Executive Director – Debt Capital Markets 

Allinfra

Dave Sandor – Co-founder and CEO

Bill Kentrup – Co-founder and Head of Origination 

Kelvin Yuen – Head of North Asia and CFO

Michel Dinh – CTO

Nicolae (Nick) Oprisan – Head of Engineering 

Francisco Angulo – Full Stack Blockchain Engineer 

Ryan Chan – Full Stack Engineer

Andreea Petrovan – Project Management / Quality Assurance

Digital Asset

Karen Qian – Associate Director, Business Development 

Dorrit Du – Technical Sales Engineer

InterOpera consortium

InterOpera

Will Lee - Founder and Executive Chairman 

Michael Chin - CEO

Pete Park - Head of Engineering

Lianne Lee - Tech Lead / Product Manager 

Calvin Neo - Head of Business Development 

Krungthai Bank

arong Vongsinudom - Head of Capital Market Innovations

Sungshin Cement

Kim Tae-Hyun - Chairman

Samwoo

Shin Sung-Jae - Vice Chairman

King & Wood Mallesons 

Urzula McCormack – Partner 

Jo Dodd – Partner

Dale Rayner – Partner