 Couple of words about myself One is I'm the chair of the identity and Capital markets thing identity working group and capital markets sig in hyper ledger. I've been involved in Hyper ledger since its inception. I was in the first meetings. I Actually wrote The template for the hyper ledger improvement proposal that everybody has to go through every project has to go through to get into the Get into incubation inside hyper ledger store all projects that are currently in hyper ledger have followed that process And it's been an exciting journey watching the progression of Events in hyper ledger and the way the community has developed and Coalist two things About me one is that I am a technologist through and through I've worked in various industries and in the fixed income space for about 15 or 20 years So I'm very familiar with capital markets especially the technology and and I went through a crisis with the 2008 2009 and I'm familiar with what happened afterwards and of course I've been involved with blockchain Bitcoin and various other Thought in this space for more than five years and I Try to bridge the gap between technology and business with that said Let me go to the next slide. The agenda is going to be interoperability Then the segue into the Various other aspects that are necessary to implement interoperability properly We simply go into a particular Proposal from BAFTS or in the trade finance area That is a single message That's called a digital ledger payment commitment and we will examine why that is so important and then The swift ISO 20 or 22 and the cryptographic extensions and finally We'll go into the lab proposal that I have made and you've done some work on this It's called XTSI cross-chain settlement instruction So without further Waiting for that I go into interoperability interoperability is a I Just wanted to get the one word one sentence answer to this Which is ability of two more two or more systems to exchange information and mutually use this information and It's based on ISO 1 9 9 4 1 2017 and in this talk I'm specifically focusing on digital currency Interoperability so the only other change I've made to the previous slide is the fact that I Say that at least one of the systems should be a digital currency system So I thought of it for but it's actually meant to be interop Dot one so I'm looking at several ways of looking at interoperability one of them is the layered approach which is starting with a transport the syntactic semantic and Behavioral and policy implications Since This is supposed to be a technical talk will focus on the last of the first three elements first three layers But obviously all the other layers depend on the performance of this these three layers and I have some examples of The layers on The on this side and I see that The capability increases The another way of looking at it is you know If this is a very busy diagram, but it shows you the complexity of Any kind of digital currency interoperability because you can look at it from so many different angles It is easy to get lost but I think One of the things we have to do is to Get this complexity and the control One of the other ways in which you can look at it which I Lead the digital digital currency global initiative interoperability working group So I have the pleasure of interacting with many Experts Eric Cohen Who's based this particular way of looking at things on? Capability maturity model Of course the names that are given here are Completely his own and they have no bearing on CMM but the idea is that You can measure What is happening in the space and you can decide where you are in the journey from Total chaos to the ideal state and the ideal state is not static. You have to keep evolving as The state goes on so that's that is the idea of this slide and This one is another way of looking at interoperability which is Horizontal and a vertical model that means Suppose there is a digital currency system a and another digital currency system be they can interact with each other and They can interact with the use of facing applications Which is marked here as To and they can also interact with the legacy and external data systems Normally oracles various reporting Applications and so on so suppose digital currency system a is the Let's say Bitcoin and digital sort currency system be is Ethereum Both of them are completely unaware of each other obviously So in order to interact there have to there has to be some kind of intermediaries in the picture Which I do not show here So the number one would be Currencies being sent from one system to the other through something like Uniswap or Some other way of interacting that would be one We are also aware of all of the wallets and everything else that come in the number two and Number three would be legacy and external data. So this is a way point we have gone through the various interoperability model models and now I'm Going to start talking about operation operation operationalizing interoperability Try saying that fast similar to The concept of universal description discovery and integration UDDI or similar to the domain name system So that means in order to operationalize you have to set somehow you have to have registries You have to way have a way of discovering The other System and you have to be able to pass messages between one one and the other and Of course, this depends on standards standards chemo standard ways of looking at things now. I'm going to do an escape here and look at the chat window to see whether there are any questions or anything that's Okay, I do not see any specific questions, so I'm going to go back to the Presentation that I have So in the in the big in this context, we want to talk about something called a recording contract Which I'm sure many of you are familiar with Not in that specific name with that specific name, but various ways of looking at things The recording contract is a software pattern It is a single Well, it unites the human readable contract to the machine possible contract So why am I talking about contracts here because really speaking the Transport of value from one system to another should be driven by some Contracts some promise some obligations some way of saying, okay, I want to pay you I want to take some money that I have in this system and I want to pay you in that system So that's that's the whole idea I'm not going to go into the details of hash hash time-lock and various other forms of Actually transporting the value, but I'll just focus on the messaging part Anyway going back to the recording contract It is a human readable document that has markups that allow it to be possible and It is an immutable commitment using hashing and signatures and Implementable using a smart contract and the dispute dispute resolution Uses the original contract which is available not only to the issuer of the Exchange but also to the recipient and They know fully well what the obligations are this applies normally to the issuing of a bigger sort of Let's say a security that has a larger life in In the case of an exchange of value between two between two digital currency systems. It is more of a ephemeral a short-lived contract but This I idea of a Parcible, but human readable contract that then is Implementable using a smart contract and it is also signed by the issuer and Possibly by the recipient after perceiving the The exchange is contained self-contained in this one Four corners of the page and this is the Reflection of the recording contract that shows that the return contract is collapsed into a Hash, which is a commitment which cannot be revoked and then it Closed from there into the world of accountancy Where payments are then made? I Want to just show a couple of examples of These even though these people do not call it a recording contract it is it is By the virtue of the fact that it's in Jason and it can be read by humans Obviously, it would be better to Make this into a Document but this is called a digital ledger payment commitment and it's created under the BAFT or big bank Bankers association for finance and trade and it's completely open source It is a instrument that can That is complete is legally binding enforceable and negotiable and this can be done with just a handful of data points Which in include commitments or signatures or attestations And also of course the hash of this data So this is a very simple concept you to have so now the complexity of the Interoperability surface has been reduced to this Very short document and very short message really and that can essentially Transfer value You don't even really need a Blockchain or DLT, but normally this is This unites the supply side of the content the supply chain side of where you know a somebody is actually creating a product selling it to someone else But the payment comes later so the Consignee the committee I mean the computer promises to pay later Promises to pay and that now becomes a legally binding enforceable document But the beauty of this document is that it's negotiable that means that I as a supplier who's got this document Now can take that document to somebody else and sell it to them for obviously a smaller amount and And it's a better document because that's what negotiable means So it becomes very similar to cash it is a bearer instrument Which is completely digital Our aim is to reproduce some of these qualities in Transporting value from one Digital currency system to another digital currency system Of course, we are aware of Swift and the ISO 20 or 22 Swift itself is based completely on transport of messages And ISO 20 or 22 is a standard for standards, but it does have more than 65 or so schemas for the transport of Standard financial transactions and Swift is the registration authority for ISO 20 or 22 and if you look at the Ideas or look at the way in which governments are approaching CBDCs, you can say that see that many of them are going to be relying heavily on ISO 20 or 22 unfortunately ISO 20 or 22 is Is a rather sprawling standard So if you look at the DLPC, which we just saw It is very short Doesn't have too many data items but Swift has, you know reams and reams of XML and They lacked the hashing and signatures In the document which which I in the schemas, which I thought was kind of strange because Because that cryptographic basis is what would give The document immutability They subsequently have made those modifications to the Standard and it's part of the optional header structure now so Message-based Transport of value has been around for a while and it's being done every day through Swift Obviously the Swift regular Swift messages do lack the hashing and signatures proper signatures embedded in the document and that causes Problems anyway, I'm going to before I do the final section. I'm going to Look at the chat again and see if there are any questions I need to answer Just bear with me. I Guess there are a couple of quick Q&A's which I'll come to later Chat Craig's question What are the most mature methods of interoperability you see at the moment DLPC for example? digital ledger payment commitment is live so it is very mature and obviously all of the ways in which money the values transform back both into and out of Most of the public blockchains are Matureing one can say I mean the most salient form of that is I mean salient Idea around that is the idea of AMM Automatic market making which is you know part of the Uniswap protocol There are other forms in polka dot and others that are quite mature Anyway, I go back to the presentation and I'm going to Talk about a few things That are very concrete about the proposal that we are making in Hyperlogic labs and this is a project that I Proposed and created in a hyperlogic labs called cross-chain settlement instruction It is very nascent. I mean not much work has been done in this, but we have tried to create at least a skeleton of a message back settlement instruction so it Looks very much like the LPC, but is it is a different beast The number of items there are limited to like 10 to 15 The scheme has defined in Jason It is not based on an atomic swaps swap because everybody in interoperability is going for atomic swaps, which I think is Not the right way to look at things maybe in the retail context. It's important, but in the enterprise context netting prevails for various reasons so this is for counter parties with existing master agreements and It is of course not a beauty bill and immutable with hashing and signatures the Most elemental concepts around blockchain Hashing in particular is very powerful idea The message is freestanding and transport agnostic It's similar to did come in that way Did come is a effort by Aries and a discovery mechanism called chain name service is proposed for this to fully Implement something like this I'm just giving you a bare-bones sketch of this the schema and data elements Everything is standardized for example the timestamp is a secure timestamp Which is follows the NC X 9.95 standard The message ID is a UU ID, which is very familiar to most programmers and The message signature is a digital signature from the origin and the origin is the name of the chain in a chain name service Well, this is more a Talk experiment than an actuality at this point, but we are going to propose a Way to implement chain name service. That means how do you discover? The characteristics of a chain just knowing the name this is very similar to the way DNS works DNS as you know is a database, but it's implemented as a text file It is not only the IP address of The party you are connecting to that is available in that database. It has things like The who's a registrant? How do you contact them? You know various other other pieces of data about the domain Similarly the chain name service will will allow us to discover a lot more about the guarantees surrounding the chain and In the amount, of course, there is the numeric payment amount but when you go to currency it gets more interesting because currently I saw 40 to 17 covers the ground for regular three letter codes but a new standard ISO 24165 is going to address cryptocurrencies and similar to the Way in which we talked about the domain name service they So it's it's 410 already. So anyway basically everything is standardized And I think this is the end of the session. So I'm going to go back to the to the window and I'm going to look at the chat and see How We are doing with chat and everything seems to be fine and I'm Going to end the session And leave I leave the session. Thank you