Blockchain Implementation Method for Interoperability between CBDCs

Central Bank Digital Currency (CBDC) is a digital currency issued by a central bank. Motivated by the financial crisis and prospect of a cashless society, countries are researching CBDC. Recently, global consideration has been given to paying basic income to avoid consumer sentiment shrinkage and recession due to epidemics. CBDC is coming into the spotlight as the way to manage the public finance policy of nations comprehensively. CBDC is studied by many countries. The bank of the Bahamas released Sand Dollar. Each country’s central bank should consider the situation in which CBDCs are exchanged. The transaction of the CDDB is open data. Transaction registers CBDC exchange information of the central bank in the blockchain. Open data on currency exchange between countries will provide information on the flow of money between countries. This paper proposes a blockchain system and management method based on the ISO/IEC 11179 metadata registry for exchange between CBDCs that records transactions between registered CBDCs. Each country’s CBDC will have a different implementation and time of publication. We implement the blockchain system and experiment with the operation method, measuring the block generation time of blockchains using the proposed method.


Introduction
Currently, we use computers and mobile phones to make online remittances and e-commerce transactions on networks such as the Internet, and we exchange data in online transactions. Exchange data has different security requirements depending on the situation. For example, messengers have low integrity requirements for data transmission. However, online transactions require high-integrity data to be used in authentication and transaction authentication. We rely on trusted third-party intermediaries for data integrity and pay high brokerage costs. In online transactions, brokerage costs limit daily transactions at low prices because they raise transaction costs, and non-reversible deals are theoretically impossible. Bitcoin proposed an electronic cash system directly trades without intermediaries between individuals based on cryptographic proofs instead of third-party trust [1][2][3].
Since Bitcoin was released to the world, many cryptocurrencies have been released. Many cryptocurrencies have been proposed to deal with the shortcomings of Bitcoin or to solve many global problems. Ethereum is a platform that supports smart contracts and decentralized applications (DApps) for monetary functions [4][5][6]. Smart contracts can express the contents of the contract in a language (Solidity) and automatically execute the contract when the predetermined conditions are satisfied. They can automate by combining insurance, real estate, and copyright. Ripple is a cryptocurrency to support real-time money transfers among banks around the world [7]. International remittances typically use SWIFT (Society for Worldwide Interbank Financial Telecommunications). SWIFT takes two to three hours to complete a trade, and different banks have different fees. Ripple aims to efficiently and immediately process remittances anywhere in the world to replace SWIFT. The Bank of the Bahamas has launched Sand Dollar, the world's first CBDCThe Bahamas have more mobile phones than bank accounts. Sand Dollar is designed for financial integration. Customers can pay with Sand Dollar to any vendor with a digital wallet certified by the Central Bank of the Bahamas [14]. The National Bank of Cambodia started the Bakong system. The Bakong system will be issued in digital currency by Cambodian partner organizations, not by the central bank. Anyone with a phone number under their name in Cambodia can use the Bakong system and pay Cambodian riel or dollars [15].
Bank for International Settings (BIS) Innovation Hub works on The Multiple CBDC (mCBDC) Bridge Project [16]. mCBDC Bridge is a multi-currency cross-border project that explores the capabilities of distributed ledger technology (DLT) and studies the application of CBDC to strengthen financial infrastructure. The participating authorities of the project are the Hong Kong Monetary Authority, the Bank of Thailand, the Digital Currency Institute of the People's Bank of China, and the Central Bank of the United Arab Emirates. This project explores how CBDC can be used to address the challenges of cross-country funding delivery, including inefficiency, high cost, low transparency, and compliance.
The BIS conceptually proposes three models of compatible CBDC systems (model 1), interlinked CBDC systems (model 2), and a single system for mCBDC (model 3) [17]. Compatible standards allow payment systems to reduce friction and barriers to crossborder monetary services. Model 1 is probably very similar to a traditional payment system. CBDC, like payment methods, can reduce the operational responsibility of participating in multiple systems through common technical standards such as message format, encryption technology, data requirements, and user interfaces. Linking payment systems are complex tasks and often require compatibility measures. Model 2 would simply not work together to bring the system together. Two forms can be taken for implementation of the model: (i) a shared technology interface (ii) a common deletion mechanism (a distributed shared account or a more centralized universal payment agent or system). Finally, a multinational payment system with CBDCs is possible. Model 3 potentially allows for more operational capabilities and efficiency, but increases governance and control hurdles. Through the shared network, participants can make payments across borders through deposit receipts linked to CBDCs held in the domestic system. However, a single mCBDC system creates policy problems for the central bank. For example, the scope of CBDC issuance for monetary policy and financial stability and payment policy.

CBDC Management Method Based on ISO/IEC 11179
The ISO/IEC 11179 metadata registry is an international standard for data interoperability. Interoperability is a property in which systems can be used interchangeably with other systems of the same or heterogeneous type. Data interoperability can be understood and exchanged without any additional work by other systems or repositories.
A computer does not know when to distinguish between specific data with equivocal meanings. For example, when the word "Apple" is given to a computer, the computer does not distinguish between "Apple" as in the fruit and the Apple Corporation. As the data for representing other data, metadata is used to distinguish the meaning of data, and the metadata structure the means for interpretation of the data. Metadata expression languages include Resource Description Framework (RDF) [18] and Web Ontology Language (OWL) [19].
The ISO/IEC 11179 Metadata Registry (MDR) is a metamodel that manages metadata through registration and authentication of metadata [20]. The MDR supports data element creation, registration, and management to share information between systems; it structurally supports the sharing, expression, and identification of the meaning of data and can involve data interoperability using the data stored.
We manage the CBDC to the data elements of the MDR. An efficient exchange of CBDCs should ensure that the sender and receiver interpret the same CBDC information. CBDC information sharing requires the expression of a standardized CBDC structure. Central banks will build CBDCs with their technology and guarantee its transaction. In this section, we discuss how to exchange and receive transactions between CBDCs. MDR can finely express the data and represent it to the Concept layer and Representation Layer. This may involve representing such data value as the range of the domain. In other words, we can identify the data in semantic form using the MDR. While the integrity of data stored in the blockchain is difficult to maintain, as in a database, MDR can help ensure the integrity of the CBDC.
The MDR manages data using data elements. Figure 1 presents an overview of the metadata registry. The data elements of the MDR represent the data as the Concept layer and Presentation layer. The concept layer expresses data and domain information with the Data Element Concept and Conceptual Domain. The Representation layer implies a data element and value domain that expresses the data value format and measurement units. The MDR can obtain the conceptual classification of data and expression information for data values. The "*" and "1" of the Data Element are the relationships of each element. A single Value Domain can relate to many Data Elements.
The ISO/IEC 11179 Metadata Registry (MDR) is a metamodel that manages metadata through registration and authentication of metadata [20]. The MDR supports data element creation, registration, and management to share information between systems; it structurally supports the sharing, expression, and identification of the meaning of data and can involve data interoperability using the data stored.
We manage the CBDC to the data elements of the MDR. An efficient exchange of CBDCs should ensure that the sender and receiver interpret the same CBDC information. CBDC information sharing requires the expression of a standardized CBDC structure. Central banks will build CBDCs with their technology and guarantee its transaction. In this section, we discuss how to exchange and receive transactions between CBDCs. MDR can finely express the data and represent it to the Concept layer and Representation Layer. This may involve representing such data value as the range of the domain. In other words, we can identify the data in semantic form using the MDR. While the integrity of data stored in the blockchain is difficult to maintain, as in a database, MDR can help ensure the integrity of the CBDC.
The MDR manages data using data elements. Figure 1 presents an overview of the metadata registry. The data elements of the MDR represent the data as the Concept layer and Presentation layer. The concept layer expresses data and domain information with the Data Element Concept and Conceptual Domain. The Representation layer implies a data element and value domain that expresses the data value format and measurement units. The MDR can obtain the conceptual classification of data and expression information for data values. The "*" and "1" of the Data Element are the relationships of each element. A single Value Domain can relate to many Data Elements.  Figure 2 shows the data element structure. Data elements are represented by Object Class, Property, and Representation. Object classes provide a structure for representing objects in data and represent concepts that contain data. For example, the object class of the Korea CDBC is Digital Currency. Property is a common feature that can distinguish object classes. For example, the Bank for International Settlements (BIS) distinguishes the digital currency as a CBDC, Non-CBDC Token, and Non-CBDC Account. The Data Element is expressed as a combination of value domain, data type, and unit of measurement. Figure 3 is a CBDC example of the data element concept; it can express an object class as digital currency and property as a central bank.  Figure 2 shows the data element structure. Data elements are represented by Object Class, Property, and Representation. Object classes provide a structure for representing objects in data and represent concepts that contain data. For example, the object class of the Korea CDBC is Digital Currency. Property is a common feature that can distinguish object classes. For example, the Bank for International Settlements (BIS) distinguishes the digital currency as a CBDC, Non-CBDC Token, and Non-CBDC Account. The Data Element is expressed as a combination of value domain, data type, and unit of measurement. Figure 3 is a CBDC example of the data element concept; it can express an object class as digital currency and property as a central bank.
The data value of the MDR is expressed using a conceptual domain and a value domain. Figure    The data value of the MDR is expressed using a conceptual domain and a value domain. Figure    The data value of the MDR is expressed using a conceptual domain and a value domain. Figure   The central bank can register and manage CBDCs in the MDR. ISO/IEC 11179 Part 6 Registration proposes a data element registration method in MDR. Figure 5 shows the CBDC registration process. Central banks organize groups for CBDC transactions.  The central bank can register and manage CBDCs in the MDR. ISO/IEC 11179 Part 6 Registration proposes a data element registration method in MDR. Figure 5 shows the CBDC registration process. Central banks organize groups for CBDC transactions. According to the registration procedure, the central bank group conducts the Submitter, Steward, and Control Committee agrees on identification, submission, checking, and confirmation, and can register and identify the CBDC in the MDR. Moreover, central banks can keep the CBDC registered in the MDR updated. The central bank can register and manage CBDCs in the MDR. ISO/IEC 11179 Part 6 Registration proposes a data element registration method in MDR. Figure 5 shows the CBDC registration process. Central banks organize groups for CBDC transactions. According to the registration procedure, the central bank group conducts the Submitter, Steward, and Control Committee agrees on identification, submission, checking, and confirmation, and can register and identify the CBDC in the MDR. Moreover, central banks can keep the CBDC registered in the MDR updated.

Blockchain System for Exchange between CBDCs
This section describes the MDR-based blockchain system for exchange between CB-DCs. Figure 6 is an overview of the MDR-based blockchain model. In the blockchain system, the central bank group registered in the MDR participates as a node. The blockchain contains transactions between CBDCs in the transaction, and. The nodes of the blockchain group determine the blockchain consensus. The transaction consists of the sender's amount and CBDC address (e.g., A kr_CBDC) and the receiver's Amount and CBDC address (e.g., B ch_CBDC). The MDR helps to validate the CBDC of the transaction.

Blockchain System for Exchange between CBDCs
This section describes the MDR-based blockchain system for exchange between CBDCs. Figure 6 is an overview of the MDR-based blockchain model. In the blockchain system, the central bank group registered in the MDR participates as a node. The blockchain contains transactions between CBDCs in the transaction, and. The nodes of the blockchain group determine the blockchain consensus. The transaction consists of the sender's amount and CBDC address (e.g., A kr_CBDC) and the receiver's Amount and CBDC address (e.g., B ch_CBDC). The MDR helps to validate the CBDC of the transaction.      Figure 7 shows the transaction registration process in the proposed blockchain system. Transactions between CBDCs execute the generation of the block. Smart Contracts are available to ensure the stability of transactions. A Smart Contract is created as a move request between CBDCs. The Smart Contract waits for the block generation of the transaction, running with block creation. The sending CBDC burns the sending amount, and the receiving CBDC mints the received amount. Eventually, each central bank recognizes the CDBC as a burn and mint transaction.

Experiment
In this section, we experiment to verify the proposed blockchain system for exchange between CBDCs. The experiment stores transactions between CBDCs based on MDR in a blockchain (Bitcoin, Ethereum). In the experiment, the blockchain system stores the "A kr_CBDC to B ch_CBDC" transaction in the block. The experiment covers the part on how to record CBDC transactions on the blockchain.
Bitcoin stores arbitrary data using the OP_RETURN script. OP_RETURN can record up to 80 bytes and receive support from Bitcoin Core 0.9 version [21]. This experiment stores CBDC transactions in the OP_RETURN script. Figure 8 shows the creation of an account in a test environment and ten blocks, in which we send the transaction to the account.

Experiment
In this section, we experiment to verify the proposed blockchain system for exchange between CBDCs. The experiment stores transactions between CBDCs based on MDR in a blockchain (Bitcoin, Ethereum). In the experiment, the blockchain system stores the "A kr_CBDC to B ch_CBDC" transaction in the block. The experiment covers the part on how to record CBDC transactions on the blockchain.
Bitcoin stores arbitrary data using the OP_RETURN script. OP_RETURN can record up to 80 bytes and receive support from Bitcoin Core 0.9 version [21]. This experiment stores CBDC transactions in the OP_RETURN script. Figure 8 shows the creation of an account in a test environment and ten blocks, in which we send the transaction to the account. Bitcoin stores OP_RETURN as Hex. Figure 9 shows the conversion of the value to Hex to be stored. The data "30 kr_CBDC to 40 ch_CBDC" is stored in the block as Hex "3330206b725f4342444320746f2034302063685f43424443." Bitcoin stores OP_RETURN as Hex. Figure 9 shows the conversion of the value to Hex to be stored. The data "30 kr_CBDC to 40 ch_CBDC" is stored in the block as Hex "3330206b725f4342444320746f2034302063685f43424443." Bitcoin stores OP_RETURN as Hex. Figure 9 shows the conversion of the value to Hex to be stored. The data "30 kr_CBDC to 40 ch_CBDC" is stored in the block as Hex "3330206b725f4342444320746f2034302063685f43424443." Figure 9. Convert input data to Hex. Figure 10 shows creating a raw transaction that stores the OP_RETURN value converted to a Hex value. We choose "txid" to make the transaction and create a raw transaction. Additionally, Then, we search the account's UTXO (Unspent transaction output) with the "listunspent" command. Raw transactions are created using the "createrawtransaction" command. The raw transaction is created using the searched txid and Hex.  Figure 10 shows creating a raw transaction that stores the OP_RETURN value converted to a Hex value. We choose "txid" to make the transaction and create a raw transaction. Additionally, Then, we search the account's UTXO (Unspent transaction output) with the "listunspent" command. Raw transactions are created using the "createrawtransaction" command. The raw transaction is created using the searched txid and Hex. To send the transaction, it must be signed using a private key. Figure 11 shows the transmission transaction. The private key can be obtained using the "dumpprivkey" command, and we use the private key to sign the raw transaction. The signed transaction is sent to the mempool using the "sendrawtransaction" command. If the transmission was successful, a transaction hash is an output.  Figure 12 shows that the insertion of the transaction was sent to mempool. The 11th block is generated using the "generatetoaddress" command. Then, we check the transaction hash using the "getblock" command. Figure 13 shows the decryption of the To send the transaction, it must be signed using a private key. Figure 11 shows the transmission transaction. The private key can be obtained using the "dumpprivkey" command, and we use the private key to sign the raw transaction. The signed transaction is sent to the mempool using the "sendrawtransaction" command. If the transmission was successful, a transaction hash is an output. To send the transaction, it must be signed using a private key. Figure 11 shows the transmission transaction. The private key can be obtained using the "dumpprivkey" command, and we use the private key to sign the raw transaction. The signed transaction is sent to the mempool using the "sendrawtransaction" command. If the transmission was successful, a transaction hash is an output.  Figure 12 shows that the insertion of the transaction was sent to mempool. The 11th block is generated using the "generatetoaddress" command. Then, we check the transaction hash using the "getblock" command. Figure 13 shows the decryption of the insert transaction. We can confirm the data inserted into the OP_RETURN value.  Figure 12 shows that the insertion of the transaction was sent to mempool. The 11th block is generated using the "generatetoaddress" command. Then, we check the transaction hash using the "getblock" command. Figure 13 shows the decryption of the insert transaction. We can confirm the data inserted into the OP_RETURN value.  Ethereum stores arbitrary data using the input of the transaction. Figure 14 shows how to store Hex values in transactions in Ethereum. The input of Ethereum transactions serves the same purpose as Bitcoin's OP_RETURN. We created a transaction that stores the Hex value using the "eth.sendTransaction" command. Ethereum sends the generated transaction to the transaction pool.   Ethereum stores arbitrary data using the input of the transaction. Figure 14 shows how to store Hex values in transactions in Ethereum. The input of Ethereum transactions serves the same purpose as Bitcoin's OP_RETURN. We created a transaction that stores the Hex value using the "eth.sendTransaction" command. Ethereum sends the generated transaction to the transaction pool.  Ethereum stores arbitrary data using the input of the transaction. Figure 14 shows how to store Hex values in transactions in Ethereum. The input of Ethereum transactions serves the same purpose as Bitcoin's OP_RETURN. We created a transaction that stores the Hex value using the "eth.sendTransaction" command. Ethereum sends the generated transaction to the transaction pool. Ethereum stores arbitrary data using the input of the transaction. Figure 14 shows how to store Hex values in transactions in Ethereum. The input of Ethereum transactions serves the same purpose as Bitcoin's OP_RETURN. We created a transaction that stores the Hex value using the "eth.sendTransaction" command. Ethereum sends the generated transaction to the transaction pool.   Figure 15 shows the transactions stored in the transaction pool of Ethereum. A Transaction pool is a storage place for creating the block. We added two transactions to the transaction pool. The first transaction is a transaction between the general accounts, and. The second transaction is a transaction that Hex data stored in the input item.  Figure 15 shows the transactions stored in the transaction pool of Ethereum. A Transaction pool is a storage place for creating the block. We added two transactions to the transaction pool. The first transaction is a transaction between the general accounts, and. The second transaction is a transaction that Hex data stored in the input item.  Figure 16 shows the contents of the block generation in Ethereum. Our generated transactions are stored in block 4. Figure 17 shows the contents of the transaction in the block. The Hex value was stored in the input item of the transaction.   Figure 16 shows the contents of the block generation in Ethereum. Our generated transactions are stored in block 4. Figure 17 shows the contents of the transaction in the block. The Hex value was stored in the input item of the transaction.  Figure 15 shows the transactions stored in the transaction pool of Ethereum. A Transaction pool is a storage place for creating the block. We added two transactions to the transaction pool. The first transaction is a transaction between the general accounts, and. The second transaction is a transaction that Hex data stored in the input item.  Figure 16 shows the contents of the block generation in Ethereum. Our generated transactions are stored in block 4. Figure 17 shows the contents of the transaction in the block. The Hex value was stored in the input item of the transaction. Figure 16. Generated block contents in Ethereum. Figure 16. Generated block contents in Ethereum.
We apply the proposed method to ECCPoW cryptocurrency systems [23]. ECCPoW is a PoW method that uses error correction code. ECCPoW can be personalized by hard forking Bitcoin and Ethereum. ECCPoW has the effect of solving different problems every block for ASIC resistance. ECCPoW uses hamming weights and signs to control difficulty. We use the default generation time (bitcoin 180 s, Ethereum 60 s) of the block because we need to store additional CBDC information in the blockchain. Figure 18 shows the block generation time of Bitcoin and Ethereum using the proposed method. Figure 18A is a block generation time graph of Bitcoin, and Figure 18B is a block generation time graph of Ethereum. Table 1 shows the target block generation time, difficult change time, average block generation time, and support of user data insertion in blockchains. Bitcoin's block generation time controls the difficulty of solving blocks for every 2016 blocks to occur every 10 min. The block generation time of Ethereum controls the difficulty with the goal of 10 to 20 s. We set the low difficulty of the block and created the block. For support of user data insertion, Bitcoin uses OP_RETURN, while Ethereum uses input. Bitcoin's average block generation is about 538 s per 400 blocks, while Ethereum's block generation time is approximately 4000 blocks per 1183 s, on average. As a result of the experiment, Bitcoin and Ethereum can be created using CBDC information. In the experiment, it is possible to create a stable block using a large number of nodes.
We apply the proposed method to ECCPoW cryptocurrency systems [23]. ECCPoW is a PoW method that uses error correction code. ECCPoW can be personalized by hard forking Bitcoin and Ethereum. ECCPoW has the effect of solving different problems every block for ASIC resistance. ECCPoW uses hamming weights and signs to control difficulty. We use the default generation time (bitcoin 180 s, Ethereum 60 s) of the block because we need to store additional CBDC information in the blockchain. Figure 18 shows the block generation time of Bitcoin and Ethereum using the proposed method. Figure 18A is a block generation time graph of Bitcoin, and Figure 18B is a block generation time graph of Ethereum. Table 1 shows the target block generation time, difficult change time, average block generation time, and support of user data insertion in blockchains. Bitcoin's block generation time controls the difficulty of solving blocks for every 2016 blocks to occur every 10 min. The block generation time of Ethereum controls the difficulty with the goal of 10 to 20 s. We set the low difficulty of the block and created the block. For support of user data insertion, Bitcoin uses OP_RETURN, while Ethereum uses input. Bitcoin's average block generation is about 538 s per 400 blocks, while Ethereum's block generation time is approximately 4000 blocks per 1183 s, on average. As a result of the experiment, Bitcoin and Ethereum can be created using CBDC information. In the experiment, it is possible to create a stable block using a large number of nodes.
We apply the proposed method to ECCPoW cryptocurrency systems [23]. ECCPoW is a PoW method that uses error correction code. ECCPoW can be personalized by hard forking Bitcoin and Ethereum. ECCPoW has the effect of solving different problems every block for ASIC resistance. ECCPoW uses hamming weights and signs to control difficulty. We use the default generation time (bitcoin 180 s, Ethereum 60 s) of the block because we need to store additional CBDC information in the blockchain. Figure 18 shows the block generation time of Bitcoin and Ethereum using the proposed method. Figure 18A is a block generation time graph of Bitcoin, and Figure 18B is a block generation time graph of Ethereum. Table 1 shows the target block generation time, difficult change time, average block generation time, and support of user data insertion in blockchains. Bitcoin's block generation time controls the difficulty of solving blocks for every 2016 blocks to occur every 10 min. The block generation time of Ethereum controls the difficulty with the goal of 10 to 20 s. We set the low difficulty of the block and created the block. For support of user data insertion, Bitcoin uses OP_RETURN, while Ethereum uses input. Bitcoin's average block generation is about 538 s per 400 blocks, while Ethereum's block generation time is approximately 4000 blocks per 1183 s, on average. As a result of the experiment, Bitcoin and Ethereum can be created using CBDC information. In the experiment, it is possible to create a stable block using a large number of nodes.

Comparison of Proposed Methods and Exchanges
This section compares the proposed method with the cryptocurrency exchange. Cryptocurrency exchanges have both a centralized and decentralized exchange method. We compare the proposed method with the exchange's technical use of blockchain, Private Key rental, amount of fluidity, transaction liability, transaction target cryptocurrency, and cryptocurrency information management. Table 2 shows the comparison with the proposed method and the exchange. The technical use of blockchain uses the proposed method, while the decentralized exchange uses the blockchain to store transactions. Centralized exchanges use centralized storage instead of a blockchain. The use of blockchain technology can determine whether a transaction can proceed without an arbitrator. Decentralized exchanges disclose transaction details and technically guarantee trust. Centralized exchanges keep their transactions private and rely on trust in the exchanges.
Private key rental is not required by the proposed method and distributed exchange. Private key rental is closely related to security. The centralized exchange receives the private key and operates the exchange. In high volumes, centralized exchanges are a security risk. Cryptocurrency security incidents typically occur on exchanges rather than on blockchains.
The amount of fluidity has many centralized exchanges, with few proposal methods and decentralized exchanges. The amount and price of liquidity are challenging to establish a deal at the time you want. Nevertheless, the proposed method of transactions always requires the consensus of the central bank.
Transaction liabilities are all different. Transaction liability is a legal entity that guarantees cryptocurrency. If there is a problem with the transaction, it is responsible for solving the problem and compensation. Centralized exchanges are the responsibility of the exchange. In the event of a problem, the exchange guarantees a settlement. The responsibility for decentralized exchange is not clear, or the decentralized exchange is responsible. The proposed method is the responsibility of the central bank as a transaction between groups. A centralized exchange is responsible for the transaction. The decentralized exchange technically guarantees the reliability of the transaction. However, if there is a problem with the transaction, the liability may be unclear.
Transaction target cryptocurrency is as follows. The proposed method can deal with CDBC, decentralized exchanges with the same hash function cryptocurrency, and centralized exchanges with all cryptocurrencies. Decentralized exchanges are possible when they have the same hash function. Examples of this include ERC-20 Coin and Bitcoin Hard Fork Cryptocurrency.
Cryptocurrency information management is possible with the proposed method and centralized exchange. Decentralized exchanges can only trade cryptocurrencies that are initially set. The proposed method is managed by the central bank's public groups based on the MDR. The centralized exchange can further manage the cryptocurrency allowed by the exchange.

Conclusions
This paper proposes an inter-CBDC exchange system based on ISO/IEC 11179 in preparation for the introduction of CBDC by central banks around the world. CBDC would be difficult to implement and supply in one standard way, managed by a central bank or equivalent (for example, mCBDC Model 3 of BIS). This paper proposes a blockchain system that applies ISO/IEC 1179's approach to data interoperability. The system stores and manages CBDCs from central banks that want to be exchanged according to metadata registry elements.
CBDC has officially only released Sand Dollar. Therefore, we hard forked and applied blockchains (Bitcoin, Ethereum) that are conceptually functioning well at the moment. The experiment assumes that CBDC Data Elements generated by ISO/IEC 11179 is stored. We used space that allowed users of Bitcoin and Ethereum to use. The proposed theory could be applied to existing cryptocurrency systems. However, its application to existing cryptocurrency systems has structural limitations in which CBDC Data Element is added to free space. In practice, blockchain structures will be needed to efficiently manage CBDCs implemented in multiple ways.
In the face of the growing need for CBDCs by central banks, this paper presents a method of sharing among CBDCs. According to the BIS, more than 84% of central banks are involved in CBDC-related businesses, indicating that other CBDCs will be issued soon. Therefore, the need for interoperability will become more important for the success of CBDC.