 Okay, you were live. If you want to get started, Angelo and Ellie and others, so we're set. So many, many thanks. Maybe we take like a first round of introductions at least of the of the presenters. So, welcome everyone to the workshop on experimenting on some of these occurrences using hyper ledger technologies. I'm Ellie Andrew Lackey. I'm a Distinguished Engineer at IBM Research, driving the decentralized trust activities at IBM Research and Global. And we have two more people from IBM Research here, Angelo Decaro and Paltar El Kiawi who will introduce themselves. But we also have people from Banco Framstein that will present the experimentation we did around Venus and they will give more information on this. So we have no further delays. I will hand over to the rest of the people to introduce themselves, and then to Clement and quarantine to start off with a central bank this currency definition requirements and the context of Venus project. Yeah, I'm Angelo Decaro. I'm a senior technical staff member at IBM Research Zürich, working with Ellie on the decentralized trust. Maybe some of you knew me also because I've been for three years and the TSC, the technical committee of hyper ledger, the hyper ledger project was really a lot of fun being there. I'm one of the architects of hyper ledger fabric as well and the token SDK that we will see today. Thank you. Okay, so I am Kaltar and I am a research staff member at IBM Research. And yeah, with Angelo and Ellie we've been working for the last few years on CBDC and blockchain. Hello everyone, I'm Clement Delano and I'm working at Banco de France since 2020 as a blockchain expert mainly on central bank digital currency subjects. And hello everyone. I'm very glad to be here to present our work. So I'm going to Simon. We're also working in Banco de France since two years on blockchain subjects and more especially on CBDC. And yeah, let's go on the presentation. So let me, well maybe I think everyone has just introduced himself and if it's the case then I'm going to try to share my screen. Please feel free to confirm if you are seeing my screen correctly. Okay, perfect. Thanks. You can start. Welcome to this presentation about the Banco de France business statement that was conducted as part of the Banco de France work sale central bank digital currency program. In that context, we use the Banco de France DLT, the name DL2S and based on hyper ledger fabric to issue and manage on CBDC. We will start this presentation by introducing some key concepts and definitions about money and CBDCs and we will give you some background on the Banco de France experience. Then we will present you the DL2S DLT that we used on many of our experience. We can barely hear you, sorry to say, but we can barely hear you. Yeah, your audio is a little low. Can you speak closer to the mic? You're not able to hear you when I'm speaking or it's really a micro issue. That sounds better. Okay. Okay, so maybe I can speak a little bit. Can you hear me quickly? Can you hear me? Yeah, much better like this. Thank you. Yes, yes, like this, it is much better. Okay, okay, thanks. So we will start this presentation by introducing the key definitions and concepts about money and CBDCs and we will give you some background on the Banco de France experience. Then we will present you the DL2S DLT that we used on many of our experience. And after that, we will give you feedback on the Venus experiment that was conducted in partnership with Banque Centrale du Luxembourg and Goldman Sachs in 2022. We will conclude with some highlights and lessons learned from Venus, but also from our experiments. So Clément and myself, we are part of the BDF blockchain team. So it's a team of nine experts. So we are only two of us today, but we are nine. We have various skills and this team was created in 2021 to assemble most blockchain skills and capabilities to support initiatives and around blockchain and DLT internally. So we officially, the two of us joined at the launch, but Banque de France is working on blockchain technologies and DLT since 2016 with, for example, the Madrid project that was built with Ethereum. And we are mostly working, as we said, on CBDC subject because it's obviously a hot topic currently, but not only. And we have multiple activities from blockchain education within Banque de France or also toward the outside world. We've consulted in studies with where we are trying to technically form a technical perspective into some interesting subject about the ecosystem. Prototyping from POC to MVP. We free main activities, the technical design and architecture, the audits with code, of code smart contract and architecture, but also the development on many two big technologies that are Ethereum and hyper edge of fabric, but also full stack deployment because we know, we all know, I think on blockchain project, it's not only on the ocean that we have to build. So, to better understand and introduce CBDC, let's try to have a more global vision about the different forms of money currently and their purpose, at least on your system framework. So, it's a quick introduction just to have a better vision for everyone, but we have three different big kind of actors. So we have the central bank that is issuing and guaranteeing the two different forms of currency depending on the actors. So we have the fiduciary money, that is the cash, the coins and bills that we are using for payments that is physical form of this money, but we also have scriptural money that is on commercial banks accounts with the central bank for interbank sentiments. And so depending on the reserve that the central banks have, they can issue another form of commercial money this time. That is another form of scriptural money, but it's customer accounts that customer has at the commercial bank and it's the digital form that we know in our bank account correctly. And the convertibility is assured between all those kinds of money, different forms of money, which makes the system works. For instance, one bill of one euro is equivalent to one euro in a bank account. So for that, this distinction is not very well known, I would say, but for a good reason because the convertibility is fully assured thanks to this. So blue boxes is central bank money and the purple one is commercial bank money. And here's the concrete distinction between those two kinds in the economy currently. And so it's the global vision to better understand the current context and the place that could take the CBDC in the next months or years if we are going until building those kind of systems. So CBDC would be a new form of central bank money alongside banknotes and deposits held by commercial banks at the central banks. So two forms like the central bank money that we know currently, the retail CBDC that will be used for day to day payments between economic agents. It will be a digital version of banknotes that currently are only physical with the aim to be more efficient and to serve as alternatives with the declination of the use of the cash. Because currently we don't really have a digital version for retail central bank money. We have one version for the commercial bank money with bank accounts, but not for the money that is issued by central bank. So it's very important in important points. Having in mind that's the only direct link with the public from the central bank to the public. The other goal is also to foster innovation in payments for more secure, efficient and inclusive systems for users. On the other side, we have the world sales CBDC. We have another context because we already have a digital form with the scriptural money, the blue box that we had on the right in the previous diagram that was represented by accounts of commercial banks within the central bank. And so here it's more to support the tokenization of finance, which makes central banks review the central bank money services they are currently providing with the aim of adapting them to this new digital age. And the possible associated development of the tokenized finance by offering a safest and liquid settlement assets. But also to support technological progress to enhance market efficiency while ensuring their stability. So free objective, different objectives that can that would be the goal I would say of those kind of technologies. So first of all, the monetary sovereignty that is an important topic today at the European level. Cross-border payments improvements, which can obviously be improved. But even though the DLT is not the server bullet here, it could help to rethink the systems that we currently have. More availability with 24-7 and each every day of the years. Maybe having some programmability as this is possible on money and payments and adapt to the new infrastructures that are currently built by the ecosystem. And just to be a little bit more aware, we are standing currently. So we are working in the two subjects. But today we will be more focusing on the world of CBDC because the Venice experiment is in this context. It's the experiment that we are going to go more deeper in this presentation. Now that we have introduced key definitions and concepts about the CDC. I will share with you some context about the Banque France experiments program. In 2020, Banque France has published a course application with the aim of carrying out a series of experiments. The three main objectives were identified at the time. The first one was to explore how conventional use cases for central Germany can be achieved through CDC on a DLT. And more precisely, we showed how to ensure safe management of central Banque money on DLT technologies. We bested use cases for wholesale CDC, such as delivery of payment for settlement of financial transactions and payment for cross-border payments. The second objective was to identify the benefits of introducing a CDC for the current ecosystem. And identify to how CDC might foster financial innovation. And to achieve that, we analyzed the results of the experiments. We were in regard to the existing ecosystem and we compared performance, efficiency, security and forcible productivity gains. The last objective was to conduct an analysis of the potential effects of introducing CDC on financial stability, monetary policy and regulatory environment. And Banque de France investigated what could be the impact on monetary policy transmission and examined the possible restrictions imposed by the current legal and regulatory framework. And to summarize the objective of Banque de France with this course for application, it was to conduct real life experiments with the financial industry and within the existing legal framework. And this course for application received a great success with a strong response from the ecosystem. We received more than 50 application feelings with a broad business and technical coverage. From a business point of view, we received responses from a variety of actors such as banks and fintechs from around the world and we diversified the proposals. On technical side, these experiments enabled us to explore important topics such as performance or scalability, but also privacy and interoperability with a public or private directories or with a legacy system. And this course for application allowed Banque de France to lead nine experiments between 2020 and 2021 and there is a public report to summarize what we learned from these experiments that was published in November 2021. And a new series of experimentations started in 2022 and is still ongoing. It focuses on cross-border payments and cross-platform DVPs. And the Venus experiment that we will present to you is part of this new series. In the Venus experimentation, we used Banque de France asset which is called DL3S, digital ledger for security system. That is an innovative DLT solution for financial transactions proposed by Banque de France for world-sale CBDC. So this platform has multiple capabilities. So first of all is the digital asset issuance and distribution. The platform allows to create and distribute assets in a digital form such as money with CBDC, but also securities in the forms of tokens. We also have asset custody where assets live on the blockchain platform and are tutored by managers that are ensuring the proper accessibility and security around digital assets. All the life cycle and events about those digital assets are under on the platform obviously. We have different type of transactions, financial transactions I would say, from DVP, delivery versus payment that was mentioned just previously. And also maybe too complex transaction to mention here, but multiple kind of transactions can be handled, but also the CBDC issuance, transfer and redemption obviously. Based on specific workflow for each type of transaction to go through, built on different smart contracts. And we also have some optimization mechanism, for example recycling, trying to automatically settle every eligible instructions that are not already settled if needed. And so I mentioned smart contract chain codes, it's because all those things are built on Hyperledger Fabric. So this centralized permissioned blockchain network that I think everyone around the call here already heard about at least. And it was built with an hybrid cloud deployment philosophy where the solution can be deployed everywhere and anywhere with an idea to have interoperability with legacy systems, but also other blockchain protocols. We have several different chapters for this platform. For example, the simplification and automation of the different processes, financial processes that I mentioned just previously, with reduction of in processing times compared to what we currently have in legacy systems. Contemporary risk reduction with atomic transactions thanks to the DLT technologies, but also the use of central bank currency. Multi-currency is possible on the platform, but also for the payments. And the platform was built in an eco-friendly way. For the technical part, it's a fully decentralized solution. I'm going to show why afterwards, but it's in the blockchain philosophy. We have confidential and anonymous transactions, but that can be also auditable thanks to specific technologies that I think Elie, Angelo and Kauta will speak more deeply after. We also have pretty good performance and scalability, at least on the wholesale context and connectivity with legacy infrastructure and interoperability with other protocols. So it's an asset that was built and improved over the years through experimentation within Bank del France, but also with external partners. In particular, there were two experiments with Euroclear and one with HSBC that were part of the first phase, but also the various experiments, which is our main topic of discussion for today. And it will continue this year obviously with the European pilot regime that should come. So let me present you a more simplified technical stack about the application to have a better visualization of it. So the first layer is the business features. So it's in the user interface that is built in Angular. So it's a BDF interface proposal, but finally, this one can be modified, adapted to specific needs for the participants, for example, or integrated into their own system. Thanks to the implementation of the back end of the solution. As you can see, all those things are accessible via APIs, allowing different participants to access and end or push information according to their roles. And interacting with the different back end services of the application where all the logic is developed in store with a service oriented architecture. All those things are built in Golanke. We also have tools like classical authentication stack for managing the users of the application, storing their credentials and managing their rights on the application. And we also have the FSC FTS stack, which will be presented more in details later in this workshop, to allow us to make option interactions in the context of DL3S between participants, while having a token implementation with privacy and privacy, thanks to zero knowledge asset transfer, and ZCAT implementation. And we are also using the HLF SDK GO to interact with the protocol layer, sorry, that is hypervisor fabric, using idemix, which provides strong authentication as well as privacy preserving features such as anonymity and linkability. We are also using a form of private data to allow sharing of private but verified informations between different parties. We are using RAVT as consensus for the ordering service port, and CodGB as worsted for rich credits. And finally, all those things are deployed on cloud infrastructures in docker containers that are orchestrated via docker. So as I already mentioned, it's a service oriented architecture with a multi-cloud setup that is possible. We've done some performance testing, but it's more focused on HLF, not DL3S as a whole, but on HLF. It's up to KTPS, a pretty good number, at least for the protocol layer part. And we have interoperability, so to name a few with traditional platform, so target two securities, that is a new European legacy system that's offering centralized delivery of the payment settlement, having cash and securities on the same platform, so a legacy system, European system. Sorry for that. But also, market DLT with Corda and Fabric, with Hyperledger Reaver, and HLC APIs with the various experiments. Now that we have introduced you to DL3S, let's dig deeper into the various experiments. 100 million euros of unlisted digital bond were issued by the European Investment Bank on the securities DLT operated by Goldman Sachs. The settlement was done in CBC, issued by the Bank de France and the Bank Centrale du Luxembourg on BDF settlement DLT, namely DL3S. And you can see at the bottom right the full list of the participants of this experiment. In addition to the already mentioned participants, there are the Société Générale and Banco Centraire commercial bonds. Société Générale contributed to the experiment as a custodian and a Banco Centraire as an investor. The Auver investor were AXA and Lune investment. And Venus was an innovative experimentation on many aspects. We allowed two central banks to issue CBC on the same blockchain network. The execution of the DVP was automated between two blockchains of different technology without the intervention of trusted fair parties. And we implemented with a success the hashtag network. Okay, so I've been working on something and I wanted to share with you. Yeah, I hear you. Yeah, no much think. Sorry. So someone is speaking. Yes, I was saying that we are implemented with a success the hashtag network contract or HTLC interoperability standards, which ensures the atomicity of securities and cash movements under certain operational assumptions. And we will detail this specific points later in our next slide. So sorry for the for the introduction. I have some issues with my diverse currently is maybe to try to to to speak loud. Hopefully in going to stay fine until the end of the presentation. But so let me quickly go through the network topology that we use for various experimentation. So we retrieve the different participants that Clément mentioned just before. And so we have different participant type that are possible in the various network. So we have the two central banks, the France and BCL, the two custodians, so it's a giant government site that are blockchain participants on the network. So they also blockchain node of the network, and therefore as access to the ledger. So if we come back to the technical stack that represented previously, they finally are hosting every layers of the stack, obviously. We have EIB, so the European Interesting Bank that is a direct participant. So all the layers, but no, no blockchain nodes, so no IPA ledger peer. And he's connecting via the node of another production participants. In this case, it's by central to Luxembourg to retrieve and push the necessary information to the to the DLT. And finally, we have the investors that are indirect participants, so they do not host anything, but access the application by connecting directly to the system of the dedicated blockchain participants. Here they are, they are custodians. So as I already mentioned, we had raft implementation as for the ordering service. We have a free order on node or nodes distributed on the network that are not represented here because it's more technical nodes for making IPA ledger fabric working, but it was free different instances that those that we are seeing here currently. And for the hosting part for the FPS, the FPS at least we have different modes. We can host all those networks in one instance for testing purposes generally, but we can distribute all those participants in several instances to having a real to achieve the main goal of the decentralization, I would say. And the hosting is also possible to be distributed from BDF complete hosting, BDF hosting, all the participants stack on the on its own cloud to the independent hosting of the stack of the different participants. For instance, Goldman Sachs, who could host its own node and interact with the others that could be hosted somewhere else. So, and just to make some context here, for various experiments, we use machine instances configurations, but it was all on monocloud with monocloud hosting at BDF. Even though it's something that we already did, the multi-cloud hosting I'm mentioning in other experimentations. I'm going to explain the general HTLC mechanism. Here we have two distinct blockchain networks. The security network on the left called network one and the cash network on the right called network two. Cash and securities stay the respective network. That means the cash only circulates on the cash network and the securities only circulates on the securities network. And that's not like a rage, for example, which would allow tokens to go from one blockchain to another if we simplify. Then we have two parties, Alice and Bob, and they want to realize a DDP where Alice is the seller of the securities and Bob is the buyer of the securities. And both Alice and Bob have access to the two blockchain. Now that we have in mind the configuration, let's see how HTLC actually works. The principle of HTLC is that Alice locks her securities in a smart contract using a hash. Bob locks his cash in a smart contract with that same hash. And then Alice claims the cash using the pre-image of the hash, which rebates at the same time the pre-image, and allows Bob to claim the securities. But let's see in details the different steps that we have here. So we start with a step zero, which is the off-chain agreement between Alice and Bob to define the terms of the DDP. And before initiating the HTLC process, Alice and Bob, so they must agree on the amounts of securities and cash to exchange. And also on other parameters, I will introduce to you in a few seconds, such as the timeouts. At the step one, Alice generates a secret and then she hashes it. She keeps the secret to herself and she locks securities on the network one in a smart contract with the hash for a period of duty. And in fact, the HTLC smart contracts are time-based escrow. So assets are only locked from a limited and predefined amount of time that expires at a given timeout here after a duty. So both securities and cash HTLC smart contracts have a timeout and timeout parameter, which represents the duration over which the assets will be locked by the smart contract. And if the timeout is reached and the asset has not been claimed by the relevant party, then the asset is returned to the original owner. At the step two, Bob audits Alice's HTLC smart contract before moving forward. And the code of the smart contract should tell something like only Bob can claim a great amount of securities until a period of duty is reached. And Bob checks this and if he agrees with the conditions set by the smart contract, he then goes to step three. At the step three, Bob locks CBDC on the network two with the same hash as Alice and the fork period T. And Bob got that hash when he audited Alice's smart contract. In this example, we use a T and two T for respectively the cash timeout and the securities timeout, but overvalues could be used. The important idea here is that cash timeout must be strictly less than securities timeout in such a way as to always let enough time for Bob to claim securities once cash has been claimed by Alice. At step four, the same way as Bob, Alice audits Bob's HTLC smart contract before moving forward. And if she agrees with the term of the smart contract, she then goes to step five. At step five, Alice claims Bob's CDC using a secret S and before period T expires. And while claiming CBDC, Alice reveals a secret at the same time. And of course, the smart contract checks that hashing the secret results in the expected hash before transferring the cash to Alice. And the claim of the CDC and the sharing of the secret are done in a single atomic transaction. So that means that Alice cannot receive the cash if the secret is not revealed. And conversely, the secret cannot be revealed if Alice does not get the CDC. So this is all or nothing logic that makes it possible to deliver cash and securities in turn with a delay. Because Bob has the guarantee that he will be able to claim the securities using the published secrets. And the last step is step six, where Bob claims the securities using the secret S. So that was revealed by Alice on the Network 2. And he claims the securities before period 2T expires. Now we will explain how HTLC was implemented in the various experiments. I will first recall the definition. That's basically what I've explained in the previous slide. So HTLC is an interoperability protocol used to exchange digital assets without trusted third party and relying on smart contracts which are used as a time-based vault to block and secure funds. It allows a decentralized DVP solution without a trusted third party. It uses a cryptographic process that links private data as a secret to public data, the hash. The assets are locked with the hash and unlocked with the secret. The recipient can unlock the asset due to him on the condition of providing the secret within a predetermined timeframe. Our HTLC has some specificities. We adapted the HTLC concept to private environments because the DVP was between two private blockchains based on Hyperledger Fabric for Bank de France, a DLT, and based on Digital Assets, a damel for Goldman Sachs, a DLT. And the process is orchestrated by the buyers and sellers, custodians, which are both on access to the two DLTs. There are two trust assumptions here. The first one is that the DVP instruction matching is done on the security of the DLT on me. The second one is that cash and securities custodians of the same investor, which can be different entities, they must trust each other about cross-DLT messages they exchange. It is a fair trust assumption as both custodians represent the same investor and therefore they share a common test. I will explain in more details what happens on the next slide, but this is important to note right now that buyer securities and buyer CBC custodians on the one hand and seller securities and seller CBC custodians on the other hand exchange messages to share DVP and HTLC relative data between the two networks. And that's the communication between custodians of the same investor. So there is no cross-chain communication between the custodians of the buyer and the seller. So as you can see in the diagram at the top right, there are two communication channels. The first one is between the buyer CBC custodian and the buyer CBC custodian, which both represent the buyer. And the second communication channel is between the seller CBC custodian and the seller CBC custodian, which both represent the seller. We have identified some key feedback. HTLC is a trustless protocol. So there is no need for a trusted third party and that implies a high level of security. HTLC allows conditional DVP. So in fact, HTLC does not achieve a capacity because it is an interactive process consisting of a combination, a series of off-chain and on-chain operations. And depending on the results, different states can be obtained at the end. For example, if the buyer is not able to claim the securities before their timeouts, the seller will own both CBC and securities at the end of the process. Because as we saw previously, if an asset has not been claimed before its timeouts, it is returned to the original owner. So HTLC does not achieve technical atomicity, but it is fair enough to say that we have DVP atomicity under certain operational hypotheses. Because if the seller and the buyer ensure that they are fully operational during the HTLC procedure, then they are guaranteed to receive their respective assets. One other important point that I have already mentioned before is that there is an atomicity of cash claim and secret sharing operations, which are done in a single transaction with all or nothing logic. And if these two operations are not done in the same transaction, HTLC cannot work. We say that this is the earth of HTLC. One last point about reusability. The current implementation can be reused with all DLTs sharing the same ashing functions as an DL2S. And that's because in order to implement HTLC, the two networks must use the same ashing algorithm to lock the assets. We will now describe how the two DLTs interface. The custodians exchange cross-DLT messages via APIs. So DL2S and the securities DMT, they both expose APIs. There are three messages that we call message one, message two, and message three to emphasize the order of execution. And these messages are sent automatically between the two DLTs. So there is no operator beyond them. Now let's see the content and the role of each of these messages. After having locked the securities on the securities DMT, the seller's securities custodian sends the message one to the seller's CPDC custodian in order to share the settlement section with the secrets. And later, the seller's CPDC custodian on DL2S will be able to claim the cash using that secret he received from message one. After having audited the securities HTLC smart compact, the buyer's securities custodian sends the message two to the buyer's CPDC custodian to share the settlement instruction with the securities timeout and the hash. And the buyer's CPDC custodian on DL2S will then lock the CPDC using that hash he received. Once cash has been claimed by the seller on DL2S, the buyer's CPDC custodian retrieves the secret, which is public now. And he shares it to the buyer's securities custodian via the message three. And after receiving the message three, the buyer's securities custodian claims the securities using that secret. I will now expose you some highlights we have identified. This setup is efficient, but it requires the implementation of several contingency procedures in order to manage some unapply paths. HTLC is a secure protocol, but there are some operational risks which are not the same for the buyer and the seller. The risk for the seller is a leak of the secret after securities have been locked and before cash has been locked. And in that case, the buyer will be able to claim the securities without having to lock the CPDC. The risk is different for the buyer. Once cash is claimed on DL2S by the seller, the buyer must absolutely claim the securities. And if he fails, the seller will return on both cash and securities at the end. And in fact, and that will be our last point, there are several ways to control this risk. We can implement automatic or manual contingency procedures or set up a larger HTLC timeout to make sure the buyer will have enough time to claim securities. We implemented a manual contingency procedure on DL2S for various experiments. In case of failure of the automatic sending of the message free, a script was ready to be manually executed in order to send that message free. It's time to conclude with the main highlights and main lessons learned from the Venus experiment but over experiments too. Blockchain and DLT technologies have reached sufficient maturity to become serious candidates for underpining market infrastructure. CBC, science, circulation, ownership control and supervision can all be securely supported at the applicative level, on the both private and public networks. Interoperability has been successfully demonstrated between cash and securities networks and without trusted third parties. We have demonstrated the technical feasibility of cross-chain DVPs and between blockchains of different technologies. DL2S solutions maturity allowed to restrict real DVPs of 100 million euros. One last point, using DLTs makes DVPs more efficient as it speeds up the transaction's finality. Maybe to really conclude this presentation, some links and an opening. So it links about reports that I previously mentioned during the presentation. So the global report published in November 2021. There is also about the first phase of experimentation from the front. The report for Euroclear experiment that was conducted with Euroclear construction banks to assess the potential of post-trade capital market settlement operations in CBDC for French sovereign debt securities. And for this experimentation, there were both the currency and the securities on the same platform that was DL3S. And for HSBC, so in addition to the issuance and distribution of the CBDC, the idea was to experiment bound subscription in primary and secondary markets, including component payments, and the execution of cross-border and cross-network payments. So in this experiment, several networks with several technologies have been used. So Hyperledger Fabric and Air Free Corridor, interoperated through Hyperledger Weaver that is now being included into Hyperledger CACTI. And maybe just to open a bit about the fact that all the experiments that we accumulated on the DL3S development and the things that we've done for evidence experiments are being currently invested in the pilot regime. That is a text with the main aim is to have a temporary framework that should provide favorable context for the use of blockchain for financial securities in the interbanking context. And so this is the opening point for central banks for the settlement asset that will be used in this context. I will copy past all the links mentioned in the chat for those that are interesting to dig a bit more about what we presented. Still no report for the Venus experiment. So for the others, you have a way, a lot of things to read if you are interested to dig in it. So thanks for your attention and we are available for question. That's because I see a lot of question on the chat with some answers sometimes. I don't know how do we want to proceed for this part? Maybe I suggest that we continue with the presentation and then we take all the questions in the end. At the same time we can try to answer the questions from the chat and bring up the ones that have not been answered at that point in time. We will look at the chat and try answering some questions. Perfect, thank you. Okay, very good. Thank you. So I start sharing my screen. Okay, so can you now see my screen? We're still seeing Simon's screen. Simon, can you share? He'll have to unshare. I have to unshare. The previous person who's the current person sharing the screen. Let me see if I can. Okay, you're good. We can see your screen now. Okay, so hi from my side. After a very nice overview of Clamon and Quarantine, I'm going to give on what central boundaries are the exact scope and deliverance on the Venice project. I'm going to give an overview of the Hyperledger technologies relevance into the central bank, its currency topic starting off with a very high level architecture of the typical central bank this currency system. It's, you know, that there have been more than 60 reports on central bank this currency issued by different various central banks, and more or less, majority of them agree on the two tier architecture, assuming at the top level a wholesale central bank this currency, facilitating exchanges of cash but also securities different types of financial assets between central banks and major commercial banks. We see tier two are referring to a retail central bank this currency facilitating exchanges of cash between individuals or corporations, just like we do today with our bank notes that we have on our wallet and that we use to pay. And then, on the last end we do have the consumer that would order the payment service provided that would interact through APIs to the retail CBDC network to offer a service to other consumers individuals that would itself need to interact and interoperate with a wholesale CBDC network. Of course, a lot of requirements I already mentioned, not explicitly, but I mentioned interoperation, for example, being important one interoperation between two different central bank digital currency systems, different partitions of the same central bank digital currency system, even, but also interoperation between a central bank digital currency system and legacy systems. So this is an aspect that we know, for sure, will be important. And because of the variety of the importance that system would be compliant to regulation and to some extent regulation differing from a country to country. We have different architects of different platforms to facilitate the requirements in different countries therefore interoperation becomes even more interesting to address. So this is an important aspect, privacy of the payments involved, especially if we are talking about a system that would need to transparently validate transactions that appear in it. So that every participant in it can verify that this transaction was indeed honoring the rules of that asset management system, but at the same time privacy needs to be combined with accountability. Namely, participants of the system should not be able to repudiate their participation in a certain transaction. So strong identity management already becomes a clear need in this system. I mentioned before privacy with accountability need to coexist and also in a way that regulation compliance is enforced. Transparency is an important tool to facilitate security and resilience is another security aspect that needs to be strongly positioned in this set of requirements of a central bank digital currency system. When I refer to resilience is ensuring that the system will do its work as promised as intended, even in the event if some nodes in the system get fail, like crash, but also in the case where nodes in the system, some nodes in the system get compromised and introduce arbitrarily messages into the system trying to mess up possibly with a systems operation. So resilience for critical infrastructure of this sort is an important and this is where distributed ledger technology would bring a strong value. Scalability and performance are necessary for the wholesale central bank digital currency was already mentioned before performance is not so challenging to address but when it goes to this retail central bank digital currency this because it becomes of critical importance and quite challenging to address especially with all these other requirements being addressed at the same time. And we want to emphasize that it makes sense also to separate the set of requirements on the two levels. The governance level which says who should be making decisions into to to to upgrade the system changing the rules the asset management system so for example, some thresholds of cost of the particular entity in the system should own or upper bound of this source. So who should be authorizing the issuance of new money to the system and so on so forth. So governance of their own subset of requirements to address again around compliance privacy and and accountability but also resilience. But it's also another level is when it comes to decisions that have already been taken to be enforced then it comes to the execution side, where again we have distributed setting that brings a lot of advantages as we will discuss later and where again, we will need a system to support the transaction processing with high degrees of resilience. And to meet all these requirements is not an easy thing. We know from cryptography and security there are ways that one could combine privacy and transparency for example. We have primitives cryptographic parameters like zero knowledge proofs of the human part of computation that could be used, but these come with certain overheads computation overheads, and they need to be treated with care. So to meet to to have a system that would accommodate all these requirements in combination. It makes sense to do a full technology stack investigation. Understand the application very well work with the main experts to extract the real detailed and requirements and threat models, which party in the system can be trusted, which party cannot be trusted and for what. And using that information, one could build middleware components and libraries like ones that are evident that we need here are the ones around identity management and the ones around asset management like token exchange are over way to incorporate in certain capabilities into the platform level that in this case it is represented by distributed ledger technologies and in particular hyper ledger fabric. Ideally, one would also need to engage with their dedicated infrastructure optimized hardware to speed things up. But the important point is that one could not possibly address all this in a practical system from a performance scalability perspective just by looking at the application side or the library side one would need to look at the system holistically. And just to say a few words and we will cover here again how privacy preserving the centralized asset management is an important building block. Angelo and counter will cover the token SDK and fabric smart client combination that meet this, but also need to be combined with a secure privacy preserving identity foundation, because we are, because of this requirement. The requirement for accountability, strong identity management is important. And I will also say a few words of hyper ledger fabric and what are the characteristics of the platform that make it a relevant, more than relevant and the preferred DLT for this CBGC at least experimentations would be involved. So, our speakers before quarantine and Clement already mentioned the industry confirmations about the relevance of distributed ledger technology into central bound digital currency and summarize it here. So, this distributed ledger technology bring value in business networks and three ways through the distribution of trust, building trust essentially across a set of participants that are not necessarily mutually trusting each other. And transparency and automation. In this particular case, the use of DLT's significantly increase the ability of the system to be resilient to notes that are under cyber attacks or insider attacks so resilience of the system to compromise notes. That automatically allows the operational risk and related cost to be reduced as well. Because the system has a stronger guarantee that it would work well. Because of the combination of the distribution of trust and a high degree of resilience and transparency, one would argue that it unlocks the ability to leverage what is listed there the smart contracts that are used there in order to automate the processes. And that automatically allows together with the transparency as mentioned before, the reduction of the reconciliation time between issuers and security depositors and custodians and clients. All the way, resulting into much shorter trading cycle, trade to settlement cycle to essentially zero days within the same day at least compared to today that it would take at least a couple of days to take place. Last but not least because of again of the transparency that it brings into the picture and the fact that the single ledger is acting as a source of truth trace ability. It was also being able to and overall reconciliation would be better optimized. So that's short, and these are an overview of hyper ledger technologies that can be brought together in order to meet the set of requirements that were mentioned before. Of course, I mentioned the identity management and then we have a strong representatives on hyper ledger us and iris and indie projects. We have interoperability frameworks. We have a cacti hyper ledger project that allows general purpose in general purpose platform in interoperability. The platform agnostic interoperability mechanism as it mentioned but also hyper ledger weaver interoperability protocol that was recently merged to cacti project or is to be merged. And then we have hyper ledger fabric token SDK that is combined with the hyper ledger labs fabric smart client to things connected to what higher degrees of flexibility and privacy into asset exchange on top of fabric. And of course on the platform side we have hyper ledger fabric hyper ledger Orion hyper ledger fabric offering decentralized consensus based transaction processing hyper ledger Orion offers transparent centralized transaction processing. And moving forward, we will focus our discussion on these two parts hyper ledger fabric token SDK and and smart client as well as hyper ledger fabric. I'm not going to dive deep into the token SDK because Angelou and Carter have lots to say about this. I'm also, I'm only going to emphasize on a few distinct characteristics of this components that were made that technology relevant to the DL3S platform that was mentioned also before. The main characteristic here and you know asset management has been very long investigated into the decentralized trust community blockchain community. It's quite straightforward what one is to check in a given transaction that moves an asset from one party to the other, especially trivial, trivial like conceptually, not in practice I guess when it's implemented is no trivial. But the idea is that one is to check whether the owner of the current registered owner of the asset is the one authorizing the transfer, and that's during the transfer there is no new money created. If I own one US dollar I can spend at most one US dollar I cannot spend more. And this is essentially being converted by the community into a privacy preserving setting where everything is concealed, but everyone is able to check that at least it's the owner of the asset that has been authorizing the transfer of its and that the value, the balance property essentially no new money has been creating upon transaction is being preserved. In the enterprise setting, which is again compatible to what we mentioned the central bank the wholesale central bank digital currency would look for. We go one step further. In addition to the on in the to the privacy that the open source community the open system community has built. We restrict that privacy into the permission setting we enforce strong identity management of the individuals. And accountability and allowing that dedicated auditors that can be user dependent on type of asset dependent are able to view the history of transactions that refer to that user or to that asset. So audit support is the way we extended that but also a strong identity management. Okay. And this is essentially the token SDK that is offering this kind of unique state of the art capabilities. Privacy and audit support differentiators but also the offer some support for interoperability hash time lock protocol that was mentioned before is something that there are hooks into lots of that it can interact with another system supporting that protocol. But two important things we also need to mention here. Three actually, first is that architecturally oops, sorry. It's agnostic to the underlying DLT that is using so it's primarily attached to fabric but it can also work with other teams. And the second thing is that it does support the UTXO model because of the privacy advantages that this UTXO model come with. The third thing equally important is that it is not just the system that that we built a prototype that was built and was put under hyper ledger lab, but it is also has the protocol itself have been reviewed by the scientific community. And it's out there in detail the cryptographic protocol can be reviewed and the technology has already incorporated into mature central bank digital currency experimentation including the DLTS and subsequently to Venice projects that that were mentioned before. Just a few words just to conclude on the relevance of hyper ledger fabric for central bank digital currencies. Again, one question would be okay, why would you use a permission DLT for central bank digital currencies. It depends on the governance mechanism that would be desired in this setting. We do see central bank digital currencies requiring to large extent control to be on the central bank side, or they're decided upon participants and and then control we refer to not only on whether they decide to issue a currency so that the governance side of thing that we mentioned before make decisions on whether new money is going to be issued or a new securities are going to be introduced into the system and what are the terms for that and so on so forth. But also the transaction processing layer. What happens if there is a bag into my smart contract that has been developed and some money have already been transferred by an attacker that has leveraged that bag to another address that nobody can get access to or cannot easily blacklist. So the governance side is important if you remember in the past this has happened like 2016 if I'm not mistaken or a year later, and it led to forking the public ledger system that was there. There is an important reason and control on the depending on the on the on the preferences or the specifications of them level of control that the central bank and the commercial bank should have in such a system and appropriate technology would make sense to be used. So hyper ledger fabric is able to leverage to how comes with a very modular policy framework allowing policies to be set for different levels of the system. We have governance mechanism or policies governing how the system overall system would be upgraded or individual components of the system should be upgraded from ranging from the membership components all the way to upgrading of a specific smart contract in it and so on so forth. So it has a very advanced policy framework addressing a lot this enterprise needs for specifying authorization of different partners in there. We also have modularity modularity and agility in the way the system has been architected modularity and the crypto components and the membership components allowing an easy smooth transition of the system to another crypto library, or even to post quantum, some safe crypto libraries that will come up at some point and it will merge at some point in time. There are already making support gtpr compliance in the system. And we also come with a strong state of the art performance and scalability aspects and I will say a few words about it in the next slide. A lot of the operation of the system and I say this because it's also important in our view, our view as researchers is that the system is there and works but it is also backed with a very thorough report that has been published out there and top tier scientific information has been reviewed by the distributed system experts so it is well founded on multiple aspects in multiple ways. And this is to talk about the throughput of the system. Actually, these numbers are a bit outdated, but Byzantine fault tolerance is the consensus algorithm allowing strong resilience to faulty notes, notes that not only crash but can also be assumed compromised exhibit an arbitrary behavior when it comes to processing transactions. So this is definitely a desired property in the system and we already have a smart BFT includes did into fabric in an early version of it, but our plan is really to go into mere BFT and insanely scalable state machine replication that would allow a transaction throughput to go on the level of multiple tens of thousands of transactions per second, even with a number of participants beyond 80 traditional Byzantine fault tolerance algorithm tend to degrade throughput wise once then a number of participants above 10 or 20 but and that's what you see here, but, but this is not present in the in the algorithm we're moving towards. Last but not least I mentioned identity being the needed foundation of a secure asset management system and in particular identity mechanism that would allow privacy preservation bash with accountability properties strong accountability properties in place. So this has been very active in that space. We've seen a non crates protocol, hyper legionaries, hyper legionary Indian Ursa, of course, our projects are associated to that. And we've seen a lot about a non crates as specification protocol allowing this combination of privacy and accountability. I also want to mention the centralized identity comes with strong advantages on the on the scalability and privacy side of things since the users are the ones owning the level in which they will interact with their environment sharing information with their environment. There is no central authority that needs to get access to the all information about the user and leveraging such a mechanism, connecting that with us and management is, but very, very much relevant in that context. The mixed technology that was also mentioned before is an early version of this kind of cryptography that is used in hyper ledger in the sorry hyper ledger. It's provided in Ursa but also used very much in in the non crates credentials. Without our handover the word to Angela and counter to do a deep dive to our assets. If there are any questions to be raised on the side I will take care of the questions on the chat. Okay, Angela. Okay, I guess I need to stop sharing, right? Yeah. Okay, I'm ready to share. Let's see if I can catch this. We've got your desktop. There you go. You're looking good Angela. You're looking great. Okay, sometimes it goes goes great. All right, very good. So let's now take this move to this other face of this other session, a section of the presentation and have a deep dive in one of the core assets that was that is behind all the efforts that have been you've been described the described so far. It's the fabric token fabric token SDK. I put in parentheses fabric because it's true that it was born in the context of fabric but over time it evolved to become something that is agnostic to the to the to the back end and I will show you I will show you why. So for this for this part for this section for this session. I want to talk about the privacy or the ability part of the technology, the technology stack. And I also want to show you what what it means to have a what's the transaction life cycle in the in the for for the token for the token SDK. Before, before the deep dive, let me let me first locate where we are in terms of the stack and also gives you give you some other highlights to better position the token SDK so this is what I presented before just a few minutes earlier. So we are there at the. I will talk about the centralizing the regulated tokens so the token SDK sits in that at the middle where at the middle where components so from on it talks to the token SDK talks with the platform so with so with the back ends to have the applications settled to retrieve information from the back end as needed and it offers API to the application layer in order to perform set token operator token related operations. All right, let me I also like to to to go back to this slide that I just presented to just to for to to spend a few seconds on on this on this on the on on a fact that depending on the on the requirements might require different level of different level of privacy. Right so this is our little told us about this three examples and what you and the last one where you have also audit ability, but you might have been even other kind of combinations depending on the on the specific use cases depending on the privacy that you want to that you want to achieve or you want or your system is able should sustain you might be you might have certain compromises in certain cases or you want to have for you want to go for full privacy no matter what in in in in other in other cases so for us this was was an important point because we thought okay, we need to be flexible we need to design and a system a stack an asset that it's flexible enough to adjust to different to different requirements without us having to rewrite the application continuously so every time we change the requirements we have to rewrite the the application so definitely this was not a goal. For us we wanted to be able to reuse the same API, no matter what no matter what no matter your requirements or the specific requirements for the use case. So that's why the fabric token SDK was born we wanted we wanted to apply all the cryptographic we wanted to make it real. The use of all these cryptographic protocols that we designed over over the years in a in a in a software stack that would have allowed us and any developer to create quickly. The token based applications at the beginning was a hyper ledger fabric but then we quickly switch it to to an infrastructure that would can allow us essentially to to swap fabric to change fabric with other with other DLT or even centralized system by by by your mates it doesn't from the point of the token SDK doesn't really it doesn't really matter. Let me go again early they gave already a heads up on the main highlights of the token SDK let me go, let me go again through through them, and give some, some also motivations on on on some of these points. So we adopted adopted, we decided to go for the UTXO model for a very, for a very good reason, the UTXO model is the one that allows gives you the maximum privacy possible. You can achieve some certain certain privacy guarantees in the account model, but you have to compromise in a way or another there are compromises to be made. The UTXO model is that is very amenable for to be protected in in all aspects, and to really simulate the some key, key privacy privacy properties that you have with with the real world with the real cash with your bank notes and and so on. The token SDK takes care automatically on the wallets and the key management so you can use HSMs to store keys or you can use a different infrastructure to you to store to store your keys, or you can just have on the file system as well but the token SDK takes care automatically of all these things you don't have to worry about that. It supports also multiple privacy levels so from something from an instantiation that has no privacy goal to instantiation that have all sorts of that employed zero knowledge proofs to obtain different flavors of privacy depending on the on your specific your specific use case. And this is the this is possible, keeping the token SDK API the same though we'll go later in in some details about the token API or give you also some some example in terms of code, what it means to use the token SDK, the token SDK API. The point really here is that the principle is bright once your application and then decide when it's time to deploy the system, which kind of privacy, which kind of privacy you need and you want for for your system but the application remains the same. We have included in the token SDK this auditability support so concept like auditors that can look at the transactions and see what's going, what's going on. The API is flexible enough to handle both fungible and non fungible tokens so you can really play not not just with you can use the token SDK not just to implement coins, so the digital currency of different flavors but also to handle non fungible tokens, and it has embedded support for interoperability counter actually after this section we'll talk we'll go more in details about the interoperability capabilities that we embedded in the in the token SDK. All right, so what I mean we are talking about tokens you take so what's a token for from the point of view of the token SDK it's very simple is the following triplet. So we have we have we have an owner and this owner essentially defines what it means to do the defines the concept of ownership of that specific of this specific token so the in the simplest case it can be just a public key, or it can be something complex like, like a script, and so on and so forth. We have a token as a type. It's essentially the denomination of the token but it's really just a string so you can put inside this thing whatever you want you can even load the type with a JSON structure representing your non fungible your non fungible token. Now we have the quantity that in a sense represents the amount of value, depending on the type, because you will, you will get you will give a meaning to this to this value but the amount of value that is stored in this token so the amount of the value is clear if we are talking about currencies so that the type will represent a clear denomination, we can be sense or units or whatever it is and then the amount it's clear what the amount means with the respect to the, with the type. So now then these tokens are fungible with respect to the same to the same type so if you have two tokens of the same type that for you these are fungible, these are representing the same entity so you can do two tokens of the same type of the same amount. They're absolutely fungible, you cannot distinguish between between them if the tokens are different if the types are different than essentially what it means that you cannot merge these two tokens so you cannot perform operations like merging or you cannot. If a token is non fungible you cannot split this token in multiple in multiple other tokens so very simple definition very clear not to very really to the point and not only it's easy to this definition is generally enough to model multiple type of tokens, but it's also simple enough for us to implement the zero knowledge proofs that are needed to deliver to deliver the privacy. So this is, this is the stack of the token SDK, you can see here the two main components forming the entire stack, it's the fabric token SDK and the fabric smart client, these are two hyper ledger labs projects or two different repositories. But personally in my mind I like to think about them as a single stack that provides this application, this SDK to build the token base of the applications in a way that it's very close to the business logic. And you will see later an example so I think this was the other, the other important aspect for us at zero knowledge and advanced cryptography like multi party computation or threshold cryptography are very complex to handle in practice so we wanted to also for we wanted to have a system that would take care of all these complex aspects so give us a very simple API, this was the request for the token SDK give us a very simple API to talk about tokens and take the rest take take care of all the data so what it means to generate the zero knowledge proofs, zero knowledge proof here and there. So in a bit more going a little bit deeper, we have multiple layers of the token SDK as multiple layers in the stack there are multiple layers. The top one is contains essentially what we call the services that are libraries or pre package the software components that allow you allows the developer to build quickly token token base of the token base of the application so this is the part that is the super customizable because if something is not provided that you can build by yourself and you can you can even you can put this as an add on for the token for the token SDK, these services will will use the essentially the token API so I built on the on the token API and the token API is essentially backend agnostic and also would say the privacy agnostic so the token API gives you a way to describe operations over tokens and nothing else then this this course the course to the token API are translated to course to a lower layer that we call the driver, the driver API now it's the driver that does the dirty job essentially it takes care of all the complexities of the zero knowledge proofs or any other technology that you might you might want to my world to use so through the driver API we go to the driver to the specific drive the implementation that again it can give you the flavor of privacy that you need from in the in the open source we have two two drivers that you can use right now one that we call the faptoken essentially doesn't doesn't have any privacy so everything is in the clear anyone who looks at the ledger can see exactly who did what and then we have a version of the the cat that the telly the lead described quickly without without graph fighting that I can go in more detail later later what we mean to me encounter again describe in more detail what it means but it just a flavor of it's just a driver that supports zero knowledge and protects certain certain part of the second part of the tokens. So this structure this is this layering of the token SDK allow us to quickly change the driver once we need so we can upgrade the system to new drivers or we can even switch at the beginning and the token API allow us to say to implement application and so without having to worry about the underlying driver, the underlying driver implementation so we achieve the goal that we wanted the right to answer application, forget about the back end forget about the the privacy that you are the complexity of the zero knowledge proof so on and so forth just focus on your business business application. Now how do we sense how do we run this this guy. So the stack can be executed as a standalone network node and in this case you will have or you will have a topology like like this so you will have multiple multiple nodes that are running the stack. We usually call them FSC nodes but no matter what these are nodes that belong to the application to the application system to the application layer and these nodes not only talk to each other. But they also talk that they can talk to multiple to multiple back end that at the same time so you might have multiple fabric in sensation and Iranian sensation abasus sensation and so on and so forth so you can handle all this topology that is complex as as complex as the as this one. But you can even embed this tech in your existing your existing application this was the approach used in the F3S so there was already an application stack that the token SDK the token SDK stack has been simply embedded in these in these already existing application stacks so maximum flexibility you can you don't you don't have a simple a single way to deploy the smart the smart client. Now let me tell you more about let me tell you more about how do we achieve the this decoupling of the actual implementation of the token so the actual details about the zero knowledge proof or any other technology that you you want to use. And the token API the way we talk about tokens in the context of the token SDK. So we have a we have an object data structure token SDK that it's called a token request. So let me let's go through let's see the anatomy of this token request to understand what what what it contains so the token SDK the token API speaks about the token request so it knows how to manipulate this, this data, this data structure, it doesn't know anything in anything else from at least from the point of view of the token API. So there are three main sections in the token request there is an anchor. Just to understand the content to understand the answer we can think about the transaction ID in the context of fabric or any unique identifier for for the specific request. Then we have a section dedicated to the actions that we want to perform. So the two most fundamental actions in the context of the token SDK are the issuance and the transfer so issuance allows allows the possibility to allow someone an issuer in particular to create new tokens out of the blue. So they have a specific section inside the token the token request to specify the will to create new tokens. And tokens can also be transferred so there is a section in the token request that speaks about the transfer of tokens from one or from a recipient from sorry from a sender to a recipient. Now the actions are also accompanied by witnesses that are sure are needed to make to convince a validator that these actions are correct so are legitimate. Think about the fact that if Alice is transferring a token to Bob, Alice needs to prove that she's the legitimate owner of the tokens that she's trying to transfer. In the witness section, you will find the signature from Alice, for example. And then we have met the meta data part meta data part it's very important it's it's something that it's used to transport all these little secrets that are needed to the office hate the zero knowledge proof or the to better understand the content of the actions right so the actions something like zero knowledge proof or cryptographic commitments as something that it's off for skating what's what's going on because we want the system our system to be private but when Alice and Bob are exchanging this information for them the content of the action should be like like like it was in in the clear. So the meta data is the section when Alice and Bob are exchanging secrets that are that allow them to understand the actions that are there that they are discussing. So this is the the the main data structure that is in the token SDK and it's used the it's it's manipulated by the token API. Then, when it's time to store to make it real to make these actions happening and being settled in the back end. We have the concept of token request translator so now there will be a translator that take this token request that converts it to the data format understood by the back end so for fabric can be a read read set for Orion. It can be it can be another data structure actually running also supports a sort of data of of data of read read set what is important is that the meta data are are stripped out by by the token request translator because you don't want to store secrets right on the on the back end these secrets are just for the parties who have been involved in a specific in a specific transaction. Let me let me give you more a better flavor by taking an example so we understand also with the kind of information that are exchanged between these parties. Suppose that we have, let's say in this example we have two parties, Alice and Bob. These are the classical names that we always using cryptography Alice Bob Charlie Dave, these are the classical names that we use so we always refer to them. So where Alice and Bob, they want to exchange, they want to exchange, they want to perform an atomic exchange so Bob. Alice wants to exchange with Bob five usd actually bubble in exchange of five Swiss friends. So what they do what I said Bob will do with they will start talking to each other and assemble the token request by feeling the old sections of the token request that I showed you before so there will be a transfer section that contain the zero knowledge proof that Alice and Bob have constructed to, to prepare the transfer and there will be in the meta data section something about the something that deal for skating the zero knowledge proofs in a sense let me be very slowly at this stage because we're not going into the cryptographic, the cryptographic, the cryptographic details. So once Alice and Bob are ready they can sign the total request so they can put their signature there are anonymous signatures inside the witnesses, and then these objects can be sent to the to the back end for for commitment for settlement and to have this to have this settle sorry. So this is just a very high level business use case that you might have that can be converted in actions in the in the token in the in calls to the token token API. Now let me give you a sense of what's what's really happening behind the scene. When we have a fabric as a when we have fabric as a backup. So on the left hand side, we have a bunch of people business parties. We might have more than two business parties that collaborate all together in a peer to peer fashion, they come together and they decide they want to perform a certain token operations atomically. On the right hand side we have fabric with with a chain code installed that we call the token chain code. This token chain code is the creates the name space in fabric to store all the tokens that we are that the system manipulates over over over time. So now the first step is for this business parties to start communicating and assemble the token request I gave you before an example of us walk but it can be anything you will see with the API it's up to the developer to decide the the particular business business flow. Then at some point that this business part is this business party they also have to collect the order required signatures. These are the signature of the business parties but can be one or more signatures coming from an auditor that must see the transaction before this can be submitted submitted to the legends on and so forth. So once the token request is ready. What they do is that one of the one of them one of these business party will invoke the token chain for for a specific reason so now this business party they have the token request. They strip out the metadata because they don't want to leak this price secrets to the to the to the blockchain. Now the token chain code does the following thing. It to two specific things it validates the token request so he checks for example that all the zero knowledge group are correct that all the invariance of the payment system are satisfied like only the legitimate owner must transfer the tokens and no money out of the blue is created by the system. Notice that the token chain code if you are if you are using the driver that supports zero knowledge the token chain code does not enter for the endorsers do not learn anything about the content of the transaction because they see only zero knowledge proofs right so what they do they validate the zero knowledge proof and if if they are all valid they translate this the token request to something that fabric understood the red set. Now notice that at this stage we can we cannot yet verify double standing, which is another key key property of any payment system payment system because the endorsement as you know in fabric they can happen in part multiple endorsements can happen in parallel and in parallel the legend gets updated. So the double spending check can only happen at a committee time. Anyway, we got the chain code invoked the endorsers are responding back to responding back with the endorsement. The business part is now everything to prepare a token transaction sorry to prepare a fabric transaction and to submit it to the ordering service. So the transaction is submitting to the ordering service. All the committers the ordering service or the transaction the transaction is distributed to the entire network. And as you know now the committer are the committer are verifying that are verifying essentially two things that the transaction has been endorsed properly. They check for the signature and they check for the so called MVVC MVCC checks, which are, which, which, which are, which are about conflicts of keys in the key value in the key value store so this is the time where we have where we check for double standing and how do we do that? We essentially the translation of the token request to a read write set essentially will prepare a read write set that will generate a conflict if a double spend happens. And if if a conflict so the the the committer will understand that if a conflict happens this is essentially a double spend and the transaction will be rejected. So now I know what you are thinking this is very complex. There's a lot of steps going on. How will you ever, how can the API be so simple to handle all this complexity. Let me give you and I agree with you. So things are complex because the system handles a very, it has many wheels to make it running. So it's complex for a good reason I would say. And this doesn't mean that using it must be complex as well. Right. So we every day we're using our mobile phone without really knowing anything about quantum mechanics, even though the phone, the response are using the quantum mechanics in a heavy, heavy way. We will try to do the same. And let me do, let me give you an example of what it means to write an application with the token, with the token SDK, with the token SDK API. So usually you write what we call flows of views. Anyway, units of computation that perform perform certain certain oppression and these units of computation are executed by by the FSC notes that I showed you before and essentially the token SDK that takes care of executing these pieces of business business logic. So remember that for us the goal was we want something that doesn't speak about the underlying the underlying back end. We want something that doesn't speak about zero knowledge proof for any other privacy technology trusted execution or multi-party computation we don't want that level of complexity at the API we want something that is very high level. So the first thing if you if Paris has to transfer tokens to Bob, the first thing that Alice would do in general is contact Bob and say Bob I need one of your, one of your pseudonym because I have to transfer money money to you. Why is this because we want we want to listen Bob want to perform a privacy preserving the transfer right so as we will go we'll go to Bob and say Bob please give me one anonymous identity of yours that you will use only one pseudonym. Okay, this is the recipient so Bob on the other side will prepare the pseudonym and send it back. Then Alice to say okay I need to prepare an anonymous transaction because I don't want to leak any anything about who is the creator of this transaction. In this token transaction I want to want to perform a transfer that transfer tokens that comes from a certain wallet tokens of a certain type that comes from a certain wallet for a certain a certain amount. And I want to give this token to Bob. So one line. This is this transfer this this call to token API essentially load the token request with all the relevant the relevant information. Now the token request is ready, we need to perform all the all that complex protocol that I described you before, but for the from the point of view of the token API we just have a single call that it's essentially we call it's the collect endorsements. It takes care of everything takes care of contacting all the business parties to collect signature to contact the orders to to contact the endorses the fabric endorses or to contact any, any, anyone that needs to sign this transaction depending on on the specific token that you are using for, for this, for this transaction. And at the end, you want to order this the transaction that you can understand as settled, essentially you want to settle at this point that the the operation. It is that simple all the zero knowledge proof all the complexity of the back end are all hidden behind this call of the API of the token, the token, the token SDK. So if you're using the tool if you're using zero knowledge or if you're using transfer the execution environment or if you're not using any privacy at all. This code will remain the same. So this was very convenient for us and convenient also to develop to develop other applications. So here in this is from the website from the token SDK. GitHub repo, you will find multiple samples that you can, you can go through and discover a play with them. I really encourage you to do to do that so and give us feedback give us feedback and even contribute to the, to the get travel. So we are really happy today to involve as many as many as many of you as as possible. So last, last, last slide. Before I take, maybe I answer I see that in the chat there are messages that before I, maybe I take, I take live some of your questions. I really remember, let me recall you that the token SDK is is a set of API and services to develop a token based on distributed applications very quickly and with the motto right once play right once the site later the back end and the privacy model. It's basic though it uses new UTXO model to represents the tokens supports fungible and fungible tokens it has a programming model that is very close to the business to the business logic. You can find the most documentation and samples at the on the GitHub repo repo and you can reach us all on Discord on the Fabric token SDK, Fabric token SDK channel. With this I will stop, maybe I can either take live questions or I can look at the. I can look at the questions on the on the chat. Let's see. Let me start from the last one. Who installed the chain code in Fabric. So the chain code is part of the setup of the of the farm if you're talking about fabric that's part of the fabric, the fabric in the fabric set up so I would expect that the administrator one or more administrators of the network and the four of the organizations in the fabric network, they will receive the token, they will receive the chain code the token chain code package, they will install on their peers and they will, they will, they will follow the deployment, the deployment path. How committed to send the validation message to the FSC node back is very good that's a very good point so the FSC the FSC nodes will connect to a trusted trusted peer to say in the same organization to learn about which transaction are committed so actually the FSC node leverage the delivery service of the fabric peers to learn about the what to learn about the status of each of each transaction of course you need to take care because you want your FSC node to connect to either trusted peers or to connect to in the same organization or to connect to multiple peers and to take the majority of their or their or their answer. Oh, but I feel now I see that also earlier once and oh maybe I don't have to then I feel there are really many answers so maybe I can, I don't have to take further. So this was my last slide and now I think we can jump if there are no other questions so we can jump to counter and to see what what it means to do interoperability with the token, with the token SDK. Okay, somehow I cannot start like video but I think it should be fine. So, what we'll be discussing in the next thing half hour or so is interoperability in the token SDK. And, okay, do you see my screen. We can see your screen it looks great. Okay. So there are two use cases that we focused on for the interoperability in the token SDK the first one is asset exchange and this is what Corentin earlier, I think Corentin and Clément earlier touched upon which is basically you want to exchange let's say CBDC for securities and you want to have this exchange happens atomically in the sense an entity can only receive the securities if they pay for it and vice versa. And the second use case is asset transfer, and this is basically reflect the movements of assets from one network to the other. As Corentin and Clément mentioned earlier in the asset exchange we are assuming that the CBDC resides in one network they will not leave that network and the securities reside in another network and they will not leave it. Whereas in the asset transfer the scenario we have is that the assets, you could imagine there is the first network of CBDC and then there is another network of CBDC and that's somehow the assets they will move from one network together and you want to make sure that the assets are transferred from one network to the other that there is a preservation of value across networks in the sense this asset will be destroyed in the first network and an asset with the same value will be created in the second network and if this creation of asset phase in the second network you want to make sure that you could actually roll back let's say the destruction of the asset in the first network. So the first thing we will start with is asset exchange and we start with sort of like an overview like or like let's say the basic use case that we try to address when we talk about asset exchange. So here we assume that we have Alice and Bob so we have Alice in network A and for simplicity we say okay this network is for Euro and Alice and Bob they are both in the same network that they both kind of can send and receive as like CBDCs in that network and then we have a second network which is network B in which we have security and the use case here is that Alice would like to exchange 100 euros for 100 let's say bonds and she agreed with Bob on that exchange which is very important to keep in mind here is that HTLC or let's say this asset exchange or the assumption in this asset exchange is that Alice and Bob they are rational and they are online and it will become apparent why we have this assumption like why they should be rational and the online especially if we are using HTLC for the asset exchange. So, so I think already and already described a bit how HTLC looks like in here I will just talk to the expand on that. So when it comes to HTLC what we are the first thing that would happen or the first interaction that would happen it would be Alice and Bob agreeing on the terms of the contact. And here the terms of the contract if we go with the example I presented in the previous slide would be Alice saying yeah I will pay 100 euros for 100 E bonds. And then there are other elements that are specific for HTLC and those are the hash and the time out. So those are kind of also let's say in some way are part of the contract. And here for simplicity or like just for the sake of clarity we would assume that Bob is the one computing the hash so this is HTLC is asymmetric in the sense when we start the HTLC Alice and Bob they do not know the same information for example in this case we have Bob he would pick a secret value x and he will compute the hash of x and Alice will only know the hash. At the top when we start the HTLC so Bob will compute this hash of x you will stand the hash of x to Alice. And Alice would based on this hash of x based on the time out they agreed on and based on the terms of the contract which is like yeah I will transfer to you 100 euros for 100 E bonds it will create a transaction for Bob. And Bob will do also the same for Alice. And here and it's something that is very important to keep in mind here is that whoever knows the secrets that is behind the hash should be the first entity to submit the transaction. So here we have Bob knowing the secrets behind the hash so Bob is required to first submit the transaction into this network where we have the security because Bob here would like to transmit the security. And the transaction that Bob would submit will lock the 100 E bonds for Alice. And it will specify what we call unlocking conditions in here the unlocking conditions are Alice revealed x before time out which is in this case the double of the time out they agreed upon or if Alice doesn't meet this condition in that case Bob would reclaim the bond. So basically this means if Alice does not claim this 100 even even even before the time out elapses Bob could just go in the reclaim the 100 event. Once Alice sees that this transaction will successfully submitted into the security network, she will go and submit her transaction into the euros network so basically here the unlocking conditions. Of the transaction that Alice is submit is that Bob revealed the secret key behind the hash which is the hash of x before the time out elapses here the time out will be T whereas in Alice. So transaction whereas in Bob's transaction the time out with double T. And if Bob does not reveal the secret before this time out elapses then Alice would be able to just get would be able to just get back for 100 years. So it's very important that this order of the submission of transaction is respected, because if we flip this order. What happens is that Alice will submit let's say first that transaction both does not have to submit his transaction because the moment that transaction is submitted by Alice, he can just claim it because he knows the secret key to claim the token that Alice lock in her transaction. So it's very important that whoever knows the secret of the hash is the first party to submit the lock the first party to submit the lock transaction. So this is like classical HTC and and token SDK will provide support for them for this HTC in a very simple, let's say, manner. So we we kind of the token SDK does not necessarily care about how this terms of the contract are kind of read upon so as I said the terms of the contract would be the plan out. The hash that is the hash that is would be used in the HTC plus the value and the type and basically the center in the recipient. So those terms are agreed upon, let's say, out his bank, although in the token SDK actually will provide no kind of mechanisms that allows one to have these interactions but for simplicity will just assume that we get this information. Out of them. And now we say that for the support HTC the owner of a token and the token SDK can be an HTC script and then HTC script is specified very simply so it just have let's say four fields. Basically it identify the standard it identifies the recipient. It has a hash and the plan out. And then a lock of the token and the token SDK corresponds to transferring this token to this HTC script so basically this is a token whose owner would be this HTC script so it will go back to what Angela presented saying okay we have a token that has a type of value owner. To support HTC we don't have to change the definition of the token we keep the definitions as it would just kind of extend what an owner is so in our case now an owner could be an HTC script which is defined by four feed was sender is an identity recipient is an identity and hashing some out are just like a string and duration. And we provide a simple API to kind of build the transaction for lock in a token for the HTC script so we have the lock that takes the sender wallet. It takes the recipient it takes the value of the top and the hash and the sign out so this is kind of very straight forward and behind let's say and under the hood but the lock that is actually to create a transfer transaction in which the owner is an HTC script. Now, there is the claim operation which corresponds to the happy pack so basically Alice and Bob that are both online that are both willing to complete the cycle of the HTC script so the moment they see a lock transaction. They would claim conditioned on them receive like condition on them knowing the preimage of the hash in the in the script. So here the claim would just have the recipient wallet it will have it will identify the locked token and it will take the preimage. And why we do have the recipient wallet is that the lock in of the token is not only show me the preimage, but also show me that you are the recipient identified in the HTC script so we say okay I have to see permit preimage but this preimage should be, should be actually sent by the recipient and HTC so the recipient needs to sign this transaction in addition to providing the preimage. So what what the claim does is very straightforward it will just transfer the ownership of this lock token to the recipient. So basically we just sort of change the owner so the owner fees now is no longer the script is going to become the recipient and again the claim is just a transfer so under the hood the claim use the transfer that was presented earlier by envelope. Now this is the claim which as I said is the happy path so basically both parties decide to just continue the protocol and sort of claim the asset. The reclaim corresponds to what you could think of as the unhappy path so basically for example Alice Bob submitted his transaction Alice submitted her transaction but then Bob for whatever reason decides just not to continue so he doesn't submit the preimage. So in that case Alice can reclaim the token and the way to do that is just she. You should be good to go. So here what we have the reclaim as I like the like I said the reclaim corresponds to what we could think of as the unhappy path in the sense both doesn't claim the token and doesn't reveal the preimage then Alice just go and reclaim her token and the reclaim let's say API again very simple we just have the sender wallet and the lock token so basically we identify the token that needs to be reclaimed. And this would be this reclaim would create a token whose owner now is the sender which would correspond for example to Alice and this reclaim transaction which is again just a transfer transaction would be signed by the sender so as a verifier. And in the talk like as a validator of the transaction. If I see that this is a reclaim our only accepted if first of all the time out has elapsed and if it was signed by sender of the lock token so basically by the initial owner of the lock. Any questions. Okay, so just to kind of go back to the point about being online and rational is that when it goes to when we when we talk about HTC, we have these time out so we have the time out, for example, if I go to the previous slide. We have this time out for example team. So we could easily imagine that if Bob revealed X right after T elapses like he wanted to he wanted to kind of claim, but for whatever reason the transaction was delayed, and what he just kind of did not submit the transaction. Like, as early as possible, what could happen is that Bob would reveal X right after T elapses and then he cannot claim because the condition is that like you have to make sure that you submitted it before the time out time out elapses. But then Alice now has X so she can she could claim it the asset that Bob locked for her because, especially if this time out this double T has not elapsed. So it's kind of you could you could run into this case where Bob could not claim the token but Alice was able to claim the token so it is very important that like the moment we see the transaction submitted we have to go and claim them so we should be able to not wait until last minute because we could actually end up in these situations where I claim but it's just a little bit too late so I cannot really claim whereas the other party could go and claim the asset I lost for them. So it's a very important to kind of this online condition is very important so it cannot be that like yeah I submit the lock transaction and then I go offline you submit the lock transaction and then you kind of try to submit the claim transaction as soon as possible. Okay. So now I move to the asset transfer and as I said the asset transfer is more about moving assets from one network to the other so whereas in the asset exchange the assets say the assets saying the same. They do not like change networks. So the way we implement asset transfer or the way we think about asset transfer is that to implement it what we do is that we let's say we assume that Alice would like to transfer 100 euros to Bob. However Alice is in network a whereas Bob is in network B so they do not reside in the same network so Alice cannot just send assets to an address in her network because Bob is not part of that network. So what Alice does is that like say okay I will send the asset the asset cross networks however it's very important to ensure that like when Alice sends this asset cross networks that the asset is destroyed in her network and it is created in Bob's network and that this destruction and creation of asset is atomic and also preserves value. So if, for example, the creation of the asset space in network B Alice should kind of be able to kind of reclaim her asset in some way so because the transfer phase now she should be able to just like the gets back her token. So this is what we kind of specify here so that's across network transfer could be understood as a redeem and the origin network or in the network of Alice and an issue in the network of Bob. And what is also important is that to ensure that the values that are being destroyed and created the other thing. So again, when we go back to the token SDK and what Angela presented the token SDK has tokens that are defined just as owner typing on just as owner typing value so we do not have anything that is sort of dedicated for cross transfers and we do not really want to extend the token definition just to support it. But what we do is that we say okay the owner in the token SDK is quite flexible because just a stream of bytes. And we said okay now would specify an owner which is a script like what we did with the issue he and the script we call it like a pledge. In the split script sort of specify under which condition. If we take the case where Alice so basically Alice is led to the token for pop. So the script would for what specify okay this is a token that is pledged for pop. Bob is in network. Bob does not claim the token before a certain time out, then Alice should be able to get back her program. So this is sort of the conditions that this pledge script try to capture. Now we if we go in sort of just try to think about the flow of this cross network transfer so we start as we said like Alice would create a token for Bob and it will specify script that actually captures let's say this cross network transfer. Alice would notify Bob because Bob doesn't have a way to know if the token was pledged for them because he's not part of that network so Alice would notify Bob and say okay I look token for you and it will give him the identifier of this token. Again because Bob is not part of that network you cannot just like take Alice's word for Alice's word like for granted because Alice could just be lying. So what Bob does is that he uses a relay service, which is kind of provided by the hyper ledger weaver. And this is a relay service that is trusted let's put it this way by his network. So Bob leverages this relay service to get to prove that actually this, there is a token and Alice's network that is pledged for him. So he would sort of contact the relay service he will get this proof, and he would inspect that this token and the proof are valid and that the token actually corresponds to whatever he's expecting. And then Bob would contact the issuer in his network whoever is responsible for the introduction of tokens in the system in his network they will contact them and they will contact them with the proof they have received from the relay service. Now the issuer would check that the proof is valid. And then they will check that actually the time out has not elapsed because as I mentioned at the beginning Alice would specify time out before which Bob can claim the token. So whether the proof is invalid or that out has elapsed the issuer would just reject so he would just decide okay I'm not going to create the token. However, if these two conditions, if the conditions that is like the time out has not elapsed and the proof is valid are met the issuer was created token that has the same value that has the same type, and which is intended for Bob. And then it will also publishes in this let's say issue transaction, the hash of the token ID which is the identifier of the token that was pledged in Alice's network and the origin which is the network in which this token was pledged which is in this case will be a network with Alice's network. And why we add this hash of token ID origin is that to prevent Bob from claiming the same token twice, because you could just imagine that like the issuer doesn't store this information and then later Alice's with Bob would just come again with the same proof and they would present it to the issuer and the issuer would just issue the token again so it is very important for the issuer to keep track of the tokens that have been pledged. Okay. So, now if you want to just sort of go across what we have what what is the information that we have in the script and like what is the flow between the claim and the reclaim. We kind of, yeah, this is what we will be actually addressing now. So again, as I said the scripts, the pledge script specifies, as I said that this is a token for Bob, Bob is in certain network and that this is the time out. They also specify another information which is the identity of the issuer and the origin network which would help the sender to reclaim. So this is the case where let's say Bob for whatever reason they do not claim the token in their destination in their network. And now Alice said, okay, I see that Bob did not claim the token or like Bob tells me that he did not claim the token. And I go and I sort of try to reclaim it and I would have the issuer in my, let's say, in my network sort of creating again the value that was blocked for Bob in the pledge script. So, again, like in the previous slide we just talked about claims, whereas in this slide we will talk about claim and reclaim. So again, a pledge token would rely on invoking this relay service to get a proof that said, okay, there was a pledge token pledged for Bob in Alice's network. Bob then they will invoke the issuer with the proof and then the issuer would check, yeah, this proof is valid. I see that the time out has not elapsed. And then, as a result, the issuer would submit an issuer transaction that would create the token for Bob and then it will add this unique sort of hash to the ledger to make sure that Bob can move that. Now, if Bob doesn't claim what Alice could do is that they will invoke the relay again, but this time the relay is more for the network of Bob, and they will get to prove that the token they have pledged this kind of that this check, because it's very important, because we have to make sure that this relay service sends this proof of non-existence after the time out elapses. So the relay service they will send the proof that says, yes, I checked the ledger for this hash of token ID origin after the time out has elapsed, because otherwise you could imagine Alice going to this relay service before, let's say time out elapses, and then the token doesn't exist in the ledger. Alice goes back to her network and says, you know, I have a proof that the token was not claimed, and then Alice would kind of get back her token, whereas Bob meanwhile would go and claim, because he still had the possibility to claim, because the time out has not elapsed yet. So basically it's very important to have this proof that it does not exist, attached to like the proof that the time of this query, whether the token existed or not, is larger than a certain. As for the ownership of a token to a pledge script, the way we do it is by calling this pledge function, which take the standard wallet, the destination network of the recipient, the deadline, the identity of the recipient, the issuer, as I said, this is mostly to help the sender reclaim in case some issues happen with the claim, and then there is a unique pledge ID, then there is typing value. And this pledge will create a lock token that has an owner pledge. And then we have the claim method and this is invoked by the recipient and it sort of has a very simple, again, interface so we have the issuer. We have the type, the value, the recipient, the identifier of the token that has been pledged and the origin network and then the proof and here the proof is the proof from the relay network that says that the token has been pledged. And the reason we have the proof here included in the claim is more for, let's say, auditability purposes. And sorry, I mean, I mentioned that the claim is submitted by the recipient, it's not submitted by the recipient, sorry, it's submitted by the issuer. So the claim is the one sort of submitting this transaction. And again, the claim was just created token for the recipient. A reclaim will transfer again, as we said, the ownership from the script to the sender and the way this is performed is by calling the method reclaim which has an argument, the sender, the pledge token, the issuer signature that was received by the sender and sorry, and the proof. And this reclaim would just create a token for the sender. Again, these are sort of a bit of a low level methods in the sense in the token SDK repo, we have applications that sort of handle everything you see here. So basically they had like you see a method that sort of orchestrates the interaction between the sender, the recipient, the relay service. So this is something that whoever is developing applications for this cross network transfer the most have really to worry about, because it's taken care of by the token SDK. So we have to provide views that handle these application interactions. So it's not something to that like whether it's developing an applications that have something to do with cross network transfer, they do not have to worry about this. Any questions. Okay, so with this I conclude my presentation unless you have any sort of questions either for me or for my colleagues. Ellie maybe back to you for our closing statements or I'm keeping answering questions on the on the chart here. Sorry, I was a minute. So thank you Carter. Thank you all. So, I don't know if there are any questions that haven't been answered that you would like to bring up. Now we still have time to answer those early. There's always the discord channel and don't forget. Yes, there is always a discord channel and also we are all happy also to answer questions via email. So many many thanks for your time attending this workshop hope that it was useful to all of you. I see a question did just come in on the zoom chat. Sorry, can you please tell even provision the database as a service in cloud. Is it possible to connect. I think it is a follow up question to one of the questions that are in them. So, yeah, yeah, that's fine. That's fine. Maybe the question of this one is this architecture or similar architecture being used by any federal governments in the world for CDBC implementation. Maybe you can take that one. I'm sorry, if you're referring to the architecture of two tier, likely two tier architecture. I'm, I'm, I don't think I can answer this question. I know that it has been the recommended one by pretty much all of the central bank. I have a couple of currency reports of central banks and they've been more than 60 on this point. I, as I mentioned, DLT based architecture is for the wholesale CBDC is there is consensus that there is alignment. In fact, I would say that for the wholesale CBDC may have some information but I'm unfortunately not able to to share at this point because it's confidential. I don't know. So initial, if I'm pronouncing your name correctly, which architect, what's level of architecture are you referring to the two tier architecture or a DLT based implementation of the wholesale CBDC or the use of token SDK. I meant, yeah, this is Sitaram. Yeah, Karthi. Yeah, whatever you presented right in the last slides. Yeah, I'm wondering if that architecture or similar architecture being used by any, you know, federal governments in the world, you know, because I know China, they have implemented CBDC one year more than a year and India is it's in the initial stage of implementation. So I'm just wondering if any of them are Japanese in plan I have that's what we are hearing right or other government some other governments. So I'm wondering if this did they use this, you know, hyper ledger based architecture which you are showing as a use case or did they use their own, you know, implementation of blockchain. Okay, will you stick to say that there is definitely a very advanced interest on the token SDK but unfortunately not able to say more than that. So wholesale and and to retail central banks or currencies much stakeholders are not seeing with interest token SDK capabilities I mentioned because of the combination of privacy and and regulation compliance particular audit support. What about other architecture whatever other ones you have shown. The other elements of the yeah the previous slides I mean before the token one right you have shown the initial them or them use cases. Oh, the hyper ledger fabric you mean the three. Yeah, yeah. Yeah, so token SDK but also hyper ledger fabric comes for wholesale central bank this currency quite relevant. As I mentioned before, the same holds from. I mean, I don't know if if David has something more to others as a hyper ledger, but from. I know for sure if you use the central bond digital currency tracker. And the web page you would be able to see quite a few experimentation until it's looking at hyper ledger fabric, but there are also some advanced versions of those, but unfortunately I'm not able to say more. Oh, okay, okay. Thank you. I'll just add one thing and I'll drop a link I mean in terms of case studies that we can talk about publicly there are a number of published case studies on the hyper ledger website not all of them necessarily related to CBC is it kind of covers a range of use cases but there are, you know there are some deep dive case studies there and some of them do touch on this topic so you feel free to check out that link. Oh, okay. Okay. Thank you. And for the attendees we are going to send out a thank you email with links to the video. Relevant links. If we can get the decks from the presenters. All that will be up there and you can also find them if you if you're not. If you don't get that we have a link to the wiki page for this event at the top of what I just put in the chat. Let me thank you very much for organizing all this being great thanks a lot Dave. Yeah, well thank you so much I am glad there was so much interest in this topic and thank you. Thank you. Thank you everyone. Thank you everyone. Thank you. Thank you. And we can post questions right we can interact with you guys. Let's move this call that's better. Yeah. Okay, great. Yeah, we'll go away as soon as this ends but yeah the discord is permanent feel free to join on discord chat hyper ledger.org and yeah you can talk to people there for sure. Cool. Great. Thank you. Thank you everyone.