Jasper – Ubin Design Paper

Enabling Cross-Border High Value

Transfer Using Distributed Ledger
Technologies

Powered by:
2 | JASPER – UBIN DESIGN PAPER
CONTENTS

01 | Introduction........................................................................................................................................................ 8
1.1 What is cross-border payment?......................................................................................... 10
1.2 What are settlement systems?........................................................................................... 10

02 | Design Options for Cross-Border Settlement Systems.......................... 11

2.1 Use of intermediaries................................................................................................................................................... 11
2.2 Widened access to central bank liabilities.................................................................................................... 12

03 | Proposed Technical Approach for Cross-Border Payments............. 14

3.1 Enabling atomicity of transactions with Hashed Time-Locked Contracts................................. 14
3.2 Proposed technical designs................................................................................................................................... 16

04 | Technical Proof of Concept.......................................................................................................... 26

4.1 Set-up for the proof of concept............................................................................................................................ 24
4.2 Singapore network design...................................................................................................................................... 29
4.3 Canada network design............................................................................................................................................ 32

05 | Discussion............................................................................................................................................................ 34
5.1 DLT platfom support for Hashed Time-Locked Contracts (HTLC).................................................. 34
5.2 HTLC across multiple networks........................................................................................................................... 35
5.3 Advantages and limitations of HTLC................................................................................................................ 35
5.4 HTLC alternatives.......................................................................................................................................................... 36
5.5 Network scalability...................................................................................................................................................... 36

06 | Glossary.................................................................................................................................................................. 39

07 | Appendix................................................................................................................................................................ 40
7.1 Quorum Framework...................................................................................................................................................... 40
7.1.1 Quorum node................................................................................................................................................................. 40
7.1.2 Constellation and Tessera..................................................................................................................................... 41
7.2 Corda Framework.......................................................................................................................................................... 41

JASPER – UBIN DESIGN PAPER |3

FOREWORD

The Bank of Canada (BOC) and the cross-border payments today. DLT could
Monetary Authority of Singapore (MAS) offer an easier and faster path towards
are pleased to present the report “Jasper- adoption than a centralized approach
Ubin Design Paper: Enabling Cross-Border because it can leave the different
High Value Transfer Using Distributed jurisdictions involved in control of their
Ledger Technologies”. portion of the network while allowing
for tight integration with the rest of
In 2016, BOC and MAS embarked the network.
on Project Jasper and Project Ubin,
respectively, to explore the use of The Jasper-Ubin project is experimental
Distributed Ledger Technology (DLT) for in nature, and whether we will eventually
the clearing and settlement of payments use blockchain technology for high-
and securities. This report describes how value cross-border payments remains
the Jasper and Ubin prototype networks, to be seen. Technology exploration and
developed on different blockchain experimentation will continue because
platforms, were able to interoperate, we see potential in this technology.
allowing for cross-border payments to be More importantly, cross-jurisdictional
settled on central bank digital currencies, collaborations must continue, as the
which in turn enables greater efficiencies development of common shared
and reduces risks. understanding will benefit the global
ecosystem regardless of the technology
The collaboration between the two that we eventually choose to use.
central banks has successfully proven the
ability for settlement of tokenized digital We would like to express our appreciation
currencies across different blockchain to JP Morgan and Accenture for their
platforms. In combination with earlier contribution to this pioneering work
work on Delivery versus Payment (DvP) and endeavor.
settlement, we are forging a path forward
for blockchain platform interoperability We encourage central banks,
in a future world of heterogeneous regulators, financial institutions and
distributed ledger platforms. technology companies to read about
the achievements and learnings from
A fragmented world, with differing the Jasper-Ubin project, and join our
standards, processes, norms, and efforts in making cross-border payments
regulations is the key challenge in cheaper, faster, and safer.

Scott Hendry Sopnendu Mohanty

Senior Special Director, Chief FinTech Officer,
Financial Technology, Bank of Canada Monetary Authority of Singapore

4 | JASPER – UBIN DESIGN PAPER

JASPER – UBIN DESIGN PAPER |5
EXECUTIVE
SUMMARY

The Jasper-Ubin project sets Cross-border payments generally involve a

set of actions (updates to multiple separate
out to determine whether, with
systems) that are not tightly synchronized,
recent technological innovations, creating the possibility that one action will
it is possible to make safe cross- succeed and another fail. This leaves the
border payments and realize payment inconsistent, which essentially
creates a risk that one party will gain at
other benefits in a future world
another's expense. This specific risk may
of heterogeneous distributed be eliminated by ensuring all actions
ledger platforms. succeed or the transaction, in its entirety,
is cancelled. One way to accomplish this
This work undertakes a line of enquiry is to employ a third party acting as escrow
emanating from the paper “Cross-Border to the transacting parties; this third party
Interbank Payments and Settlements,”1 will ensure commitment of the whole
authored by the Bank of Canada, the Bank transaction. Another way is to provide a
of England, the Monetary Authority of technology-based means of ensuring this
Singapore, HSBC and a group of other commitment without a trusted third party.
commercial banks in the United Kingdom,
Canada and Singapore. That paper The Monetary Authority of Singapore
highlights a host of issues in current (MAS) and the Bank of Canada (BOC),
cross-border payment arrangements: lack together with JP Morgan and Accenture,
of transparency of payment status, limited embarked on the Jasper-Ubin Project, a
service availability, processing time, costs technology-based experiment to realize
and operational risks. It proposes a small this all-or-nothing guarantee through an
set of models that alleviate these issues. atomic transaction for a Canadian Dollar
(CAD) - Singapore Dollar (SGD) payment
Specifically, two models in that report across two distributed ledger technology
describe a tokenized form of a wholesale (DLT) platforms based on Hash Time-
central bank digital currency (W-CBDC) Locked Contracts (HTLC).
issued on blockchains by the central bank
HTLC uses smart contracts2 to
for use by commercial banks. We explore
synchronize all the actions making up a
the architecture that supports these
transaction so that either they all happen,
models by building a proof of concept
or none happens.
to understand some of the technical
challenges in implementing these models. Furthermore, the Jasper-Ubin project
assumes DLT-based domestic gross
settlement (RTGS) systems sit on different
platforms in each country—in this case,
on Corda3 in Canada and Quorum4
in Singapore.

6 | JASPER – UBIN DESIGN PAPER

The team successfully demonstrated Our work does not constitute an entire
a cross-border, cross-currency, cross- solution for cross-border payments.
platform atomic transaction without the There are open questions to be pursued:
need for a third party that is trusted by How would such a system behaves
both jurisdictions. In our tests, no other at scale? What are the complications
action would proceed if any action fails, that will arise with a large number of
thus ensuring the end to end consistency jurisdictions? How should such a system
of a transaction. In the correspondent be governed, for example in updates
banking method of payment, the sender to the protocol? Are there regulatory
and receiver trust the correspondent or legal aspects to be considered? Can
bank. In this DLT-based system using HLTC be used to integrate with non-DLT
HTLC, trust will still be required, albeit based Real Time Gross Settlement (RTGS)
in the technical system rather than in systems? What problems, highlighted in
a third party. the “Cross-Border Interbank Payments
and Settlements” paper, are also solved
HTLC is a reliable way of passing using this method (e.g. transparency)?
messages between the two systems.
Distributed ledger platforms must also
support the basic constructs of HTLC:
locking or encumbering the asset
to be transferred, secret disclosure
to the counterparty to complete the
acceptance process, and a timeout
mechanism to release the encumbrance
should the counterparty fail in its
acceptance process.

JASPER – UBIN DESIGN PAPER |7

INTRODUCTION

In 2016, BOC and MAS embarked

01
trusted central party across jurisdictions.
In cross-border payments, central banks
on Project Jasper and Project Ubin,
act as the trusted central party within
respectively, to explore the use of their jurisdictions, however, there is no
distributed ledger technology (DLT) single organisation that can act as the
for the clearing and settlement of trusted central party across the global
payments network.
payments and securities.
This technical study is a collaboration
Both projects unilaterally aimed to between BOC and MAS that uses the
develop more resilient, efficient and learnings from Project Jasper and
lower-cost alternatives to today’s financial Project Ubin to test the hypothesis
systems based on central bank–issued that DLT will enable greater efficiencies
digital currencies. and reduce risks arising from errors in
coordinating processes across institutions
Both projects successfully developed DLT-
in crossborder transactions. The project
based prototypes for domestic interbank
builds on earlier work previously
payments, and subsequent experiments
undertaken by the Bank of Canada, the
have also explored and successfully tested
Monetary Authority of Singapore, the Bank
the viability of simultaneous exchange
of England, HSBC and a group of other
and final settlement of tokenized digital
commercial banks in the United Kingdom,
currencies and securities assets. While
Canada and Singapore to analyze the
these experiments have proven the viability
various business operating models for
of the technology, there are limited,
enabling more efficient crossborder
incremental benefits of DLT in a domestic
high-value payments. Among the five
context where there is a trusted central
possible models developed in that earlier
party and where centralized systems
work,1 this project focuses on Model 3a
perform efficiently. (a W-CBDC that cannot be transmitted
beyond its home jurisdiction), Model
With an intuition that DLT has merits,
3b (a W-CBDC that can be transmitted
we opted to investigate cross-border
beyond its home jurisdiction), and variants
payments with multiple parties transacting
of Model 3b, which are characterized by
across different DLT networks in different
the linking up of different cash settlement
jurisdictions, with no single trusted entity.
networks, assumed to be built on different
DLT is hypothesized to be suitable for
distributed ledger platform technologies.
this use case because (a) traceability of
ownership throughout the transaction
across different networks is crucial;
and (b) there is currently no single

8 | JASPER – UBIN DESIGN PAPER

The Jasper-Ubin technical project,
supported by Accenture and JP Morgan,
began with a design and analysis of the
different possible models of connectivity
between the two DLT networks—Quorum4
and Corda3. Workshops were conducted
with the Project Ubin consortium to discuss
their design considerations and understand
the implications of each model across
technology, business and operations, and
legal and regulatory policies. The team also
successfully built a cross-border (Canada and
Singapore), cross-currency (CAD and SGD),
cross-platform (Corda and Quorum) system
for atomic transactions based on HTLC.

This report captures the design

considerations and discusses the technical
aspects of implementing DLT for cross-border,
cross-currency, cross-platform high-value
payments. This report outlines the high-level
architecture and technical design options
and examines the use of Hashed Time-
Locked Contracts (HTLC) to enable atomic
transactions across DLT networks.

JASPER – UBIN DESIGN PAPER |9

1.1 WHAT IS CROSS-BORDER the sender, there would be a transfer
PAYMENT? of LCY from sender to intermediary,
and a transfer of FCY from intermediary
A cross-border payment transaction is one to recipient.
where an entity wishes to send a payment
Figure 1
to a recipient in a different jurisdiction.
Typically, the sender and end receiver Domestic Network Foreign Network
do not have access to the same ledger;
LCY
hence, transactions between them take 1a
place through a series of linked transfers 1b
Bank 1 Bank A Bank 2
on different ledgers. A common example FCY
is where multiple correspondent banks FCY
are used in a series of intermediary 2

transactions to reach the receiver.

Cross-border payments often involve 1.2 WHAT ARE

foreign exchange (FX) since the sender SETTLEMENT SYSTEMS?
holds local currency (LCY), while the
receiver would like to receive funds in On the most fundamental level, electronic
their local currency, which is labelled as settlement systems are accounting ledgers
foreign currency (FCY) from the sender’s where the ownership of assets is recorded,
perspective. The methods of obtaining and settlement is the process of updating
FCY vary (e.g., the sender may already have the record of ownership of the assets being
FCY from previous transactions). Therefore, transferred. Payment, or a transfer of
the FX funding aspect is distinct from the funds from sender to receiver, is “settled”
payment itself. For our experiment we have by updating the ledger, decreasing
incorporated the FX funding aspect as part the sender’s balances and increasing
of the overall process. the receiver’s balances, whereby any
obligations for that payment between
In such a scenario, the transaction can be the sender and receiver are diminished.
considered as two separate logical steps:
As such, direct transfers can only
• Step 1 is an FX trade of LCY for FCY take place between parties with
• Step 2 is a transfer of the FCY to assets maintained on the same ledger.
the receiver. An example of ledger transfers is
domestic interbank settlement systems,
• Step 1 of an LCY-FCY exchange can be
where participating institutions transact
further broken down into 1a, a transfer
with each other on the central bank’s
of LCY from the sender to the FX trade
ledgers. This is referred to as transacting
counterparty, and 1b, a transfer of
on central bank liabilities, as the balances
FCY from the FX trade counterparty
maintained with the central bank represent
to the sender.
“deposits” that are repayable on demand.
These steps form the building blocks of These balances are recorded as liabilities
a cross-border payment transaction and from the central bank’s perspective. It is
can be performed in different orders. In also possible for parties to transact on a
the example above, if an intermediary or private institution’s ledger by maintaining
correspondent bank performs the FX for accounts and assets with it.

10 | JASPER – UBIN DESIGN PAPER

DESIGN OPTIONS
FOR CROSS-BORDER
SETTLEMENT
02
SYSTEMS

The Jasper–Ubin project builds upon 2.1 USE OF

prior technical study conducted INTERMEDIARIES
by BOC and MAS. Its focus is on
operating model underpinned by the The use of intermediaries in the traditional
interoperability of different DLT-based correspondent banking model results
cash settlement networks, specifically in credit default risk (the risk that a party
from Project Jasper and Project Ubin. is unable to deliver the currency it sold)
Although this is a technical study and and settlement risk (the risk that a party
not a policy research, this section outlines delivers currency it sold without receiving
the business context for this project. currency it bought) for the transacting
parties. One way of eliminating such risks
The models in Project Jasper and Project is by removing the need to hold funds
Ubin are limited by one particular design with the intermediary.
constraint: parties can transact directly
only with other parties that are on the Figure 2: Cross-network communication
same ledger. In crossborder payments,
where there are many transacting parties Domestic Network Foreign Network
who do not exist on the same ledger,
these parties would be able to transact
electronically with each other only by
Bank 1 Bank 2
either (a) using intermediaries, or; (b)
granting direct access to a central bank’s 1 LCY 3 FCY
liabilities. Jasper-Ubin referred to these
two broad design options.

IntA(L) InA(F)

2
Cross-network communication,
FX Conversion

JASPER – UBIN DESIGN PAPER | 11

Using the same scenario described In the above example, there are two
earlier, a sender will transfer LCY to linked transactions, but there could
an intermediary on the LCY network, be scenarios where atomicity must be
and the intermediary will transfer FCY ensured across multiple linked transfers.
to the receiver on the FCY network.
The intermediary facilitates the completion Adopting this intermediaries model
of the transaction without requiring minimizes credit risk and settlement risk;
transacting parties to hold funds in addition, as it is largely similar to the
with it. This differs from the traditional current correspondent banking model, it
correspondent banking model where will be able to rely on existing regulations
funds are held with the correspondent and processes.
bank, which reduces credit risk exposure
Requiring the intermediaries to exist
to the correspondent bank (or indeed vice
on both the LCY and FCY networks
versa where the sender receives credit
significantly reduces the number of
from the correspondent for the payment).
financial institutions that can play the
Settlement risk can also be eliminated intermediary role. Based on an analysis
by ensuring the atomicity of the related of the 64 financial institutions that
or linked transfers. Atomicity refers participate directly in Singapore’s MAS
to the completion of all transfers Electronic Payment System (MEPS+)
comprising the transaction where they and the 17 that participate in Canada’s
either succeed together or fail together. Large Value Transfer System (LVTS), only
In the case of failure, the other linked five global financial institutions have a
transfers would automatically fail as well, presence in both MEPS+ and LVTS.
reverting the funds back to the sender.

Figure 3: Number of direct RTGS participants in Singapore and Canada

RTGS participants of the same

international financial institution group

Singapore RTGS Canada RTGS

Participants Participants

59 5 12

12 | JASPER – UBIN DESIGN PAPER

In the ideal case, the intermediary would There are open questions ranging
be a global financial institution with a from regulatory and legal challenges,
presence in both networks and thus to economic and monetary policy issues,
bears no credit risk. Nonetheless, the to commercial costs and benefits for banks.
intermediary could be a pair of separate
financial institutions that are willing to At the same time, research into this area
bear the credit risk with respect to each has been limited because there have not
other. In this case, there is still no credit been viable technical models that could
risk for the transacting parties, but the enable a central bank’s liabilities to be
intermediary bank would assume the easily transacted beyond a limited group
credit risk of its counterparty intermediary of regulated financial institutions. This
bank. This could also increase the number report aims to develop technical models
of intermediaries that could facilitate and posit their technical viability and,
cross-border transactions. in doing so, create interest and research
opportunities from the other perspectives.

2.2 WIDENED ACCESS

TO CENTRAL BANK
LIABILITIES
The alternative to using intermediaries
is to grant transacting parties direct
access to central banks’ liabilities.
However, widening access to central
banks’ liabilities to non-regulated or
foreign financial institutions raises a
number of considerations and challenges.

JASPER – UBIN DESIGN PAPER | 13

PROPOSED
TECHNICAL
APPROACH FOR
03
CROSS-BORDER
PAYMENTS
3.1 ENABLING ATOMICITY Two-phase commit could work in the
OF TRANSACTIONS WITH systems through the use of intermediary
HASHED TIME-LOCKED escrow accounts, which act similarly
CONTRACTS to the temporary storage. As an example,
the FX exchange of LCY for FCY requires
Since cross-border payments usually two separate transactions: (a) transfer
consist of a series of linked transfers, of LCY from buyer to seller, and (b)
ensuring the atomicity of these transactions transfer of FCY from seller to buyer.
could minimize settlement risk. HTLC offers If an intermediate escrow is used, a buyer
a possible technical solution to ensuring the would first transfer the LCY to escrow
atomicity of transactions across multiple and a seller would transfer the FCY to
DLT-based systems. In most computer escrow. Once the escrow has ascertained
systems, including databases, atomicity that both legs of the transaction have
is guaranteed through the concept of been performed, it would complete the
“two-phase commit.” A two-phase commit transaction by sending the LCY to the
is a protocol that coordinates two or more seller, and the FCY to the buyer. If one
processes that participate in a transaction leg of the transaction fails, such as the
to decide to commit or abort (roll back) seller failing to transfer the FCY to escrow,
all the processes of the transaction. the escrow can roll back the transaction
The two-phase commit is typically by refunding the LCY to the buyer.
implemented as follows:
Achieving atomicity of transactions on
Phase 1—Each participant in a transaction conventional systems is not new. An
writes its data records to a temporary entity such as an exchange can act as the
storage and indicates to the coordinator trusted party by operating an account
whether the process is successful. and allowing for delivery-versus-payment
settlement only after both legs of a
Phase 2—Upon confirmation that all transaction have come in and temporary
processes are successful, the coordinator ownership of both cash and securities
sends a signal to all participants to are assigned to the exchange. However,
commit¸ which is to update the records the problem becomes more complex when
from the temporary storage into the there is no single trusted party, as is the
actual storage. If any participant fails, case with cross-border payments. This is
the coordinator sends an instruction to where HTLC comes into the picture.
all participants to abort and roll back.

14 | JASPER – UBIN DESIGN PAPER

The HTLC design has been used in to manage both parts of the transaction.
public blockchains to allow for asset swaps The recipient will generate a secret (denoted
to take place across different blockchain by S), and this will be converted into an
networks. While similar in concept to a encrypted output of a fixed length known
two-phase commit, HTLC has no need for a as a hash (denoted by H(S)) to be included
trusted third party. Rather, the intermediate in the transaction. The recipient will need
escrow account is operated autonomously to verify the H(S) of a transaction from the
as a smart contract with predefined rules. sender within a predefined time frame, T;
otherwise, the transaction will be voided.
In the context of cross-border payments,
where the transaction consists of two parts,
one in a home country and one in a foreign
country, the HTLC protocol may be used

Figure 4: Hashed Time-Locked Contracts, two-party explanation

1. Alice opens a payment channel to Bob. 2

2. Alice wants to buy something from Bob for $1,000.
3
3. Bob generates a random number and generates
its SHA256 hash. Bob gives that hash to Alice. H(x)
A B
4. Alice uses her payment channel to pay $1,000, 4
but she adds the hash Bob gave her to the T(a, h(x), t, c1)
payment along with an extra condition: in order for
Bob to claim the payment, he has to provide the 5
data that was used to produce that hash. T(x)
5. Bob has the original data that was used to produce
the hash (called a pre-image), so Bob can use it to On-ledger a Amount
finalize his payment and fully receive the payment
Off-ledger t Time constraint
from Alice. By doing so, Bob necessarily makes
the pre-image available to Alice. H(x) Hash function of “x” cn Currency
T( ) Transaction u Time taken to generate
second transaction

Figure 5: Hashed-Time-Locked Contracts, multi-party explanation

1. Alice opens a payment channel to Charlie, and 2

Charlie opens a payment channel to Bob.
2. Alice wants to buy something from Bob for $1,000. A B A
3. Bob generates a random number and generates 3
its SHA256 hash. Bob gives that hash to Alice. H(x)
4. Alice uses her payment channel to Charlie to pay him
$1,000, but she adds the hash Bob gave her to the 4 5
payment along with an extra condition: in order for T(a, h(x), t, c1) T(a, h(x), t, c2)
Charlie to claim the payment, he has to provide the
data that was used to produce that hash.
5. Charlie uses his payment channel to Bob to 7 6
pay Bob $1,000 and Charlie adds a copy of the T(x) T(x)
same condition that Alice put on the payment
she gave Charlie.
B
6. Bob has the original data that was used to produce
the hash (called a pre-image), so Bob can use it to
finalize his payment from Charlie. By doing so, Bob On-ledger a Amount
necessarily makes the pre-image available to Charlie. Off-ledger t Time constraint
7. Charlie uses the pre-image to finalize his payment H(x) Hash function of “x” cn Currency
from Alice. T( ) Transaction u Time taken to generate
second transaction

JASPER – UBIN DESIGN PAPER | 15

The execution of HTLC for each Access to the central bank’s liabilities
cross-border-payment approach can be achieved through two different
will be illustrated in detail in the designs. The first design achieves direct
following sections. access by granting transacting parties
direct access to accounts or wallets on
3.2 PROPOSED the network, i.e., allowing a financial
TECHNICAL DESIGNS institution to hold FCY issued by the
central bank even if it is not a financial
Here we propose three broad institution in that particular jurisdiction.
conceptual design options for cross- The second design allows LCY to flow
border payments where a sender and into foreign currency networks where
a receiver are transacting on different it can be transacted directly. This can
ledgers with different currencies. The also be viewed as a multi-currency
first option involves using intermediaries, settlement system.
and the second and third involve granting
transacting parties access to the central Figure 6 illustrates the three broad
bank’s liabilities. technical designs and Table 1
summarizes their characteristics.

Figure 6: Cross-border transaction approaches

Cross-Border Payments

1. Intermediaries 2. Widened Access to a 3. Multiple Currency

Approach network (Direct Access) support within a network
(Direct Access)

Table 1: Cross-border payments summary

Intermediaries Approach Direct widened access Direct multiple-currencies

• also known as asset • also known as direct • also known as asset transfer
swap via intermediary access • allows for multiple currencies
• needs intermediary for • does not involve an within the same network
foreign exchange and intermediary • still need intermediary
transfer (which could be the central
banks) for transfer

16 | JASPER – UBIN DESIGN PAPER

3.2.1. INTERMEDIARIES In this example, Int A(L) and Int A(F)
APPROACH belong to the same international financial
group, acting as intermediaries to
Conceptually, this method achieves complete the cross-border transfer.
cross-border payments by employing an For this scenario we assume the
intermediary to facilitate the settlement. exchange rate is 1.05 LCY to 1 FCY.
The intermediary is a third party to the
payment, acting as a middleman; the 1. Bank 1 needs to make a payment of
intermediary, typically a bank, would 100 FCY to Bank 2. Bank 1 will pledge
have access to both home and foreign 105 LCY to Int A(L).
networks. Having access to both networks 2. Int A(L) converts the 105 LCY to 100 FCY
enables the intermediary to receive using its entity in the foreign network,
money from the sender in LCY in its Int A(F). Bank 1 will be charged
domestic network, and to send money to a transaction fee for this process.
the receiver in FCY in the foreign network.
3. Int A(F) transfers the 100 FCY
Because the intermediary facilitates to Bank 2 to complete the transaction.
the payments process, the sender would
not need direct access to the foreign
network, and, similarly, the receiver
would not need direct access to the
domestic network of the sender.

The FX conversion and transfer can be

provided by the intermediary because
each network can operate only its own
currency. Therefore, the process of
funding is integrated into the transfer
process. Figure 7 illustrates this approach.

Figure 7: FX conversion and transfer via intermediary

Domestic Network Foreign Network

Position: LCY 500 Position: FCY 500

Transfer 1: (-) LCY 105 Transfer 3: (+) FCY 100
Balance: LCY 395 Balance: FCY 600
Bank 1 Bank 2

1 LCY 3 FCY

Position: LCY 500 Position: FCY 500

Transfer 1: (+) LCY 105 Transfer 2: (+) FCY 100
Transfer 2 (-) LCY 105 Transfer 3: (-) FCY 100
Balance: LCY 500 Balance: FCY 500
IntA(L) IntA(F)

2
Cross-network communication,
FX Conversion

JASPER – UBIN DESIGN PAPER | 17

HTLC sequence flow
Smart contracts are self-executing computer
programs that perform predefined tasks
An HTLC contract consists of two parts:
based on a predefined set of criteria or
hash verification and time expiration conditions. Smart contracts cannot be
verification. A secret, denoted as S, will altered once deployed, which ensures the
faithful completion of contractual terms.
be created first, and then its hash
will be generated, denoted as H(S). H(S) The implementation of smart contracts varies
with the platform in use:
and S are key information used to ensure
the atomicity of the linked transactions In a Quorum smart contract, an asset
or currency is transferred into a program.
across the two blockchain networks. The program runs the code and at the same
time validates a condition. It automatically
The sequence diagram below provides determines whether the asset should go
a generalized illustration of how HTLC to a person or be refunded to the sender.

is executed for an asset swap via an In a Corda contract, the executable

intermediary. Note that HTLC may be code validates changes to state objects
in transactions. The state objects are
implemented differently on different DLT data held on the ledger that contains
platforms, depending on the capabilities the information such as sender, receiver
and the amount to be paid.
and limitations of each platform.

Figure 8: HTLC flow for swap via intermediary

Domestic Foreign
Sender Intermediary Intermediary Receiver
Network (LCY) Network (FCY)

1 Initiate fund transfer ( $X )

Respond with H(S) 1a

2 Put funds into escrow ( B, $X, H(S) )
Generate secret S
Return with T & hash H(S)

3 Inform FI(c) of transaction ( H(S) )

4 Get transfer details ( H(S) )

5 Send information
B, $X, H(S), T 6 Put funds with End Time
Return with B,
into escrow ( B, $X, H(S), T )
$X, H(S), T

Ack
7 Inform FI(B) that transaction
Ack H(S) added to escrow

8 Redeem funds
from escrow (S)

Return with secret S

10 Redeem funds 9 Pass secret S
from escrow (S) Ack

Ack
Ack

Off-Chain

18 | JASPER – UBIN DESIGN PAPER

1. The sender from the domestic network parameter may be different but
initiates a payment transfer request should equal the same value that
and requests an H(S) from the receiver is received from the intermediary.
in the foreign network. The receiver
The intermediary in the foreign
generates an H(S) and a secret
network then adds funds to an
for the transaction and acknowledges
escrow account and locks it. As soon
the sender with an H(S).
as funds are added to the escrow
2. The sender creates a smart contract in account, an acknowledgment (Ack)
the domestic network with the details is sent to the entire network.
below and puts funds in escrow.
7. The intermediary informs the receiver
a. B = Receiver that the funds have been added to the
escrow. The intermediary sends the
b. $X = Amount to be sent to receiver
hash of the secret to the receiver.
c. H(S) =Hash tied to the transaction
8. The receiver uses the hash to retrieve
The domestic network sets the the correct secret from its repository.
time lock window, e.g., one hour or The receiver uses the secret to unlock
two hours for this transaction to be the transaction and redeems funds
completed, otherwise this transaction from the smart contract account.
expires and be rolled back. Also, the receiver gives secret S to the
3. The sender informs the intermediary intermediary in the foreign network.
in the domestic network about the 9. The intermediary in the foreign
transaction and sends the hash of the network sends the secret S to
secret, H(S), to that intermediary. the intermediary in the domestic
4. The intermediary requests the smart network. This is a cross-network
contract on the transaction details communication. It is important to
and presents the hash in order to be maintain a secure and reliable cross-
authenticated as the valid party. network communication channel so
as to ensure that the intermediary in
5. The intermediary in the domestic
the home network is able to claim the
network sends the details on
funds (as described in Step 10 below)
the receiver, amount and H(S) to
before the time period ends.
the intermediary in the foreign
network. This is a cross-network 10. The intermediary in the home
communication. network presents the secret
to the smart contract. The smart
6. The intermediary in the foreign
contract hashes the secret and
network also creates a smart contract
compares it with the original hash.
in the foreign network based on the
If they are same, the smart contract
details received from the intermediary
allows the intermediary to unlock
in the domestic network, i.e., receiver,
the account and claim the funds.
amount, H(S) and time window.
This time lock window for this smart
contract will be half (T/2) of the
overall transaction (as per Step 2
in this sequence). Here, the amount

JASPER – UBIN DESIGN PAPER | 19

3.2.2 WIDENED ACCESS Funding wallet in foreign network:
TO A NETWORK Figure 9 illustrates Bank 1 funding
its FCY wallet via another market
In this approach, a bank would have
participant, Bank 2.
access to both home and foreign networks
and hold funds in each of these networks.
Figure 9: Asset Swap via market participant
This means that a sender bank would
be able to hold a wallet in the foreign Domestic Network Foreign Network
network, with FCY in that wallet, and
a receiver bank would be able to hold Position: LCY 500 Position: FCY 0
Transfer 1: (-) LCY 105 Transfer 3: (+) FCY 100
a wallet in the domestic network, with Balance: LCY 395 Balance: FCY 100
Bank 1 Bank 1
LCY in that wallet. This would represent
a change from existing policies where 1 LCY 3 FCY
only a subset of domestically regulated
financial institutions can gain direct
access to the RTGS systems and central Position: LCY 500
Transfer 1: (+) LCY 105
Position: FCY 500
Transfer 3: (-) FCY 100
bank liabilities. It would require a Balance: LCY 605 Balance: FCY 400
Bank 2 Bank 2
widening of access policies.
2
Cross-network communication

Bank 1 does not have sufficient funds in

its FCY wallet. For this scenario we assume
the exchange rate is 1.05 LCY to 1 FCY.

1. Bank 1 sends LCY to Bank 2’s

wallet in the domestic network. It is
assumed the two banks have agreed
in advance to an FX conversion
outside the system.
2. Bank 2 internally manages its LCY and
FCY wallets to increase the equivalent
amount in its FCY wallet.
3. Bank 2 then transfers FCY to Bank 1’s
FCY wallet in the foreign network.

20 | JASPER – UBIN DESIGN PAPER

HTLC sequence flow
Figure 10 illustrates how HTLC is executed for the funding process of an asset swap.
The detailed steps in this figure are similar to those in Figure 8, except that the
intermediaries are now the market participants.

Figure 10: Asset swap through market participant sequence flow

Domestic Market Market Foreign

Sender Receiver
Network (LCY) Participant Participant Network (FCY)

1 Initiate fund transfer ( $X )

Respond with H(S) 1a

2 Put funds into escrow ( B, $X, H(S) )
Generate secret S
Return with T & hash H(S)

3 Inform FI(C) of transaction ( H(S) )

4 Get transfer details ( H(S) )

5 Send information
B, $X, H(S), T 6 Put funds with End Time
Return with B,
into escrow ( B, $X, H(S), T )
$X, H(S), T

Ack
7 Inform FI(B) that transaction
Ack H(S) added to escrow

8 Redeem funds
from escrow (S)

Return with secret S

10 Redeem funds 9 Pass secret S
from escrow (S) Ack

Ack
Ack

Off-Chain

JASPER – UBIN DESIGN PAPER | 21

Transfer: Pledging:
Once Bank 1 has sufficient funds in its FCY A sender can purchase new funds
wallet, it can make direct transfers to other directly from the issuer. Figure 12
participants in the foreign network in FCY. depicts pledging, the process flow for
Figure 11 illustrates the process flow of a the initial issuance of LCY into an LCY
direct transfer from Bank 1 to a recipient wallet in the foreign network through
bank (Bank 3) in a foreign network. the central banks.

Figure 11: Direct transfer Figure 12: Initial pledging flow

Domestic Network Foreign Network Domestic Network Foreign Network

Position: FCY 100 Position: LCY 500 Position: LCY 0

Position: LCY 100 Transfer 1: (-) FCY 100 Transfer 1: (-) LCY 105 Transfer 1 (+) LCY 105
Balance: FCY 0 Balance: LCY 395 Balance: LCY 105
Bank 1 Bank 1 Bank 1 Bank 1

1 FCY 1 LCY 3 LCY

Position: FCY 500 Transfer 1: (+) LCY 105 Transfer 2: (+) LCY 105
Transfer 1: (+) FCY 100 Transfer 2: (-) LCY 105 Transfer 3: (-) LCY 105
Balance: FCY 600 Central Operator 1 Central Operator 2
Bank 3

2
Cross-network communication
1. With sufficient FCY after the initial
funding, Bank 1 makes a transfer of 100
1. Bank 1 pledges 105 LCY to
FCY to Bank 3 in the foreign network.
Central Operator 1 for transfer
2. Bank 3 successfully receives the FCY, to the foreign network.
and the payment flow is complete.
2. Central Operator 1 then informs
Central Operator 2 that there
3.2.3 MULTIPLE CURRENCY is a request to transfer 105 LCY
SUPPORT WITHIN to Bank 1 in the foreign network.
A NETWORK
3. Central Operator 2 sends the 105 LCY
In the previous approach, money is sent to Bank 1 in the foreign network,
from the sender in the domestic network while Central Operator 1 redeems
in LCY to the receiver in the foreign the 105 LCY on the domestic network.
network in FCY. The FX conversion and
transfer are managed by the intermediary Once multiple participants have
because each network can operate repeated this process, all of them
only in its own currency (leaving aside will have both LCY and FCY balances
alternative funding arrangements). in each network, enabling direct
transactions between them.
This model assumes multiple currencies can
be transacted in each network. For example,
the sender bank will have both LCY and FCY
wallets in its domestic network.

22 | JASPER – UBIN DESIGN PAPER

Funding: Transfer:
A sender can purchase new funds Continuing from the previous example,
directly from other participants. Once Bank 1 now has 100 FCY in its domestic
FCY is available in the domestic network, network wallet. Bank 1 can make
participants can transact with each other a payment transfer to Bank 2 in the
in FCY within their domestic network. foreign network. Figure 14 illustrates
Assume Bank 1 does not have a balance in the process flow of the payment.
its FCY wallet. In the funding process, Bank
1 exchanges LCY with other participants Figure 14: Asset transfer
in return for FCY within the domestic
network. Figure 13 illustrates this process. Domestic Network Foreign Network

Position: FCY 100 Position: FCY 500

Figure 13: Funding within home jurisdiction Transfer 1: (-) FCY 100 Transfer 3: (+) FCY 100
Balance: FCY 0 Balance: FCY 600
Bank 1 Bank 2
Domestic Network Foreign Network
Position: LCY 500
Position: FCY 0 1 FCY 3 FCY
Transfer 1: (-) LCY 105
Transfer 2: (+) FCY 100
Balance: LCY 395
Bank 1 Balance: FCY 100 Bank 2 Transfer 1: (+) FCY 100 Transfer 2: (+) FCY 100
Trabsfer 2: (-) FCY 100 Trabsfer 3: (-) FCY 100

1 2 Central Operator 1 Central Operator 2

LCY FCY
2
Position: LCY 0
Position: FCY 500 Cross-network communication
Transfer 1: (+) LCY 105
Transfer 2: (-) FCY 100
Bank 3 Balance: LCY 105 Bank 4
Balance: FCY 400 1. Bank 1 transfers 100 FCY to
Central Operator 1 for transfer
to the foreign network.
1. Bank 1 sells LCY to Bank 3.
2. Central Operator 1 then informs
2. Bank 3 transfers FCY to Bank 1.
Central Operator 2 that there
This process is possible because is a request to transfer 100 FCY
Bank 3 has sufficient funds in its FCY to Bank 2 in the foreign network.
account to complete this transaction. 3. Central Operator 2 sends the
100 FCY to Bank 2, while Central
Operator 1 redeems the 100 FCY
on the domestic network to ensure
that no extra money is created.

Funds can be transferred between

banks using the central operator as an
intermediary. Note that commercial banks
may also act as the intermediary, sending
FCY in the foreign network in exchange for
accepting FCY in the domestic network.

JASPER – UBIN DESIGN PAPER | 23

HTLC sequence flow
Figure 15 illustrates the HTLC sequence flow for transfer via central operators
with the currency identification code included in the message payload.

Figure 15: Asset transfer

Domestic Market Market Foreign

Sender Receiver
Network (LCY) Participant Participant Network (FCY)

1 Initiate fund transfer ( $X )

Respond with H(S) 1a

2 Put funds into escrow ( B, $X, H(S) )
Generate secret S
Return with T & hash H(S)

3 Inform FI(C) of transaction ( H(S) )

4 Get transfer details ( H(S) )

5 Send information
B, $X, H(S), T 6 Put funds with End Time
Return with B,
into escrow ( B, $X, H(S), T )
$X, H(S), T

Ack
7 Inform FI(B) that transaction
Ack H(S) added to escrow

8 Redeem funds
from escrow (S)

Return with secret S

10 Redeem funds 9 Pass secret S
from escrow (S) Ack

Ack
Ack

Off-Chain

24 | JASPER – UBIN DESIGN PAPER

JASPER – UBIN DESIGN PAPER | 25
TECHNICAL PROOF
OF CONCEPT 04
To verify the conceptual designs outlined In the Singapore network, local Bank
in section 3.2, we developed a simplified A and Intermediary A each uses two
proof of concept using Quorum and different Quorum nodes. In the Canada
Corda. The proof of concept covers only blockchain, Intermediary A and local
one model—the intermediary approach Bank B in Canada will use two different
(see Table 1), which is the least complex Corda nodes. Intermediary A has a
approach so as to focus on proving presence in both networks and acts as
the technical viability of transacting an intermediary. As part of this example,
atomically across two dissimilar local Bank A in Singapore will transfer
blockchain networks using HTLC for SGD$105 to local Bank B in Canada with
atomic transactions.5 the FX rate of 1 SGD to 0.95 CAD. At the
end of the transaction, local Bank B in
This technical proof of concept has Canada will receive CAD$100.
two objectives:
The set-up of the proof of concept is
• To implement HTLC contracts across
illustrated in Figure 16.
Quorum and Corda DLT platforms

• To establish secure communication In the Singapore network:

between Quorum and Corda to transfer
Initiate HTLC transaction
transaction details, including secret (with time to expiry T)
hash H(S) and secret S
1. Bank A in Singapore and Bank B in
Canada share the hash of secret H(S)
4.1 SET-UP FOR THE off chain via a secure communication
PROOF OF CONCEPT channel. Bank B generates secret S and
In this section we illustrate the asset swap creates H(S). Bank A uses H(S) to lock
model between a bank in Singapore and a the contract.
bank in Canada using intermediaries. We 2. Bank A initiates the HTLC transaction
assume each of these jurisdictions has its and completes the following actions
own DLT-based payment networks, based as part of the HTLC initiation:
on different DLT platforms, i.e., Quorum
i. Bank A locks the amount in the
in Singapore and Corda in Canada. The
designated escrow account with
atomicity of the cross-DLT transaction
the Intermediary A in Singapore
is achieved by implementing an HTLC
as the recipient.
protocol in both networks.

26 | JASPER – UBIN DESIGN PAPER

 Figure 16: Overview of an HTLC

Singapore Blockchain Canada Blockchain

2 2 Initiate HTLC Contract 1 Transfer hash 5 Using secret & hash
of secret digest complete HTLC

Bank A Bank B
(Local Bank Singapore) (Local Bank Canada)

4
Time to Complete

T 3 5 T/2

Monetary Bank of
Authority of Canada
Singapore
3 Inspect HTLC Receive hash 4 6
& Transfer digest & initiate
Singapore Hash Digest new HTLC Canada
Intermediary A Intermediary A

7 7 8
Receive secret & Complete HTLC
complete HTLC & transfer secret

ii. The expiry time for the contract in Singapore only after receiving
is set to T, which will be the the original secret from the
overall duration for completing corresponding DLT network.
the payment processing across
ii. Retrieves the contract expiry time T.
both DLT platforms.
iii. Sends the hash digest H(S) and
iii. Since Intermediary A in Singapore
contract expiry time (T/2) to
is an intermediary bank in this
Intermediary A in Canada.
contract, it receives the hash
digest information. In the Canada network:

Inspect HTLC Initiate HTLC (with time to expiry T/2)

3. Using the hash digest H(S), which 4. Intermediary A in Canada receives
is part of HTLC, Intermediary A the hash digest from Intermediary A
in Singapore can review the contents in Singapore to start and lock the new
of the contract and validate that the contract in the Canada DLT network.
appropriate amount is locked in the i. Intermediary A in Canada starts
escrow account. As an intermediary a new HTLC contract with an expiry
bank in this payment process, time of T/2 and the same hash
Intermediary A in Singapore digest H(S).
performs the following checks:
ii. Intermediary A in Canada locks
i. Verifies that the amount of locked the amount in the escrow account
funds is correct. Locked funds with the recipient as Bank B.
can be claimed by Intermediary A

JASPER – UBIN DESIGN PAPER | 27

 iii. Since Bank B is the beneficiary 2. Loss of secret S and completion of the
in the above contract, it receives second leg of the transaction by Bank B
the hash digest information H(S). in Canada—If Bank B loses the original
secret S after sending H(S) to Bank A in
Inspect and complete HTLC Singapore or is unable to complete the
5. Bank B, the beneficiary bank, inspects second leg of the transaction in T/2 time,
the contract on the Canada blockchain. then the transaction will expire in both
networks, and the funds will eventually
i. Bank B verifies that the locked
be returned to Bank A.
amount is correct.
3. Transfer of secret hash H(S) from
ii. Bank B completes the contract using
Intermediary A in Singapore to
the original secret to claim the funds
Intermediary A in Canada—If Intermediary
from the escrow account and in
A in Singapore is unable to send H(S)
the process releases the secret to
to Intermediary A in Canada, then no
Intermediary A in Canada.
transaction will be initiated in the Canada
6. Intermediary A in Canada shares network. As a result, the transaction in
the secret with Intermediary A the Singapore network will expire after
in Singapore. T time, and the funds will automatically
be returned to Bank A.
In the Singapore network
4. Transfer of secret S from
Complete HTLC Intermediary A in Canada to Intermediary
A in Singapore—If Intermediary A
7. Intermediary A in Singapore receives
in Singapore is unable to receive the
the secret S and will be able to
original secret S from Intermediary
complete and redeem the locked
A in Canada, then the transaction in
funds from the escrow account.
the Singapore network will expire after
The basic flow described above T time, and funds will automatically
remains the same for the transactions be returned to Bank A. In this scenario,
initiated in the Canada network. the intermediary bank loses the funds
since it has paid Bank B in Canada
but has not received the funds from Bank
4.1.1 EXCEPTION
A in Singapore. This can be prevented
SCENARIOS
by ensuring a reliable communication
A key aspect of the HTLC protocol is channel and/or a different rollback
the off-chain transfer of secrets and mechanism as discussed in the section
hash digests between the participating “Advantages and limitations of HTLC”.
and intermediary banks to facilitate the
initiation and completion of transactions.
As a result, the following exception
scenarios may occur during the process:

1. Transfer of secret hash H(S) from Bank B

in Canada to Bank A in Singapore—
If Bank A loses H(S), it will not be able to
initiate the transaction. Bank B will have
to regenerate H(S) and send it to Bank A.

28 | JASPER – UBIN DESIGN PAPER

4.2 SINGAPORE A sample user interface using React JS to
NETWORK DESIGN demonstrate the actions taken by various
participants during the life cycle of an
The Singapore network was built using HTLC contract was created. The client
Quorum, which is a blockchain platform application communicates all user actions
developed by JP Morgan for the financial to the decentralized application (DApp)
services sector. For this technical of the DLT network via HTTP REST calls
proof of concept, we used Solidity as and displays the up-to-date balances,
the programming language for smart transaction history and active contract
contracts and Node.js for the application details on the respective networks.
layer. We used React for the user interface
layer. Refer to the Appendix (Quorum The DApp functions as the orchestrator
Framework) for a detailed technical of the payment process and acts as a
description of the Quorum platform. bridge between the public and private
contracts. It contains all orchestration
This section provides an architecture and flow and logic. The DApp accepts
design overview of the Singapore network requests from a client through a RESTful
solution in the proof of concept. application programming interface (API)
and invokes the appropriate sequence of
4.2.1 ARCHITECTURE smart contract calls. The DApp utilizes
the Web3 library to interact with smart
Figure 16 depicts the logical architecture contracts via JSON-RPC through HTTP
of the prototype. Details of each layer and listens to contract events, which
are explained in the subsequent sections. will subsequently trigger calls to the
appropriate services. The DApp also
calls an off-chain binary for the transfer
Figure 17: Quorum logical Architecture of the secret and hash digest.

Following functional APIs were used:

Client Client App / UI
• To set up a new bank in the network
Node.js • To add a bank balance
API
• To reduce a bank balance
DApp
Event Listeners Services • To get the current balance of the bank

Adapter (Web3)
• To get all HTLC transactions for a bank
• To initiate an HTLC transaction
Quorum
Smart Contract
• To reclaim the transfer amount
Node
if the transaction fails or expires
• To initiate an HTLC transaction on
another DLT
• To complete an HTLC transaction

JASPER – UBIN DESIGN PAPER | 29

Cross-chain functional APIs used The DApp uses events emitted by
the smart contract in two ways:
The following information is used to send
an encrypted secret hash to a bank on a 1. Returning values when performing
corresponding network for redemption: call transactions—The DApp will invoke
smart contract methods by sending
• The bank identifier code (BIC) code of
transactions and will receive responses
the sending intermediary bank
through events that are emitted in
• The BIC code of the receiving the form of returning promise values.
intermediary bank
2. Listening to events that are emitted
• The BIC code of the contract as a result of actions taken by other
originating bank parties on the network. A bank receives
• The BIC code of the contract notification that another party has
beneficiary bank acted by listening to events that get
emitted. For example, when a sender
• A unique identifier for the
submits a fund transfer, an event is
transaction. This is created during
emitted that notifies the receiver.
first-leg contract initiation.
• Encrypted value of the secret hash The DApp is stateless and relies on
used to initiate the contract the data stored in smart contracts
to carry out operations.
To send an encrypted secret to
a bank on the corresponding network The DApp’s services layer contains
to initiate the second leg of the contract, functions that call the smart contract
the following information is used: methods when an action is invoked
using the API. The event listeners
• The BIC code of the sending also respond to the emitted events
intermediary bank by calling functions in services.
• The BIC code of the receiving
Services are broken down into:
intermediary bank
• bank-related functions, such as pledge,
• The BIC code of the contract
redeem balances, etc., and
originating bank
• HTLC-related functions.
• The BIC code of the contract
beneficiary bank For this HTLC proof of concept, we used
• A unique identifier for the the following private smart contracts:
transaction. This is created during
• HTLC—This represents the core HTLC
first-leg contract initiation.
contract that is created between the
• Timeout used for first-leg contract initiating and counterparty banks for
(in seconds) every cross-chain transfer function. Each
• Amount to be transferred (in the HTLC contract owns an escrow contract
currency of the network of origin) in which the transferred funds are locked
using the secret digest. This contract
• The encrypted secret used
also tracks the HTLC expiration time
to initiate the contract
based on the network timeout value.

30 | JASPER – UBIN DESIGN PAPER

• Stash—This is the store contract that Below are a few predefined rules
holds the individual balances for each used in the proof of concept:
bank in the network. All debit and credit
1. The requester of the funds and
of funds is performed by this contract.
the counterparty should be same.
• Escrow—The escrow account plays
2. The HTLC identifier must match
a critical role in HTLC implementation.
between the fund requester and
This is an extension of the stash
the escrow account.
contract that keeps track of the
locked balance held between the 3. The HTLC completion or timeout
initiating and counterparty banks. criteria must be met.

The process of using the escrow Similarly, for the timeout scenario,
account is described below: funds are transferred from the escrow
account to Bank A automatically once
• Bank A locks the funds in an escrow the validation succeeds.
account with Intermediary A in
Singapore as the counterparty.

• Intermediary A in Singapore claims the

money only after receiving the secret
from Intermediary A in Canada.

• While Intermediary A in Singapore is

claiming money from the escrow account,
a set of validations (a predefined set
of rules) is performed to ensure that
the correct counterparty is claiming
the money. Once all the validations
have successfully been completed,
the amount will move from the escrow
account to Intermediary A in Singapore.

JASPER – UBIN DESIGN PAPER | 31

4.3 CANADA 1. The period after "Singapore network"
NETWORK DESIGN to be removed
2. The UI also demonstrates
The Canada network was built using open
source Corda version 3.2. Corda is a DLT 3. The UI,which is also known as the
platform from R3 that is designed for client application, communicates all
use with regulated financial institutions. user actions to the Corda distributed
Refer to Appendix B (Corda concepts) application
for a detailed technical description of In the Corda-based DLT network, each
the Corda platform. This section of the participant runs a node with business-
report provides an architecture and specific functionality implemented
design overview of the Canada network in CorDapp to provide peer-to-peer
solution used in the proof of concept. private transactions. CorDapp (consisting
of states, contracts, transactions and flows)
4.3.1 ARCHITECTURE was developed using the Corda platform
to support various use cases. These are
For the proof of concept, Corda nodes the key nodes in the networks:
(Bank, Bank of Canada, notary, etc.)
• Bank of Canada node issues tokenized
and other components are hosted in
CAD W-CBDC.
Azure virtual machines. Figure 17 shows
the architecture of the Corda-based • Bank nodes participate in the
DLT solution used to set up the Canada cross-border payment transactions.
network and process HTLC transactions. • Notary node provides uniqueness
consensus on the transactions.
Figure 18: Corda node
• Escrow node is a trusted entity
introduced in the proof of concept
Web UI
to hold the funds in escrow to facilitate
cross-border transactions using HTLC.
Node.js based Web Server
The tokenization of cash (W-CBDC) follows
a digital depository receipt (DDR) model
Corda Node similar to the one implemented in the
previous Jasper projects. A participating bank
States Contracts can obtain CAD W-CBDC tokens from the
Corda
RPCOps
Bank of Canada by pledging cash from its
Flows existing account at the bank (off-DLT ledger).
The Bank of Canada issues CAD W CBDC
ServiceHub tokens for the given amount and transfers the
same amount from the requester’s account
Database JDBC
to a pool account. Similarly, a participating
Vault Tx Storage
bank can redeem CAD W-CBDC tokens it
owns at the Bank of Canada in exchange

32 | JASPER – UBIN DESIGN PAPER

for receiving the underlying cash in its time validation. The hash validation process
account, transferred from the pool account. using the escrow node is described below:

For the cross-border (interledger) payment 1. Intermediary A locks the funds with
transactions, we considered various the escrow node by providing the
architecture options (using Composite Keys, hash of the secret.
Encumbrance states etc.) to successfully 2. Bank C presents the secret to
build HTLC functionality in a Corda network. the escrow node.
Currently, the Corda platform does not
3. The escrow node hashes the secret and
fully support the features (locking, secret
compares it with the hash provided by
disclosure, timeout) required to properly
Intermediary A. If it matches, the escrow
implement HTLCs without introducing
node releases the funds to Bank C.
unacceptable failure modes and a trust
model. The development effort that For the time validation, the escrow node
would have been required at a platform ensures that Bank C claims the funds (by
level to achieve this was not possible providing the secret) within the time window.
within the time available to the team. Otherwise, it automatically returns the funds
to the intermediary. The time lock element
For this reason, we introduced a trusted
of HTLC is implemented by suspendable
entity, the escrow node, which is part of
Corda flows with timeouts set to throw
the transactions, to implement the HTLC
an exception and reject the transaction
functionality. The escrow node is assumed
for the originator to reclaim the funds.
to be trusted and will be owned/maintained
by the network operator, similar to the The HTLC protocol relies on the ability
trust framework for the notary. Around of the nodes in two different networks
the escrow node, the flows and signatures to pass secure reliable messages (secret,
are carefully managed to ensure that the hash code, timeout, amount, etc.). This
transaction cannot be sabotaged by any functionality was implemented in the
party. As part of the HTLC protocol, the network using custom RESTFul APIs to
escrow node provides hash validation and communicate with the Singapore network.

Figure 19: Corda logical architecture

Regulator
(node)
1 2
Intermediary A Bank C
(node) (node)
H(S), Bank C, Secret
T, Amt Escrow
(node) 3

Intermediary B Bank D
(node) (node)

Notary
(node)

JASPER – UBIN DESIGN PAPER | 33

DISCUSSION
05
The project successfully implemented 5.1 DLT PLATFOM SUPPORT
and demonstrated the ability to perform FOR HASHED TIME-LOCKED
atomic transactions between a Quorum- CONTRACTS (HTLC)
based network in Singapore and a
Corda-based network in Canada using HTLC protocol uses hash locks and time
HTLC. This was proven by the successful locks to ensure the atomicity of transactions
transfer of SGD$105 between local across two DLT platforms. The receiver of
Bank A in Singapore and local Bank B in the payment either acknowledges receiving
Canada with the FX rate of 1 SGD to 0.95 the payment prior to a deadline (timeout)
CAD. At the end of the transaction, local by generating cryptographic proof of
Bank B received CAD$100. Various failure payment (hash lock) or forfeits the ability
scenarios were also successfully tested. to claim the payment, which results in the
For example, local Bank A in Singapore payment being returned to the payer. A
was able to get SGD $105 back when DLT platform must support locking, secret
the Canadian bank did not claim the disclosure and timeout to successfully
corresponding $100 before the deadline build the HTLC functionality. A DLT platform
set by the HTLC timeout period. We also lacking these features may find it difficult
analysed the design for various failure or impossible to implement HTLC. However,
modes, e.g. the impact of the failure of there are no standards to govern how HTLC
different nodes at specific points in a is implemented on each of the platforms;
transaction execution. We found HTLC to therefore, HTLC implementation may differ
be robust in handling these scenarios. from one platform to another. In addition,
reliable communication channels, such
While the specific proof of concept of as redundant circuits, are needed among
cross-border payments between two the networks for the transfer of the secret,
different DLT networks was proven, the contract details, etc.
limited scope of the Jasper-Ubin project
means that many opportunities for in-depth
research remain open. The key findings,
challenges and limitations are listed in this
section to encourage further exploration by
the DLT community.

34 | JASPER – UBIN DESIGN PAPER

5.2 HTLC ACROSS In a permissioned network where
MULTIPLE NETWORKS participants are known, and where there
are trusted third parties, there could
HTLC could theoretically be used for be alternative methods of rolling back
atomic transactions across three or more a transaction; each with its own set of
networks, but this was not tested in the considerations.
current proof of concept, which tested
only for atomic transactions across two One possibility is for the rollback to be
DLT networks. There are possible use triggered manually rather than through
cases for such transactions, such as a time-lock mechanism. This would
a foreign currency transaction with a solve the problem of the secret not
bridge currency, i.e., SGD to USD to CAD, being transferred in time, but it could be
or in delivery-versus-payment-versus- disadvantageous to the sender because
payment transactions where investors of the opportunity cost of having funds
convert their LCY to FCY to purchase locked up for a longer period (an example
securities denominated in FCY. Further of this is in the scenario where there are
experimentation on HTLC across three deliberate delays by the intermediary.).
or more networks would be required However, in a consortium blockchain,
to support such use cases. the governance framework could prevent
a deliberate delay, possibly by monitoring
and imposing fees or penalties when
5.3 ADVANTAGES AND such activities are detected.
LIMITATIONS OF HTLC
Another possibility is for the rollback to
The HTLC protocol was originally
be a transferred to an account controlled
designed for public blockchain networks,
by a third party instead of directly
where there is no trusted central
to the sender. This would introduce
authority and transacting parties are
dependency on a central entity, which
possibly adversarial. It works well in
would not work in a public blockchain,
facilitating atomic transactions between
but it could possibly be a solution in
DLT networks while minimizing risk to
consortium networks. In such a case,
transacting parties.
failed transactions would not cause
However, the HTLC protocol fails if the financial loss, but they would incur other
intermediary in the receiving network costs in the form of operational needs
is not able to transfer the secret to the (manual intervention to release the
intermediary in the sending network payment) and opportunity costs (funds
within the specified time period. locked up). However, if most transactions
are completed successfully, then such a
The crux of this issue lies with the time- solution may prove to be effective while
lock or rollback mechanism when the still reducing risks.
transaction is not completed in time.

JASPER – UBIN DESIGN PAPER | 35

5.4 HTLC ALTERNATIVES 5.5 NETWORK
SCALABILITY
Although HTLC has become quite
popular and gained momentum in the The proof of concept was tested with
financial services industry, there are a limited number of participants on each
other alternatives. Vitalik Buterin defines network, and we assumed that each
three categories of strategies for chain participant would be able to transfer
interoperability solutions in his paper directly to any other participant in the
“Chain Interoperability,”6 defines three other network. In a real-world scenario
categories of strategies for chain where there are hundreds to thousands
interoperability solutions: of participants on each network, with tens
to hundreds of inter-connected networks,
• Centralized or multisig notary schemes,
such a model is untenable due to the
where a trusted entity or a set of entities
complexity and scalability challenges.
trusted as a group is used to inform
The direct node-to-node connectivity
chain X that a claim in chain X is true.
is also a single point of failure, with a
An example of this is the Interledger
negative impact on resiliency.
payment protocol7 by Ripple.
• Sidechains/relays, where blockchains We hypothesize that these challenges
have the capability to read and validate could be overcome through alternative
events from other blockchains. These network models, such as:
are a more direct method of facilitating
• Using gateway nodes that act as service
interoperability compared with the
nodes for its network participants
notary schemes. An example of this
is BTC Relay8 between Bitcoin and • Leveraging on a centralized connector
Ethereum. between networks, where networks
register and connect directly to
• Hash-locking, which uses the preimage
the broker
of a particular hash on both chains
to perform interoperability. This is being • Having an additional DLT to established
actively explored as an interledger connections between the networks
protocol by many public and private
Each network model has its own
DLT platform providers. Along with
considerations, benefits and limitations.
HTLC, Clearmatics’s Ion9 is a good
More in-depth research is required.
example of a protocol in this category.

In addition, there is active research

and development in off-chain channel
networks to achieve scalability and
interoperability. Some examples of
these are Lightning Network, Raiden
and COMIT.

36 | JASPER – UBIN DESIGN PAPER

REFERENCES

See Bank of Canada, Bank of England

1 5
We do not believe the HTLC
and Monetary Authority of Singapore, implementation required is dependent
“Cross-Border Interbank Payments and on the choice of model from Table 1.
Settlements: Emerging Opportunities 6
See V. Buterin, “Chain Interoperability,”
for Digital Transformation,” November
September 2016.
2018.
See S. Thomas and E. Schwartz,
7
2
A smart contract is a software
“A Protocol for Interledger Payments.”
construct that computationally
(not legally) binds parties to
8
See BTC Relay.
programmatically expressible 9
See GitHub, “Ion Interoperability
commitments. Framework.”
3
Corda is a DLT platform from R3 that
is designed for use with regulated
financial institutions. It is inspired by
blockchain systems and designed for
recording, managing and synchronizing
commercial agreements between
known and identified parties at scale
without compromising privacy.
4
Quorum is a blockchain platform
developed by JP Morgan. It is a fork
of Ethereum, meant explicitly for
enterprise use within the financial
services sector.

JASPER – UBIN DESIGN PAPER | 37

ACKNOWLEDGEMENTS

BANK OF CANADA MONETARY AUTHORITY

OF SINGAPORE
Rakesh Arora
Wee Kee Toh
Dinesh Shah
Lizhi Chen
Scott Hendry
Damien Pang
André Usche
Sopnendu Mohanty
Yusu Guo

Adrian Guerin

PROJECT TEAM
Fraser Edwards (Accenture) Raunak Rajpuria (JP Morgan)

Hong Yi Lim (Accenture) Sai Valiveti (JP Morgan)

James Hwa Jaan Gan (Accenture) Samantaray Debidutta (JP Morgan)

Janis Olekss (Accenture) Viswanathan Sugumar (Accenture)

Jessica Johnson (Accenture) William Lim (Accenture)

John Velissarios (Accenture)

Jonathan Seah (Accenture)

Naveen Mallela (JP Morgan)

Peter de Rooij (Accenture)

38 | JASPER – UBIN DESIGN PAPER

GLOSSARY
06
ACK Acknowledgement, a positive response signal between
data communicating processes or computers

API Application Programming Interface

BIC Bank Identifier Code

BOC Bank of Canada

DApp Decentralized Application

DDR Digital Depository Receipts

DLT Distributed Ledger Technology

FCY Foreign Currency

HTLC Hashed Time-Locked Contracts

HTTP Hypertext Transfer Protocol

LCY Local Currency

LVTS Large Value Transfer System (Canada RTGS System)

MAS Monetary Authority of Singapore

MEPS+ MAS Electronic Payment System (Singapore RTGS System)

RPC Remote Procedure Call

RTGS Real Time Gross Settlement

W-CBDC Wholesales Central Bank Digital Currency

JASPER – UBIN DESIGN PAPER | 39

APPENDIX
07
7.1 QUORUM FRAMEWORK While Quorum has been designed with
financial services use cases in mind,
Quorum is an Ethereum-based distributed its implementation is not specific
ledger protocol that was developed to financial services and hence is
to provide the financial services industry appropriate for other industries that
with a permissioned implementation are interested in utilizing Ethereum
of Ethereum that supports transaction but require the above primary features.
and contract privacy.
Figure 20 depicts key components
Quorum includes a minimalistic fork of the Quorum design:
of the Go Ethereum client (also known
as Geth) and, as such, leverages the Figure 20: Quorum design
work that the Ethereum developer
community has undertaken. Quorum

Constellation
The primary features of Quorum, Quorum Node
and therefore extensions over public Transaction
Enclave
Ethereum, are: go-ethereum Manager

• Transaction and contract privacy

• Multiple voting-based consensus
7.1.1 QUORUM NODE
mechanisms
• Network/Peer permissions management The Quorum Node includes the
following modifications to Geth:
• Higher performance
• Consensus is achieved with the Raft
Quorum currently includes the
or Istanbul BFT consensus algorithms
following components:
instead of using Proof-of-Work.
• Quorum Node (modified Geth Client) • T
he P2P layer has been modified
• Constellation/Tessera – Transaction to only allow connections to/from
Manager permissioned nodes.

• Constellation/Tessera – Enclave • T
he block generation logic has been
modified to replace the ‘global state
root’ check with a new ‘global public
state root’.
• T
he block validation logic has been
modified to replace the ‘global state
root’ in the block header with the
‘global public state root’

40 | JASPER – UBIN DESIGN PAPER

• The State Patricia trie has been It utilizes the Enclave for cryptographic
split into two: a public state trie and functionality (although the Enclave can
a private state trie. optionally be hosted by the Transaction
Manager itself.)
• Block validation logic has been modified
to handle ‘Private Transactions’
The Transaction Manager is restful/
• Transaction creation has been modified stateless and can be load balanced easily.
to allow for Transaction data to be
replaced by encrypted hashes in order The Enclave
to preserve private data where required Distributed ledger protocols typically
• The pricing of Gas has been removed, leverage cryptographic techniques
although Gas itself remains for transaction authenticity, participant
authentication, and historical data
preservation (i.e., through a chain
7.1.2 CONSTELLATION
of cryptographically hashed data.)
AND TESSERA
To achieve a separation of concerns,
Constellation and Tessera are Haskell as well as to provide performance
and Java implementations of a general- improvements through parallelization
purpose system for submitting of certain crypto-operations, much of the
information in a secure way. These cryptographic work, including symmetric
are comparable to a network of MTA key generation and data encryption/
(Message Transfer Agents) where decryption, is delegated to the Enclave.
messages are encrypted with PGP. These
The Enclave works hand in hand with
are not blockchain-specific, and have
the Transaction Manager to strengthen
many other potential applications for the
privacy by managing the encryption/
exchange of individually-sealed messages
decryption in an isolated way. It holds
within a network of counterparties.
private keys and is essentially a virtual
The Constellation and Tessera modules
hardware security module isolated
consist of two sub-modules:
from other components.
• The Node (which is used for
Quorum's default implementation 7.2 CORDA FRAMEWORK
of the Transaction Manager)
• The Enclave Corda is a DLT platform from R3 that
is designed for use with regulated
Transaction Manager financial institutions. It was used in
the Jasper III proof of concept to build
Quorum’s Transaction Manager is
the delivery-versus-payment equity
responsible for Transaction privacy.
settlement system. This appendix
It stores and allows access to encrypted
provides a simplified explanation of
transaction data, exchanges encrypted
Corda concepts, highlighting how Corda
payloads with other participant's
specifies and enforces control over use of
Transaction Managers but does not
assets on-ledger. For a detailed technical
have access to any sensitive private keys.
description of the Corda platform, refer
to the introductory and technical white
papers available on Corda's website.

JASPER – UBIN DESIGN PAPER | 41

A Corda distributed application (CorDapp) • Contracts specify the rules associated
is a distributed application installed at with a state. They take a proposed
the node level that leverages Corda’s transaction as input and define whether
platform to handle business logic and the transaction is valid based on the
processes. It consists of four components contract’s rules for every input and
that jointly determine the capabilities output state present in the transaction.
and controls of that application: states, For example, a W-CBDC contract
transactions, contracts, and flows. is associated with all W-CBDC states,
and it specifies (among other rules)
• States are immutable on-ledger
that a transfer transaction cannot
objects that represent shared facts.
change the issuer, increase the
Participants that hold a state are in
amount, or change the currency.
consensus about the contents of that
state. In the proof of concept, cash and • Flows specify how participants
equity on-ledger are digital depository communicate transactions and
receipts (DDR), which are represented reach consensus on them.
as a state that fully specifies the DDR,
Ultimately, flows orchestrate the
including its current owner.
inclusion of states from each necessary
• Transactions are actions, known as party, the contracts that govern these
commands, on a set of states. Corda has states, and the collection of signatures
an unspent transaction output (UTXO) from these same parties to establish
model in which a transaction consumes a new transaction, which is stored
a set of input states (i.e., marks them as to each participant’s ledger.
historic or no longer valid) and produces
a set of output states, as specified by The Corda platform provides a network
one or more commands. States are map service that manages and publishes
immutable, but transactions offer a way the identities of the nodes on the
to mark consensus on a change of the network. This service can be distributed
facts in the state: it consumes the state and run by an independent party.
with the old values and produces a new
state with updated values. For example, The pluggable notary service of the
to transfer some W-CBDC to another Corda platform provides a uniqueness
participant, a “transfer” transaction and/or validating consensus by attesting
would consume a state with the payer to the finality of the transactions. A notary
as its owner, have one single “transfer” may be a single network node, a cluster
command, and produce a new state of mutually trusting nodes, or a cluster
with the payee as its owner. of mutually distrusting nodes. Corda also
has a “pluggable” consensus, allowing
Corda transactions are atomic: they notaries to choose an algorithm based
either succeed entirely or fail entirely. For on their requirements in terms of privacy,
the transfer transaction, this means that scalability, legal-system compatibility,
either the payer owns the old W-CBDC, and algorithm agility. In the Jasper III
or the payee owns the new W-CBDC. proof of concept, the notary provides
A situation where both W-CBDC states are only uniqueness consensus.
valid, or that neither of them is, will never
happen as a result of this transaction.

42 | JASPER – UBIN DESIGN PAPER

JASPER – UBIN DESIGN PAPER | 43
ABOUT ACCENTURE

Accenture is a leading global professional

services company, providing a broad
range of services and solutions in
strategy, consulting, digital, technology
and operations. Combining unmatched
experience and specialized skills across
more than 40 industries and all business
functions—underpinned by the world’s
largest delivery network—Accenture
works at the intersection of business and
technology to help clients improve their
performance and create sustainable value
for their stakeholders. With 477,000 people
serving clients in more than 120 countries,
Accenture drives innovation to improve
the way the world works and lives.
Visit us at www.accenture.com.

Copyright © 2019 Accenture.

All rights reserved.
Accenture and its logo are trademarks of Accenture. 181931