 Okay, yeah, I'm putting you on the call. I have it all recorded. The recording is going on. You know, you can start. They can all hear you. I will be back on the internet as soon as I can. But in the meantime, welcome to the capital markets. I'm connected to money's phone. I can talk about a couple of things. One is the code of conduct. We are supposed to be obeying the code of conduct from the next foundation, which means that we treat each other with respect. The second item on the list is the antitrust policy that is the only requirement that is needed for us to be on this call. Otherwise, it's completely open. So if you do not agree with the antitrust policy, please log off the call. Then I will first start off by asking if he is on to talk about the insurance subgroup and then we will launch directly into the into the white paper. Thank you. Thanks. We've been. Hi, everyone. My name is. I'm with Citas FinTech, which is a startup which is based out of London. I've been a part of the capital markets for a while now. And I've been working in both the domains, which is capital markets as well as insurance markets. I've seen that there are quite a few blockchain and distributed ledger related projects, which are running with a certain degree of maturity in Europe as well as UK for the insurance space. However, there's still a lot of hurdles that need to be overcome. And I thought it would be a great opportunity for people who have expertise in the insurance markets to come together and do something similar to what capital markets has been able to achieve so far. Some of the things I was proposing are more on the lines of building taxonomy, looking at standardized data structures, a common domain model for insurance. And of course there are lots of use cases from B3I and other companies within the insurance space. So I think it's a great opportunity for us to kind of focus on some of these things. I've also kind of looked at updating parts of the insurance projects subgroup, which is within the wiki for Hyperledger. So there are some of the points that I speak about, which are clearly articulated there. I also think that there's a great opportunity to look at some of the business architecture, which is associated with maturity that is required for a business to be on the blockchain. So these are some of the business problems that I'm trying to kind of address. With me, I bring in some more colleagues of mine who are interested in being a part of this focus group. And that's kind of the gist of the message that I wanted to kind of put forth to the group and kind of hear your thoughts on how should we kind of progress on this and what could possibly be the next steps. Thoughts, anybody? Questions? No? Is there anyone associated with insurance in this group today? Anyone on the call? In any form? Not me, unfortunately. Neither. So I guess then I think it opens the avenue for us to kind of bring some more people from insurance background into the specifics of group and organize a different focus group. That's just a thought process I wanted to put forward to. If you have colleagues that you want to refer to this subgroup, insurance market subgroup, you're more than welcome to send out the links which are on the wiki. And the purpose statement that's clearly part of the wiki. So that's to summarize everything I had on the agenda for today. Thanks, everyone. We've been back to you. Yeah, I am now back on the internet. So that's good. I keep talking about people's struggles with that, the whole internet thing, ever since this whole pandemic started. Anyway, money will start the presentation and I will take off, take, you know, a few minutes to introduce the paper and then we'll go from there. Money, can you share the paper, the presentation? Yeah, hold on one second. Hello, Paolo. Hi, how are you, Lippin? All right. Everything's good? Yeah. Let's push, push, push. Yeah. We got to keep pushing. Okay, are you able to see the screen? Yeah, can you put it in presentation mode maybe? I don't know. Yeah, hold on one second. I did and then it somehow went back. I'll go here. Okay, go ahead. Okay, so the full paper is divided into two main sections. One is an introduction to central bank money. And it's relation to money supply, the purpose of central banks, and so on. Most people on this call, it should be familiar, but if you are not, you can take a look at it. Other things in that section are the rationale for CBDC, several people, several publications, several organizations have come up with surveys of what, why CBDC is necessary. The most important of them being, you know, as part of the public service, that is central banks are at the, you know, are a public organization to serve the public to achieve monetary stability. And one of the most important features of money, which is to make as a medium of exchange to make payments. And so that is one of the central themes of why CBDC is necessary because that brings forward the payment system into the 21st century, the only way the retail can use central bank money today is using cash, but most interactions are happening over the internet with online payments and so on. So payments using central bank money can only happen if public has direct access to central bank money. The other, you know, there are several other rationales, the other ones are mainly related to monetary policy because of the lower bound of cash at a 0% of monetary policy cannot be implemented properly without, you know, bumping up against that lower zero bound. But we do detail some of those and a very good treatment is in the reference that we have in the paper, which is from ECB, which is a table based on why we should have CBDC. Then we go into a small discussion on the models. The most important thing that we detail are the fact that open market operations and other schemes that are that are run by the central banks. Do not reach the public directly and there are problems because of that and also those schemes are, you know, the central banks have very strong trading teams because they need to operate in the open market. And they are huge. So they can really swing the prices and the open market operations would also benefit by using wholesale CBDC. That's our contention. So we touched on to wholesale and retail and then we also grow a little bit into the cross borders section. Now our CBDC implementation focuses on standards. And the other thing that it does is it brings contracts into the picture and linking the contracts and payments along with the security is the main theme of the paper, meaning we are not existing in a vacuum. The payment system is not existing in a vacuum and linking both of them along with existing standards in those areas which we do which we think will keep advancing forward, especially with the lots of different agencies that are involved in this matter. But we start with what we have today just to demonstrate how we can use the standards that are today available today to implement this and we do distinguish the contract standard from CDM from a messaging standard like ISO 2022 and others. And then we go into a sketching and implementation based on this very basic building block, that is the dual network, we call it the contract and payments. And then we argue for a convergence that means we do not believe that WCBC infrastructure, the retail CBDC infrastructure and the cross border CBDC infrastructure should be implemented on totally different platforms. We believe it should be integrated, at least in this pattern. And then we go into the next steps for deployment which is quite extensive. Anyway, I think I've taken up more than enough time and money should continue the presentation. Before we jump in, we just want to get any inputs or opinions from anyone. So far, any questions? Well, from my side, I totally agree with Vipin. Interoperability is key and standards are the basis for that. That's why we should focus on that. Could it be a sort of integrated model with existing financial sort of currencies towards the CDBC or it be like a coexisting platform? No, none of the proposals ever envisaged CBDC as the only one. It is meant to be coexisting with other platforms in the beginning. And let the market decide. That is one thing. The second thing is, if it exists along with other platforms, there have to be interoperability. Anyone else? Don, you are the most knowledgeable on this call. Yeah, I think you summarized the issuance rationale and so on so far. We are also very keen on the idea of building interoperability. The challenge in achieving that interoperability we found as we discussed with other central banks is that we have to first of all start with defining what level of the infrastructure standardization is to take place. And that is kind of a work in progress right now. But we say in our work that it is important. I mean central banks are starting their efforts right now. Some of them are piloting and on the verge of actually activating their CBDC. So, you know, we often say the horse is kind of bolted out of the barn already. But, you know, we have to sort of scramble to catch up and look for some level at which interoperability can take place. So, we start off with this very basic diagram, which was first sort of promulgated by the BIS guys as a flower, you know, there are multiple sets beautifully laid out. We have just these three and we are focusing on WCBDC and RCBDC here, which are issued by the central bank. We're not interested in the other picture, but they will exist coexist with everything that we have money you want to go forward. Yeah. Do you want to outline this thing or I mean we we are sort of hinted at this, the open market operations and other functions, repo operations, swap lines, which with other cross currency with other central banks, then, you know, all the other services. All seem to all, I mean, all other operation, they seem to bring the central bank more in line with with the operations of commercial banks as they have huge bigger and bigger trading desks, bigger and bigger, you know, lots of firepower. In the market. You know, maybe for a different reason than than regular commercial banks but their operations seem to resemble more and more the commercial bank operation. So, you just wanted to, you know, the journey we took and we ended up in CBDC is interesting in the sense that from a commercial point of view we are, you know, from swap sub right now being labeled as OTC digital. If you look at all the new emerging digital assets in the marketplace and we wanted to bring in a sort of a capital market infrastructure. And that's where we started out at connecting to these, some of these assets as they start, you know, as these regulated assets and some unregulated, but most of your focus on regulated assets, as these come out of the market place, and also be seeing the infrastructure being you can see the exchanges are now developing a digital based infrastructure for trading where we felt the value add is, you know, the buy side needs access to this market infrastructure, and we can work with the sell side to provide infrastructure based upon digital infrastructure and that's what we focused on implementing these solutions we found that there's always a need for a common media or a medium of exchange, while to some extent stable coins and bank points, the overwhelming they felt that there was a need for CBDC, and we started taking a look at CBDC, the implementation, the issuance process of the life cycle very much resembles to what a commercial bank does. Dan, can you go on mute please Dan Schwartz. It's conviction and also, oh, I don't want to get this bottom I want to get the next bottom. Money, could you. Yeah, I just put him on mute. Okay. Okay, as this infrastructure is developed so we felt that there is a commonality between what the commercial banks is trying to achieve and using data and standards and what the central banks are going to achieve with respect to CBDC, and hence we felt that our participation in capital markets and in building standards and more of a specific digital standard would help a lot on CBDC and that's why you know we took a very serious interest in CBDC. That's, that's the you know the reason why, you know, we initiated an early project within Hyperledger capital markets, which is the e-collar project. Essentially the first step to CBDC, looking at the life cycle of a simple wholesale CBDC, using token taxonomy framework which is another data token standard. And then we started applying how do we bring in capital market standard which is the common domain model on top of CBDC. So I'm going to jump into saying, you know, we are, we have been associated with the ISDA or the SWAP dealers association, SWAP derivatives association work on CDM for the past three years. The reason why a separate digital standard is warranted as opposed to what we use today and we have been using in the derivatives market and another standard called FPML for almost like 15 years. The main reason is that is the standards like FPML, PIXML, ISO 5022 is all designed in an era where there is always a centralized player and these act as a messaging structure framework or standards, or however you want to call it as more of a placeholder and then the implementers being the centralized service providers, whether it is a central bank or a CCP or a CSD or even market middleware providers would make the specifications into an actual implementation standard and these standards can vary from one play one implementation or another and we have seen this proliferation. You know, you can talk about the fixed protocol or FPML. Same thing we can talk about ISO 5022 standards as well. Then the derivatives association recognize that this will not work on in a peer to peer infrastructure where we are trying to deploy DLTs or blockchains where you really want any party to communicate with any other party using a single data standard and that's where we started off with common domain model. And earlier on the focus was on derivatives. Now, in the past six months, we have added all sorts of assets from equities to bonds to digital assets to the life cycle of common domain models. And now this is the other associations covering repose and security finance have also joined forces with ISDA to comprehensively address the entire pretty much the product life cycle of every capital market product you can think of from commodities to foreign exchange to security finance derivatives and cash. So that's why we felt that applying the standard uniformly on every DLT or blockchain implementation would that much more help interoperability between capital market service providers and we felt that it's it's very much helpful to bring the same idea to CBDC. This is simply also CDM being a life cycle type of standard also can be standalone in the sense that if you serialize the CDM. All the provenance everything is embedded in it. So it's almost like a mini blockchain in inside itself. So you can take that CDM serialized CDM and move it to another any other platform. And so it becomes upgradable immediately because you are now not dependent purely on the platform on which it is implemented. Today, most of the standards. Most of the POCs of CBDC are on specific blockchain platforms. So this is another reason why CDM would help us move across platforms if need arises. That means if the platform is hacked. There are some problems that come to light whatever the reason may be. Anyway, go ahead. Yeah, carry on. So the main problems via the standard addresses is portability as just been talked about and also interoperability. In Capra markets, we expect to see dozens of these DLT networks to come out to see various products and they all have to interact because ultimately they all depend upon each other. And also the end of the day, it boils down to how this is these contracts are linked to payments. And that's where CDM already addresses what would be a payment. I wouldn't want to say a message infrastructure is more of a primitive from a digital standards perspective. And it is very much very much very precise in the sense that the payment itself defines the parties and the current you know the whatever the underlying asset to be exchanged. But it has been pointed. It refers to the original contract where this payment started from. And that's where the lineage comes in and it's very critical in a digital standard in a digital environment, as we may be multiple networks is important to know where it came from and how we make sure that as an audit trail, not only within the network. It's not only internet but it's all the internet network of networks, how these whole chain of information can be carried forward and then be, you know, validate, and that's why the standard becomes much much more critical. We're going to briefly touch on NPC, which is simply that there are many standards for custody. There are many many implementations is another area where I wouldn't want to call a standard but a practice or different types of technical implementations are emerging. One of the newer ones and most software based is an multi party computation. We took that approach because that gives the most asset today the best breed of safety and a real time in nature of moving payments between parties. We, you know, as we said in the paper, there's a lot to cover on security and custody. We just touched upon what we found the most predominance. Again, more, more close to your standards based. And this is also again taken up by standards organization to bring this in more in line as another digital standard. So that's why, you know, we felt that it's important to highlight this. Two, two groups are working on it. One is the NIST for the threshold cryptography standard and also the NPC Alliance for the NPC standard. So they are already working on it but it's not, it's not cast in stone that standards are not yet, you know, released. Anyway, go ahead. Yeah, for the purpose of this thing, what we have, what we developed in the white paper and decided that there are two main principles that CBDC are for that matter any digital asset needs one is to maintain privacy. The other one is also because it involves digital assets you really want to have a trust that we call as a current world state. Any given moment, anyone to be able to have a trust in that underlying asset. So we, the DLT provides a more or less we call it a point to point network provides a very robust privacy. So whereas a blockchain gives you as kind of like a broadcast network, which gives you the current world state so we felt that combining these two can give us the properties of what we really want to achieve in any digital asset and CBDC in particular. That's why when we look at the lifecycle of any, any contract or any business activity that is always a peer to peer contract that must remain private, but any payments that need to be settled must be visible to the parties such that they trust the digital asset system itself. That's why we may be defined as two different network, we are not suggesting these are had to be physically two different networks. If there is a certain blockchain or DLT that can meet these two properties they can be in the same physical infrastructure. We just kept it from a logical perspective is showing that by keeping these networks we can now create patterns and be able to build on top of the patterns to create the various types of CBDC and we'll go through this very quickly. In terms of simple issuance an FSB meaning a bank or a payment service provider can make a request to an issuance which is simply a peer to peer call to the central bank. Central bank will then verify against the reserve accounts and then once it is satisfied to the needs it can then go ahead and issue the request for the appropriate number of CBDC tokens. Or digital dollars or whatever you want to call it as in the asset network confirms that message back to the FSB and the FSB can in turn independently verify that this transaction is complete on the asset network and then hence complete the entire contract. So by this we are essentially created one pattern whereby an issuance can be made it uniform and this could be applied to whether wholesale or retail the concept is the same. And thereafter the FSB scan then directly transfer payments amongst themselves on the asset network based upon either a CDM contract on the CBDC, we call them the CBDC contract network, or it could be another third party network where they have the original contact. It's not important what it matters is that is when there is a payment we always link that payment to the contract where it started from that that's the whole purpose of the separation and defining the defining the roles of the players. Now we take the same idea and applying it to retail CBDC which is the same CDM contract and the same kind of the same asset network and we now group them together and say hey this same pattern can be applied for retail in the sense that the entire operations of issuance and transfers between central banks and FSBs would work exactly the same. Now we are bringing in you know the retail participants and how do we bring in a direct claim into this network is by saying as a retail user could ask for a registration of a wallet. Here we're given an example on FSB, it need not be an FSB, it could be any government authorized institution, all that we want is that is that particular retail user is somehow identified, gone through some sort of a KYC and the particular wallet is registered in the CBDC network. Once the wallet is registered then the money transfer can happen between the retail users and any form of the choose. They do not need the dependents, they do not need an FSB to coordinate any sort of interpersonal money transfers. Any questions so far? Yeah from my side. I'm honestly, I'm starting to grasp the value of the CDM contract in regards to the asset network and I get that you separate the different aspects of it so on the asset network you create the space for different asset networks to coexist. You already mentioned a few of them in the previous slide and honestly I'm still struggling a little bit about the core value that you bring with the CDM. If you could just briefly go over it again, I would really appreciate it. So the CDM is essentially a contract network that enables a life cycle of a CBDC. So the life cycle of a CBDC starts with, even on day one, there is a minting process by CBDC. The minting process, then there's an issuance process. The issuance process is between an FSB and a central bank. Then we have a transfer between FSB to FSB transfer. And eventually there are other functions which we'll soon be introducing when it comes to cross-border network. The next step we'll discuss about that. So in reality, what we're trying to say is that it is not only about simple payments, you have a particular central bank and the regulators want to know what is the contract for which the payments are happening. And they want a record of that. That could also be recorded on the CDM. We are not saying it isn't necessary, but it could be an additional, apart from life cycle of CBDC, we are also bringing digital assets into any type of digital asset on the life cycle could be recorded in CDM. So you essentially have a placeholder or a central place to record all of your contracts. So there is a two-way bridge. Basically there is a two-way bridge. There is a possibility of a two-way bridge between the CDM contract and the CBDC network. It will become much more interesting when we start getting into the cross-border and then you see the pattern becomes much more clear. Probably it becomes easier for the current CSD model when you want to interoperate between different currencies and the CDM would help the current CSD role to interoperate between different digital. That's what you're going to put in the next one. Thank you. Thank you for that. Thank you. So I'll go move on to the next one. So now we are saying we looked at how wholesale works and how retail works. Here is the pattern where it becomes integrated. So if a central bank is looking at saying, how do I ensure that we have a standard way of implementing but wholesale and retail, this is how it would operate. Now one of the interesting properties of such interoperable networks is that is the FSPs are constantly going to move money between a wholesale and a retail because sometimes they may need the transfer. And that is again facilitated by the central bank because if an FSB felt that they need a lot more tokens on the retail side, then they are using on the wholesale. They could simply make another contract request to the central bank saying please move X amount from my wholesale to my retail or vice versa. And the CDM contract will help through is actually almost acting like a mini exchange between two networks. So that's what again the interoperability adds value. And again, it's a pattern. The implementation because of it is CDM and the digital asset could be of any network. This can be implemented by any number of parties. All that they are saying is these are standards. Once you apply to the standard, the banks are free to choose any technology, any technology providers to build these networks because interoperability is at the data standard level, not at the physical network level, which is not a DLT physical platform. So you're saying at the end of the day, you're saying that even the central bank can use the CDM contract to update its own balance sheet, right? That's up to them. If within, for example, if Fed is an example where it is spread between multiple regions and there they could share a common infrastructure like a CDM to share the balance sheet and the operations between the various fets within the U.S. Yeah. So, but that's not our focus here. Yeah, but your point is right. That any financial contract, any final operations could be standardized on CDM. Now taking the next level is that is we do see this cost currency infrastructure where two central banks occasionally need to exchange their currencies for whatever reason and then it's been happening off late because of COVID-19 and in the course in 2008 that this kind of operations come in periodically and again by applying standard cross currency swaps, which is already covered by CDM. This is commercial banks do it all the time. We follow the same pattern whereby the one central bank makes the request for a cross currency swap. The other bank verifies and it is possible to do this, whatever the internal verification is, and then they will confirm that they would then go ahead with the actual transfer of the cross currencies. Step A is involved, each party then sending their transaction to the other party and the party is then verifying it. This is just one leg. That is what we call it the initial or the spot leg and then you could take the same idea and then apply it to the forward leg, which is three months forward, the currencies or the payments are reversed. But we are applying the same commercial bank CDM contract to a cross-border infrastructure, so which means now already there's a standard there, you know, we can be applied to bring in cross-border transaction between two central banks. Manny, this is Dan. I'm still struggling to be honest with the focus on CDM as the solution. And, you know, my own experience is on the traditional asset side, so apologies not so familiar with the digital asset side. CDM really arose because there were long-lived transactions which evolved over time, and it was a way to embed the evolution of the transaction directly in the transaction itself, meaning if there's a rate reset, the contract itself knew how to deal with the rate reset and calculate what would be the next payment. A simple example. I can see the value of adding central bank digital currencies to take advantage of the templates or structures that will be established in CDM. CDM, by the way, for all, not entirely well adopted yet. It's exactly digital standard, yes. Biggest adoption is probably inequity derivatives. But okay. The problem that it seems that you're talking about is more or less than, to me, it seems twofold. The first is enabling central bank digital currency CDDCs as a new quote unquote currency type within the ISDA realm. And the second is interoperability between wallets or settlement process. And the latter I don't think CDM really is great at accomplishing. Am I missing? I guess the fundamental point is, what am I missing? Because those seem to me the problems you're stating and they seem to have different issues. Yeah, so take the second part of the actual settlement, right? In this example, there is a settlement that needs to be verified between these two central banks. Central bank A delivered dollar and central bank B delivered, or central bank one delivered dollar and central bank two delivered euro. Now, those two messages, somehow they had to communicate saying that each one has to indicate what wallet they want the money to be transferred. And then the other party actually initiates a transfer. And then the requesting party now has to verify that the money got transferred. And then CDM comes into the picture because it's acting more or less like a contract mechanism and looking at that simple life cycle of how do you exchange payments. But CDM really isn't focused on the hard mechanics of settlement. CDM is focused on the life cycle. You're right, but any life cycle needs a workflow, right? Even take the very basic life cycle, it means two parties to initiate a workflow. What CDM defines is the data standard on that particular life cycle endpoints. And in this scenario, the workflow mechanism itself refers to the actual settlement. And as each part of the settlement by each central bank, it gets recorded on the ledger. And that's what, you know, you're simply repeating that CDM construct again and again to inform that you have done your part and you're waiting for the counterparty to do their part. And thereby when the two parts completed the contact itself gets complete. Yeah, and so look, my last point is, I agree with you, while I agree with you that abstractly there's a workflow. I don't think CDM actually has, it has life cycle events. I'm not certain about settlement workflow events. And I'll just be clarified that these are data standard that are CDM does not represent workflow events they left it out for us implementation. Because this implementation can be very different from different networks, you're doing, you know, in a traditional network is one way, and if you're implementing on a digital networks, another way, it is designed to say the various states of life cycle of any contract. And we're not even talking about, you know, to go further into DVP, you know, delivery versus delivery, PVP, which we discussed now, are even simple sometimes single payment, all of these things are covered under a contract which comes from a original source of a contract. That's where the real value at kicks coming. I agree with you on a simple fact. If I have a simple messaging to send a payment across. Why not ISO, you know, standard or even a fixed messaging protocol will work and again this is where I could we originally discuss these were standards proposed in a centralized environment where there's a central party would step in and define the standards. We are now moving completely are moving towards and enabling a peer to peer economy, where there are no centralized player who could step in and define the standard and hence the standard itself. We can proceed with the top, and we can answer some of these questions later on, and your question has been noted, Dan, and your skepticism about the use of CDM in this context is noted. Thank you. No problems. No problems. Okay. We're just going to go into quickly in the very last step and here is the other cross-border network where two banks who are more in cross-border transactions. Again, simplified, if you look at this as a CBDC network, we talked about central bank exchanging currencies. We take the same idea and applying it between two FPSP's exchanging currency, the same concept, and we talk about a cross-border CDM contract. This is a long-lived contract. It should be anywhere from a couple of months to a year or 18 months, depending upon what the contract is. So we are uniformly applying the same concept for all functions of CBDC. That's what we are proposing with the White Paper. I think we would stop at this point. I wouldn't want to go too far into CDMs and events if this is for maybe another day's discussion. Let's focus on the White Paper and definitely points like Dan, you know, to what exploring. So anything to comment? Yeah, I mean, you know, we presented what a white scope in a very short period of time. There are still unanswered questions. Many of them are also in the paper at the end because in order to go to a deployment for a CBDC, which is a very sensitive topic for central banks, we have to go through a lot of different, you know, different steps. There have to be processes in place to secure the network, to do all kinds of other stuff which are very, very important. And as far as the CDM, the use of CDM for this particular contract infrastructure, we acknowledge the fact that CDM is not getting a lot of take up, but there is no comparable standard. The ones that are proposed by most central banks like ISO 20 or 22 are monsters. They are basically metastandards and they are episodic. They are not doing any kind of lifecycle tracing, any kind of linkages, you know, the hashing functions are problematic. They have introduced the header recently, which seems to be a last minute attempt to get some kind of a cryptographic verifiability into the process. But even that is slipping out of, you know, there are multiple ways in which you can implement that. Anyway, the point here, which is made in the paper is also that CDM is the one that we have today, and something like it will be the solution in the future. Standards are still evolving, but we are just looking at, you know, like John said, the horse is already out of the stable in some places. So will they come back to a standard base implementation? Who knows. The Chinese already almost ready to deploy DCEP, which is the most large scale deployment that is possible. Anyway, so anyway, the, you know, the next steps are to engage and also to give us feedback about this paper so that we can improve it. By any means, we don't consider it, you know, complete, but it's just an opening salvo, not just in writing a paper, but in actually putting it into practice. Several of these things are already built. Anyway, Satish, can you, you know, you can go ahead and announce your meeting and we will engage later. Can you hear me? Yes, yes. Yeah. Money, if you don't mind, can you just quickly bring up the GITS 2020 or can I quickly do a screen share? How do I do that? Well, I mean, Satish, I think you can just do a small. Yeah, I'll circulate the matter quickly, guys. We are doing a global information technology summit this Friday 11th. So it's a complete ritual when usually we do it like a proper one last year. It was in London School of Economics. We did a full one. This year we are going a ritual. It's a global one and we have brilliant presenters. I won't take much time over there. I will send the details out through Wipin and the do-do please register and attend the meeting. We do and we are planning to open the event with Blockchain Infintech, our favourite subject. Any queries you can just, you know, ping me. My email is on the network so you can just send it across to me if you have any queries. Thank you. Money, any last thoughts before we close? No, no, we wait for anyone else to give their comments. Obviously, can you indicate how they can provide as a comments back to us? So either by email or by referring to the paper itself. We don't have the paper open for public comments money or should we throw it open to public comments? Yeah, at this point, we opened up select few, particularly, you know, obviously the capital markets being one of them. We want to see if there are any challenges and there are obvious issues. Maybe we could take some time with Dan and see his concerns and really understand and that would be worthwhile. Otherwise, the Hyperledger itself, they can put their comments, right? I mean, they can log into Hyperledger and then register the comments, correct? Yes, we can actually have a page specifically devoted to that. Everyone can see their comments. They'll be easier for everyone to see their comments. All right. Thank you. Any comments last minute? Well, from my side, I think it's really important to have a specific page to share with the Hyperledger community because I see at least I have the perception that the CBDC discussion is picking up within the Hyperledger community. And it's going to be a topic in this week's summit. So if we could at least mention the work that is being done here, I think it would be valuable for the whole community. Does that make sense? Yeah, we are not participating in the summit because we are not members, I guess. If you want to throw something in, let me know. No, no, I'm not talking about the GITS but about the Hyperledger member summit. That doesn't mean that I cannot briefly mention the work that's being done. Oh, yeah, sure. You should mention it if it intrigues you and if you think it is important. Yeah, I think it's important and I think the value should be given to the people that are driving this discussion here. So regardless of the membership approach, I think it makes sense to at least mention the work that you're doing on the standard side because it will benefit a lot of players. Thank you. So that's it. We will convene the next meeting. It's going to be an interesting one with Tangium talking about their disconnected CBDC approach, which is smart card based. Go there in this paper yet, but in the paper there are indications that we can have an anonymous CBDC and similar to what the Chinese are doing with the different levels. That means if you have a level two or level three wallet, then you can only hold so much and you can only transact so much without KYC. Anyway. Interesting. All right. Okay. Thank you. Thank you all. Thank you everyone. More than happy to give your comments, please. We'll take a look and follow through. Thank you.