 Let me first thank you for giving me this opportunity to talk to you a little bit about our Panca d'Italia solution, which is called tip-sush link. Next slide, please. In this presentation, we want just to give you a glance of the basic feature of tip-sush link. Plenty of information will come into the demo, the demo video that you will see after that, and what you will find in the service description documentation that we are going to provide to you. It is a living document, so we will gain expertise and it will drive us along this journey of the exploratory work. Basically, our tip-sush link solution offers an interoperability model between generic market DLT platform and payment system, and it is based on a DLT agnostic application programming interface. DLT agnostic means that we do not trust of any specific features on the DLT side. Basically, we have no requirements for external DLT besides two very basic features. First, cryptographic primitives like hashing and second, the capacity to run smart contract. All the business logic resides on the market DLT. Our API is a REST-like API, so it is based on this protocol and the payload of the messages is standard ISO 222 payload as we used to in the target services domain. Next slide, please. Well, this is just a quick word cloud, meaning that all the things, all the topics that are covered by our service description, going through the onboarding process, all the features of our solution, are detailed API catalog together with a swagger, some sort of sandbox where you can interact and simulate our APIs. And then all that comes with the experimental approach by the Euro system. So onboarding, liquidity management, business day with tips such link, handling with normal and abnormal situation as well as use cases. Next slide, please. Well, here, just to remind you about the onboarding and testing process, but already was shown by the ECB very well. So the Legible Market Participant and Operator must complete their technical onboarding process before taking part to trials and experiment. Next slide, Market Participant and Operators have to send a sign from three. Actually, now we have a little bit changed the game of the three forms. It's the registration form part two, which is solution specific and send it to their responsible NCB to be allowed to operate with tips such link. Then we go through the testing phase one, as we did technical connectivity security mechanism test with the API gateway component, and we may conduct some operational and functional tests. Then we have, already know this, the testing phase two where Market Participant with their responsible National Central Bank and Market the Operator would perform some some sort of dress rehearsal, a full trial day process with the desired use case. And then last but not least, as Holger mentioned, we have the signing of the legal arrangement between the Euro system Legible Market Participant, as well as Euro system and eligible market DLT operators. Next slide. Well, here I want to highlight a specific feature of our tip such link solution tip such link solution is hosted inside Bank of Italy and these are second instance of the tips engine, but trusting on the multi currency capabilities of tips. Tips such link can segregate. I mean the trials for from experiments by using two different currency codes, the EU are standard currency euro for trials in the EXP for experiments. There is very little difference just in the specification when invoking the APIs, but we can enjoy this full segregation of cash, not mixing real money for trials with the mock transaction for experiments. Next slide. And another aspect that you can find in a service description is you to a and a to a connectivity. So plenty of information on how to interact in a a to a mode by invoking all the APIs for submitting transaction like TVP, but also you to a channel for basic information tools and monitoring purposes. Boot function enjoy all the security features that are provided with the API gateway, such as the IP filtering and the user access control. Next slide on the information tools. Very quickly at the following way. Or you can find the swagger where all the APIs are well described and these URL provides four different sections, one for a tip such link overview, the full service description documents and the gateway and participant API. And when it comes to monitoring how the trials and experiment are proceeding, then each project, let's say, which is trial or an experiment is identified by a specific acronym PRJ and an ID. All the projects, let's say, are fully segregated and there are specific views for the user there. And the dashboard the user can can access is made to display selected reports data in a tabular form, change the date the reports refer to and copy export all the data they are involved in the experiment or trial. Next slide. And then in the end, the full protocol description use case by use case. Here it's just a sample of all the steps which are described for a DVP to happen with tip such link, and it's made of five steps that are described very into details, and we will see in the upcoming demo. But also other use cases like lifecycle management and so forth. Again, it is a living document. So we will try to add the more use cases come the more we will publish into our service description. So we are finally there and we can start with our demo on let's say a complete show of the exploratory work phase with tips such link and deep dive into the DVP flow. Dear participants market DLT operators, ECB and central bank colleagues. Welcome to the demo of the tips hash link solution operated by Bank at Italia. In this presentation, we will give you an overview of the specific demo setup. Then we will describe all the phases of the exploratory work business day. And finally, we will have a deep dive into the DVP trial flow. The first item we will illustrate is the tips hash link demo setup. The reference setup for today's tips hash link demo consists of a market DLT platform here shown on the left hand side. The yellow square in the middle represents the tips hash link infrastructure operated by Bank at Italia in a private cloud environment. The last square on the right hand side corresponds to T2, the real time gross settlement system owned and operated by the Euro system and used to implement the escrow mechanism. Today's business case is a trial DVP transaction between two eligible participants. In the slide, they are represented by the seller and the buyer. The asset leg or the transaction is settled on the market DLT platform, whereas the cash leg is settled on the tips hash link platform. Participants have wallets in the market DLT platform and Euro denominated accounts in tips hash link. The seller owns the asset to be exchanged in his wallet. The icons of the seller and the buyer in this slide correspond to the participants software applications that communicate directly with the market DLT platform and the API gateway. Now we will illustrate the tips hash link standard business day. This is the standard business day schedule with all the cutoffs from 9am until 3.30pm. The trial DVP flow we are presenting today can be broken down into four main phases. The first phase lasts until 9am and this is when the funding process of the central bank escrow account takes place. The second phase goes from 9 until 9.59am. During this period, Bankad Italia as tips hash link operator performs the minting process on the tips hash link cash accounts based on the information provided by the relevant central banks. The third phase goes from 10am until 2pm and is dedicated to the real-time settlement. Finally the fourth phase that goes from 2pm until 3.30pm and consists in the execution of the end-of-day procedures which are the alignment, the burning, the defending. Given this background information on the different phases of the business day schedule, we can now introduce our DVP trial flow. So the phase one is the funding process. Until 9am participants are expected to fund the central bank escrow account via the execution of a liquidity transfer from their RTGS account in the T2 product environment. The central bank prepares the minting form with a breakdown of funds received from all participants and sends it to Bankad Italia. The second phase is the minting process. The operator means the exploratory liquidity by debiting the Euro-transit account and crediting the participant cash account. This happens via the technical injection of account 050 liquidity transfer XML message which is based on the information taken from the minting form. Worth remembering that the TIPS-hashlink solution operates with the same ISO 2022 standard XML messages used in the Euro-system target services domain. At the bottom of the slide we have reported what the operator screen looks like at the start of the day. As you can see, all TIPS-hashlink cash accounts have a zero balance. This is because for trials, no liquidity is carried overnight. In this slide we continue describing the minting process. In particular, we highlight the data needed by the operator for the exploratory liquidity minting process. And these data are the currency code, the creditor big, the creditor account, the amount and the settlement date. In the table we can also observe the participants' main information which are the account ID, the cash account name, the party big, the currency code, Euro for trials and export experiments. With regard to the cash account name structure, please note that the second and third letters represent the central bank account record, in our case IT for Italy. And the suffix is the trial or experiment ID, here PRJ1203. With the minting execution, the amount is transferred from the Euro-transit account to the participants' account and the balances are updated. As a consistency check on the TIPS-hashlink platform, the operator verifies that the sum of the balances of all participants' accounts is equal to the overall balance of the Euro-transit account. And this is the same for all the accounts used for experiments. After the minting execution at 10 am, Bankad Italia opens the API Getaway A2A channel to the external world. From now on, participants can start submitting DVP transactions. So far we have shown what the operator screen looks like. Now we present the dashboard of the users. Central banks, participants and market DLT operators can check the balance of the TIPS-hashlink cash accounts after the minting process. In this example, we display the cash account balance involved in the minting process of the trial named PRJ1. Please remember that each trial or experiment has a specific segregated data scope. From 10 am, we enter the third phase, the so-called real-time settlement phase. Participants may now submit DVP transactions until 2 pm according to the TIPS-hashlink DVP protocol. This protocol, which we will now describe in detail, is structured in four steps. The first one is the DVP initialization. In this simulated trial, the seller invokes the initialization service on the API Getaway by communicating the DVP information. The API Getaway then generates the DVP identifier, the pre-images, which are kept secret, and the corresponding cryptographic proofs, here shown with the red and green locks. The DVP identifier and the cryptographic proofs are collected in the API Getaway response, which is sent both to the seller and to the buyer. The next four slides describe the second step of the TIPS-hashlink protocol that takes place on the market DLT platform. The seller collects the data received in the initialization response and publishes a hashlink contract on the market DLT platform. This current slide shows the main hashlink contract attributes, the DVP ID, the asset ID, and the hashed pre-images protecting the asset. Here, you can see the specific hashlink contract address where all these data are stored. This address can be visualized with a blockchain explorer tool, as we will examine in the next slides. To check that the hashlink contract actually contains the locked asset, the buyer uses the blockchain explorer tool by typing the hashlink contract address in the search field. This information is shown in the slide in the yellow square. The asset is transferred from the seller address to the hashlink contract address. Look at the column marked with from and to. Furthermore, by clicking on the transaction ID that created the hashlink contract, the buyer may retrieve further transaction information as shown in the next slide. The buyer can retrieve here the hashlink contract address, the hashed pre-images, and the asset ID. These data are the same received in the initialization response of the API gateway. Let's now consider the seller's view. As illustrated here, all the data available to the buyer are also available to the seller. To access this information, the seller uses the blockchain explorer tool again by typing its own address or the hashlink contract address in the search field. We shall now continue by describing the third step of the TIPS hashlink protocol, which is when the buyer can proceed with a payment. In a simulated trial, the buyer invokes the payment service on the API gateway, which embeds a standard PAX008 XML message. The API gateway forwards the payment message to the TIPS hashlink settlement engine, and the engine transfers the funds from the buyer's cash account to the seller cash account. Finally, the settlement engine generates a payment response in the form of a PAX002. Such response is then forwarded by the API gateway to both the buyer and the seller. The payment response carries the DVP transaction identifier received in the initialization response in the step 1 of the protocol. The TIPS hashlink operator can monitor the settlement process by checking the statement of accounts and the balances. In the statement of accounts here, you may now see the set of transactions with the amount agreed between the seller and the buyer. At the bottom of the slide, we report the updated cash account balances. We now move to the last step of the DVP transaction protocol, the DVP finalization. For the purposes of this demo, we only consider the happy path identified in the protocol as the cooperative or bilateral execution. The collaborative seller, after receiving the payment response by the API gateway, immediately unlocks the asset in the hashlink contract by transferring it to the buyer's wallet. Since this is the happy path example, the activity is completed without sending any pre-images to the buyer. In the blockchain explorer tool, both the buyer and the seller can now display a new transaction, the asset leg or the DVP. Here we can see how the asset has been transferred to the buyer's wallet. All the steps of the TIPS hashlink DVP protocol have now been completed and both the asset leg and the cash leg of a transaction are settled. In the slide, we can observe the participant's dashboard showing the statement of accounts where they can check all the payments and the liquidity transfers that took place during a specific trial. With the real-time settlement completed, we can now move on to the last phase of the business day schedule, the phase 4, that takes place from 2pm until 3.30pm. During this time, the end-of-day procedures are executed. Bankad Italia closes the TIPS hashlink API getaway A2A channel and from now on, any further incoming requests are rejected. The end-of-day procedures that Bankad Italia performs in phase 4 are the alignment reporting to all central banks, the burning of the exploratory liquidity, the creation of the reports to support the central bank defunding process in T2. So the first procedure is the alignment. This is triggered in case of transaction between eligible market participants of different jurisdictions. To perform the alignment, Bankad Italia processes the statement of accounts, calculates the bilateral turnovers and sends a report to each central bank with the amounts to be transferred to the other central banks' screw accounts. At this point, the updated balance of the central bank's screw account corresponds to the amount that will be defunded to the market participants in T2. In our example, no cross-border transaction took place, therefore the turnovers amount to zero. The second end-of-day procedure is the so-called burning. The operator burns the exploratory liquidity by debiting the participant's cash account and crediting the Euro-transit account. This happens via a technical liquidity train. At this stage, as already illustrated in the minting process, the operator enters all the needed parameters, which are the currency code, the debt to be, the creditor account, the amount and the settlement date. When the burning process is completed, all the balances of the participant's cash accounts must be zero. We have now come to the last end-of-day procedure, the defunding. The operator runs an automatic procedure to generate the defunding report to be sent to all central banks. These reports contain the breakdown of funds to be transferred from the central bank's screw accounts to the RTGS accounts of the participants in T2. All the end-of-day procedures have now been completed. There is one more step the operator has to perform, the change of the business date in the system. This activity consists in sending a camped 0.19 message to the TIPS Ashling platform. The business date has now ended. This brings our presentation also to a close. We thank you for your attention and the colleagues of Bank of Italy are now available to take your questions. So, really thank you for your attention and now reading the chat. Very few questions, thank you. I don't know if this is a good or a bad sign. Giuseppe, that's a good sign. That means it was totally clear. Starting from a couple of questions about the swagger and the TIPS Ashling KPI specs in the URL invalid page not found. Well, actually you were so quick. Thank you. But as we explained for security measures, the U2A access is protected with the IEP white listing. But in this phase, you will have plenty of documentation, all the API catalog and description into the service description. But as soon as you have an expression of interest with TIPS Ashling, when it starts connectivity and onboarding, you will get U2A access and then everything will be disclosed. And then coming to the command line screenshots of the API gateway is shown into the presentation. Well, actually let me explain that that was only the TIPS Ashling operator view for the sake of transparency. We just open the engine chassis to let you put your eyes into our engine. But the banks only need to connect to the API gateway by invoking the APIs. I stress this point because the Ashling solution does not require a participant to run any particular software component interaction. Only happens via REST-like APIs. So the U2A protocol, which we call Ashling. Now I see, yeah, the question that I see on the screen is about consistency and how TIPS Ashling solution realizes atomicity. Well, actually through the APIs and with the happy flow and all the Hanepi parts, I mean, there is a state automata machine that you can follow. And it is completely described into the service description. So by means of using the pre-images of the secrets, if there is no cooperative execution, then the seller or the buyer can trigger a forced execution of a forced cancellation. But through the usage of all the APIs, as you will see in the full description, then you can enjoy, let's say, full integrity between the cache lag and the security lag of the DVP transaction. We make, for instance, the DVP, but it could be a PVP interleaked operation, whatever. But everything will be more clear and very well detailed into our documentation. And again, you have our contact, so even for the nuts and bolts, just drop us an email and we will reply. I hope I answered correctly to your question.