(AGENPARL) – lun 26 settembre 2022 The views expressed in the papers are those of the authors and do not necessarily reect
Via Nazionale, 91 – 00184 Rome – Italy
NTEGRAT
MARKET
NFRASTRUCTURES
PROOF
CONCEPT
SECURE
BETWEEN
ATFORMS
by Rosario La Rocca
Giuseppe Galano*, Simone Mancini*, Gabriele Marcelli*, Piero Martella*, Matteo Nardelli*
and Ciro Oliviero**
Abstract
The rise of a market for digital assets, both natively digital (e.g., non-fungible tokens, utility tokens)
and those representing non-digital resources (e.g., security tokens, stablecoins, e-money tokens), is
closely linked with the growing diffusion of distributed ledger technologies (DLT) platforms among
investors. The increasing volume of transactions involving digital assets makes it worthwhile to
investigate how central bank money can contribute to make the settlement safer and more efcient.
While this is not strictly needed at the current juncture, central banks should arguably prepare to
ensure that they can keep central bank money at the core of the settlement process of nancially
relevant assets. This requires the identication of possible solutions to increase interoperability
between currently independent infrastructures: those regulating the exchange of the digital assets
and those providing central bank money settlement services. A way to achieve this goal is to allow
these transactions to ow through the market infrastructures, where central bank money is safely
managed. This implies building a “bridge” between DLT platforms and market infrastructures.
This paper analyses several technical interoperability models and then describes the results of two
experimental activities, which evaluate two different solutions for synchronizing the asset-leg and
the cash-leg of a DvP (delivery versus payment) transaction. Both use the Target Instant Payment
Settlement (TIPS) platform to provide the settlement services of the cash leg. The rst, named “TIPS
Hash-Link”, is a lightweight, API based and DLT agnostic protocol which enables a loosely coupled
integration of the market infrastructure with the majority of DLT platforms. Inspired by the Hash
Time
Locked Contracts (HTLC) protocol, TIPS Hash-Link has been specically tailored to overcome some
failure scenarios commonly experienced with HTLC, leveraging TIPS as a trusted escrow for funds
and a smart contract to coordinate the DvP operations on the DLT in a safe and consistent manner.
The second one, named “TIPS-Algorand Just In Time Locking”, takes advantage of the features
offered by a specic DLT platform, Algorand. In particular, it leverages a native feature of the chosen
DLT that simplies DvP transactions guaranteeing atomicity; as such, this approach needs the two
systems to be directly connected to interact with each other.
Keywords
: DvP, TIPS, DLT.
Bank of Italy, Directorate General for Information Technology.
Distributed Ledger
(DLT). L’aumento del volume delle transazioni che coinvolgono asset digitali rende
centro del processo di regolamento delle attività nanziariamente rilevanti. Questo richiede
l’identicazione di possibili soluzioni per accrescere l’interoperabilità tra infrastrutture attualmente
centrale è gestita in modo sicuro. Questo implica la costruzione di un “ponte” tra le piattaforme
delle infrastrutture dei mercati nanziari con la maggior parte delle piattaforme DLT. Ispirato al
per superare alcuni scenari di errore comunemente sperimentati con HTLC, sfruttando TIPS come
sicuro e consistente. La seconda soluzione, chiamata “
Algorand Just In Time Locking
”, utilizza
Introduction
Background and business context
Scope of the document
Related work
DvP Integration Models
A list of relevant dimensions of analysis
Orchestrated DvP with Cash-leg Locking
Just In Time Locking of the cash-leg
Tokenized Cash-leg Locking
API-based DvP with Hash-Time Locked Contract
API-based DvP with Hash-Link Contract
Summary of DvP models analysis
Experiment
Actors of a cross-ledger DvP
The Algorand DLT
TIPS Hash-Link Contract DvP
TIPS Gateway
Algorand Hash-Link Contract (HLC)
TIPS-Algorand Just In Time Locking DvP
TIPS-Algorand Orchestrator
Algorand Atomic Transfer
Tests and Results
Test scenarios
Results
Conclusions
References
Introduction
Backgroundandbusinesscontext
Thegrowingdiusionofdistributedledgertechnologiesplatformsamonginvestorsisoneof
thefactorsdrivingtheriseofamarketfordigitalassets.Thetransferofownershipinsecurities
transactionsisacomplexprocess;itistypicallybrokendownintothreemainphases:
trading
phase
,whenadealisestablished,withaselleragreeingtosellandabuyeragreeingtopayfor
asecurity;the
clearingphase
,whenthetradingpartiesarrangeforthetransferofmoneyand
securities,typicallybymeansofacentralclearingcounterparty(CCP),whichaggregatestrades
andnetsouttransactionsforthetradingday;the
settlementphase
,whenmoneyandsecurities
areactuallyexchangedinacoordinatedmannerbetweenthepartiesinvolvedonasettlement
date.Typically,thesettlementdateisacoupleofbusinessdaysaerthetradedate.Exchangeof
moneyinvolvestheuseofapaymentsystem(PS)
enablingtransferseitherincommercialbankor
centralbankmoney.
Theusualrecoursetoclearingintermediariesisneededinordertominimize
thecounterpartycreditriskbetweenpartiestoatransactionandisobtainedbyvariousmeans
(e.g.,mutualizationofrisksamongallCCPmembers,nettingoftransactions,depositofcollateral,
creditworthinessmonitoringofmemberparties,guaranteefunds,andsoon).Thecomplexityof
thisprocess,andthenumberofintermediariesinvolved,makesecuritiessettlementoenslow
andcostly.
Inthiscontext,theappealingpromiseofstreamliningthisprocessloweringcostsandexecu-
tiontimeswhilemaintainingcomparablelowlevelsofriskisoneofthekeyfactorsforthegrowing
diusionofdistributedledgertechnology(DLT)platforms(seethenoteon”DLTs,blockchains,and
smartcontracts”).
WewouldliketothankAlgorandLabs,andspecicallyAdrianoDiLuzio,CosimoBassi,StefanoDeAngelisandFederico
Demicheli,fortheirvaluableexpertiseandsupportintheexperimentalactivities.
2SeeECB,
2022b
APSisusedtosettlenancialtransactionsbytransferringmonetaryvalue.PSsmaybephysicalorelectronic,eachwithits
ownproceduresandprotocols.Standardizationenabledinter-operability,allowingsomeofthesesystemsandnetworksto
growonaglobalscale.Nonetheless,therearestillmanycountry-specicorproduct-specicsystems.Averyhigh-level
denitionisprovidedinthisdocument,becauseaPSisprimarilyresponsiblefortransferringmoneyandsettlingthe
so-calledcash-legofaDelivery-versus-Payment.ThePSusuallyholdsaledgeroverseeingcorrectmoneytransfer.This
ledgercanbeorganizedusingatoken-basedoranaccount-basedabstraction.Atoken-basedsystemholdsalistofeither
spentorunspenttokens,representingmoney.Anaccount-basedsystemstoresthebalanceforeachcustomercorrectly
registeredwithinthePS.Formoredetailsabouttoken-basedandaccount-basedPScharacterization,albeitfocusedona
centralbankdigitalcurrencyscenario,pleaserefertoUrbinati
etal.
Centralbankmoney:Liabilitiesofacentralbank,intheformofeitherbanknotesorbankdepositsheldatacentralbank,
whichcanbeusedforsettlementpurposes.Commercialbankmoney:Commercialbankliabilitiesthattaketheformof
depositsheldatacommercialbankwhichcanbeusedforsettlementpurposes.SeeECB,
DLTs,blockchainsandsmartcontracts
Theumbrellaterm
DistributedLedgerTechnology
(DLT)encompassesatechnologicalinfra-
structuretogetherwithitsprotocolsallowingaccess,verication,andupdateofinformation
storedonacommon,sharedledgerspreadacrossmultiplelocationsand/orentities.Since
dataisdistributed,theso-called
consensusprotocols
ensuretheachievementofanagree-
mentondataupdatestobecommittedontheledger.
blockchain
isaclassofDLTswheretheinformationisorganizedinblockslinkedtogetherin
anorderlyfashion.Eachblockischained,inanappend-onlyfashion,toitspredecessorby
meansofacryptographichash,uptotherstblockinthechainwhichisusuallyreferred
toasa
genesisblock
Whilenotstrictlytiedto,norrequiredby,thearchitecturalstyletheyrepresent,DLTsoen
supportsomeformofprogrammabilityusingscriptsorsmartcontracts.
Smartcontracts
deterministiccomputerprogramsstoredontheledgerthatexecutewhenpredetermined
conditionsaremet(e.g.,seeIBM,
Smartcontracts
areusuallyadoptedtoautomate
theexecutionofagreements.Beingavailableonapublicledger,theyenableparticipantsto
auditimplementationandverifyoutcomeswithoutrequiringanyintermediaryinvolvement.
Smartcontractsarealsooenusedtocreate
tokens
representingassetslikesecuritiesin
digitalform.
Theadoptionofasharedledgeramongpartiesinvolvedinnancialtradesisseenasatre-
mendousopportunityintermsoftimelyandsecureinformationexchange,operatingpotentially
365/24/7.Theusageof
smartcontracts
enablesthecreationofcomplexnancialinstrumentsand
enshrinesthebusinesslogicinaguaranteedimmutableandeasilyauditableform,potentially
reducingrecoursetointermediaries.
Scopeofthedocument
Thispaperfocusesontheaforementioned
settlementphase
,underthehypothesisthatthenancial
instrumentsresideonsomesortofDLTplatform
asatokenizedasset
,andthepaymentismade
incentralbankmoney.Thisrelatestothe
Delivery-versus-Payment
(DvP)inthecaseknowninthe
literatureascross-ledgerDvP,wherecashandsecuritiesresideonseparateledgers,respectively
thecentralbankpaymentinfrastructuresandDLTplatforms(seethenoteon”Delivery-versus-
Payment”).
5ThisexcludesexplicitlyalltheassetscurrentlymanagedintheEurosystemPlatformTarget2-Securities(T2S).
Theprogrammingcapabilitiesof(someofthe)blockchainsenablethecreationofspecial
tokens
,whichcanrepresentspecial
assets
-bothfungibleandnon-fungible.Someexamplesoffungibletokensarestablecoins,securitytokens,andutilitytokens.
Analyzingthelegalaspectsrelatedtotheissuanceoftokenizedassetsisoutofthescopeofthispaper.Fromthetechnical
perspective,aprominentexampleoffungibletokensstandardisrepresentedby
ERC-20
,whichformsthebasisofothertoken-
relatedstandardsontheEthereumblockchain(seeformoredetails:
https://ethereum.org/it/developers/docs/standards/
tokens/erc-
ƒ
);forsecuritytokens,theformerisoenextendedby
ERC-1400
(see:
https://polymath.network/erc-
‚…
https://thesecuritytokenstandard.org/
https://github.com/ethereum/EIPs/issues/
‚…‚‚
).Non-fungibletokens(NFTs)
areanon-interchangeableunitofdatastoredonablockchain,whichcanbesoldandtraded.NFTscanrepresentadigital
art-workor,ingeneral,adigitalle.Ownershipofatokenisassociatedwithspecialrightstotherelatedobject.Forexample,
owningaNFTisoenassociatedwithalicensetousetheunderlyingdigitalasset.ThedefactostandardinNFTissuanceon
theEthereumblockchainisnamed
ERC-721
,andisrepresentativeofthevastmajorityofcurrentlytradedNFTs;seeformore
details:
https://ethereum.org/en/developers/docs/standards/tokens/erc-
ˆƒ‚
Delivery-versus-Payment
Delivery-versus-Payment(DvP)isaformofsettlementforsecurities,whichlinksasecurities
transferandafunds(cash)transferinsuchawaythatthedeliveryoccurs
ifandonlyif
correspondingpaymentoccurs(ECB,
2022a
).Acorrectsettlementrequiresthatthesystems
performoperationswithall-or-nothingsemantic.
Thisconceptisquitegeneralasitessentiallyaccountsforfulllinganobligationtoprovide
somekindofgoodorserviceifanagreedpaymentisnalised.However,thetermisused
specicallyinthecontextofnancialmarkets,wherethegoodtobedeliveredisusuallya
security
inexchangeforacorrespondingpayment.
ThepresenceofmultipleledgersleadstotwomaincategorieswherebyaDvPcanbecon-
ceptuallyandtechnicallydesigned:ina
single-ledgerDvP
,bothcashandsecuritiesareon
thesameledger;ina
cross-ledgerDvP
,cashandsecuritiesareontwoseparateledgers.
Theobjectiveofthestudyhasbeentoinvestigatehowcentralbankmoneycancontributeto
makingthesettlementofDvPtradesindigitalassetssaferandmoreeicient,increasinginteroper-
abilitybetweentheDLTplatformsregulatingtheissuanceandexchangeofthoseassetsandthe
systemsprovidingcentralbankmoneysettlementservices.
Fromatheoreticalperspective,multiplepossibleinteroperabilityandintegrationmodelsfor
DvPhavebeenexploredandacomparisonframeworkhasbeendened,withtheidentication
ofrelevantdimensionsofanalysis-frombothabusinessandatechnologicalpointofview.Each
solutionhasbeenanalysedandclassied;moreover,acomprehensivefailureanalysiswithan
approachsomewhatremindfulof
Failuremodeandeectsanalysis
(FMEA)hasbeenputinplace,
pinpointingforeachsolutionpotentialfailurescenariosandeects.
Inthiscontext,anovelDvPinteroperabilitymodelhasbeenproposedbasedonthisstudy,
called
“API-basedDvPwithHash-LinkContract”
,whichdrawsuponthewell-knownHashTime
LockedContracts(HTLC)approachandovercomessomelimitationsofthelatterintermsofsafety
ofDvPtransactions,whichisparamountindeninganinteroperabilitymodelwithcentralbank
moneysettlementsystems,whileatthesametimeimposingminimumtechnicalrequirements
ontheasset-managingDLT.
Toourknowledge,thismodelhasnotbeenintroducedbeforeinthe
literature,eitherinthecentralbankingcommunityorinthewideracademiccommunity.
Fromtheexperimentalperspective,twointeroperabilitymodelshavebeenselectedandevalu-
ated.Therstone,
API-basedDvPwithHash-LinkContract
model,hasbeenselectedtorepresent
loosely-coupledsolutionswhichdonotrequiretheoperationofanodeontheasset-managingDLT.
Thesecondone,
OrchestratedDvPwithJustIntimeLockingoftheCash-leg
,hasbeenchosentorep-
resentsolutionswhichrequiretight-coupledintegration,operatinganodeoftheasset-managing
DLT.Inbothcases,theTargetInstantPaymentSettlement(TIPS)platformwasusedtoprovide
paymentservicesforthecashleg;TIPSwasselectedfromtheEurosysteminfrastructures,for,
amongotherreasons,its365/24/7availability.AlgorandwastheDLTplatformchosenamonga
numberofcandidatestomanagetheassetlegduetoitspermissionlessforklessnature,witha
deterministicconsensusprotocol,andlowblocknalizationtime.
Themaingoaloftheexperimentwastoverifythefeasibilityoftheproposedmodels,eectively
validatinginteroperabilitybetweenaDLTandtheEurosystemMarketInfrastructuresintheDvP
use-case.Severaltest-cases,bothfunctionalandnon-functional,havebeenexecutedtoverify
thesystemresponsebothinpositivecases(“happypath”)andinvariousfailurescenarios.The
architectureofbothsolutionsispresentedindepthfromatechnologicalpointofview,alongwith
comprehensivetestingresults.
TherequirementsontheDLTsideareessentiallylimitedtothesupportofsomecryptographic
hashfunctions
,whichare
widelyimplementedbythevastmajorityofDLTsandblockchains,beinganessentialcomponentoftheirinnerworking.
Theconclusionsectionsummarizestheresultsandndings,highlightingthestrengthsand
weaknessesoftheexperimentedsolutions.Inparticular,itshowshowtheproposedimplementa-
tionofanovelinteroperabilitymodelnamed
“TIPSHash-Link”
representsaviablesolutionin
termsofperformanceandexhibitsdesirablecharacteristicsintermsoflow-couplingwithrespect
tothespecicasset-managingDLT.
Relatedwork
SeveralcentralbanksinvestigatedtheuseofDLTsinsecuritiessettlement,inordertogainabetter
understandingoftheopportunitiesoeredbythisnewtechnology.Thissectionlistssomeadvanced
researchworksthathaveinvolvedthesettlementofpayments,securities,andthedenitionof
DvPmodels.
InMarch2018,theEuropeanCentralBankandtheBankofJapan,inthecontextofthesecond
phaseofthecollaborativeProjectStella,focusedonsecuritiesDvPinaDLTenvironment(Project
Stella,
).BesidesprovidingacleardenitionofdierentDvPscenarios,theStellareportdetails
andanalyzestheprocessowsofnoveltechniquesforsingle-ledgerDvPandcross-ledgerDvP,
basedonHashTimeLockedContracts.ThemainndingsincludethatDLTsoeranewapproach
forachievingDvPbetweenledgers,whichcouldgiverisetoadditionalchallengesintermsofsafety
andeiciencythatwouldneedtobeaddressed.
InOctober2018,theBankofCanada,incollaborationwithCanadiannancialinstitutionsand
technologicalcompanies,publishedtheresultsofthethirdphaseofProjectJasper.
Theproject
focusedonaPoCforaDLT-basedintegratedsecuritiesinfrastructureprovidingDvPsettlementto
helpre-imaginethepaymentexchangeprocessofCDSX-Canada’sclearingandsettlementsystem
forsecurities.JasperPhaseIIIsuccessfullydemonstratedthataDLTplatformcanbeusedfora
paymentandsecuritiessettlementsystem.
InNovember2018,theMonetaryAuthorityofSingaporepublishedtheresultsofthethirdphase
ofProjectUbin.
Ubinwaslaunchedin2016toexploretheuseofBlockchainandDLTinthenancial
system,andthethirdphaseanalysedtheDvPcapabilitiesforthesettlementoftokenizedassets
acrossdierentblockchainplatforms.TheprojectdemonstratedthatDvPsettlementnality,inter-
ledgerinteroperability,andinvestorprotectioncanbeachievedthroughspecicsolutionsdesigned
andbuiltonblockchaintechnology.Albeittheprojectonlyprovidesahigh-leveldescriptionofthe
dierentDvPmodels,notingtheimportanceofanarbitratorfordisputeresolution.Section
discussesitsimportanceinguaranteeingthesafetyofdierentDvPmodels.
InDecember2020,theBISInnovationHub,theSwissNationalBankandthenancialinfrastruc-
tureoperatorSIXannouncedtheconclusionoftherstphaseofProjectHelvetia.Theexperiments
demonstratedthefunctionalfeasibilityandlegalrobustnessofsettlingtokenizedassetsintwo
dierentways,bymeansoftwodierentexperiments.Therst,withawholesaleCentralBank
DigitalCurrency(CBDC)andthesecondbylinkingaDLTplatformtotheexistingcentralbank
paymentsystem.
Asecondphase,completedin2022,focusedspecicallyonwholesaleCBDC.
InMarch2021,DeutscheBörse,DeutscheBundesbankandGermany’sFinanceAgencypublished
theresultsofanexperimentinwhichtheydevelopedandsuccessfullytestedasettlementinterface
forelectronicsecurities,workingwitharangeofothermarketparticipants.Securitiessettlement
8SeeBankofCanada
etal.
9SeeMAS
etal.
10SeeBISInnovationHub
etal.
digitalcurrency.
InDecember2021,BanquedeFrance,theBISInnovationHubSwissCentre,theSwissNational
BankandaprivatesectorconsortiumannouncedProjectJura
,whichexploresthedirecttransfer
ofEuroandSwissFrancwholesaleCBDCsonasingleDLTplatformoperatedbyathirdparty.
TokenizedassetanddigitalcurrenciesaresuccessfullysettledonaDLTusingsingle-ledgerDvP
mechanisms.
Ourdocumentspecicallyfocusesoncross-ledgerDvPsasidentiedintheStellaPhase2report.
Section
identiesfourmainmodelstoachievecross-ledgerDvP,andanalysesthemindetail
acrossanumberofdierentdimensions.TheDvPmodelsarealsodividedintotwocategories,
namedorchestratedDvPmodelsandAPI-basedDvPmodels.AmongAPI-basedDvPmodels,this
documentpresentsanovelsolutionthat,besidesbeingDLTagnostic,introducestheroleofthe
DvPoracle,atrustedentitywhichguaranteestheDvPsafetyincaseofdisputesbetweenBuyer
andSeller.Fortwoofthesemodels(thenovelAPI-basedandanorchestratedone),theanalysis
isalsocomplementedwithpracticalexperimentthatinvolvestheTIPSpaymentsystemandthe
AlgorandDLT(seeSection
).Similarlytootherworks,thispaperalsoconcludesthatitispossible
toestablishatechnologicalbridgebetweenaDLTandaconventionalpaymentsystemforthe
settlementofsecuritiesincentralbankmoney.Furthermore,thispapershowsthatAPI-basedDvP
modelscanbemadeDLT-agnosticwithadvantagesintermsoftheeortrequiredtodevelopand
integratethemwithmultipleandheterogeneousDLTs.Incontrast,theorchestratedDvPmodels
canrelyonspecicDLTcapabilitiestoprovideadditionalfunctionality(seeSection
DvPIntegrationModels
Thissectionpresentsvariousmodelsforcross-ledgerDvP.Eachmodelisassessedagainstasetof
relevantdimensionsofanalysisdescribedinSection
.Beingcross-ledgerDvPthescopeofthis
work,thisdocumentconsidersascenariowheretheasset-legofeachDvPtransactionissettledon
aDistributedLedgerTechnology(DLT)onwhichtheassetisissued,whereasitscash-legissettled
onaPaymentSystem(PS).ForeachDvPtransaction,therearetwoinvolvedcounterparties,named
BuyerandSeller.BuyerandSellerhaveagreedtoexchangeagivenamountofsecuritiesagainst
paymentincash.Theexchangeneedstotakeplacewithinagiventime,whichhasalsobeenagreed
uponbythetwocounterpartiesanddepends,amongotherfactors,alsoonthelatencyofthePS
andDLTinstancesadopted.Thedetailsofhowthistradingagreementbetweenthepartiesiscarried
outisoutofthescopeofthiswork.Thissectioninsteadfocusesonhowtoachieveatomicityof
thecashpaymentonthePSanddeliveryofsecuritiesontheDLT.ItisassumedthatbothBuyer
andSellercanaccessthetwosystems,eitherdirectlyorviaatrustedintermediary(e.g.,abank).
ForeachDvPmodel,an
InteroperabilitySolution
isdescribed:thisisasystemcomponentthat
needstobedevelopedinordertofacilitatetheDvPinthatspecicmodel.Itisassumedthatthe
InteroperabilitySolutioncanaccessthePSand(ifneeded)theDLT.Moreover,theInteroperability
SolutioncanhaveaccountsonthePS,and(ifneeded)anodeandawalletontheDLT.Itisalso
assumedthattheInteroperabilitySolutionisoperatedbythecentralbankthatalsooperatesthe
PS.Inthereferencescenario,thePS,theDLT,andtheInteroperabilitySolutionaretrusted,i.e.,they
arenotsubjecttopersistentcrashorByzantinefailuresanddonotdeviatefromtheirexpected
behaviour.Inparticular,allDvPmodelsassumetooperateinabsenceofforksontheDLT,because
eithertheDLTis
forkless
(e.g.,whendeterministicconsensusprotocolsareadoptedasusually
thecaseofpermissionedDLTs)oritishighlyimprobabletorevertconrmedtransactions(e.g.,
duetothediicultyofperforminga
†‚
%attack).Itisalsoassumedthatcommunicationchannels
amongthedierentactorsareweaklysynchronous,i.e.,maybesubjecttounpredictabledelays
11SeeDeutscheBörse
etal.
12SeeBanquedeFrance
etal.
thatdonotgrowindenitely.Thisislikelytobetrueinaproductionsystemwithtransientnetwork
faults.Moreover,communicationchannelsaresecurewithexchangedmessagesassumedtobe
condentialandauthenticated,i.e.,noimpersonationattackcantakeplace.FourmainDvPmodels
areidentiedanddistributedintotwoclasses,namely”Orchestrated”and”API-based”.Intherst
twoDvPmodels(Sections
),theInteroperabilitySolutionisalsocalled
Orchestrator
becauseitcoordinatestheprotocolstepsonboththepaymentsystemandtheDLT.Intheothertwo
DvPmodels(Sections
),theInteroperabilitySolutionisalsocalled
APIGateway
,because
itcanbeseenasanextensionofthePSfunctionalities,bymeansofanApplicationProgramming
Interface(API),whichisindependentfromthespecicDLTtechnologiesadoptedfortheasset-leg.
Alistofrelevantdimensionsofanalysis
Thissectionpresentsanon-exhaustivelistofrelevantdimensionsforanalysingtheDvPintegration
models.ThesolutionsdescribedinSections

willbeassessedagainstthesedimensions.
Somedimensionsshouldbeconsideredcrucialforthesuccessofthesolution,suchasthesafetyof
theDvP.OthersdealwithtechnologicalcouplingbetweentheInteroperabilitySolutionandtheDLT
platform,andmayaectthedevelopmentandmaintenancecostoftheanalysedsolution;these
dimensionsinclude,forexample,thezero-codesupportfornewDLTsorthesolutionagnosticism
towardstheDLT.Finally,therelevanceofsomeotherdimensionsdependsonthescenarioinwhich
thesolutionisdeployed.
DLTagnosticism.
ThecapabilitytoapplythesolutiontodierentDLTs/blockchain,under
minimalassumptionsandconsideringthatnothingisknownorcanbeknownaboutthecorrect
functioningandoperationoftheDLTplatform.ADLTagnosticsolutionallowstointeroperate
withanewDLT,notoriginallysupported,withoutrequiringnewdevelopmentsspecicallytied
tothatplatform.
NoDLTnodetooperate.
ThecapabilityofthesolutiontointeroperatewithaDLTwithout
requiringtomanageanodeforeachintegratedplatform.
NoDLTwallettoown.
ThecapabilityofthesolutiontointeroperatewithaDLTwithoutrequiring
toownawalletforthenativecrypto-assetoranyotherassetthatisissuedontheDLT.
PresenceofatrustedDvPoracle.
WhetherthesolutionguaranteesDvPsafetybyrelyingona
trustedoraclethat,actingimpartially,providestheoutcomeoftheDvPincaseofadispute.
Safety,atomicityguarantees,andpotentialDvPfailures.
Theguaranteesprovidedbythesolution
intermsofsafety,regardingtransactionatomicity(i.e.,all-or-nothingtransferofcashand
security)andfailureavoidanceincaseofunforeseenoperationalbehaviourfromoneorboth
partiesinvolved,orthenetworkconnectionbetweenthepartiesandtheplatform.
Liquidityeiciency.
Thecapabilityofthesolutiontoavoidlockingcashliquidity(i.e.inescrow-
likescenarios)untilthewholetransactioniscompleted.
Absenceofthefreeoption.
Whetherthesolutiondoesnotoer,tooneoftheinvolvedparties,
therighttochoosetonalisethetransactionornotwhilekeepingtheotherpartyengaged,
withoutcorrespondingafeeforthisright.
SpecicfeaturesrequirementsoftheDLT.
Whetherthesolutionreliesonfeaturesthatarespecic
ofaparticularDLT.WhileitisreasonabletoassumethataDLTshouldsupportwidespread
cryptographicprimitives(e.g.,SHA-256),constraintsuponspecicprogrammabilityfeaturesor
signaturealgorithmsoftheplatformareconsideredaspecicfeaturerequirement.
13Equivalentofacallorputoptionforfree.
OrchestratedDvPwithAsset-legLocking
ThemostsimpleDvPmodelintheDLTecosysteminvolvesanOrchestratorthatactsasanescrow
fortheasset-legandanarbitratoroftheDvPtransaction.Twovariantsofthisprotocolexist.Inthe
simplerone,theOrchestratoractsasanactualtemporarycustodianoftheasset,i.e.,itreceives
theassetfromtheSeller,anddeliversittotheBuyeruponevidenceofpayment.DuringtheDvP,
theOrchestratorhasexclusivecontrolovertheassetthathastobedelivered.
Inamoreadvancedone,theOrchestratorsharesthecontroloftheassetwithBuyerandSeller,
usuallyinanescrowarrangementthatusesa2-of-3thresholdsignature
,wherethe3possible
signersaretheBuyer,theSeller,andtheOrchestrator,andtwosignaturesarerequiredtotransfer
theasset.IfBuyerandSelleragreeamongthemontheresultoftheDvPtransaction,thenthe
Orchestratorisnotinvolved,sincenoarbitrationisneeded.Thisiswhathappensduringnormal
operation.Onthecontrary,ifadisputebetweenthecounterpartiesarises,eithertheBuyerorthe
Sellercaninvolvethearbitratorintheprocess(i.e.,theOrchestrator),inordertosolvethedispute
andreleasetheassetfromtheescrow.
Themoreadvancedprotocolisconsidered,wheretheOrchestratorsharescontroloftheassets
duringtheDvP.ThestepsofasuccessfulscenarioareillustratedinFigure
Step1
,theSeller
(andBuyer)initializetheDvPontheOrchestrator;in
Step2
,theSellertransfersthesecuritiestothe
escrow;in
Step3
,theBuyermakesthepaymentwithintheagreedtimeout;in
Step4
,theSeller
authorizesthetransferofthesecuritiesfromtheescrowtotheBuyer.InthisscenariotheDvPis
consideredcooperativelyexecuted,becausenoarbitratorwasinvolved.
Figure1
OrchestratedDvPwithAsset-leglocking,successscenario.
Potentialsettlementfailuresmayhappeninthescenarioslistedbelow.
ˆ
InStep3,ifBuyerdoesnotcarryoutthepaymentwithintheagreedtimeout.Inthiscase,theBuyer
canauthorizethetransferofthesecuritiesfromtheescrowtotheSeller(cooperativecancellation).
Ifthisdoesnothappen,theSellerhastoinvolvetheOrchestrator,actingasarbitrator,tounlock
theassetsfromtheescrow.Inthislatestscenario,theDvPisconsideredforcedcancelled,because
thearbitratorhadtobeinvolved.
ˆ
InStep4,iftheSellerdoesnotauthorizethesecuritiestransferfromtheescrow.Inthiscase,the
Buyerhastoinvolvethearbitrator,thatacknowledgesthepaymentandtransferstheassettothe
Buyer(forcedexecution).
14Multi-signature:
https://en.bitcoin.it/wiki/Multi-signature#Multi-signature_application_examples
DvPfailurescannothappeninthehypothesisthatBuyerandSelleractintheirowninterest,
andtheOrchestratoreventuallyfullsitsownresponsibilities.
ThisDvPmodelreliesontheOrchestratorasatrustedDvPoracle(D4),whichacknowledges
paymentsandreturns/transfersassetsontheDLT.Forthisreason,thesolutionisnotDLTagnostic
(D1)andthearbitratorhasfullvisibilityoftheDvPtransactionontheDLT.Thesolutionrequiresnew
developmentforeachnewDLTthatneedstobeintegrated,sincethearbitratorimplementation
dependsonthecharacteristicsoftheDLTthathoststheassets.Thearbitratoroperatesanodeon
theDLT(D2)andownsawallettosigntransactions(D3).SinceDvPfailuresareexcluded,safetyis
alwaysguaranteed(D5).Thesolutionlockstheasset-legonly,whilethecashisnotlocked(D6).
TheBuyerownsanoptiontobuytheasset,andmayrefusetocarryoutthepaymentinthesecond
step(D7).ThesolutiondoesnotrequirespecialfeaturestobesupportedbytheDLT(D8),sinceit
onlyrequiresstandardtransactions(intherst,simpler,variant)andathresholdsignatureescrow
(inthesecondvariant).
OrchestratedDvPwithCash-legLocking
Inthissection,weillustratetwomodelsthatrelyonthelockingofthecash-legoftheDvPtransaction,
inordertoensurethesafetyoftheDvP.TherstmodelreliesonanOrchestratorkeepingon-holda
pre-authorizedassettransfertransactionontheDLTuntilthepaymentoccurs;bydoingso,itcan
reducetheamountoftimeinwhichthecash-legislocked.Forthisreason,wecallthissolution”Just
InTimeLocking”ofthecash-leg,abbreviatedasJITL.ThesecondmodelreliesonanOrchestrator
actingasbridgecomponentthatcantransfervaluefromthePStotheDLT,andvice-versa,inthe
formofaNon-FungibleToken(NFT)
representingthecashontheDLT,withinthecontextofa
specicDvPtransaction.Wecallthissolution”TokenizedCash-legLocking”.
JustInTimeLockingofthecash-leg
TheJITLmodelusesapre-signedtransaction(orapackageoftransactions)thattransfersthe
securitiesfromSellertoBuyerontheDLT.Thetransactionisnotimmediatelybroadcastedtothe
DLTnetwork,butitisgiventotheOrchestrator,thatwillreleaseitonlywhentheBuyersuccessfully
reserves,onthePS,anamountoffundsneededtocarryoutthepayment.
Atokenisnon-fungiblewhenitisunique(i.e.,non-interchangeable)andcannotbedividedintotokenswithloweramounts.
Forthesereasons,theNFTcanbeusedwithinthecontextofaspecicDvPtransactiononly,andnotasageneralpurpose
cashtokenontheDLT.
Figure2
OrchestratedDvPwithJustInTimeLockingofthecash-leg.
AJITLDvPisillustratedinFigure
;thestepsofasuccessfulscenarioarethefollowing.In
Step1
,BuyerandSellerinitializetheDvPwiththeSellerprovidingtheOrchestratorwithavalid
andpre-signedDLTtransactionthateventuallytransfersthesecuritiesfromSellertoBuyeron
theDLT.
Step2
,Buyertransfers,withinatimeout,cashneededforthepaymenttoanescrow
technicalaccountownedbytheOrchestratoronthePS.In
Step3
,theOrchestratorbroadcasts
Seller’stransactiontotheDLTnetwork,andtheassettransfertotheBuyercompletesontheDLT.In
Step4
,theOrchestratortransferscashfromtheescrowtotheSelleraccountonthePS.
Potentialsettlementfailuresmayhappeninthescenarioslistedbelow,whileDvPfailurescannot
happeninthehypothesisthatBuyerandSelleractintheirowninterest,andtheOrchestrator
eventuallyfullsitsownresponsibilities.
ˆ
InStep2,Buyerdoesnotperformthepayment,orperformsthepaymentwithanincorrectamount.
Inthiscase,thetimeoutexpiresandeitherSellerorBuyercanrequesttheOrchestratortocancel
Thepre-signedtransactioncaneitherbeasimpletransferoftheassetfromSellertoBuyer,signedbytheSelleronly,ora
morecomplexatomicpackageofDLTtransactionssignedbySeller,BuyerandalsotheOrchestrator,includingtheissuance
andredemptionofacash-legrepresentationontheDLT.Forsakeofclarity,thissectionpresentsthesimplestmodel.In
Section
,itispossibletondtechnicaldetailsonamorecomplexvariantofthesamekind,thatprovidesadditionalsafety
guarantees(e.g.,incasethepre-signedtransactionleaksfromeithertheSellerortheOrchestrator,ortheircommunication
channel)buthasadierenttrade-o(e.g.,itrequirestheOrchestratortoownawalletontheDLT).
theDvP,deletethepre-signedtransactionand,ifnecessary,refundpartialcashpayments.
ˆ
InStep3,Seller’stransactiondoesnotgetconrmed,e.g.,becauseSellerspentthesecuritieson
theDLTinthemeantime.Inthiscase,theOrchestratorcancelstheDvPandreturnscashtoBuyer.
TheDvPprotocolreliesontheOrchestratorasatrustedDvPoracle(D4),whichhandlescash
transfersonthePS.Forthisreason,themodelisnotDLTagnostic(D1)andtheOrchestratorhas
fullvisibilityoftheDvPtransactionontheDLT.Themodelrequiresnewdevelopmentforeach
newDLTthatneedstobeintegrated,sincetheOrchestratorimplementationneedstovalidateand
broadcastDLTtransactions.TheOrchestratoroperatesanodeontheDLT(D2).Awallettosign
transactionsisnotneededbecausetheDLTtransactionisasimpletransferfromSellertoBuyer
(D3).SinceDvPfailuresareexcludedbythepresenceoftheoracle,safetyisalwaysguaranteed
(D5).ThisDvPmodellocksthecash-legforthetimethatisneededforthesecuritiestransactionto
conrmontheDLT(D6).NeitherBuyernorSellerownanoptiontobuy/selltheasset,andbothcan
causethethirdsteptofail(D7).ThemodeldoesnotrequiresspecicfeaturesontheDLTside:only
theabilitytotransferanassetisneeded.SincetheSellergivesavalidandpre-signedtransaction
toathirdparty,itwouldbedesirabletheabilitytodeneself-expiringtransactions,sothattheDLT
canautonomouslypreventassettransfersaerexpiration(D8).
TokenizedCash-legLocking
MostDLTsallowparticipantstoissueassetsontheledgerintheformoftokens,whicharedier-
entfromthenativeassetoftheledger.
Fortheseledgers,itbecomespossibletoachievean
orchestratedDvPwithcash-leglocking.
Atthebeginningoftheprocess,theBuyerreservesanamountofcashthatisneededforthe
paymentoftheasset,e.g.,bytransferringittoanaccountcontrolledbytheOrchestrator.Then,the
Orchestratorissues,ontheDLT,aspecialtokenthatrepresentsBuyer’sfunds,andtransfersthis
tokentotheBuyer.Thetokenisnon-fungible(i.e.,anNFT),andcanbeusedonlyinthecontextof
thespecicDvPtransactionforwhichitwasissued:BuyercaneithertransferthetokentoSeller,
whichinturnwillreturnittotheOrchestrator,ortheBuyercandirectlyreturnthetokentothe
Orchestrator.ThetransferofthetokenfromBuyertoSellerhappenscontextuallywiththetransfer
oftheassetfromSellertoBuyer,directlyontheDLT.Forthistohappensafely,theDLTmustprovide
supportforSingleLedgerDvP
.Ultimately,SellercanclaimthefundslockedbytheOrchestrator,
bytransferringthereceivedtokenbacktoit:thiswillreleasethefundsfromtheescrowandcredit
Seller’saccount.
Thestepsofasuccessfulscenarioofthecash-leglockingwithtokenizationarethefollowing.In
Step1
,BuyertransferscashneededforpaymenttoatechnicalaccountownedbytheOrchestrator
onthePS.In
Step2
,OrchestratorissuestheNFTontheDLT,andtransfersittoBuyer.In
Step3
,Buyer
andSellerengageinasingleledgerDvPbetweenassetandcashNFT.In
Step4
,Sellertransfersthe
NFTtotheOrchestrator.In
Step5
,OrchestratortransferscashfromthetechnicalaccounttoSeller,
andPScreditsSeller’saccountofthepaymentamount.
Potentialsettlementfailuresmayhappeninthescenarioslistedbelow,whileDvPfailurescannot
happeninthehypothesisthatBuyerandSelleractintheirowninterest,andtheOrchestrator
eventuallyfullsitsownresponsibilities.
ˆ
AtStep3,ifBuyerandSellerdonotengageinthesingleledgerDvP;BuyercanreturntheNFTto
theOrchestrator,togetitsaccountcredited.
ThenativeassetofaDLTisheredenedastheoneusedtopaythetransactionfeestotheDLTconrmationnetwork;
examplesarebitcoinfortheBitcoinblockchain,etherfortheEthereumblockchain,andalgofortheAlgorandblockchain.
ExistingDLTsoerthreemaintechnicalsolutionstoimplementasingleledgerDvP.SomeDLTs(e.g.,AlgorandChen
etal.
)oerdedicatedprimitivestoswapoftwoassetsdenedontheledger.Fromtheuser-developerperspective,thisis
thesimplersolutiontoadopt.OtherDLTs(e.g.,BitcoinNakamoto,
)allowtocreateandsignasingletransactionwith
dierentassettypesintheinputsandoutputs.DLTswithexpressivescriptlanguages(e.g.,EthereumButerin,
)oera
moregeneralapproachwiththecreationofdedicatedsmartcontracttoencodetheswaplogic.
ThisDvPmodeldoesnotrelyonathirdpartyactingastrustedDvPoracle(D4),becauseit
modelstheDvPassingle-ledgerDvPthattakesplaceontheDLT.TheDvPisperformedasanatomic
transaction,wheretheatomicityisguaranteedbytheDLTfunctioning.Forthisreason,theDLT
recallsthefunctionalitiesofaDvPoracle;nevertheless,itisnotconsideredassuch,becausethe
DvPoracledenitionincludesonlythirdparties(i.e.,itexcludesthePSandtheDLT).Forthisreason,
themodelisnotDLTagnostic(D1)andtheOrchestratorhasfullvisibilityontheDvPtransaction
ontheDLT.ThemodelrequiresnewdevelopmentforeachnewDLTtobeintegrated,sincethe
OrchestratorimplementationdependsonthecharacteristicsoftheDLThostingtheassets.The
OrchestratoroperatesanodeontheDLT(D2)andownsawallettosigntransactions(D3).Since
DvPfailuresareexcluded,safetyisalwaysguaranteed(D5).ThisDvPmodellocksthecash-leg,
potentiallywithindenitetime,soitisnoteicient(D6).NeitherBuyernorSellerownanoptionto
buy/selltheasset,andbothmaydecidetonotexecutethethirdstep,i.e.,thesingleledgerDvP
(D7).ThemodelrequirestheDLTtosupportissuanceoftokenizedandnon-fungibleassets,aswell
asfunctionalitiesforsingle-ledgerDvP(D8).
API-basedDvPwithHash-TimeLockedContract
ThisDvPmodelreliesonAPIGateway,whichissittinginfrontofthePSandexposesadditional
functionalitiesbymeanofAPIs.TheAPIgatewayoperatesatechnicalaccountonthePS,whichcan
receiveandholdfundstobetransferredfromBuyertoSeller.Italsoenablesthesecureexchange
ofmessagesfromSellertoBuyer.WecallthisDvPmodelAPI-basedDvPwithHTLC,becauseit
leveragesHashTimeLockedContracts(HTLC
,Poon
etal.
)onthePSandDLTtoregulate
boththecashandsecuritiestransfer.AnHTLCisaspecialcontractthatiswidelyavailableonDLTs;
itenablestime-boundedconditionaltransfers.Besidesactingasanescrow,itcombinestwotypes
oflocks:hash-lockandtime-lock.Thehash-lockallowsunlockingthefunds(orassets)inescrowby
providingacorrectsecretphrase(referredtoas
preimage
)withinanagreedtimeout.Thetime-lock
addsanexpirationtimetotheescrow.Therecipientofthefunds(orassets)lockedwithinthe
escrowshouldclaimthembeforeexpiration.
Otherwise,theoriginalsendercanclaimbackthe
funds(orassets).
AnAPI-basedDvPwithHTLCisillustratedinFigure
;thestepsofasuccessfulscenarioare
thefollowing.In
Step1
,theSellerrandomlygeneratesapreimageandkeepsitsecret;then,they
calculateacommitment
ofthepreimage(e.g.,itscryptographichash).In
Step2
,theSeller
transferssecuritiesfromhisaccounttoanHTLContheDLT.TheHTLClockssecuritiesonthe
commitment
untilatimeout
Timeout
‚
expires;In
Step3
,usingtheAPIgateway,theBuyermoves
fundsfromhisaccounttoatechnicalHTLCaccountonthePS.TheHTLClocksfundsonthesame
commitmentusedforthesecurities,untilatimeout
Timeout
ƒ
(with
Timeout
ƒ
Timeout
‚
)expires;
Step4
,theSellerclaimstheBuyer’sfundsprovidingthepreimagetotheAPIgateway:thefunds
movefromtheHTLCaccounttotheSelleraccountonthePS.TheAPIgatewaytimelynotiesthe
Buyerandprovideshimwiththepreimage.In
Step5
,leveragingthepreimage,theBuyercanunlock
theSeller’ssecuritiesfromtheHTLCandmovesthemtohisaccountontheDLT.
Potentialfailuresmayhappeninthescenarioslistedbelow.
ˆ
InStep3,theBuyerdoesnotmovefundstothetechnicalaccount.Thisresultsinasettlement
failure.However,theSellercangetbackhissecuritiesassoonas
Timeout
‚
expires.
ˆ
InStep4,theSellerdoesnotclaimtheBuyer’sfundswithin
Timeout
ƒ
.Asettlementfailureoccurs.
TheBuyercangetbackhisfundsassoonas
Timeout
ƒ
expires,and,assoonas
Timeout
‚
expires,
theSellercanalsogetbackthesecurities.
19HashTimeLockedContracts:
https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts
Inablockchain,thetime-lockcaneitherbeexpressedintermsofminimumnumberofblockstobeconrmedfromthelock
transaction(relativetime-lock)orwithablockchainheight(absolutetime-lock).
Figure3
API-basedDvPwithHTLC,successscenarioandcriticalDvPfailurescenario.
ˆ
InStep5,theBuyercannotclaimthesecuritiesbefore
Timeout
‚
expires.ADvPfailureoccurs,
resultinginacriticallossofintegrity.TheDvPsafetyiscompromised,becausetheSellercan
collectboththefundsandthesecurities.Itisimportanttohighlightthatthisfailuremaymateri-
alizeforexternalcauseswhichdonotdependontheBuyer.Inparticular,atemporarynetwork
unavailabilityonthecommunicationchannelbetweentheAPIandtheBuyer,maypreventthe
BuyertotimelyreceivethecashtransfernoticationinStep4.Moreover,adelayonthecommu-
nicationchannelbetweentheBuyerandtheDLT,maypreventtheBuyertotimelysendtheasset
transferrequestinStep5.Amitigationtechniqueforthisriskistoset
Timeout
‚
reasonablyhigh,
asafunctionoftheprincipalamount:allotherfactorsbeingequal,ahigheramountimpliesa
higherriskandrequiresalongertimeout.Notethatthetimeoutvaluedeterminesatrade-o
betweensafetyandeiciencyintheDvPprocess:alongertimeoutincreasessafetybutdecreases
eiciency(duringtheDvPtheassetislockedintheHTLCandcannotbetransferredbytheSeller),
whileashortertimeoutincreaseseiciencybutcanbedetrimentalforsafety.
ThismodelfacilitatestheDvPsettlementbyintroducingspecicAPIsinfrontofthePS.The
modelisDLTagnostic,anddoesnotrequirenewdevelopmentforsupportingnewDLTs(D1).There-
fore,itdoesnotrequiretooperateanodeontheDLT(D2),ortoownawallettosigntransactions
(D3).ThismodeldoesnotrelyonatrustedDvPoracle(D4);asadirectconsequence,itintroduces
criticalfailuresthatcompromisetheDvP(step5):thesafetyoftheDvPtransactionisnotalways
guaranteed(D5).TheweaknessofthismodelrevolvesaroundtheideaofsolvingtheDvPusing
timeoutsinsteadofarbitrators:forthisreason,afailuretodeliveragiveninstructionwithinagiven
timeoutmaycauseaDvPfailure(seeProjectStella,
,sectiononDvPfailure).TheAPI-based
DvPwithHTLCsolutionlocksthecash-legforthetimethatisneededforconrmingthesecurities
transaction(D6).TheSellerownsafreeoption,astheycanunlocksecuritiesbynotclaimingthe
Buyer’sfundsinthethirdstep(D7).ThemodelrequirestheDLTtosupportHTLCfunctionalities
(D8).
Anadvantageofthismodelisthatitallowsparticipantstoreuseanexistinghashvaluetocreate
anHTLClinkedwithotherDvPtransactionsusingthesamehashvalue.Insuchaway,relatedDvP
transactionsacrossmultipleledgerscanbecreated.Thischaracteristicmayenableadditional
applications,suchascross-borderpayments,thatarehoweverbeyondthescopeofthiswork.
Therecentdenitionoftheadaptorsignaturescheme
hasintroducedanalternativewayofde-
ningthisDvPmodel.Inparticular,anadaptorsignaturecanbeusedinplaceofthehashpreimage,
tolinkthecashandassettransfer.Adaptorsignaturesrelyonellipticcurvecryptography.Thesmart
contractsthatuseadaptorsinsteadofhashvaluesarecalledPoint-TimeLockedContracts(PTLC),
wherethepointonacurveisapublickeyagainstwhichthesignatureisveried.Theadoptionof
PTLCsinplaceofHTLCsimprovesthecondentialityoftheDvPonpublicledgers,becausethelogic
underlyingthesmartcontractcanbehiddeninthesuccessscenario,sothattheassettransaction
appearsindistinguishablefromaregulartransferontheDLT.However,theadoptionofPTLCsdoes
notchangethesafetyconsiderationsregardingthisDvPmodel:NotintroducingatrustedDvP
oracle,itadmitscriticalDvPfailuresthatcouldcompromisethesafetyofDvPtransactions.
API-basedDvPwithHash-LinkContract
ThissectionpresentsanovelDvPmodelthatreliesonanAPIgatewaytosimplifytheDvPdenition
andsettlement.TheAPI-basedDvPwithHash-LinkContractbuildsupontheprimitivesofan
HTLC,andintroducesatrustedoracle,asintheorchestratedmodels,thatsolvespossibledisputes
betweenBuyerandSeller.TheinvolvementofatrustedoracleallowstoguaranteethesafetyofDvP
transactions,alsoincaseoftemporaryunavailabilityofoneoftheinvolvedactors(and,inparticular,
oftheAPIgatewayitself).TheAPIgatewayplaystheroleoftrustedDvPoracle.Thismodeldenes
Hash-LinkContract
(HLC)ontheDLTthatlockssecuritiesuntilsomespecicconditionsaremet.
Fromabusinessperspective,theseconditionsarethefollowing:(i)theBuyeragreesonthereturn
ofsecuritiestotheSeller,or(ii)theSelleragreesonthetransferofsecuritiestotheBuyer,or(iii)
thereisadisputebetweenBuyerandSellerandtheoracleisinvolved.Theknowledgeofpreimages
isusedtosignalthedecisionoftheoracle,thathasexclusiveknowledgeoftwopreimages,namely
cancellationpreimageandexecutionpreimage.IftheDvPoracledecidestosolvethedisputein
favouroftheSeller,e.g.,becausethepaymentdidnotoccurwithinanagreedtimeout,thenit
revealsthe
cancellationpreimage
totheSeller,whichinturnusesittogetbackthesecuritiesfrom
theHLC.Onthecontrary,iftheDvPoraclesolvesthedisputeinfavouroftheBuyer,e.g.,because
thecorrespondingpaymentdidalreadyoccur,thenitrevealsthe
executionpreimage
totheBuyer,
whichusesittoclaimthesecuritiesfromtheHLC.
21Adaptorsignaturescheme:
https://bitcoinops.org/en/topics/adaptor-signatures/
Figure4
API-basedDvPwithHash-LinkContract.
AnAPI-basedDvPwithHLCisillustratedinFigure
;thestepsofasuccessfulscenarioarethe
following.In
Step1
,theSellerinitializesaDvPtransactionbyinteractingwiththeAPIgateway.The
lattergeneratesthetwopreimagesandcommunicatestheircommitment(e.g.,acryptographic
hash)tobothBuyerandSeller.Toresolvepossiblefuturedisputes,theAPIgateway,actingas
oracle,startsatimerforthecurrentDvP,whichexpiresaccordingtotheinformationreceived.
Step2
,theSellertransferssecuritiesfromhisaccounttoanHLContheDLT.TheHLClocks
securitiesuntilitisprovidedwithavalidsignature(fromeithertheSellerortheBuyer)orapreimage
(eitherexecutionorcancellation).UnlockingwiththeSeller’ssignatureortheexecutionpreimage
movesthesecuritiestotheBuyer’saccountontheDLT.UnlockingwiththeBuyer’ssignatureorthe
cancellationpreimagetakesbackthesecuritiestotheSeller’saccountontheDLT.In
Step3
,using
theAPIgateway,theBuyermovesfundsfromhisaccounttotheSeller’saccountonthePS.TheAPI
gatewayreadilynotiesbothBuyerandSellerofthecorrectcompletionofthefundsreserve.In
Step4
,theSellerunlockstheHLCtomovesecuritiestotheBuyer’saccountontheDLT.Thiscaseis
called
cooperativeexecution
,becauseBuyerandSellercollaboratetosuccessfullycompletethe
DvPtransaction.
Potentialsettlementfailuresmayhappeninthescenarioslistedbelow.DvPfailurescannot
happeninthehypothesisthatBuyerandSelleractintheirowninterest,andtheAPIgateway
eventuallyfullsitsownresponsibilities.TheAPIgateway,actingasDvPoracle,guaranteesthe
protocolsafety,alsoincaseoftemporaryunavailabilityofinvolvedactorsandarbitrarydelayson
thecommunicationchannels.
ˆ
InStep3,theBuyerdoesnotmovefundstotheSeller’saccountonthePS.Thisresultsina
settlementfailure.TheSellercangetbackhissecuritiesbyretrievingthecancellationpreimage
fromtheAPIgatewayassoonasthetimeoutexpires.Thiscaseiscalled
forcedcancellation
ˆ
InStep4,theSellerdoesnotcollaboratewiththeBuyertoopentheHLC.TheBuyercanobtain
theexecutionpreimagefromtheAPIgatewayandcollectthesecuritiesfromtheHLContheDLT.
Thiscaseiscalled
forcedexecution
TheAPI-basedDvPwithHash-LinkContractmodelintroducesthepresenceofatrustedDvP
oracleforsolvingdisputesbetweenBuyerandSeller(D4).Usinghashpreimagesinsteadofdigital
signaturesallowstomaintainaverylowlevelofcouplingbetweenAPIgatewayandDLT.Thismodel
isDLTagnostic,anddoesnotrequirenewdevelopmentforsupportingnewDLTs(D1).Therefore,
thismodeldoesnotrequiretooperateanodeontheDLT(D2),ortoownawallettosigntransactions
(D3).TheAPIgatewayonlyneedstosupportthesamehashfunctionoftheDLTplatform.Dierently
fromtheAPI-basedDvPwithHTLC,thisDvPmodelguaranteesthesafetyoftheDvPtransaction
(D5).ThisDvPmodellocksonlytheasset-legforthetimeneededforconrmingthefundstransfer
transaction(D6).TheBuyerhasthefreeoption,astheycanavoidtransferringfundsinthethird
stepdescribedabove,whiletheSellerhasalreadyengagedthesecuritiesintheHLC(D7).The
modelrequirestheDLTtosupportHLCfunctionalities(D8).
SummaryofDvPmodelsanalysis
Inthissection,thedierentDvPmodelsarecomparedagainstthedimensionsofanalysisintro-
ducedinSection
.Table
summarizestheresults.Noticethatthedierentdimensionsarenot
equallyimportant.First,ifaDvPmodeldoesnotguaranteesettlementsafety(D5),itwillbehardly
consideredforanactualDvPimplementation.Thisis,forexample,thecaseoftheAPI-basedwith
HTLCmodel.Second,thedimensionsassessingtheneutralityofthemodelandthecouplingwith
theDLTplatform(D1,D2,D3,D8)areprioritized.Forexample,theDLTagnosticismcanbeuseful
whenitenablestheintegrationofnewDLTswithaverylimitedeort,thusavoidingtheneedof
developingnewDLT-specicadapters.DedicateddevelopmentfornewDLTcouldslowdownthe
integrationprocess,thusindicatingalessextensiblesolution.TheneedfortheInteroperability
SolutiontoownawalletforthenativeDLTcrypto-assetisalsoarelevantdownside,becauseitintro-
ducesstrongcouplingwiththeDLT.Also,theneedforspecicfeaturescouldaecttheneutralityof
theInteroperabilitySolutionOperator.However,specicDLTfeaturesmightbenecessarytoimple-
mentaDvPmodel,suchastheabilitytodeploycontracts,non-fungibleassets,orperformatomic
transfers.Third,otherdimensionsthataecttheDvPcostforparticipantsareconsidered,suchas
theliquidityeiciency(D6)andtheabsenceofthefreeoption(D7).Finally,otherdimensionssuch
aspresenceofatrustedoracle(D4),arelessimportantinthespecicscenarioconsideredinthis
document.Overall,thereisnotasingleDvPmodelthatdominatesalltheothers.TheDvPmodels
usinganOrchestratorenablesafetyandcanbeadoptedwhenatightercontrolofwhathappenson
theDLTisdesirable.Nevertheless,thesemodelshavehighercouplingwiththeDLTplatformand
requirehighereortonthedevelopmentside.ToimprovetheInteroperabilitySolutionoperator
neutralitywithrespecttoDLTs,API-basedDvPwithHLCappearsasthemostsuitedDvPmodel.
Table
belowsummarisestheanalysisoftheDvPmodelspresentedinthissection.
Table1
SummaryoftheDvPmodelsanalysis.
Dimensions
Asset-leg
locking
Justintime
cash-leg
locking
Tokenized
cash-leg
locking
Hash-Time
Locked
Contract
Hash-Link
Contracts
D1:DLTagnosticism
D2:NoDLTnodetooperate
D3:NoDLTwallettoown
D4:UseofaDvPoracle
D5:SafetyoftheDvP
D6:Liquidityeiciency
D7:Nofreeoption
D8:SpecicDLTfeatures
ThiscolumnshowstheanalysisforthesimplestJITLmodelonly.Othermodelsmaydierin:(i)theneedtoholda
walletontheDLT,(ii)theneedforspecicDLTfeatures,suchastokenissuanceandsingleledgerDvP,(iii)additionalsafety
guaranteesinscenarioswithamorepowerfuladversarialmodel;
Cash-legislockedonlyforthetimerequiredforthe
assettransfer;
Thresholdsignatureswallet;
Tokenissuanceandsingle-ledgerDvP;
HashfunctionsandTime-locked
transactions;
Hashfunctionsonly.
Experiment
TheexperimentaimstodevelopandevaluateProof-of-Concept(PoC)solutionsforsecureexecution
ofaDvPbetweenadistributedledgerandapaymentsystem,hostingrespectivelyassetsandcash.
Section
introducestheactorsandsystemsinvolvedinthePoC:theTargetInstantPayment
Settlement(TIPS)systempresentedinSection
,whichprovidesthesettlementservicesof
theDvPcash-leg;theAlgorandblockchain,presentedinSection
,wheretheasset-legofthe
DvPresides.AmongthedierentDvPintegrationmodels,twoofthemwereselectedforadeeper
investigation:Section
presents”TIPSHash-Link”,aninstanceoftheAPI-basedDvPwithHash-
LinkContractmodel;Section
presents”TIPS-AlgorandJustInTimeLocking”,aninstanceof
theOrchestratedDvPwithJustInTimeLockingmodel.Theformerrepresentsaloosely-coupled
solutionthatdoesnotrequireanyconnectionwiththeDLT.Thelatterrepresentsasolutiontailored
foraspecicDLTand,assuch,requiresatight-coupledintegrationandalsotooperateanodeon
theDLT.
Actorsofacross-ledgerDvP
Theexperimentconsidersatypicalcross-ledgerDvPscenarioinwhichaSellerandaBuyer,interact
toexchangeassetsonaDLTforcashonapaymentsystem.Figure
representsthetwoinvolved
actors,togetherwiththeassetandcashledgers:theAlgorand
DLTimplementstheplatform
holdingtheasset-leg,whileTIPSimplementstheplatformholdingthecash-legoftheDvP.Buyer
andSellerowntheassetsontheDLTthankstoprivatekeysstoredintheirrespectivewallets,
representedinblue.
22Thename”Algorand”isusedtorepresentthenetworkofnodescollectivelyoperatingtheDLT.
Figure5
Actorsofacross-ledgerDvP:SellerownsassetsontheAlgorandDLTandwantstosellthemtoBuyer
foranagreedamountincash;thecash-legresidesonaseparateledger,i.e.,ontheTIPSsystem.
TheTargetInstantPaymentSettlementSystem(TIPS)
Inthisexperiment,thepaymentsystemisinstantiatedastheTargetInstantPaymentSettlement
(TIPS
)platform,whichprovidesthesettlementservicesofthecash-leg.TIPSwasselected,
amongtheothermarketinfrastructuresownedbytheEurosystemsuchasTarget2,forits365/24/7
operationalmodel,whichmostcloselyresemblestheserviceoeredbyaDLTplatform.
TIPSmanagescommercialbanks’accountsandregulatescentralbankmoneyowsamong
theseaccounts.Customers(e.g.,BuyerandSeller)havenovisibilityonTIPSandcannothold
accountsinit:theycanonlyaccesstheTIPSservicesthroughacommercialbankactingasatrusted
intermediary.TheinteractionwithTIPStakesplaceviatheMessageExchangeProcessingforTIPS
(MEPT,4CB,
)protocol.WithoutlossofgeneralityoftheDvPmodels,andonlyforthescopeof
thisexperiment,asimplifyingassumptionisconsidered:thePoCassumesthatBuyerandSeller
havedirectaccesstothesettlementservicesprovidedbyTIPS,theyownaTIPSaccountandhave
(directorindirect)accesstoit.BuyerandSelleraccountsareusedtomovetheliquidityforthe
cash-legoftheDvPtransactions.
TherealizationofthePoCrequiredthesetupofadedicatedTIPSprocessingenvironment.The
newenvironmentwasimplementedwithintheBankofItaly’sPrivateCloudinfrastructure(Figure
andinheritedallthecharacteristicsoftheproductionone.Fromaphysicalpointofview,theTIPS
environmentofthePoCwasdistributedoverthreedatacenters,thuscreatingan
active-active
architecturethatreplicatesthecomponentsoftheTIPSsettlementengineasintheproduction
environment.Virtualmachineslocatedineachdatacenterhosttheapplicationcomponentsand
themiddlewarenecessaryfortheconstructionoftheTIPSsettlementengine.Allvirtualmachines
havebeencreatedusingtheAPIexposedbythePrivateCloudplatform,whichinturnisbasedon
OpenStack.
23SeeRenzetti
etal.
andArcese
etal.
TheAlgorandDLT
Algorand
isapermissionlessandpublicblockchainfoundedin2017bytheACMTuringAward
winnerandMITprofessorSilvioMicalianddevelopedbytheAlgorandFoundation
andbyAlgorand
Inc.,acompanybasedinBoston.ThisPoCbenetedfromacollaborationwithexpertsfrom
Algorand,whoprovidedadviceonthebestuseofconstructsandspecicfeaturesoftheDLT.
Algorandconsensus.
Algorandusesa
PureProofofStake
(PPoS)consensusprotocoltoupdatethe
distributedledger.ThePPoSalgorithmallowsAlgorandtoconrmtransactionsandupdatethe
blockchainwithlatencyintheorderofsecondswhilescalingtomanyusers.PPoSleveragesa
novel
ByzantineAgreement
protocoltoreachconsensus,whichisaimedtoensureahighlevelof
security
withoutlackingin
scalability
decentralization
Algorandensuresthatusersnever
havedivergentviewsofconrmedtransactions(i.e.itensuresthatforksdonotoccur),evenifsome
oftheusersaremaliciousandthenetworkistemporarilypartitioned.
Algorandinfrastructure.
Tointeractwiththeblockchain,auser(e.g.,Buyer,Seller)mustoperatea
DLTnode,whichactsasapeeroftheAlgorandblockchainnetwork.Tosimplifyresourcedemand,
lightweightnodesexist:theyactonlyasaclientofthenetworkanddonotdirectlyparticipatein
theconsensusprotocolthatgrowsthechain.ThisexperimentadoptsanAlgorandnodehosted
byPurestake
.Furthermore,tosigntransactionsandoperateupontheirassets,auserholdsa
pairofpublic/privatecryptographickeys;whenatransactionissignedwiththeuser’sprivatekey,
theauthorshipisclearandcannotberepudiated.Toimproveprivacy,ausercanholdmultiple
public/privatekeys.Awallethelpstostoresuchkeysandsimplifytheprocessoftransactionsigning.
Algorandledger.
Algorand’snativeasset,i.e.,theassetthatisusedtopaytransactionfeesin
theAlgorandledger,iscalledthe
.ByholdingAlgos,userscanalsoregistertoparticipatein
consensus,whichmeansthattheywillparticipateintheprocessofproposingandvotingonnew
blockstogrowthechain.TheAlgorandfunctionalitiesincludethecreationofnon-nativeassets
ontheblockchain,calledAlgorandStandardAssets(ASA).AnASAcanbeconguredtorepresent
eitherafungibleoranon-fungibletoken(i.e.,NFT)and,inaddition,allowtransferrestrictionsto
beplacedonit.BeforeanewASAcanbetransferredtoaspecicuser,thereceivermust
opt-in
receiveit.
TheAlgorandledgerorganizesthestateusingaccounts(account-basedledger),which
liveontheblockchainandareassociatedwithspecicon-chaindata,e.g.abalance;anAlgorand
addressisusedtoidentifyanAlgorandaccount.Theaccount-basedorganizationoftheDLTstatein
AlgorandsmoothlytswiththeabilitytorunsmartcontractstoupdatetheDLTstate.
Algorandprogrammability.
TwomainformsofprogrammabilityexistinAlgorand:smartcontracts
andsmartsignatures.
Smartcontracts
arepiecesofcodedeployedontheDLT,whichhavepublic
addresses,andcanholdaninternalstate.Theirexecutionistriggeredbytransactionsdirected
totheiraddress.Theirbusinesslogicoenincludespre-conditionsandactions,whoseoutput
leadstointernalstateupdateortofunds/assetstransfer.Thesmartcontractlogicisexecutedby
theDLTnodes,anditsstateisalsokepton-chain.Runningthesmartcontractlogicrequiresthe
paymentoffees,whosevalueisproportionaltotheamountofoperationsperformed.
Instead,
storingthestaterequirestheescrowofaminimumbalancethatwillbereturnedaerclearingthe
state.A
Smartsignature
isaprogrammablelogicexecutedwhilespendingatransaction.Itcan
24SeeChen
etal.
https://algorand.foundation/about-us
https://algorand.foundation/algorand-protocol/about-algorand-protocol/pure-proof-of-stake
https://www.algorand.com/technology/white-papers
https://www.purestake.com/
https://developer.algorand.org/docs/get-details/asa/
https://developer.algorand.org/tutorials/understanding-teal-opcode-budget/
https://developer.algorand.org/docs/get-details/dapps/smart-contracts/#smart-signatures
bethoughtasanaccountwhoseprivatekeyincludesthesourcecode:knowledgeofthesource
codeisanecessaryconditiontoissueatransactiononbehalfofthesmartsignatureaccount.The
transactionwillbesuccessfullycompletedonlyifthesmartsignatureallowsit:e.g.,byhard-coding
thetransactionbeneciaries,asmartsignaturecanenforcepaymenttowardstheiraccountsonly.
SmartsignaturesdonotstoreadditionalstateontheDLTbutthetransactionitself.Theycanbe
usedtodeneescrowsaswellasdelegatesignatureauthority.Forthisreason,theyareusually
createdwithadisposablesemantic.Aninstanceofasmartsignatureiscreatedfromatemplate
withalimitedscope,e.g.,inthecontextinvestigatedinthisdocument,toserveasingleDvP.Serving
alimitednumberofactors,smartsignaturesarealsolessriskythansmartcontracts:anexploitin
asmartcontractwouldaectallusersinteractingwithit.Smartcontractsandsignaturescanbe
writteninaprogramminglanguagecalledTEAL,orinhigherlevellanguagesuchasPython,thatis
thencompiledtoTEAL.ThecompiledTEALprogramproducesanAlgorandaddressandaprivate
key,called
LogicSignature
.Thelattercanbeusedtoevaluatethebusinesslogicwhilespendinga
transaction:thetransactionisallowedwhenitevaluatestoTrueagainsttheTEALlogic.
TIPSHash-LinkContractDvP
ThissectiondescribesthePoCimplementingtheAPI-basedDvPwithHash-LinkContractmodel
describedinSection
,sittingbetweentheTIPSandAlgorandplatformsintroducedinSection
ThecorecomponentofthePoCistheTIPSGateway,representedinFigure
,whichimplements
theHash-Linkspecicfunctionalities.
Figure6
TheTIPSHashLinkproofofconcept.
TIPSGateway
SowareArchitecture.
TheTIPSGatewayisamodularapplicationwritteninJava,andcomposedof
thefollowingmodules:
ˆ
APIController
exposesthefunctionalitiestoinitializetheDvP(asinStep1),toforwardpay-
mentsmessagestothepaymentsystem(asinStep3),andto
force
eitherthecancellationorthe
executionoftheDvP.Italsoexecutespreliminarychecksonthevalidityofthereceivedmessages,
andtranslatesthemintothecorrespondingeventsthatwillbeinternallyforwardedtotheEvent
Manager.TheAPIisdesignedtobe
asynchronous
:whenthecontrollerreceivesarequest,it
dispatchesthecorrespondingeventtotheEventManager,andsendsaresponsebacktothe
client,indicatingthattherequesthasbeensuccessfullyreceivedandtakenincharge.Theresult
oftherequest,onceready,willbesentbackviaacallbackURLprovidedbytheclient.
ˆ
EventManager
overseestheoverallDvPows,coordinatingtheinteractionswiththeother
systemsaswellasBuyer’sandSeller’sclient.Itisanasynchronouscomponentthatactivates
uponreceptionofinternalevents.ThisallowstoeasilyscaletheTIPSGatewaywhenthesystem
isoverloaded.
TheEventManagermanagestheDvPphasesasfollows:inthe
initialization
phase
(Step1),itcreatesanewDvPdescriptorlledwithauniqueDvPidentier,execution
andcancellationpreimages,SellerandBuyeridentiersandstoresitusingtheDataLayer.
Tocomputethepublicpreimagecommitments,TIPSGatewayusestheSHA2hashfunction.
Finally,tosolvetheDvPincaseofdispute,theeventmanagerstartsatimerthatlockstheDvP
forapredenedamountoftime(i.e.,timelock).Inthe
paymentphase
(Step3),theBuyerpaysthe
Sellerthroughgateway,whichforwardstherequesttotheTIPSsystem.Then,itupdatestheDvP
instanceaccordingtotheTIPSresponse,andnotiesBuyerandSellerofthepaymentoutcome.
Inthe
forcedexecutephase
,itqueriesTIPStogetinformationabouttheexistenceofapayment
withaspecicidentierand,ifitexists,itprovidestheexecutionpreimagetotheBuyer.Inthe
Forcedcancellationphase
:itchecksthatthetimeoutprovidedfortheDvPisexpired.Ifitis,it
queriesTIPStogetinformationaboutthepaymentwiththespecicidentier.Ifitdoesnotexist,
itpreventsanyfuturepayment,forthespecicDvPid,frombeingenteredand,nally,itprovides
thecancellationpreimagetotheSeller.
ˆ
DataLayer
providesprimitivestostoreandretrieveaDvPdescriptor,whichholdsinformation
regardinganinstanceofDvPtransactionbetweenSellerandBuyer;theDvPdescriptorstores
dataandmetadatasuchastheDvPandassetsidentiers,preimagesandtimelocks.TheData
LayerallowsdecouplingthepersistencelayerfromtheothercomponentsofTIPSGateway.
ˆ
PSLibrary
(PSLib)usesmessagequeuestocommunicatewithTIPS,eitherbysending
instructionsorbyreceivingmessagessignalingtheoccurrenceofeventsthatneedtobeforwarded
totheEventManager.Ithasbeendesignedtointroduceanabstractionlayeroverdierent
paymentsystems,andtodeneasimpleinterfacethatmasksthelogicneededtooperateona
specicone.
GatewayApplicationProgrammingInterface(API).
APIController
exposessimpleAPIsenabling
userstoaccesstheTIPSGatewayfunctionalities,whilecontrollingtheexposedobjectsandac-
tions,andhidingtheunderlyingimplementationdetails.TodesigntheTIPSGatewaywithease
ofinteroperabilitywithexistingstandards,theAPIControllerhasbeendesignedconsideringtwo
principles:REST-likeAPIdenitionandcompliancewithstandardsfordatatransmission.The
REST-likeAPIdenitionallowstosimplifytheBuyer/SellerinteractionwiththeTIPSGateway.Due
totheasynchronousnatureofthecommunication,thedesignedAPIsareasynchronousaswell:
theyreturnHTTPresponsestatuscodes,informingwhethertherequesthasbeentakeninchargeor
not.ToreceiveTIPSGatewayanswers,thecustomersarerequestedtoexposespecicendpoints.In
arealworldscenario,theseendpointscanbehostedbyatrustedparty(e.g.,acommercialbankas
currentlyoccursforpaymentsmanagedbyTIPS);however,inthisexperiment,nointermediariesare
consideredbetweenBuyer/SellerandTIPS.ThedesignedAPIsacceptapayloaddenedaccording
tothedesignprinciplesofthepan-Europeaninteroperabilitystandardforpaymentsystemsdened
byTheBerlinGroup
.Moreover,theAPIstakeintoaccounttheworkconductedsofarwithinthe
Inanasynchronousapplication,commandsareencapsulatedineventsthatarestoredininternalqueues,waitingfor
workersableofexecutingthem.
TheexperimentusesSHA2(Dang,
),althoughotherhashfunctionscanbeusedaslongastheDLTsupportsthem(e.g.,
Dworkin,
,whichisalreadysupportedbyseveralDLTs,includingAlgorand).
TheBerlinGroup(
https://www.berlin-group.org
)isapan-Europeanpaymentsinteroperabilitystandardsinitiativeand
FinancialStabilityBoard(FSB)Stage3Roadmap
.Specically,businessinformationiscarried-out
byISO20022
)messages.Thispromisestoeasilysupportfutureservicesand
needs.Also,theusageofISO20022messageswouldallowasimpleconnectivitythroughexisting
NetworkServiceProvidersforTIPS,whichoerconnectivityservicesviaXMLmessage.Moredetails
abouttheAPIscanbefoundinAppendix
.WhentheAPIControllerreceivesarequest,itperforms
apreliminaryvalidationandtranslatesitintoaninternaleventthatwillbeforwardedtotheEvent
Manager.Whiledoingso,theAPIControllersendsanHTTPresponsebacktotherequestclient,
indicatingthattherequesthasbeensuccessfullytakenincharge(i.e.,
202ACCEPTED
statuscode).
Otherwise,anerrorcodeisreturned.
Infrastructure.
Fromaninfrastructurepointofview,theTIPSGatewayisdeployedinBankofItaly
privatecloud.
AlgorandHash-LinkContract(HLC)
TheimplementationofTIPSHash-Linkisquitestraightforwardbecauseithasalowcouplingwith
theDLT:TheTIPSGatewaymanagesthecreationofexecutionandcancellationpreimages,and
acceptspaymentsfromBuyer;TheSellerisinchargeofcreatingtheHLContheAlgorandDLT;The
Buyerhastoperformthepayment,andthencompletetheDvPinacooperativeorforcedmanner.
ParticularlyinterestingfortheAlgorandsideofthisDvPmodelistheStep2,inwhichtheSeller
transferstheassetsfromhisaccounttoanHLC,actingasanescrowandmanagingtheassets-leg
settlement.ItisimportanttonotethattheHLCdenitionliesoutsidetheresponsibilityperimeterof
theTIPSGateway,anditsdevelopmentcanbeleentirelytothemarket.Neverthelessanexample
ofsuchsmartcontracttemplatefortheAlgorandblockchainisprovidedtothereaderinthissection
asareference.
OnAlgorand,theHLCcanbeimplementedusingeitherasmartcontractorasmartsignature,
andthisPoCimplementsHLCusingsmartsignatures.Specically,anHLCiscreatedusingaTEAL
templatewiththefollowingparameters:
,addressofSelleraccountonAlgorand;
,addressof
Buyeraccount;
,hashofexecutionpreimage;
,hashofcancellationpreimage;
TIPS_GW_TX_ID
DvPidentiergeneratedbyTIPSGateway;
APIframeworkwiththeaimofdeningopenandcommonschemesthateverypaymentsystemshouldadopttoreacha
concreteharmonization.
FinancialStabilityBoard(FSB)Stage3RoadmapandinparticulartheBuildingBlock15HarmonisingAPIprotocolsfordata
exchangeisastandardizationapproachforthedenitionofaglobalstandardfortheAPIappliedtothecross-borderusage.
https://www.fsb.org/
ƒƒ
‚
/enhancing-cross-border-payments-stage-
„
-roadmap
https://www.iso
ƒƒƒ
https://developer.algorand.org/docs/get-details/atomic_transfers
AtomicTransfer
PayTx
amount

ƒ‚
receiver
Seller
OptInTx
asset
:asset
LogicSig
AssetTransferTx
asset
:asset
receiver
Seller
TheDvPcompletesontheDLTwithoneofthefollowingscenarios:cooperativeexecution,
cooperativecancellation,forcedexecution,or,alternatively,forcedcancellation.
CooperativeExecution
,Sellerisnotiedaboutthepaymentandpublishesatransactionon
AlgorandtomovetheassetsontheBuyer’saccount.InAlgorand,thisrequirestocreateanatomic
transferwiththreetransactions.Therstisatechnicaltransaction(withamount0)neededto
encodethroughthedigitalsigner,theSeller’swillingnesstoperformtheoperation.Thistransaction
piggybacks(usingthenote
eld)theDvPidentier.Thesecondtransactionmovesassetstothe
Buyer.ThethirdtransactiongivesbackthedeposittotheSeller.Thisatomictransferalsocloses
theHLCaccount:theDvPisindeedcompleted.
AtomicTransfer
PayTx
amount

receiver
Seller
AssetTransferTx
asset
:asset
receiver
Buyer
LogicSig
PayTx
amount

receiver
Seller
LogicSig
CooperativeCancellation
,BuyerandSellerjointlyagreetoaborttheDvP.TheBuyersubmits,
totheAlgorandDLT,anatomictransfertoreturntheassetstotheSeller.Thisatomictransfer
looksliketheoneusedincooperativeexecution,withthetransactionsignerandassetsreceiver
accordinglyset:Buyersignsthetransaction;Sellerreceivestheassets.
ForcedExecution
,theBuyerqueriestheTIPSGatewaytoobtaintheexecutionpreimage.TIPS
GatewaycheckswithTIPSwhetherthepaymenthasbeenperformedbytheBuyerfortheDvP.Ifso,
itreturnsthepreimage.TheBuyercannowsubmitanatomictransferontheDLTtounlockthe
assetsfromtheescrowbyprovidinghissignatureandtheexecutionpreimagetotheHLC.Alsoin
thiscase,theatomictransferincludesthreetransactions:TherstrunstheHLCwiththeBuyer
signatureandthecancellationpreimage;thesecondtransferstheassets;thelastreturnstheHLC
deposittotheSeller.
https://developer.algorand.org/docs/get-details/transactions/transactions/#common-elds-header-and-type
AtomicTransfer
PayTx
amount

receiver
Buyer
AssetTransferTx
asset
:asset
receiver
Buyer
LogicSig
PayTx
amount

receiver
Seller
LogicSig
ForcedCancellation
,theSellerqueriestheTIPSGatewaytoobtainthecancellationpreimage.
TIPSGatewaycheckswhethertheDvPtimeoutisexpired.Ifitisexpired,thegatewayinteractwith
TIPStocheckwhetherBuyerperformedthepayment.Ifthepaymentdoesnotexist,TIPSprevents
anyfuturepaymentsfortheDvP.Hence,TIPSGatewayreturnsthecancellationpreimagetothe
Seller,whocansubmitanatomictransfertounlocktheassets.Theatomictransferincludesthree
transactions:TherstrunstheHLCwiththeSellersignatureandthecancellationpreimage;the
secondtransferstheassetstotheSeller’saccount;thelastreturnstheHLCdeposittotheSeller.
FurtherdetailsontheHLCdesigncanbefoundinAppendix
TIPS-AlgorandJustInTimeLockingDvP
ThissectiondescribesthePoCimplementingtheJustInTimeLockingDvPmodeldescribedin
Section
,whereaDvPOrchestratorcoordinatesoperationsbetweentheTIPSandAlgorandplat-
formsintroducedinSection
.ThecorecomponentofthePoCisthe
TIPS-AlgorandOrchestrator
representedinFigure
,whichimplementsthebusinesslogictocarryouttheDvP.
Figure7
Tips-AlgorandJITLproofofconcept.
TIPS-AlgorandOrchestrator
SowareArchitecture.
Fromasowaredeveloperpointofview,theorchestratorapplicationisa
modularsowarewritteninJava,andcomposedofthefollowingmodules:
ˆ
APIController
exposesthefunctionalitiestoinitializetheDvP(asinStep1)andtoforward
paymentsmessagestothePS(asinStep2).Italsoexecutespreliminarychecksonthevalidityof
thereceivedmessages,andtranslatesthemintothecorrespondingeventsthatwillbeinternally
forwardedtotheEventManager.
ˆ
EventManager
handletheeventscomingfromothersowaremodules(e.g.theAPIcon-
troller),andmanagestheDvPows,orchestratingtheinteractionswiththeothersoware
components.Inthe
initializationphase
(Step1)itcreatesanewDvPdescriptor,withanewunique
identier,andstoresit.Then,itpreparesanatomictransferskeletonwhosetransactionsmust
eachbesignedbythecorrespondingDvPactors(seedetailslaterinthesection).Inthe
execution
phase
(Step2andStep3),ittriestoreservethebuyerfundsonTIPS.Ifthereservecompletes
successfully,itsignstheremainingtransactionsinthepackage,andsubmitsittotheDLT.Once
thetransactionshavebeennalizedonDLT,theEventManagerproceedswiththeconrmation
ofthetransactiononTIPS.IfanyerroroccursbetweenthereserveonTIPSandthetransaction
nalizationontheDLT,arejectandcancellationrequestwillbesendtoTIPS.Finally,inthe
cellationphase
,iftheDvPtimeoutexpiresbeforethepaymentoccurs,thentheEventManager
destroysthetransactionssignedduringtheinitializationphasetopreventfurtherDvPexecutions.
AsdetailedinSection
,byoverseeingtheDvPsettlement,theTIPS-AlgorandOrchestration
hastobeatrustedcomponentofthesystem.
ˆ
DataLayer
,isusedtostoreandretrieveDvPrecordsinthedatabase,inparticularthepre-
signedDvPtransactionsthataredeliveredtotheorchestratorbyBuyerandSellerinStep1ofthe
process.
ˆ
PSLibrary
(PSLib),usesmessagequeuestocommunicatewithTIPS,eitherbysending
instructionsorbyreceivingmessagessignalingtheoccurrenceofeventsthatneedtobeforwarded
totheEventManager.
ˆ
DLTLibrary
(DLTLib),isanewsowaremoduledevelopedfortheexperimentphase,which
providesanhigh-levelabstractionlayeroverdierentDLTs.Thelibrarydenesasimpleinterface
thatmasksthelogictooperateonaspecicDLT.InteractingwithaDLTusuallyintroducesboth
somecomplexity,andoen,aformalismwithtechnicaldetailsthatarespecictothechosen
DLT.Forexample,eachDLTinteractionusuallyimpliestheexecutionofsometransactionsthat
needtobeformedwithaspecicDLTformalisminmind.Inordertokeepthesowaremodular
andmaintainable,theimplementationoftheDLTintegrationlogichasbeengroupedwithina
libraryandabstractedtotheabovelayers.ThisallowsexposinganhighlevelAPI.Thecurrent
DLTlibimplementationsupportsAlgorand,andusestheAlgorandJavaSDK
Infrastructure.
TheTIPS-AlgorandOrchestratorisdeployedintheBankofItalyprivatecloud,just
likethePS.IthastodirectlyreachtheAlgorandnetwork:tothisenditcommunicateswithan
AlgorandnodehostedbyPurestakethroughthepublicInternet.Finally,italsomanagesawallet
fortheAlgorandblockchain,thatisusedtosigntransactions,aswewilldetaillater.
AlgorandAtomicTransfer
ThisPoCimplementsanimprovedversionoftheprotocol,whichmodiesthepre-signedtransac-
tionusedintherststepoftheJITLDvPmodel.Thepre-signedtransactionisactuallyimplemented
asapackageoftransactions,whichareexecutedatomicallyontheAlgorandDLTusingits
atomic
transfer
functionality.
TheDvPpackageiscomposedbyasetofseventransactions,whosepurposeisthetransferof
theassetsandaLockedLiquidityASA(LLA),representingreservedfundsontheAlgorandDLT:
ˆ
TherstandthesecondensurethatBuyerandSellerareentitledtotheownershipoftheLLA
39AlgorandJavaSDK:
https://developer.algorand.org/docs/sdks/java/.
(opt-in);
ˆ
ThethirdtransferstheLLA,initiallyownedbytheTIPS-AlgorandOrchestratorinitsownwallet,
totheBuyer;
ˆ
ThefourthandthehtransactionsrepresenttheactualDvP:theyrespectivelytransferstheLLA
fromBuyertoSeller,andtheassetsfromSellertoBuyer;
ˆ
ThesixthtransferstheLLAfromSellertotheTIPS-AlgorandOrchestrator;
ˆ
Finally,theseventhtransactiondestroystheLLA.
ThepackageoftheatomictransfertransactionsisgeneratedbytheTIPS-AlgorandOrchestrator
andinitiallysignedonlybyBuyerandSeller.Thepartiallysignedpackageistransferredtothe
Orchestrator(Step1),whichwillinturnsigntheremainingunsignedtransactions,justbefore
Buyer’sfundsarereserved(Step2).Then,theOrchestratorbroadcaststhenalversionofthe
atomictransfertotheDLTnodesforconrmation(Step3).Theactualtransferoftheassetstakes
placethankstothehtransaction,whilealltheothertransactionsarenecessarytoensurethat
theLLAcirculatesfromTIPS-AlgorandOrchestratortoBuyer,fromBuyertoSeller,andfromSeller
backtotheOrchestrator,whichnallydestroysit.Inthisway,itisnotpossibletousetheLLA
outsideofaspecicDvP.WhentheatomictransferisprocessedbytheDLT,theTIPS-Algorand
Orchestratorproceedswiththeconrmationofthepaymentdependingontheatomictransfer
result:thepaymentisperformedonlyiftheDLTsuccessfullyconrmsallthetransactionsinthe
atomictransfer.
Thefollowingdiagramshowsthedetailsofthepackageoftransactionscomposingtheatomic
transferjustdescribed,usedinthePoC.Thesubscriptattheendofeachtransactionindicates
thetransactionsender,whichcoincideswithitssigner.TheuseofaLLA,andthepackageof
transactionsinplaceofasingletransactionthatsimplytransferstheassetfromSellertoBuyer,
furtherimprovesthesecurityofthearrangement,becauseitalwaysrequiresanadditionalsignature
fromtheOrchestrator.Adrawbackofthisapproachisanincreasedcomplexityofthetransaction,
thatrequirestheuseofanASA.
AtomicTransfer
OptInTx
asset
Buyer
OptInTx
asset
Seller
AssetTransferTx
asset
receiver
Buyer
Orchestrator
AssetTransferTx
asset
receiver
Seller
Buyer
AssetTransferTx
asset
asset
receiver
Buyer
Seller
AssetTransferTx
asset
receiver
Orchest
Seller
AssetDestroyTx
asset
Orchestrator
TestsandResults
Inordertoshowthefeasibilityofthedesignedsolutionsandanalyzesomespecicows,thetwo
implementedDvPmodelsweretested.Section
presentsasuiteoftestcasesevaluatedforboth
theDvPsolutions:testcasesinvestigatethenormaloperation(i.e.,cooperativeexecution)aswell
asexceptionalows(i.e.,forcedexecution,forcedcancellation,failures,duplicaterequests).
TogetaroughideaoftheDvPsolutions’performances,Section
presentsasimplederivation
ofthroughputandcomplexityofTIPSHash-Link(T-HL)andTIPS-AlgorandJust-in-timeLocking
(TA-JITL).Wecombinedthisapproachwithsystematiclatencymeasurements,aimingatreaching
robustconclusionsregardingperformances.
Testscenarios
ForTA-JITLthetestsmainlycoveredtheTIPSGatewaycomponentbecauseitmanagesthewhole
logic.InT-HL,instead,alsothesmartcontractwastested,butinaseparatedway,becauseitis
thoughttobeindependentandwithadierentownershipfromtheTIPSGateway.Alsocomplete
end-to-endtestswereexecutedinbothprotocols.ForT-HLtheyonlycoveredtheinitialization
phaseofallusecasesandthenalphasesof
forced
usecasesonly:
cooperative
onesarebased
uponanagreementbetweenbuyerandseller,externaltoTIPS,andthendonotneedtheTIPS
Gatewayinterventionforthenalphases.
RegardingtheTIPSGateway,thedesignedtestscenariosdependontheavailableoperations
oeredbythespecicintegrationmodel.Sincethetwomodelsaredierent,alsothetestcases
needtobedierent.Inparticular,fortheHash-Linkprotocol,thetestscenariosdependonthe
followingoperations:initialization,payment,forcedexecutionandforcedcancellation.FortheTA-
JITLprotocol,instead,thetestscenariosarerestrictedtothreeoperations:initialization,execution
andcancellation.Theonlycommonelementisthewaythetestswereexecuted.Inordertofacilitate
thisstepanad-hocsowaremodulewasdeveloped.ItiswritteninJavaandprovidesacontroller
thatexposesasetofAPIsthatallowtomanagetheseveralowstobetested.Itorchestratesthe
invocationstotheBuyerandSeller,triggeringtheneededactionstimeaertime.
Tables
listthetestcasesexecutedforHash-LinkandJust-In-TimeLockingrespectively.
Therstcolumncontainsabriefdescriptionofthescenario,theInitialstatecolumnisthesetof
theconditionsthathastobemetbeforetheeventspeciedinthecolumnActionistriggered,and
intheExpectedresultcolumnisdescribedwhathastohappeninorderforthetesttocomplete
withouterrors.
Table2
Hash-Linktestcases.
Scenario
Initialstate
Action
Expectedresult
Badinit
init,wrongdata
Error:operationnotpermitted
Goodinit
NewDvPgenerated,hashedpreimagesreturned
Badcancellationaerinit
forcedcancellationbeforetimelock
Error,nopreimagereturned
Executionaerinit
init+nopay
forcedexecution
Error,nopreimagereturned
Goodcancellationaerinit
init+nopay
forcedcancellationaertimelock
Cancellationpreimagereturned
pay(beforetimelock)
PaymentforwardedtoTIPS,resultreturned
Payaertimelock
pay(aertimelock)
Error,paymentrejected
Doublepayment
init+pay
Error,paymentrejected
Cancellationaerpay
init+pay
forcedcancellation
Error,nopreimagereturned
Executionaerpay
init+pay
forcedexecution
Executionpreimagereturned
Cancellationaerexecution
init+pay+execution
forcedcancellation
Error,nopreimagereturned
Doubleexecution
init+pay+execution
forcedexecution
Executionpreimagereturned
Payaercancellation
init+cancellation
Error,paymentrejected
Executionaercancellation
init+cancellation
forcedexecution
Error,nopreimagereturned
Doublecancellation
init+cancellation
forcedcancellation
Cancellationpreimagereturned
ExecutionaerwrongpayinTIPS
init+paywrongdata
inTIPS
forcedexecution
Error,nopreimagereturned
ThiscaseevaluatestheTIPS-GatewayabilitytocheckwhethertheBuyer’spaymentmatcheswhatwasagreedintheDvP
initialization.PaymentmismatchesmayoccuriftheBuyermaliciouslyperformsthepaymentinTIPSdirectly,without
interactingwiththeTIPS-Gateway,whichholdsDvP-relatedinformation.
Table3
Just-In-TimeLockingtestcases.
Scenario
Initialstate
Action
Expectedresult
Badinit
init,wrongdata
Error:operationnotpermitted
Goodinit
NewDvPgenerated,DLTtransactionsprepared
Badcancellationaerinit
cancellationbeforetimelock
Error:operationnotpermitted
Goodcancellationaerinit
cancellationaertimelock
Transactionsdeleted
Executionwithcash-legerror
cash-legerror
Error,datacleanedonTIPSandDLT
Executionwithasset-legerror
asset-legerror
Error,datacleanedonTIPSandDLT
Wrongexecutionaertimelock
executionaertimelock
Error,reservationrejected
Execution
executionbeforetimelock
DvPexecutedonTIPSandDLT
Cancellationaerexecution
init+execution
cancellation
Error:DvPinexecutedstate
Doubleexecution
init+execution
execution
Error:DvPalreadyexecuted
Executionaercancellation
init+cancellation
execution
Error:DvPincancelledstate
Doublecancellation
init+cancellation
cancellation
Error:DvPalreadycancelled
Regardingthesmartcontract,twowallets,representingtheBuyerandtheseller,werecreated
intheAlgorandTestNet
andwereusedtoexchangetheassetsontheDLT.TheDLToperations
involvingthetwoaccountsand,forTIPSHash-Link,theowsallowedbythesmartcontractwere
validatedusingAlgoExplorer
ascounterproof.Moreover,thesmartcontractwasalsotestedfrom
asecuritypointofview,tryingtomanipulateitwithasetoftamperingattempts:alltheexecuted
attemptsfailed,withoutcompromisingthesmartcontractandthenthecorrectnessofthenested
ows.MoredetailsaboutthesmartcontractcanbefoundinAppendix
Results
Thetwosolutionscanbecomparedfromaperformanceperspective.EveryDLThastwokeyper-
formanceindicators:blocktimeandblocksize.Theblocktimeisthetimebetweentwoconsecutive
blocksconrmations,whereastheblocksizeisthemaximumnumberoftransactionsthatcan
beaddedinasingleblock.CurrentlytheAlgorandDLThasablocktime(
)of4.5secondsanda
blocksize(
)of5000transactions.
Neglectingtheexecutiontimeanddelaysintroducedbythe
Buyer,Seller,andInteroperabilitySolution,thenalizationofaDvPrequirestwoblocks,bothfor
theT-HLsolutionandfortheTA-JITLsolution.AsdetailedinSection
,theT-HLprotocolrequires
theexecutionoftwoAtomicTransferoperations:onefortheHLCcreationandanotherfortheDvP
settlement;likewise,TA-JITLneedsablockforthecreationoftheLLA;oncetheLLAiscreated,its
identiercanbeincludedintotheatomictransferwithassetexchangeinasecondblock.Since
thersttransaction(i.e.,HLCorLLAcreation)canbebroadcastedimmediatelyaer(hence,witha
waitingtimeof
)orimmediatelybeforeablockispublished(withnowaitingtime):itsaverage
approvaltimeistherefore
‚
ƒ
,with
theblocktime.Topublishthesecondatomictransfer,it
isalwaysnecessarytowaitatleastforanotherblocktime
.Therefore,theaverageminimum
completiontime
oftheasset-legsettlementontheDLTisonaverage
„
ƒ
forbothsolutions:
‚
ƒ
UndertheassumptionthattheDLTisnotoverloaded,andBuyer,Seller,andtheInteroperability
SolutionsaretheonlyactiveactorsparticipatingintheDvP,themaximumDLTthroughputcan
becomputed.Themaximumthroughput(T)ofboththesolutionsdependsonthenumberof
transactions(
)requiredforeachDvP,thenumberoftransactionstheDLTcanincludeineach
Algorandoersthreepublicnetworkswheretheblockchainisdeployedwithdierentpurposes:MainNet,TestNet,and
BetaNet(
https://developer.algorand.org/docs/get-details/algorand-networks/
).ThisPoCusestheTestNet,whichallows
testingapplicationwiththecurrentversionoftheprotocolandrealisticnetworkconditions.
https://algoexplorer.io/
https://developer.algorand.org/docs/get-started/basics/why_algorand/#performance
block
,andontheblocktime
,asfollows:
GiventhatT-HLrequires6transactionstocompleteaDvP,whileTA-JITLrequires8transaction,
from(
)followsthattheformerhasatheoreticthroughputthatis
„„
%higherthanthelatter:
º
‡
‰
‰
‚
„

„„
Table
summarizestheoreticperformanceofthetwoDvPsolutions:T-HLandTA-JITL.Allthe
calculationsaretheoretical,andstrictlydependentontheAlgorandblocktime
andblocksize
Theyhoweverprovideameaningfulestimationoftheperformancesofthetwosolutions,since
theinteractionswiththeDLTaretheonlypartsoftheschemesneithertunablenorscalableinthe
scopeofthecurrentpaper.
Table4
TheoreticPerformanceofTIPSHash-Link(T-HL)andTIPS-AlgorandJust-in-timeLocking(TA-JITL).
PerformanceMetric
Averagecompletiontime(s)
Throughput(DvP/s)
Theimplementedvariantoftheprotocolwaspresentedforitssimplicity.Otherdenitionsthatreducethenumberof
requiredtransactionsimprovingbothperformancemetricscanbedened.
Theimprovementjustoftheblockchainparameters(
)wouldresultinbetterperformance
forthetwoDvPsolutions,bothintermsofminimumcompletiontimeandmaximumthroughput.
Discussion
Whileshowingsimilarperformanceintermsofaveragecompletiontime,T-HLresultsinhigher
throughput;thisismotivatedbytheusageoffewertransactionstocompletetheDvPwithrespect
toTA-JITL.Theexperimentoutcomeprovidesfurtherconrmationoftheopportunitiesoeredby
theadoptionofanAPI-basedDvPwithHash-LinkContractmodeltosolvecross-ledgerDvPswhile
keepingalowcouplingwiththeDLT,asdiscussedinSection
Theexperimentallowedalsotocomparethetwosolutionsagainsttheeortneededfortheir
realization.InadditiontohandlingthelifecycleoftheDvP,theTA-JITLprotocolrequiresthe
developmentofasowarecomponentthathasalsotomanagethewalletontheDLTandhasto
operateaDLTnodetoexecuteoperationsonit.Alltheseactivitieswouldbetheresponsibilityof
developersandmaintainersoftheInteroperabilitySolution.Theo-chaincommunicationamong
Buyer,Seller,andthetrustedoraclecouldbeoeredasanadditionalfeatureoftheInteroperability
Solution(e.g.,oeredbytheTIPSGatewayasdoneintheexperiment)orasavalue-addedthird
partyservice.Alsointhelattercase,theInteroperabilitySolutionneedstointeractwiththethird
party,thusincreasingitsfunctioningresponsibilitiesandworkload.TheTA-JITLsolutionisclosely
intertwinedwiththeAlgorandDLTsoastomakefulluseoftheAlgorandtechnicalfeaturesand
constructs.Althoughinteresting,thissolutionhassomepeculiaritiesthatcouldbelimitinginsome
usecases(e.g.,whentheInteroperabilitySolutionmustnotownawallet).
Beingamoregeneralsolution,T-HLpromisesaneasyintegrationwithotherDLTtechnologies,
asitrequiresneitherdirectDLTinteractionnorwalletmanagement.Thisisarelevantkeypointfor
acentralbankthataimstopreserveneutralitybynotclingingtospecictechnologiesorsuppliers.
Nonetheless,T-HLassumesasoliddenitionoftheHLCtemplate,whichiscrucialtoavoidDvP
threatsorfailures.Tothisend,HLCtemplatesshouldbecarefullydeveloped,extensivelytested,
andthenconvenientlysecured.Theseactivitiescouldbeperformedbyathirdpartyservice.The
PoCdoesnotfocusonthedenitionofasolidHLCtemplate,beingoutsidetheresponsibilityofthe
InteroperabilitySolutiondevelopers.Conversely,TA-JITLusesonlysimpleDLTtransactions,which
requiretheDvPactorstopayspecialattentiononlytothetransactionstobesigned.Inasense,
T-HLshisthecomplexityoftheasset-legsettlementonthesmartcontractdenitioninsteadof
thetransactionorchestrationsperformedbyTA-JITL.
Conclusions
Thispaperinvestigatesdierentinteroperabilitymodelsforacross-ledgerDvP,betweenassets
residingonaDLT,andthecashresidingontheledgerofadierentpaymentsystem(e.g.,operatedby
acentralbank,forsettlementincentralbankmoney).Inparticular,fourDvPmodelsareidentied,
andclassiedaccordingtowhethertheInteroperabilitySolutionactsasagatewayforthepayment
system,orasaDvPorchestratorbetweenthepaymentsystemandthedistributedledger.The
dierentmodelsareanalyzedacrossdierentdimensions,includingamongtheotherstheDLT
agnosticism,presenceofatrustedDvPoracle,safety,liquidityeiciency,absenceofafreeoption.
Theanalysisfavoredcash-leglockingeiciency-asmoneyisexchangedmorefrequentlythan
assets-whichshouldbeachievedwithoutanyparticulardeteriorationasthenumberofconnected
DLTsincreases.
Aerwards,thepaperdescribesadetailedexperiment,whichinstantiatesthepaymentsystem
asTIPS(forprovidingthesettlementservicesoftheDvPcash-leg),andtheDLTastheAlgorand
blockchain(forregulatingtheasset-legoftheDvP).TheexperimentimplementstwoPoCfortwo
dierentDvPmodels:TIPSHash-LinkisaninstanceoftheAPI-basedDvPwithHash-LinkContract
model;andTIPS-AlgorandJustInTimeLockingisaninstanceoftheOrchestratedDvPwithJustIn
TimeLockingmodel.
TheexperimentconrmedthefeasibilityofthechosenDvPmodelsasviablesolutionsfor
enablinginteroperabilitybetweenaDLTandtheEurosystemMarketInfrastructures.
Forboth
solutions,theabilitytoaddressapotentiallyextendeduseofdigitalassetmanagementservices
withcentralbankmoneysettlementserviceshasemerged.Theexibilityoeredbythesemodels
allowsthemtobeappliedtoretailbusinesscases,takingintoconsiderationthenewongoing
experimentbeingconductedwithexternalmarketplayers,suchasABI
Inthecurrentcontextofgrowinginterestintransactionsinvolvingtheexchangeofdigital
assetssuchasstablecoins,securitytokens,non-fungibletokensandsoonthisexperiment
demonstratedapossibleusageofcentralbankmoneyforcashsettlement.Inparticular,the
proposedimplementationscaneectivelycontributetosaferandmoreeicientsettlementof
DvPtrades,enablinginteroperabilitywithawidearrayofDLTplatformsanddierentdegreesof
integrationeortcomparedtootheralreadyestablishedapproaches.
TheimplementedsolutionspreservetheatomicnatureofaDvPtransaction,buildingabridge
betweentheDLTassetmanagementplatformandthecentralbankpaymentsystem.Inaccom-
plishingthistask,thisarchitectureoersthepotentialtostandardizecommunicationswithDLTs
and,crucially,avoidtheneedtoissuecentralbankmoneyascashtokensonDLTsakeypointof
otherapproachesthuspreservingthecentralbank’scontroloverthecash-legoftheDvP.
Adoptingsuchapproachescouldoertheopportunitytobuildservicescapabletosettletrans-
Thisinordertocreateapaymentsolutionthatcomplementstheexistingone,forassetsandbusinesscasescurrentlynot
currentmarkettrends,inacomparativelyshortertimeframethanapproachesrequiringthedeni-
tionofanativedigitalcentralbankmoney(i.e.,acashtokenizationapproach)onselforthird-party
operatedDLTs,whichcouldbettertamediumorlongtermsolutionfromtheperspectiveofthe
Eurosystem’smarketinfrastructures.
importanceofgettingthechangesapprovedbytheunderlyingcommunities.
References
4CB.(2019).
MessageExchangeProcessingforTIPS(MEPT)
(tech.rep.).InternationalOrganizationforStand-
ardization.
https://www.ecb.europa.eu/paym/target/tips/profuse/shared/pdf/TIPS_MEPT_-
_Message_Exchange_Processing_for_TIPS_-_v
‚
ƒ
_nal_rev.pdf
Arcese,M.,DiGiulio,D.&Lasorella,V.(2021).Real-TimeGrossSettlementsystems:breakingthewallof
scalabilityandhighavailability.(2021-02).
https://www.bancaditalia.it/pubblicazioni/mercati-
infrastrutture-e-sistemi-di-pagamento/approfondimenti/
ƒƒ‚
ƒ
ƒ
-MISP.pdf
BankofCanada,TMXGroup,PaymentsCanada,Accenture&R3.(2018).
JasperphaseIII:SecuritiesSettlement
usingDistributedLedgerTechnology
(tech.rep.).PaymentsCanada.
https://www.payments.ca/sites/
default/les/jasper_phase_iii_whitepaper_nal_

BanquedeFrance,BISInnovationHub,SwissNationalBank&aprivatesectorconsortium.(2021).Project
Jura:cross-bordersettlementusingwholesaleCBDC.
https://www.bis.org/about/bisih/topics/cbdc/
jura.htm
BISInnovationHub,SwissNationalBank&SIX.(2018).
ProjectHelvetiaPhaseI:SettlingTokenisedAssetsin
CentralBankMoney
(tech.rep.).BISInnovationHub.
https://www.bis.org/publ/othp
„†
Buterin,V.(2014).
Anext-generationsmartcontractanddecentralizedapplicationplatform
(tech.rep.).Eth-
ereumFoundation.
https://ethereum.org/en/whitepaper/
Chen,J.&Micali,S.(2019).Algorand:ASecureandEicientDistributedLedger.
TheoreticalComputerScience
(100),155183.
https://doi.org/
‚
‚‚‡
/j.tcs.
ƒ‚Š
ƒ
‚
Dang,Q.(2015).SecureHashStandard.
https://doi.org/
‚
‡ƒ‰
/NIST.FIPS.
‚‰
…
DeutscheBörse,DeutscheBundesbank&Germany’sFinanceAgency.(2021).Dlt-basedsecuritiessettlementin
centralbankmoneysuccessfullytested.
https://www.bundesbank.de/en/press/press-releases/dlt-
based-securities-settlement-in-central-bank-money-successfully-tested-
‰‡‚………
Dworkin,M.(2015).Sha-3standard:Permutation-basedhashandextendable-outputfunctions.
https://doi.
‚
‡ƒ‰
/NIST.FIPS.
ƒƒ
ECB.(2010).Thepaymentsystem.
https://www.ecb.europa.eu/pub/pdf/other/paymentsystem
ƒ‚Š
en.pdf
ECB.(2022a).Glossary:Deliveryversuspayment.
https://www.ecb.europa.eu/services/glossary/html/glossd.
en.html
ECB.(2022b).Securitiestrading,clearingandsettlement.
https://www.ecb.europa.eu/stats/payment_
statistics/securities/html/index.en.html
IBM.(2022).Whataresmartcontractsonblockchain?
https://www.ibm.com/topics/smart-contracts
MAS,SGX,AnquanCapital,Deloitte&Nasdaq.(2018).
DeliveryversusPaymentonDistributedLedgerTech-
nologies:ProjectUbin
(tech.rep.).MonetaryAuthorityofSingapore.
https://www.mas.gov.sg/-
/media/MAS/ProjectUbin/Project-Ubin-DvP-on-Distributed-Ledger-Technologies.pdf
Nakamoto,S.(2008).Bitcoin:Apeer-to-peerelectroniccashsystem.
DecentralizedBusinessReview
https:
//bitcoin.org/bitcoin.pdf
Poon,J.&Dryja,T.(2016).
Thebitcoinlightningnetwork:Scalableo-chaininstantpayments
(tech.rep.).
LightningNetwork.
https://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_
smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf
ProjectStella.(2018).
SecuritiesSettlementSystems:Delivery-Versus-PaymentinaDistributedLedgerEnviron-
(tech.rep.).EuropeanCentralBankandBankofJapan.
https://www.ecb.europa.eu/pub/pdf/
other/stella_project_report_march_
ƒ‚‰
Appendices
Hash-LinkContract:ImplementationDetails
ThisappendixaimstoshowthestructureoftheHLCsmartcontractanddescribeshowtheexecution
resultofeachphaseisdisplayedonAlgoExplorer,atoolforbrowsingblocksoftheAlgorand
blockchain.Belowisshownthemainsectionofthesmartcontracttemplate.
return