Project Dunbar
Project Dunbar
Project Dunbar
International settlements
using multi-CBDCs
March 2022
Contents
01 Executive summary 2
02 Introduction 3
04
Critical challenges 11
4.1. Access
4.2. Jurisdictional boundaries
4.3. Governance
06 Governance 14
07 Processes 22
08 Technology 26
8.1. Infrastructure 26
8.2. Applications 29
Appendix
1.1 Dunbar capabilities and considerations 35
1.2 Prototype developed by R3 on Corda platform 37
1.3 Prototype developed by Partior on Quorum platform 53
1.4 Glossary of Terms 61
¹ See Bank for International Settlements et al, “Central bank digital currencies for cross-border payments”, 2021, www.bis.org/publ/othp38.htm.
² See Financial Stability Board (2020), Enhancing Cross-border Payments Stage 3 roadmap. https://www.fsb.org/wp-content/uploads/P131020-1.pdf
³ See BIS, “Enhancing cross-border payments: building blocks of a global roadmap”, July 2020, p3.
⁴ See R Auer et al, “Multi-CBDC arrangements and the future of cross-border payments”, BIS Papers, no 115, March 2021.
⁵ See BIS, “BIS Innovation Hub work on central bank digital currency (CBDC)”, www.bis.org/about/bisih/topics/cbdc.htm.
Technical workstreams
2.3 Project methodology
2.3.1 Project partners and structure The design workstream was led by Accenture
(workstreams) with support from Temasek, and focused
Project Dunbar is a collaboration between the primarily on developing the high-level functional
BIS Innovation Hub Singapore Centre and the requirements and design of a shared cross-
central banks of Australia, Malaysia, Singapore border payments system. A series of workshops,
and South Africa. which were conducted across three sprints with
the participating central and commercial banks,
The partner central banks have published utilised a structured design-thinking approach
multiple reports and conducted technical to discuss and develop an innovative yet
experiments on CBDCs, bringing a wealth of practical solution.
knowledge and expertise to the project. This
has helped to generate useful insights during The goal of the technical workstreams was to
discussion workshops and led the team to develop technical prototypes on two different
develop an appreciation of the complexities DLT platforms – Corda and Quorum – to
involved in building a common platform, as well transform the idea of a multi-CBDC platform into
as on more abstract topics such as governance. working prototypes. The Corda platform
There were also two central bank observers of development was led by R3 while the Quorum
the project, the Bank of France and Hungary’s platform development was led by Partior (with
Magyar Nemzeti Bank, which contributed support from DBS, J.P. Morgan and Temasek).
substantially to the discussion, and their support The two prototypes were developed based on
is greatly appreciated. the proposed requirements and designs from the
design workstream, while leveraging the existing
Technical workstream Enable multiple CBDC Enable foreign currency (FCY) Enable new models of FX, and
issuers and customise base transactions, with multi- technical controls to support
functionality (issue, redeem, tier account structure and governance models
transact) onboarding
Transact Transact
Issue/Redeem Issue/Redeem
Distributed
Replicate
Replicate
Ledger
Replicate
Australian Malaysian
banks banks
Governance
2. Onboarding of members
Processes
4.3 Monitoring,
4.1 Integration/ 4.2 Interbank 4.5 System
reporting, control 4.4 User interface
connectivity payments administration
and notification
Technology
Role
Non-resident
1. Initiate transfer and exchange of CBDCs
banks
Corporates – Customers
N/A – Transact only through commercial banks
of banks
Onboarding/off-boarding by
Selected
Central operator Central banks commercial
banks
Selected
commercial
banks
Commercial
banks Other
commercial
(If all banks (If only selected
banks host nodes) banks host nodes)
From a technical and operational perspective, When a new participant is being onboarded
onboarding would be executed by a central onto a platform, it needs to meet two sets of
operator. onboarding requirements. The first is a set of
common rules at the platform level. The second
Selected commercial banks relates to jurisdiction-specific requirements as
Selected commercial banks could be chosen and mandated by the local central bank.
technically and operationally onboarded by the
central banks in their country of domicile. These Non-resident banks
would likely be larger banks that are existing As banks only require a single point of connection
participants of other payment schemes. to the platform, access to the platform for non-
resident banks will be provisioned in their country
of domicile.
Non-resident
banks
Legal claim
Transaction processing
⁸ See R Auer and R Böhme, “The technology of retail central bank digital currency”, BIS Quarterly Review, March 2020, pp 85-100, www.bis.org/publ/
qtrpdf/r_qt2003j.pdf.
Transactions would need to comply with a common All participants (nodes or banks) will be subject
set of business rules enforced universally across to a universal set of security policies.
the platform, and additional currency or country-
6
specific business rules may be applied by the ❶ ❹
respective central bank.
have little or no
Strategic are unprecedented or have a large impact or
Decisions that... guidance from scheme
and platform new significance
decisions policy or framework
are unprecedented
have broad guidance
Tactical or have a moderate
Decisions that... available from scheme
decisions somewhat familiar impact
policy or framework
(but meet other tests)
6.3.3 Common rules and autonomy Rules on the platform are thus designed to be
For the consistency of the platform, a set applied in three ways.
of common rules would be applicable to all
participants. Under a consortium structure, these • Platform-level rules – universal rules
common rules would be established through a applicable to all that participate in the scheme
consensus of the participating central banks. and applied at the platform level. These rules
are maintained centrally by the platform
At the same time, central banks demand operator. A potential platform-level rule
complete sovereignty and autonomy in: (i) could be managing access to the multi-CBDC
areas of critical functions, such as issuance of platform.
currency; (ii) the application of “local” rules and
regulations at the currency- and jurisdiction-level; • Jurisdiction-level rules – rules specific to a
(iii) the application and the recognition of the local requirement are applied on a jurisdiction
central bank’s mandate provided in its national level. These rules can be maintained by each
legislation; and (iv) data, including privacy and central bank. An example of a potential
selective sharing of data. jurisdiction-level rule could be limitations on
members which are allowed to obtain CBDCs
directly from the central bank issuing them.
Universal
rule related Greater Requirement
Local no no no no
to platform benefits in based on
requirement? applying rule Jurisdiction-level rule
governance specific
or platform consistently? currency?
economics?
Currency-level rule
yes yes
Achieving autonomy for central banks Strict technical controls are put in place to
Central banks are responsible for managing and guarantee this autonomy such that even a super-
regulating their nation’s currency to achieve user operator of the platform cannot violate
the objectives (fiscal or otherwise) set by that it. In addition, the platforms are designed for
country. This management of currency would resilience; this means failures at the individual
extend to a multi-CBDC platform, where a country level are isolated and therefore do not
central bank would need to be able to manage cascade into platform-wide failures. This ensures
its own CBDC on the platform. This entails not that the autonomised regions and components
only oversight over usage of its CBDC, but also of a central bank on this shared platform are not
issuance and redemption of CBDCs. infringed by the failures of other central banks.
The prototype platforms are designed to give From a technical perspective, both the R3 and
central banks autonomy within the boundaries Partior sandboxes were able to support the
and parameters of a universal platform-level necessary control that central banks require to
framework, such as in the application of manage and regulate their own currency. The
jurisdiction- and currency-level rules. Autonomy technical details are elaborated on in Section 8.
here is viewed as the ability for central banks to
exert control within the boundaries of their scope,
as well as the inability of any other party to do so
without the consent of the central banks.
2a 2b
Sponsor bank performs checks Sponsor bank for Sponsor bank for Sponsor bank performs checks
on sender bank and approves/ sender bank recipient bank on recipient bank and approves/
rejects the transaction rejects the transaction
1 3
Sender bank Sender bank initiates When both approvals are provided, Recipient bank
transfer of FCY$1m transaction is recorded on ledger
The diagram describes how a cross-border Approval routing rules for Steps 2(a) and 2(b) are
transfer takes place between a sender and determined and set by the central bank issuing
recipient bank in different jurisdictions, using a the CBDC. In this example, the approvals are
currency from a third jurisdiction. The cross- routed to designated intermediaries as both
border transfer begins with Step 1, with the sender and recipient banks are not in its
initiation of a transaction by the sender bank, jurisdiction. If the recipient bank is in the same
which results in a debit or deduction of its CBDC jurisdiction, the routing rules would skip Step 2(b)
balance. After the transfer has been initiated, as no sponsoring bank is required.
sponsor banks for both sender and recipient
banks are notified in Steps 2(a) and 2(b) and A central bank could also disable the need for
would carry out non-settlement processes such Steps 2(a) and 2(b), allowing for a direct transfer
as AML/CFT and other control processes before from sender to recipient bank, without the need
they approve the transaction. Upon receiving the for any intermediaries. Such a payment flow
necessary approval from sponsor banks and would be akin to the direct CBDC model.
fulfilling the obligatory conditions of the smart
contract, the CBDCs are credited or added to the The technical choice of designing the payments
balances of the recipient bank in Step 3, which flow and the underlying technical architecture
marks completion of the transfer.
Other capabilities
Exchange control (that are not part of transaction processing)
Reporting (extraction monitoring
of information) (if applicable)
Central bank and regulators
KYC/EDD KYC/EDD
Sponsor bank Risk mgmt Risk mgmt Sponsor bank for Integration
for sender bank recipient bank
FX
Processes embedded in smart contracts
Sanctions Payment and
Operations
screening settlement
Sanction screening
AML/CFT
KYC/EDD
Depending on FX Depending on FX
model adopted model adopted
Reconciliation
4.3 Monitoring, reporting,
Reporting
control and notification
7.4 Foreign currency exchange obligations by the counterparties are fulfilled and
A foreign exchange (FX) transaction can be viewed discharged. An example of an FX trade is where a
as two parts: FX trade and FX settlement. buyer agrees to buy one unit of foreign currency
CBDC (FCY) from the seller with two units of local
FX trade is the agreement between two currency CBDCs (LCY). This implies an FX rate
counterparties to exchange one currency for (LCY/FCY) of 0.5. The settlement is when the buyer
another at a specified rate for a specified amount successfully sends two units of LCYs to the seller
on a specified date. FX settlement is when the and receives one unit of FCY in return.
Model Who are the How are FX rates How is FX trade Connectivity
counterparties determined settled mechanism
A third-party, such as Matching of buy/sell Transfers between Integration with the
an exchange operator orders on the third- the participants and third-party platform for
party platform third-party exchange settlement on multi-
❶
FX exchange
(and clearing) operator/clearing CBDC platform
house on multi-CBDC
platform
Bilaterally among the Agreed bilaterally Transfers between the APIs for PvP settlement
participants between participants participants on multi- to ensure transfers
CBDC platform are linked through
❷
OTC between
participants unique identifiers, and
either complete or fail
together
Both R3 and Partior have done extensive work on Cloud services were ideal for deployment and
digital currency projects and were able to leverage testing of the prototypes, due to their elastic
platform functionalities developed previously. The nature that allows resources to be ramped up or
CBDC Accelerator by R3 has been used and tested down, or even suspended, depending on usage
by multiple central banks over the last few years, needs.
with a comprehensive feature set developed which
is based on the requirements of central banks. The For ease of experimentation, a single cloud
Partior Sandbox is developed by Partior, which has account was used for each set of deployments. In
since built a live platform for multi-currency a live implementation, it is likely that participants
clearing in Singapore. The Partior platform is being would manage their own nodes, either using
used for USD and SGD payments (with additional on-premises or cloud infrastructure.
currencies and corridors going live in 2022).
8.1.2 Network components and
As such, many of the basic features of a wholesale services
digital currency platform are available out-of-the- A typical network for both prototypes would
box (OOTB). This allows the project to focus on a consist primarily of nodes, which are hosted by
targeted scope of proving the technical feasibility participants. Both prototypes are built on a
of transacting on a multi-CBDC platform, while permissioned network, with access controlled by
leveraging relevant existing functionalities and the network operator.
user interfaces.
A Corda network is made up of nodes, each of
This section will describe the infrastructure, which runs an instance of Corda and one or more
application and data architecture of the two CorDapps. Communication between nodes is
prototype platforms, with additional technical point-to-point and does not rely on global
details included in the appendix. As the two broadcasts. Each node has a certificate that maps
platforms were built on different distributed ledger its network identity to a real-world legal identity.
technologies, the infrastructure is markedly A Corda network also includes other services such
different. On the other hand, the applications were as a network map service, which maps each well
built to specifications from the design workstream, known node identity to an IP address; an identity
and hence operate in a similar manner. manager service, which acts as the gatekeeper to
the network; and a signing service, which acts as
a bridge between the main network map and
identity manager services, and the public key
infrastructure (PKI) and hardware security module
(HSM) infrastructure. Additionally, a notary
service provides uniqueness consensus by
8.1.3 Nodes
Nodes are key components of a DLT network. A
node usually consists of a platform core that
manages communications with other nodes, a
distributed application that runs the logic of the
smart contracts and an internal database for data
storage. Typically, there are multiple nodes on a
network, with each hosted individually by
participants. Integration with external systems,
such as integration with central banks’ systems
for the pledging of assets, is usually performed
at the node level.
Selected
commercial
bank
Regional
commercial
bank
Corda Network Services
Austral
Global
commercial
bank
ia
Singap
Malays
Notary
Corda Oracle
Services
ore
ia
Network
map
Identity
service
Signer
S o u t h A f ri c a service
SGD CBDC
Bank
A
AUD CBDC
Bank SGD
C CBDC Issuer Bank
... E
AUD
Bank ...
A
Bank
ZAR CBDC B CBDC Issuer
Onb
ar Bank
ds Bank D
o
Pro v
Bank B
J Bank
MYR CBDC
ZAR
id es a p pro
... H
CBDC Issuer a
Bank
Payment
va
F
MYR
Bank
l
C Smart Contract
... TXN ID:001
Bank
I CBDC Issuer
Std Conditions..
Option #1 Option #2
Hosts nodes Does not host nodes
• All local commercial banks are direct participants. • Some local commercial banks are indirect
• Large number of nodes may affect performance participants.
and scalability of network. • Accessing through other banks’ nodes may affect
• Approximately 400 nodes required for four privacy for indirect participants.
countries. As a reference, SWIFT links 11,000 FIs • Multi-tenancy solutions with improved
across 200 countries. technological controls may improve privacy.
One design consideration was about banks that are allowed to host nodes and connect directly to the network, as
discussed in Section 8. The number of banks ranges from hundreds to thousands across jurisdictions. Besides the
business consideration of infrastructure costs, there is also a technical consideration of the optimum number of nodes
that can be supported on the network. Scalability and performance may be affected if all local commercial banks host
nodes as direct participants.
One potential solution to this scalability problem is to allow only central banks and selected commercial banks to host
nodes, with other local commercial banks connecting as indirect participants through these node hosts. However, this may
affect privacy for indirect participants as there is a possibility that a node host could view transactions passing through the
node despite the security measures implemented. Such technical considerations will need to be further evaluated, including
through scalability testing and security assessments.
Central banks
Name Organisation Name Organisation
John Kenyon Reserve Bank of Australia Alvinder Singh Monetary Authority of Singapore
James MacNaughton Reserve Bank of Australia Jonathan Chan Monetary Authority of Singapore
Riaan Louw Reserve Bank of Australia Vincent Pek Monetary Authority of Singapore
Adam Gorajek Reserve Bank of Australia Margaret Olivier South African Reserve Bank
Norasyikin binti Mohamad Razali Bank Negara Malaysia Annah Masoga South African Reserve Bank
Chai Yi Wei Bank Negara Malaysia Patrick Johnson South African Reserve Bank
Sharmaine Nadirah binti Roslan Bank Negara Malaysia Hein Timoti South African Reserve Bank
Zahilah binti Ismail Bank Negara Malaysia Pearl Malumane South African Reserve Bank
Charmaine Tew Shu Yi Bank Negara Malaysia Larry Cooke South African Reserve Bank
Ng Yin Shia Bank Negara Malaysia Jan Mohotsi South African Reserve Bank
Dr. Normasita binti Sidek Bank Negara Malaysia Darren Chamberlain South African Reserve Bank
Chew Ming Heong Bank Negara Malaysia Lyle Horsley South African Reserve Bank
Pham Khai Uy Banque de France Anikó Szombati Magyar Nemzeti Bank
Anne-Catherine Bohnert Banque de France Péter Fáykiss Magyar Nemzeti Bank
We acknowledge and appreciate the support of the following organisations for participating in project workshops: Absa, AMBank, ANZ, Bank of New
Zealand, CIMB, Citi, Commonwealth Bank of Australia, FirstRand, Goldman Sachs, Hong Leong Bank, HSBC, Investec, Macquarie, Maybank, National
Australia Bank, Standard Bank, Standard Chartered Bank, United Overseas Bank, and Westpac.
Governance
1. Participants and stakeholders
1.1 Commercial 1.2 Central banks 1.3 Regulators 1.4 Operators 1.5 Corporates
banks
2. Onboarding of members
2.1 Account setup 2.2 End-to-end onboarding process
Processes
4. Processing, clearing and settlement service
Technology
5. Technology and Solution Architecture
5.1 Application 5.2 Data architecture 5.3 Infrastructure 5.4 Security
architecture
1.2 Central banks Central banks are parties that manage and execute their monetary policy and
objectives. They may be operators of their own payments systems (see Section 2.4).
Central banks oversee the issuance, destruction and management of their own central
bank digital currency (CBDC).
1.3 Regulators Regulators are the regulatory authority for all financial institutions within their local
jurisdiction, and activities include supervisory and regulatory policy development.
There may be multiple different regulators within a jurisdiction – ie for prudential
oversight and AML.
1.4 Operators An operator is the central party that maintains the system and that coordinates
changes or upgrades from a technical standpoint.
1.5 Corporates Corporates are the customers of banks. In wholesale inter-bank settlement, they
transact only through the banks and not directly on the system.
1.1.2 Other commercial This refers to commercial banks that operate via a selected commercial bank. They
banks may have a limited number of privileges on the system, and are typically subject to
less stringent requirements.
1.1.3 Non-resident banks This refers to banks in other jurisdictions, and not in the local jurisdiction.
2. Onboarding of members
2.1 Account setup Set up participant accounts in the system in adherence with system’s principles of
account structure.
2.2 End-to-end Onboarding steps required for new members to participate in the scheme.
onboarding process
2.2.2 Technical integration Integrate a new participant into the system or remove a participant from the system
with system based on defined guidelines and a checklist. This includes industry testing and
certification processes.
Eg a new participant must meet minimum standards to join the network, and must
meet local jurisdiction requirements to operate in the jurisdiction.
Eg a participant being offboarded needs to redeem all CBDCs in its wallet.
3.2 Rules and Ensure the payments FMI has defined rules aligned with legislation, regulatory
compliance requirements and the payments FMI’s policies, and that both the payments FMI and
participants comply with all required legislation, regulations and rules.
3.3 Policy Define principles, guidelines and courses of action for the payments FMI to achieve its
statutory objectives. Policy may be crafted into rules for implementation.
4.2 Interbank payments Core system functionalities that facilitate the transfer of funds between members in
various currencies.
4.3 Monitoring, Tools to allow participants to monitor their systems performance and payments
reporting, control activity, and enable alerting, reporting and management of user notifications.
and notification
4.4 User interface Front-end(s) for users to interact with the application. This includes the ability to
view and access payments data (position, history, search, collaterals), print, perform
reporting, login/logoff, manage permissions and block users, etc.
4.5 System Tools that allow the operators to change system configurations, enable rules and
administration procedures for creating and managing user access, and enforce security management.
4.2.2 Issuance/redemption Issuance refers to the process of participants exchanging or pledging assets for central
bank digital currencies (CBDCs).
Redemption is the process of participants exchanging CBDCs with the issuing central
bank to redeem the assets backing the CBDC.
4.2.3 Default management Calculate and manage key metrics for default management (eg collateral pool and
participants' contributions, survivor's contribution to cover any default shortfall).
FUTURE PHASES: while the current phase takes the assumption of gross settlement, a
future iteration could consider handling defaults under a net settlement model.
4.2.4 Risk management Operationalise the system’s risk model through processes and tools (eg maximum
values on limits, checks against pre-defined thresholds, access control) to support a
risk framework covering credit/counterparty risk, settlement risk, AML/CFT, as well as
system risk.
4.2.5 Liquidity Processes and tools to: (i) allow participants to use liquidity pools to settle all payment
management priority, (ii) allocate liquidity for specific payment priority, (iii) reserve liquidity for
specific payments, (iv) and monitor liquidity.
4.2.6 Payments processing Core processes of payments including queues, message types and formats, message-
routing, viewing and tracking.
4.2.7 Settlement Manages selected systems processes, including the timing and cycles of settlements
and the debit and credit of participants’ CBDC wallets.
CorDapp anatomy
Use Verify
States Contract code Contracts Legal prose Flows
reference reference
States – These define the facts over which written in Java or Kotlin. Contract execution is
agreement is reached. States represent on- deterministic, and transaction acceptance is
ledger facts, and are evolved by marking the based on the transaction’s contents alone.
current state as historic and creating an updated
state. Each node has a vault where it stores any Legal prose – Each contract also refers to a
relevant states to itself. A state is an immutable legal prose document that states the rules
object representing a fact known by one or governing the evolution of the state over time
more Corda nodes at a specific point in time. in a way that is compatible with traditional
States can contain arbitrary data, allowing them legal systems. This document can be relied
to represent facts of any kind (eg stocks, bonds, upon in the case of legal disputes.
loans, KYC data and identity information).
Flows – Corda’s “flow framework” is a unique
Contracts – These define what constitutes a feature that enables moving of data around
valid ledger update. In Corda, contracts are the network just-in-time, on-demand and on
the mechanism used to impose constraints a point-to-point basis. These flows define a
on how states can evolve. Contracts in Corda routine for the node to run, usually to update
are quite different to the smart contracts of the ledger. They automate the process of
other distributed ledger platforms. They are agreeing ledger updates. Communication
not stateful objects representing the current between nodes only occurs in the context of
state of the world. Instead, like a real-world these flows, and is point-to-point. Built-in
contract, they simply impose rules on what flows are provided to automate common tasks.
kinds of transactions are allowed. Contracts are
⁹ See www.corda.net/blog/corda-rpc-reconnecting-client/#
Oracle service
Corda nodes communicate with each other using Corda nodes store states in a database (the
the asynchronous AMQP/TLS 1.2 protocols. vault) using JDBC.
HTTP communication is used only for the initial
registration of Corda nodes and for sharing the Integration with external systems
Corda node address locations by way of the
network map. Client applications communicate with Corda can integrate well with external world
Corda nodes using RPC calls. A node’s vault is a systems such as desktop applications, web-based
database that relies on a Java Database Connectivity applications, legacy systems and others. Each
(JDBC) connection from the Corda node. CorDapp can be accessed by invocating flows. To
invocate a flow to your node, you should be able
CorDapps are the functional aspect of Corda that to connect the RPC endpoint of the node to your
define the operations of a business network for a external system.
given use case.
Bank Bank
connectors Corda vault Corda vault connectors
(database) (database)
Other external Other external
systems systems
Corda vault
Signer service (database)
Selected
commercial
bank
Regional
commercial
bank
Corda Network Services
Austral
Global
commercial
bank
ia
Singap
Malays
Notary
Corda Oracle
Services
ore
ia
Network
map
Identity
service
Signer
S o u t h A f ri c a service
In the network design diagram above, the global commercial banks and the central bank
regional Dunbar network is a single Corda hosts a Corda node. It is important to highlight
private network (marked by the square box). The that in our model it is sufficient that each bank in
domestic sovereign networks are represented as the entire Dunbar network hosts one node. The
four logical country networks in Corda (indicated following example will explain what this means.
by the four circles, each of which represents a
country). In this representation, each country Selected commercial banks – These are local
network is a combination of selected commercial banks within their country networks and do
banks, regional commercial banks, global not have a presence in any of the other three
commercial banks and the central bank that countries in the Dunbar network. The Corda node
represents the current real-world scenario. hosted will give capabilities to operate only in
the logical network of the specific country on
In R3’s proposed model, each of the selected Dunbar.
commercial banks, regional commercial banks,
Commercial CorDapp
Corda/CENM operation
Infrastructure
Manual provisioning
On-premise
Infrastructure
provider
Clients - send and receive encrypted messages 1.2.2 R3’s CBDC Accelerator
to/from enclaves by interacting with the host R3’s CBDC Accelerator is the deliverable
over the network. in collaboration with the CBDC Working
Group, which started in September 2020 in
Host programs - load enclaves. From a security partnership with 140+ public and private sector
perspective they are fully untrusted and assumed organisations. CBDC CorDapp is built on Corda
to be malicious at all times. Hosts are relied on to Enterprise, hosted and offered by R3. R3’s aim
provide the enclave with resources but beyond with the CBDC Accelerator is to demonstrate
that work only with encrypted data. possible CBDC use cases on Corda.
Enclaves - are classes that are loaded into a Accelerator design is token-based, two-tier,
dedicated sub-JVM with a protected memory hybrid CBDC, where CBDC tokens can be
space, running inside the same operating system restricted to be issued by a central bank, as its
process as the host JVM. Code running in an liability, and distributed and transacted with a
enclave cannot be tampered with by the host vast set of intermediaries like commercial banks,
system or its owner, nor can the host system payment- or wallet service-providers catering for
or its owner see the data that the enclave is wholesale, retail and cross-border CBDCs in R3’s
processing. Enclaves communicate with clients CBDC Accelerator. R3’s cross-notary and cross-
via the host program. network interoperability have helped implement
features like delivery versus payment and payment
Figure 26: Enclave communication versus payment. The CBDC Accelerator has been
extended to support a UTXO-based decentralised
exchange enabling innovative solutions for
dynamic liquidity management and trade.
• Delivery versus payment – Allows users • Distributed interest – Allows central banks to
(commercial banks/PSPs) to exchange a real- implement positive/negative interest rates on
world asset (delivery) for digital currency their digital currency. Allows wholesale banks to
(payment). In R3’s CBDC Accelerator, bonds are loan spare liquidity for a fee (ie it is an incentive
exchanged with CBDC. mechanism).
• Payment versus payment – Allows users • Retail CBDC models – R3’s CBDC Accelerator
(commercial banks/PSPs) or central banks to extends end-to-end support for a general
exchange a currency (payment) for another purpose CBDC on a DLT framework. Features
digital currency (payment). In R3’s CBDC supported include token issuance by the central
Accelerator, one CBDC is exchanged with bank, and distribution by users (commercial
another CBDC, which can be extended to be banks/PSPs) that own and maintain retail
overlaid with workflow business rules. accounts of end-customers. Retail account
holders can initiate payments using the
• Programmable money – Allows central banks web app or mobile app using dynamic QR
and users (commercial banks/PSPs) to define code to pay at point of sale or for peer-to-
rules around assets so that they can behave or peer payments. R3’s CBDC Accelerator has
be used in a certain way. R3’s CBDC Accelerator other retail features built in such as payee
facilitates the ecosystem to explore innovative management, transaction-logging, and
use cases such as real-time direct government- business rules’ programmability.
to-citizen payments for citizens’ services such
as tax refunds, healthcare support, childcare R3’s CBDC accelerator has how-to guides for the
funding and stimulus payments. central bank and wholesale banks to learn how
to perform tasks on the user interface. The guide
• Dynamic liquidity management – Liquidity is accessed by clicking the clipboard icon in the
simply means “real time availability of liquid bottom right corner and provides step-by-step
assets or cash”. In CBDC parlance, it is the instructions for completing tasks.
Retail customer, can access their respective CBDC CBDC Accelerator Notary selection
account by logging into web portal or scanning a
QR code. In the CBDC accelerator, each central bank has
an associated notary or a selection of notaries,
Figure 47: Retail login responsible for issuance of CBDCs. These notaries
ensure there are no duplicate issuance, or any
double spend of CBDCs in the network. In
Corda, as the notary node provides the required
consensus, each CBDC is issued solely by the
central bank without any dependency on the
network.
A core component of the Corda Enterprise Transaction control – Issuers can programme
version is the Corda firewall component that transaction controls to give them authority over
enables a true Demilitarised Zone (DMZ). The how the assets they have defined are transacted.
Corda firewall, known as bridge/float component,
is designed for enterprise deployments and acts Notary selection – Notary selection lets
as an application-level firewall and protocol issuers (central banks) choose a notary (or
break on all internet-facing endpoints. The notaries) to use in transactions. The central bank
Corda firewall encapsulates the peer network designates a list of notaries that can validate a
functionality of the basic Corda Enterprise node, transaction when defining an asset. The sandbox
so that it can be operated separately from the automatically selects a notary from the list
security-sensitive Java Virtual Machine (JVM) during the first transaction with a particular asset,
run-time of the node. The firewall can also based on availability. It uses the selected notary
serve two or more nodes, thus reducing the for all transactions involving the CBDC tokens
deployment complexity of multiple nodes in associated with the initial transaction. Every
the same network. Corda is designed to prevent transaction requires at least one notary.
man-in-the-middle attacks by requiring that TLS
connections are directly terminated between By providing security at protocol and application
Corda firewalls. levels, the Corda platform safely stores and
secures end-users’ sensitive personal identifiable
Considering that cryptographic key lifecycle information (PII). Built for financial institutions,
management plays a crucial role in the Corda the Corda platform understands the criticality of
platform, the Enterprise version supports such user information involved in transactions on
integration with a variety of Hardware Security a CBDC ecosystem.
Modules (HSM). An HSM is well-trusted and
performs a variety of cryptographic operations
such as encryption and key management. An
HSM ensures that the hardware used is well
tested and has a security-focused operating
system with very limited access to the external
world. In the Corda ecosystem, operations
involving private keys, such as signature
Each node comprises several components There are two ways for users to connect to the
including an API gateway, dApp, Tessera and the platform:
Quorum platform.
1. Self-hosted node by participants.
Figure 50: A node on Quorum
2. Third-party hosted node (PaaS): An
Bank systems Partior node independent operator is set and provides
Payment node-hosting services while at the same time
system Tessera
API API dApp
maintaining the integrity of the network.
gateway gateway
Core
banking Quorum
In establishing a connection with the platform,
users are required to leverage a component
Partior node – It is a Quorem node, which known as a Distribution Application (dApp).
is a minimal fork of Go Ethereum, providing
privacy, new consensus mechanisms, network-
permissioning and higher throughput.
Quorum Public
state
Private
state
Public
state
Private
state
transaction data for private transactions, and manages the Public Private Public Private
state state state state
local data store and communication with other transaction
managers.
Enclave – responsible for private key management and for
the encryption and decryption of private transaction data.
1.3.1.3 Project Dunbar Partior network by initiating a transaction with its sponsor bank,
On the Project Dunbar Partior network, each host after which the transaction flows on to the multi-
is in control of its own “mini” network, which is CBDC platform. The following examples illustrate
depicted by the individual circles in the diagram (1) a domestic transfer and (2) cross-border FX
below. A domestic bank that is not a host may settlement.
engage in transactions on the Dunbar platform
SGD CBDC
Bank
A
AUD CBDC
Bank SGD
C CBDC Issuer Bank
... E
AUD
Bank ...
A
Bank
ZAR CBDC B CBDC Issuer
Onb
ar Bank
ds Bank D
o
Pro v
Bank B
J Bank
MYR CBDC
ZAR
id es a p pro
... H
CBDC Issuer a
Bank
Payment
va
MYR
Bank
l
C Smart Contract
... TXN ID:001
Bank
I CBDC Issuer
Std Conditions..
1. Bank A, a licensed bank in AU, is appointed by Bank B 2. As Bank B performs the domestic AUD CBDC transfer
as its sponsoring bank in the AUD CBDC. to Bank D, Bank A, which is the sponsor bank for
Bank B in the AUD CBDC network, will be required to
provide its approval for the transaction.
SGD CBDC
PvP for the cross-CBDC
4 transfer completed
Bank
B
AUD CBDC
Bank SGD
C CBDC Issuer Bank
... E
AUD
Bank ...
2 B
Bank Payment
ZAR CBDC A SGD Smart Contract
TXN ID:002
CBDC Issuer
Bank
AUD D
Bank
Std Conditions 1.. Bank
J A
Bank
ZAR
PVP Condition 1..
... H 3
Bank Payment
CBDC Issuer F Smart Contract
TXN ID:002
MYR
Std Conditions 1..
Bank
Bank G PVP Condition 1..
I CBDC Issuer
Bank REG Condition 2..
C
...
MYR CBDC
1. Bank A has arranged for Bank B to perform the 3. Bank B AU will transfer AUD CBDC to Bank A’s
cross-CBDC PvP settlement (payment-versus- AUD wallet with the same transaction reference.
payment). The transfer will be effected once all pre-validation
2. Bank A will transfer SGD CBDC to Bank B SG. The conditions are fulfilled.
transfer will be effected once all pre-validation 4. Once both SGD and AUD CBDCs transfers are
conditions are fulfilled. completed, PvP is effected and the cross-CBDC
transfer is completed.
Considerations for deciding the number of nodes 1. Network of four nodes – Network operator,
and who should host them for a live platform settlement bank, ABC bank (participant bank),
include performance, efficiency and cost of XYZ bank (participant bank) node.
investment. As the number of nodes increases,
the resiliency of the platform against fraud or 2. ABC bank and XYZ bank have a digital balance
illegal activities increases by strengthening the account with the settlement bank (AC2 and
ledger. AC3 respectively).
Generally, it is acknowledged that, from a 3. Settlement bank has its own digital balance
feasibility perspective, central banks and account AC1 on the network.
selected commercial banks would be in the most
appropriate position to be hosting nodes.
• All contracts are deployed, and accounts • ABC initiates coin balance transfer to XYZ
created with “privateFor”¹⁰ for all nodes. bank via settlement bank.
• All nodes have the visibility of the account • The transaction is marked “privateFor” for all
numbers, and balances of all accounts are three nodes.
zero.
Figure 56: Transfer
Figure 54: Network instantiation
Node AC1 AC2 AC3
Node AC1 AC2 AC3 Settlement bank 0 1800 3200
Settlement bank 0 0 0 ABC 0 1800 200
ABC 0 0 0 XYZ 0 -200 3200
XYZ 0 0 0 Network operator 0 0 0
Network operator 0 0 0
Note:
• Settlement bank is able to see the true balance
Scenario 2: Deposit of both ABC and XYZ.
• ABC and XYZ can see the true self balance.
• Each bank initiates a balance deposit. • ABC and XYZ can only see their relative position
with respect to each other and cannot see the
• Transaction is marked “privateFor” for true balance of each other.
initiating bank and settlement bank (eg
(settlement bank, ABC). Scenario 4: Withdraw
Node AC1 AC2 AC3 • The transaction is marked “privateFor” for all
Settlement bank 0 2000 3000 settlement bank and XYZ nodes only.
ABC 0 2000 0
Figure 57: Withdraw
XYZ 0 0 3000
Network operator 0 0 0 Node AC1 AC2 AC3
Settlement bank 0 1800 2700
Note:
ABC 0 1800 200
• ABC balances are visible to settlement bank
node and ABC node but not to XYZ node. XYZ 0 -200 2700
¹⁰ "privateFor” is a feature which allows for making a transaction decryptable only to a selected few parties (private transactions).
https://consensys.net/docs/goquorum/en/stable/concepts/privacy/private-and-public/#private-transactions
Functions:
CBDC issuer
Central bank
1. Create CBDC issuer & commercial bank account
Central Bank 2. Mint / Burn CBDC
3. Transfer CBDC to commercial bank account
Functions:
Functions:
Tier 2 Non-resident Non-resident Non-resident Non-resident 1. Transfers: commercial bank, non-resident bank
bank bank bank bank 2. Fund/withdraw corporate account
3. Transaction listing
CBDC issuer – Central bank: Ability to create 1.3.3 Partior Security Controls
CBDC issuer and commercial bank account, mint/
burn CBDC, and transfer CBDC to commercial 1.3.3.1 Multi-network CBDC
bank account. governance model on the Dunbar
platform in Quorum
Tier 1 – Commercial bank: Ability to create non- Membership admission criteria are common and
resident bank account, transaction listing, and can be applied universally across the platform. All
make transfers to CBDC issuer, commercial bank participants (nodes or banks) will be subject to a
and non-resident bank. universal set of security policies.
Encryted Encryted
payload Ack/Nack payload
No
42 HeP� HeP� 42 HeP� data
Participant A
Tessera node A
Quorum
1 node A 2 3 10
Dist. app Transaction
Public
store
Private
store manager Enclave
6 4 11
Block 1
LEGEND
Tessera REST Protocol
Txn AB 8 12
Ethereum P2P
Participant B
9 Tessera node B 1 Private Txn AB
2 TxnPayload
Quorum 10
node B Transaction
3 En/Decryption Request
Public Private manager Enclave 4 Txn Response
store store
11 5 TxnPayloadStore (HTTPS)
Block 1 6 Txn AB Hash
8 7 Private Txn AB (Hash)
Txn AB 12
Ethereum P2P
7 9 TxnPayloadRequest
10 En/Decryption Request
Participant C
9 Tessera node C 11 Txn Response
(Not party to Txn AB)
Quorum 12 TxnPayloadResponse
node C Transaction
Public Private manager Enclave
store store
Block 1
Txn AB 8 12
¹¹ https://github.com/ConsenSys/quorum-examples/blob/master/examples/7nodes/istanbul-genesis.json
¹² https://github.com/ethereum/EIPs/issues/650
Geth modifications