An introduction to CBDC and how to get started in Daml
CBDC (central bank digital currency) is the next digital frontier for commerce. CBDCs have many benefits over traditional digital technology that represents money in the digital world today. Using CBDC will enable significant operational improvements, such as the elimination of constant reconciliation of information stored by different parties in the banking ecosystem
In this blog, we’ll see how to work with a CBDC—a concept that is driving fintech innovation. We’ll examine how today’s banks and merchants can prepare for this transition without having to completely reimagine how they handle money.
We’ll use Daml, an open source smart contracts language that has strong privacy guarantees and allows for interoperability between various types of infrastructures used by banks through the Canton privacy-enabled distributed ledger. At its core, CBDC will be a digital token for money with a privacy-aware, golden-source-of-truth underpinning the distributed network. This makes it much easier to perform core operations such as money transfers (e.g., lending, payments, etc.), while also enabling a platform for significant innovation in all areas of commerce (e.g. warranty, promotions, service etc.).
Set-up:
In our example, we’ll consider three parties in addition to ourselves:
- Our bank, where we have our account
- Retailer, where we will buy items
- Retailer bank, who will make a payment to their bank
As a first step, let’s get a transaction going at a retailer. Every retailer on the network will have a role, and in this role they will have the ability to create a transaction with a consumer. The transaction includes the item and amount included on the transaction.
It is interesting to note that apart from being written in Daml, which allows for a common plumbing across entities, the business logic here is exactly the same as what the retailer would do today. They do not have to make any changes to the way they handle transactions.
In addition, while it’s customary to have a central bank issuing the tokens in such examples, it’s not relevant for our discussion. We’ll assume that the customers have already converted all—or at least a portion—of their traditional holdings to a digital currency issued by the central bank, and that their digital holdings are still managed by their primary banking institution.
This blog thus illustrates that consumers or merchants do not have to worry about whether they hold regular currency or CBDC. Only the banks will maintain a mapping of which customer has which CBDC tokens. So just as it happens today, their customers will only need to consider their total holdings for their specific purpose (retirement, savings, education, etc.). Meanwhile, the platform will enable the banks to map the right tokens to the right accounts in order to maintain the traceability.
As you will see, this will be straightforward in the Daml language, managed by smart contracts and orchestrated by the Canton distributed ledger across the multiple parties, regardless of their underlying infrastructure.
Daml maintains a strict privacy environment. This transaction proposal is visible only to the retailer (signatory of the contract) and the consumer (a controller on this contract who can accept the transaction, thus setting it up for payment).
Even though we have both of the banks specified on the contracts, they can see neither the transaction proposal nor the transaction contract itself. This is a strong feature of using Daml.
An optional path of checking if there is enough CBDC in the wallet has been shown above. If there isn’t enough of a balance, the consumer can apply for credit or follow other scenarios. Daml makes it easy, because each of these commands in a single choice are atomic. Either the transaction will be approved or it will be aborted.
Also note that when the consumer accepts the transaction above, they also automatically create a payment request to their bank. In this PaymentRequest contract, they have included the amount, but not the line item information. This is a privacy enhancer (in our example), and also shows how granular privacy is possible to be maintained within Daml.
As a result, we see a Transaction contract that becomes a digital receipt of the transaction. The banks do not see this receipt, unless the consumer wants them to.
Instead, the banks see the amount of the transaction, in that they will be facilitating the transfer.
This following is what the bank will see as soon as the transaction goes through:
The bank now has the ability to execute a MakePayment function. This step can be automated as well, thereby leading to straight-through processing.
Note that we could model our workflow in such a way that the payments and transactions bypass the intermediaries (i.e., banks, in our case). However, intermediaries serve important functions, such as holding escrow, handling disputes, offering loyalty points, assisting with tax filings, etc. The exact workflow doesn’t define what CBDC is, because the benefits of low latency and absence of reconciliations will still be delivered. So, we could model our workflow with multiple variations of how information will flow, with peer-to-peer transactions being only one of the many possible use cases.
The receiving bank receives the proposal and credits the wallet of the retailer. It has the option to automate all of the processing as well:
Finally, a Payment contract is created on the ledger, which serves as evidence of the transaction. No other payment reconciliations are needed to be carried out.
Summary & key considerations
In our example above, we relied on a workflow that is essentially an atomic settlement. Daml and Canton allow the settlements to be atomic, despite the two parties and the central bank operating on completely different infrastructures and technologies. This is a powerful capability that Daml and Canton bring to digital currencies.
Innovation in this space has suffered due to a lack of interoperability. It is unlikely that any two entities will have the same technology and business-process stack. With Daml working on the Canton distributed ledger, this interoperability is possible across any kind of persistence layer and infrastructure that the entities may adopt. Their Daml workflows are automatically interoperable, thus creating new possibilities in multi-party collaboration.
If you are looking for a comprehensive working example on CBDC, Digital Asset has an open source Daml project on CBDC ready for use to begin tailoring your project. Check out this detailed white paper outlining some of the core implementation principles.