Over the past year, CBDCs have emerged as the holy grail of cross-border payments, making payments faster and more cost-effective for wholesale and retail markets. While CBDCs promise to deliver significant value, there are several hurdles central banks need to clear. Top of mind is which technology to use—DLT, centralized database, or existing rails and with that comes the question of interoperability across platforms. Last November, Digital Asset announced its plans to open source its example of a CBDC implementation highlighting some potential features around programmable money and interoperability built using Daml. Today, Darko Pilav, Head of Switzerland and Customer Experience Engineering Team at Digital Asset, shares details about the work, which is now open source and available for public consumption.
Let’s talk about CBDCs: what are they and how do they differ from cash, and bank deposits that we use today?
CBDCs are a combination of the bank deposits you hold at your commercial bank, and physical cash. With CBDC you get the benefits of the ease of use of deposits for any kind of payment, with the additional benefits of physical cash being backed directly by the central bank instead of by an intermediary (i.e. commercial bank). Effectively you can see a CBDC implementation as the extension of the central bank ledger to a broader audience. Compared to physical cash, you gain the flexibility of doing instantaneous payments to any eligible recipient—you don’t have to physically move bills and coins.
The difference to bank deposits is in its risk profile. Given that CBDC are issued and backed by the central bank itself, there is no risk of defaulting. Today your money on your bank account is not directly backed by the central bank. It is rather a liability of your commercial bank, which also means that if the commercial Bank goes bankrupt, your assets are at risk. To combat that, a number of countries are providing government guarantees up to a certain amount, i.e., the government will step in and ensure owners of the deposits will not lose their money. But this is a complicated process, the covered amount is typically limited, and it effectively tries to emulate properties that you would get with CBDC out of the box.
Can you tell us about the CBDC implementation work you have been doing?
The CBDC implementation is an example of interoperability, the possible capabilities of CBDC, and how central banks can use Daml, an application platform created by Digital Asset, to integrate CBDCs across different blockchain and database platforms. It is a simplified design, which was purposely done so that we could focus on the important properties of interoperability without having to cover all the intricate details of a production solution. We have built this example using Daml to showcase all of the above, and have made it open source and available for public use.
What does a successful CBDC implementation look like?
From our perspective, we believe seamless, built-in interoperability is the only way for CBDC’s to reach their full potential. Of course, a great follow on question is what do we mean by interoperability? For Digital Asset, true interoperability includes four key components: multi-ledger technology, cross-ledger atomicity, data privacy, and composable extensibility.
Multi-ledger technology: The ability to deploy and connect digital currency systems across disparate networks regardless of the underlying IT infrastructure. Top among the challenges is deciding which technology to use—DLT, centralized database, or existing payment rails. On the back of that is the compatibility with other CBDCs. There is not going to be one ledger to rule them all. Some might not even use DLT. Ensuring that CBDCs are compatible with other CBDCs is an imperative first step, else, the CBDC runs a great risk of hitting a dead end at the start.
Cross-ledger atomicity: If one leg of a transaction fails, all sides fail. By ensuring atomicity, systems can achieve payment versus payment and delivery versus payment without the risk of handing over the goods when the payment leg fails and without the need for a central authority acting as an escrow. The counterparty risk or delivery risk are eliminated.
Data privacy: Almost all non-Daml blockchains lack crucial properties of privacy, leaking significant transaction information to the world. Some infrastructures have addressed some of the privacy concerns but lack the ability to guarantee their privacy mechanisms when transacting across chains. Any CBDC solution must feature the highest need-to-know level of privacy independent of the infrastructure that it is transacted on.
Composable extensibility: This means the ability to dynamically add new applications and connect to other networks on the fly. Imagine after a government introduces CBDC, an e-commerce company wants to tie them into their existing workflows by allowing payments to be done with CBDC. In order to maintain all the crucial properties mentioned above (atomicity, privacy, etc.), the e-commerce company can not rely on standard APIs. It must rather compose their payment process with the CBDC transfer functionality. With Daml, this is trivial to do. Furthermore, using non-Daml technology, the only way to achieve this would be to run both the CBDC solution as well as the e-commerce solution on the same platform. This is of course not practical, as a central Bank would not and should not agree to run a number of 3rd party solutions on their platform. Daml’s interoperability eliminates this problem as well. The e-commerce company operates its solution on their own infrastructure and it simply interoperates with the CBDS solution of the Central Bank.
One additional remark that I would like to add is that historically the entity managing an account is also the same entity that provides services for said account. Hence the question comes up whether this means that in a retail CBDC scenario, the central bank will have to provide all the services of a bank account to the broad population. The answer is that if you are using the right technology, and you design the CBDC solution correctly, the concern of account management and provision of services can be disentangled. This would give the opportunity for commercial banks that already have the customer relationship, and have a lot of knowledge and experience in the provision of these services to continue to do so, while the central bank is simply the maintainer of the account.
How does Daml fit into the CBDC ecosystem?
Daml provides a number of crucial properties right out of the box. A few examples would be true cross technology interoperability, extensibility, and incredibly high levels of privacy. To the best of our knowledge, no other technology is capable of providing all of the above to such a high level as Daml. Our technology stack works with the major enterprise blockchains as well as centralized databases and other systems. In our opinion these are crucial properties, for a large number of different use cases and particularly for CBDC.
Why did Digital Asset open source the code?
CBDCs have great potential to transform cross-border and domestic payments in both wholesale and retail markets. Given its importance to markets worldwide, we want to make sure everyone involved in building a CBDC solution has access to the components that will make it successful. It’s a great starting point for anyone needing to build applications that will eventually need to integrate with CBDCs.
Secondly, we also want to show how straight forward it is to implement various features of CBDC and make it interoperable across technologies when using Daml. Our technology stack is best known in the blockchain space, but it goes beyond blockchain and can be used across database and cloud technologies. The Daml code used for the demo runs across blockchain and database platforms, which is a very realistic scenario given central banks will not use the same platform to build and deploy their digital currencies.
Finally, we would like to make sure that when people are thinking about what a CBDC solution should look like, its functionality and how it should behave, they have the best technology in mind. Our technology stack is solving a few very hard problems, and this can influence the design and requirements of the CBDC solution
What other technology can achieve this interoperable state for CBDCs?
APIs could be used to connect the various CBDCs using existing message-based technology. This approach will get the job done to some extent, but it lacks a few key components, atomicity and extensibility. In this scenario, how would you connect central bank digital currency into capital markets, into insurance, or supply chain? If you don’t tie in the system that handles the delivery part of the delivery versus payment process, then just having the payment part on the system doesn’t give you all that much. Let’s look at an equity transaction using CBDCs. In this example, neither the seller nor the buyer wants to start the settlement process first. The seller doesn’t want to give you the equity and wait for you to send the cash. Nor, do you want to front the cash and get the equity later. You both want the transaction to settle at the same time. In order to do this you have to be able to connect to the system that manages the positions of the equity, e.g., a central depository system, with the central bank system that manages the CBDC, and do this atomically across two different systems.
Is this interoperability example only applicable to CBDCs? If no, what other use cases could benefit?
This particular use case is specific to CBDCs, but it is only one example that showcases the power of Daml. The purpose of the demo and our example of an implementation is to show how an external application can interface with a CBDC. And, to clarify, we have not implemented any new Daml functionality to create the CBDC use case. This is just one use case where we are applying our technology as it stands today. This demo functionality can apply to any scenario where multiple parties and complex workflow across disparate systems exist. We picked CBDC because it’s a relevant topic and very timely as central banks are evaluating their technology options and building roadmaps for their potential CBDC launches.
On the topic of technology evaluations, there are a number of key points central banks need to consider when choosing a technology to support CBDCs. We recently published a whitepaper explaining these key points in greater detail.
What do central banks or enterprises need to build this functionality in-house?
To get the most out of the open source code we recommend using developers that have some experience writing applications in Daml or willing to learn the language. We offer some tutorials and tips in our forum, called Daml Discuss or as part of the Daml Developer Certification exams.
When and where will the code be available?
It’s available today. Visit Github to download an example of a Daml-powered CBDC network.
What do you hope market participants will take away from this use case?
My hope is that anyone working with CBDCs or building applications that need to interact with CBDCs, can use this functionality as a starting point to build their solutions. For Digital Asset, we also wanted to clearly demonstrate what a CBDC implementation requires to be successful. We believe with the interoperability properties we identified, CBDCs will realize their full potential. Without it, they could hit a dead end at the start. For us, CBDCs are a great use case to show the power of the technology and how it can streamline complex multi-party workflows across disparate systems.
For more information about the technical ingredients behind a successful CBDC implementation, please download a copy of our latest whitepaper “Central Bank Digital Currency: Principles for Technical Implementation”, published in collaboration with Darrell Duffie, Graduate School of Business, Stanford University.