Enabling Cross-Border High Value Transfer Using Distributed Ledger Technologies - Jasper - Ubin Design Paper - Accenture
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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 PAPERThe 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 |7INTRODUCTION
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 PAPERThe 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 |91.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 PAPERDESIGN 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 | 11Using 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 PAPERIn 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 | 13PROPOSED
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 PAPERThe 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 | 15The 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 PAPER3.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 | 17HTLC 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 PAPER1. 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 | 193.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 PAPERHTLC 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 | 21Transfer: 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 PAPERFunding: 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 | 23HTLC 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 PAPERJASPER – 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 PAPERFigure 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 | 27iii. 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 PAPER4.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 | 29Cross-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 | 31You can also read
