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:
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
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
You can also read