CBDC should be interoperable. But how?

CBDC should be interoperable. But how?

In their 2023 report on CBDC interoperability, the World Economic Forum writes that “the central bank community should take steps at the beginning of the [CBDC] design process to include” considerations on interoperable functionalities. The authors have identified various principles for that, such as standardization, openness, and cross-border integration.

In the same vein, many other institutions have also highlighted the need for interoperability. Most recently, the Atlantic Council has published a survey of ongoing efforts in that area, noting that “there is a patchwork of first steps undertaken by both public-and private-sector entities, aimed at achieving different objectives”.

Last week, I discussed the “what”: which interoperability domains exist, and which criteria can be used to assess their similarities and differences. In this article, I will highlight some technical options for interoperability.

Interoperability criteria & domains

As a brief reminder from the last article, these are the criteria that can be used to classify interoperability domains:

  • The unit is the currency symbol, such as EUR or USD, or alternatively another asset identifier, such as an International Securities Identification Number (ISIN) for securities.
  • The issuer is the entity that manages the supply of the digital currency; this responsibility includes increasing (or reducing) currency supply in the economy.
  • The platform is the technical infrastructure that may or may not be operated by the issuer of the currency.

We have also seen four major interoperability domains: instant payment systems (IPS), retail and wholesale CBDC, foreign CBDC, and stablecoins. Depending on the concrete implementation, one of the following archetypes for interoperability can be used.

The bridge

A bridge is a deep, bidirectional connection between two (or more) systems, where participants can seamlessly transfer value. For example, a bank could request conversion of a particular amount of retail CBDC into the equivalent amount of wholesale CBDC, therefore reducing the supply of retail CBDC and increasing the supply of wholesale CBDC. However, the total circulating CBDC supply stays constant. This option works especially well if both unit and issuer are the same, or alternatively if the units have a fixed exchange rate. Of course, both platforms need to support this kind of value transfer on a technical level.

Such a connection can be easily operated on a 24/7 basis. But it should not be considered if the central bank is not in control of the other system, due to a substantial risk that vulnerabilities in third-party systems could propagate across bridges.

This option is suitable for the interoperability with instant payment systems (IPS) and across domestic CBDC. This could aid commercial banks in their liquidity management, since they would not need to retain balances or tokens in two distinct systems, and can exchange monetary value on demand. For example, if a bank’s customers withdraw more retail CBDC from their deposit accounts than is currently available in that bank’s digital vault, it could request an instant conversion from its RTGS balance.

The exchange

An exchange is an entity that controls liquidity of two or more assets that may differ on unit, issuer, and platform, providing a service that allows participants to trade one asset for another. In this option, a payment across systems would comprise at least two transactions:

  1. Payer A pays an amount x to the exchange E.
  2. Subsequently, the exchange triggers a payment of an amount y based on a pre-determined rate to the payee B.

Depending on the precise technical design, more parties might be involved. Independent of that, the total monetary supply on each individual system stays constant for each transaction.

There are technical measures to make the orchestration more reliable. Most importantly, the individual transactions should not diverge, i.e., one transaction should complete if and only if the other one completes (so called atomic settlement or atomic swap). This can be achieved through Hash-Time Lock Contracts (HTLC), a type of smart contract that can work across platforms. Though if both systems use the same platform, Automated Market Makers (AMMs), another type of smart contract, can prevent divergence and manage liquidity and pricing automatically.

An automated, standardized exchange mechanism could solve multi-laterality. But note that the foreign-exchange market is currently highly decentralised, therefore consistent pricing through smart contracts is not yet achievable. There is active work conducted on AMM research. Using AMMs, a hub-and-spoke model can be easily implemented, because there is a unified liquidity pool across multiple currencies.

This option naturally lends itself to interoperability with foreign CBDC. It can also be employed for IPS (where no currency conversion is required) and stablecoins.


The wrapper

A wrapper is a technical facility where the central bank or an authorized intermediary would provide a representation of the CBDC in another system, sharing the same unit. A conversion request would therefore entail locking or earmarking CBDC into a dedicated wallet and issuing the same amount on the other system. Effectively, this would increase the monetary supply since the same value is now present in two systems. By construction, wrapper solutions cannot easily work in a hub-and-spoke model.

The challenge with wrappers is that each participant must trust that the funds are actually locked and can be converted back at any time, should they so request. Note that stablecoin issuers follow this approach, but typically, they do not have access to central bank money to use as collateral.

We foresee that the wrapper option could be used in jurisdictions where cash issuance is devolved to commercial banks based on strict reserve criteria imposed by the central bank. Additionally, Project Mariana, in implementing a multilateral cross-border CBDC, combines an AMM exchange with domestic retail CBDC wrappers (unfortunately also named “bridge”).

Conclusion

We have described three archetypes for interoperability between CBDC and other systems: bridges, exchanges, and wrappers. Each is suitable for different domains, although there are some overlaps. Based on these considerations, it becomes clear that any CBDC design should take each of those options into account. Fortunately, technical requirements can be easily incorporated depending on the use cases.

In the next article, I will discuss a case study for integrating CBDC offline payment functionality into an existing instant payment system.

This article is an excerpt from the research paper “Interoperability aspects of CBDC across ecosystems and borders”. I thank my colleagues Polly B?umler, Vratul Kapur, Daniel Nagy, as well as the anonymous referees from Journal of Payment Strategy & Systems for their numerous suggestions to improve this manuscript. The full version can be read here.

要查看或添加评论,请登录