 Hi all, so this is, I believe, the last session for today. So thank you for all the marathoners who are still here. My talk is about creating a retail CBDC prototype with Hyperledger Fabric, an experience report of sorts, if you like. So disclosure and acknowledgement, this work was performed under and financed through a research project at our university by the Hungarian National Bank, meaning that this research was done in cooperation and under this framework, but not actually at the National Bank of our country. The participating departments were R1, the Department of Measurement and Information Systems, and the Department of Telecommunications and Media Informatics. Now the context of our work is actually not CBDC directly or only on its work, per se. Our work stream is more about smart contract ecosystems in general, industrial and financial use cases, benefits, resilient ecosystems, and certainly the impact of enabling the usage of coming CBDCs in such use cases. But to assess, analyze the impact of CBDCs in industrial smart contracts, it would really be beneficial to have a CBDC, actually, at least on the technical level. So as part of our work, something like that was created. And I will share that today. So what I will talk about today is very briefly what we see, at least in academic literature, on the industrial usage and requirements of smart contracts and specifically payment modalities. What are the possible, no-force in payment models for distributed ledgers? And I will showcase, present a Hyperledger Fabric-Based CBDC prototype with the twist that we are actually bridging out CBDC to DLTs of industrial corporations from that CBDC ledger. And as closing remarks, I will talk a bit about side-chain auditability and what we already see the little that we already see about compliance requirements. So we've performed a somewhat extensive literature review on industrial or industrially aligned, so not purely financial smart contracts, smart contract ideas, models, topics. And explicitly filtered those use cases where some kind of financial settlement is to be performed. And we see quite a number of interesting use cases, which for most of you may not be new certainly. In machine-to-machine scenarios, people are talking about payments, micropayments, for industry 4.0 business processes. Those are certainly business processes, but at the end of the day, someone somewhere pays in the process, actually. Otherwise, it's not necessarily that interesting. In the digital twins space, now there are ideas emerging about making digital twins of commodities. And when we are talking about commodities, then commodity exchanges come up, forward contracts and the like. And even the more classical digital twin concepts do involve in the lifecycle various payment operations and aspects. And the construction economy building industries are beginning to talk about various DLT-based schemes. For instance, it would be supposedly very nice to be able to create DLT-based project bank accounts where the financing for a project is put in escrow and everybody is paid at the same time from the still existing funds when the building is actually created. Certain similar services are provided by certain banks, for instance, in the UK, but this is a specialized service. And even when a bank provides it, it's quite rigid. And certainly, many people have been talking about circular economies for a while. The asterisk is there because I don't think that we really see that what will work and what won't work from those ideas. But still, those will need some kind of payment. And actually, what this distills down to is that the important part is automated and final settlement according to agreed upon rules. And distributed ledger technology is not the goal just the actually first feasible looking means to provide such services at scale in a generalized manner. But if you look at all the papers that you can find, the exact payment modalities or payment rails are actually typically left quite under or outright unspecified. So what would a payment infrastructure look like for a distributed ledger which conducts industrial business in the very broad sense? Ideally, it should be some kind of digital currency or easily and almost risk-free convertible to digital currency. It should have some tolerable platform level financial and technical risks. So stable coins are not necessarily a good match for incumbent, non-digitaly native companies should have low transaction costs and settlement delays. Smart contract control settlements should be there. So this is basically a wish list. Let's see what we can do. There's a rather good paper on the current near future and further out options for payment rails essentially for DLTs for smart contracts in mostly permissioned settings. And there should be nothing really new in that. You can always do trigger solutions. The smart contract decides to do something. The smart contract issues a SIPA transfer or whatever else transfer. And it has to wait for confirmation. Someone has to bring the confirmation back to the smart contract. So the logic of the contract actually gets quite involved quite fast. And it's not really true that when we decide that a payment should happen, that it really happens. So we can forget about atomicity. We are beginning to talk about euro-referencing e-money tokens, but those are still a bit further out. MICA is edging to actual implementation. Let's just say that. But until that arrives everywhere at the national level, that's a bit questionable. Synthetic CBDCs will be something that will be possibly available. So a bank has some amount of CBDC and uses that as a one to one backing to issue some token on a DLT ledger. And the fourth category, CBDCs in general, is what is possibly the furthest out and possibly the most interesting. Because we don't really know yet how those will be integrated into DLTs, permission DLTs. And this research was to simplify about that. We did have a hard and quite long look at those retail CBDC implementations that seem to be shaping up. Let's just put it this way. So there are at least some technical architectural documentation is available. And there are a few takeaways from this. One, we all know this. Everybody is experimenting with various models. And it's all well and good at that level. We have all kinds of technologies. Hyperledger is quite overrepresented, rightfully so. But when you begin to look at the architecture and smart contracts, the picture that begins to shape up is that one, not everybody is actually thinking about decentralized solutions at the highest level, at the authoritative ledger level. And smart contracts in the sense that smart contracts that serve the general public as well as businesses are not really on the table. So those do not seem to be a primary concern of the central banks at the moment that are thinking about issuing retail CBDCs. I'm speaking about retail because in a strict sense, wholesale CBDCs are for the financial sector. And this is not strictly about the financial sector. And we did filter out such projects where we couldn't find any meaningful technical documentation and also commercial platform offerings due to the nature of our research efforts. And as a source, let me just pitch here the Hyperledger CBDC paper because it's really good. If you're interested and haven't checked it out, do so. So takeaways. No smart contract support on the top level CBDC ledger. This doesn't mean that there will not be programmable money. But the programmable money smart contracts are actually the smart contracts of the central bank or of various state bodies. So heavily controlled pieces of code, they can be expected to be. And it's actually quite understandable that wide scale smart contract support is not planned right now for the top level CBDC ledger be it centralized or decentralized. We all know that there are hard to avoid performance issues if one begins to allow various smart contracts to live on a sizable ledger. And those things actually don't really belong conceptually there. Either one can argue on that side. And what we see is that in most cases where the architecture is well hashed out, there's some mechanism for distributing downstream the asset from a ledger. In the Euro area is actually in a quite special position because there's market infrastructure at the Euro level. So we shouldn't really expect that the tip system will be replaced. So most probably something building on that will arise. And almost all architectural models are being mapped out except the one that I will show here which is bridging out CBDC into a decentralized system from a decentralized system. We don't see open code. Typically there's only architecture descriptions and the obvious exception is certainly by now open CBDC which is a project that I'm somewhat of a fan of but that's a very different beast. So that transaction process or is at the moment is not really comparable to all these initiatives. So what did we create to experiment with? And hopefully we'll also make more widely available than how it is now. One, first design decision was that we will create a CBDC where there are Ethereum style pseudonyms and balances. Read, we created Ethereum addresses and balances. And we did that over fabric. You can do that. You can implement many things over a fabric. Famously even UTXOs as one can read in the Hyperledger fabric design paper. This is good because there are readily applicable privacy preserving techniques if we want to have private handling of assets then as long as zero knowledge proof schemes remain to be applicable, they are not broken. We can just copy over technology from the Ethereum world to create privacy enclaves for handling assets if you like, but that's just one example. There's enough design room for KYC AML. I will show one simple solution. There's enough design rule for implementing a travel rule if that's applicable at all because when private parties are sending CBDC each other we are not sure that the travel rule applies. And there's enough design rule for wallet attestation schemes where a independent party continuously checks whether the wallet integrity of a user is still intact. Professor Harjono from MIT is publishing some nice results and thoughts on that. It's easy to bridge to Ethereum and it meshes very well with SSI. Simplest approach, one can register a Ethereum address as a DID, we can get a verifiable credential for that, we can even get verifiable presentations, zero knowledge proof verifiable presentations for that as a matter of fact we are thinking about SSI based schemes where we could make the CBDC so inconvenient to handle so slow that it's as inconvenient as cash so possibly we could keep up the existing privacy guarantees. We don't know that and that's a tangent but SSI meshes very well with this world if you use pseudonyms. So our core ledger is implemented, it's finished, it was a feasibility experiment and why did we choose that? Well, to see whether it's feasible and we get out of the box DLT guarantees certainly. And we did a cactus based CBDC bridging to permissioned Ethereum. Essentially you have an Ethereum address, your private key in your wallet and the idea was to be able to frictionlessly shift the money on that address from a CBDC ledger to a sidechain ledger and back using the same private key which is also a technical simplification on our side. Now most design work was done during the first part of 2021 since then we've been doing small stuff that has to be done so some extent results that appeared since then are not reflected in this work yet. The logical architecture looks something like this. We have a CBDC ledger and the central bank does not mint the asset on that ledger it just gives financial institutions and allowance to convert other forms of digital money to CBDC. So it's a conversion based asset and it also has the power to perform legal seizure and freeze operations. In reality somebody else would do that but we wanted only to have a single regulatory party in the model. Now the members of the public and businesses have direct pseudonyms legal claims on the CBDC. Simply put if I have the private key then the money at the accompanying Ethereum address on this ledger is mine period. To prove that I don't need any financial institution. Financial institutions instead do two things. They are the gateways in a technical and monetary sense to the system. So I as a client can convert other forms of digital money to CBDC and the financial institutions and they are the KYCing parties. So they give my account some level of KYC that they say that they gave me that level of KYC and the personal information remains with the financial institutions meaning that the central bank and other parties who may operate this ledger don't see readily who's who and that may be a requirement on the part of the issuing party. Now this is a legal relationship with the identity custodian and KYC provider and authorized CBDC mentor on a technical level. What we came up with is that the financial institutions should be also gateways. So in fabric they will have fabric level identities and they are the ones who bring in the Ethereum style signed transaction requests of the clients counter signed by their fabric identities. And this is pretty much necessary to keep the performability and possibly also the security of the system intact. So the ledger is rather simple. We have Ethereum style accounts. Those have a KYC label issued by a financial institution. We also introduced a number of further simple financial primitives based on an analysis of well the most widely used crypto financial primitives from Bitcoin and Ethereum. We have hash lock transfer, time lock transfer transfers the combination of which should enable also atomic swaps although we don't really want it to go into that direction. And we have direct withdrawal authorization. I can give an authorization to the utility company to take away the appropriate amount each month. At a technical level, we implemented this ledger model in Hyperledger Fabric Smart Contracts chain code. Created a gateway layer for the financial institutions in this system who do not necessarily have a node themselves in the fabric network. That's a policy and deployment decision. We were not in the position to make but this wasn't necessary to make actually. We created a gateway for backend application for the central bank. That layer communicates directly with fabric using a fabric API. And in turn, the user applications talk to a REST API. So no fabric stuff there. On the contrary, we have Ethereum style transaction signatures. And you can implement there whatever identity checking and authorization that you would like to do. But importantly, given that this layer, in this layer, the client is not tied necessarily to the financial institution as a client. It can happen that I KYC at a financial institution gets some funds but for performing transactions, posting transactions into the system, I'm actually going to somebody else. Whether there's a payment mechanism behind, we left this open too but this is another point where this architecture allows for some agility. I don't really want to go further into the technical details. One point where we didn't spend too much energy is creating a wallet. So this is something very simple just for demonstrational purposes. If it has any meaningful message is that what the end user sees at the REST API, that's pretty much in line with the functions that the financial institutions proxy into the fabric-based CBDC system. Okay, how performant is it? Not too much but we are hopeful. Let's see what we did. CBDC microbenchmarking. What we hand is for a university cloud sizable system of many virtual machines. All of those lilac colored boxes are separate virtual machines. Each VM had eight VCPUs, 16 gigs, one gigabit per second network. So, well, could be better but already good to make experiments and we did implement it two forms of benchmarking. Hyperledger caliper can issue open loop loads and that's nice because we can hit the system irrespectively of how it answers and we also implemented some measurement in JMeter because on the contrary it's able to simulate users who are waiting for transactions to come back because they want to do the next only after that. And now we are doing pretty much constant load which is defensible because blockchains implement a kind of fletching mechanism. Transactions come into a block and only go further when the block is full or when the block time is over. That being said, it would be very nice to have an open representative load model for CBDCs. So if anybody is with a standardization body then that would be nice. We know for a fact that such models exist for the euro area, we haven't had the chance to have a look at them. They are not easily accessible. Latency-wise, we are good but I think we all know that with fabric one can go under 500 milliseconds easily. Modulo network traffic but well, if you are operating a fabric network then you probably should make sure that the connections between your nodes are highly, high bandwidth, low latency. What's possibly even more interesting is the throughput for which 300, 350 transfers per second can work. Now for this hardware, this is actually good. There's much room for improvement if we look at reference sizing guides for Hyperledger fabric. Those are actually stronger hardware and the sky is the limit. Scaling out, up should not be a problem and I would like to make the slight remark that we are not hypothesizing either the euro or the dollar area. So even though this is a research prototype we are in Hungary a country of 10 million people so the magnitudes are not the same. We created some nice visualization for analyzing our performance. The end result of which is that the various sub tasks that are being done during transaction processing are quite evenly weighted. There's no bottleneck right now. With stronger hardware, stronger single core performance and certainly after a while some tricks with the validation phase the performance can go up, should be able to go up scale up quite easily. Now the somewhat novel aspect, bridging logical architecture. So what we say is that we will have a side chain and we can do the industrial collaborations there just as we saw with KBC Bank because I really love that presentation because that rhymes with this pretty much. And we have a financial institution who at the logical level orchestrates this bridging. I as a member of the public or as a business lock down some funds on the CBDC ledger. Those are my funds. I don't give them over to the financial institution. I just put them into custody, into a custody upon which the bridging financial institution can act. Let's put it this way. So it's not exactly the same like notary schemes in their strict definition. And I still have my indirect claim on the bridged CBDC but after it's been bridged out, this is a simple two-way pegging if it's familiar this way. Then I can begin to use them on the side chain and give it over to somebody and when somebody wants to bring back out of this cooperation the funds then they can just simply bridge back, burn the assets on the right side and see them being released on the left side to their address. Now our initial implementation was based on Hyperledger cactus and token bridge and some custom contracts on the left side. So the logic is that the end user is user request to one of the financial institutions that they want to do some bridging. They act post the transaction into the fabric network and after that they tell cactus operated by a financial institution not necessarily the same that there are some funds logged there, please bridge them out. The bridging happens to a private Ethereum network and a mishmash of top contracts from the token bridge project receives them, issues them as ERC-20 tokens and you can do smart contracts with settlement in electronic Hungarian foreign which we hypothesized for this use case. After that we did an, well, we have a very bright young guy from Lisbon who's an incoming student, PhD student I think at the group of Raphael Belchior, Andre Augusto, he did the improved approach actually. There are standards for bridging assets between trusted pretty much private consortial blockchains in the drafting phase. It used to be called ODEP, open digital asset protocol. Now it's called secure asset transfer protocol. They are in drafting status at the Interent Engineering Task Force. We will see what comes out of this. They are shaping up very nicely. The end game is that this protocol will provide asset properties for asset transfers under the assumption that I can trust the Ledger A and Ledger B. They both have gateways and it is the gateways who are doing a resilient protocol. There is a prototype available for cactus. So the idea was that let's wrap that and Andre did that under our guidance. It's still more of a notary scheme than a trusted relay. Cactus is called a trusted relay because under the assumption that there's permission consensus on the source ledger as well as the target ledger, one can do such schemes where some parties sign, some known parties sign a transaction on the source ledger and the target ledger can actually look at who signed this transaction, whether it's true and in the reverse. So the trust that I have to put into my cactus instance to be specific is much lesser than what would be needed in a classic on permission world notary scheme for the further details, see the great article of Belchior et al. But we are actually for this use case, okay with that because really putting a regulated institution in between a DLT and a CBDC ledger that's not a too far-fetched idea, we believe and anyhow cactus will allow for validator consortia in the future. So that bridge layer will be able to do consortial like decision making. Hopefully it's not able to do that yet. So what Andre created in his mentorship is seems to be a bit complex, but it's not that complex at all. There's the implementation for the older protocol, pre-existing implementation for the older protocol in gateway one, gateway two, with a connector for Beezoo, with a connector for Fabric and that's a magic there. We don't have to deal with the details there. On the left side we have Fabric, one channel in this case. We have a single organization for simplicity's sake where Alice and Charlie have Fabric identities and can hold CBDC. And there's a asset reference layer. The older protocol in the older protocol each asset has to have a specific explicit asset reference. So that's a technicality we have to wrap a essentially non-fungible asset transfer protocol to make it able to transfer fungible assets. But it works and it's nice. And if we want to see it in action, it works. So what's happening here is that VRS growing the CBDC that we want to bridge out that goes into escrow. You see the bridge is holding. The bridge account identity is holding that in a chain code and we say that we want to bridge out the previously created escrow with that ID. And after a while it appears there and we can transfer over Beezoo the usual Ethereum way the funds and we can bridge back. So it's essentially that. So in our system, we also created a demonstrator. There's a EU wide quite large project called Arrowhead and Arrowhead tools where our colleagues from the other department were involved and where industrial corporations supporting local cloud software and solutions for industrial corporations is being created. And one of the last stages of that project was to create smart contract support for the various corporations of the very, very, very industrial parties involved in such mostly manufacturing activities. And they created the contracts for asset exchanges for forward contracts and a few other similar financial operations for specifically for the manufacturing sector. And without involving any heavy machinery and logos of well-known Swedish car makers this is a conveyor belt with two robots where the two robots are actually paying for each other on the DLT for the handling over of the little yellow rubber ducky. So as soon as the second robot takes over the asset the payment also happens in the DLT. Okay, so after this small hopefully at least a bit comic relief there are certainly open regulatory and compliance questions most of which we are actually not able to answer yet because which central bank has already CBDC for which the bridging compliance requirements have to be defined. So this is a bit far-fetched. Still, I hope there are a few thoughts that are worth to consider. So shifting the money out to another ledger also shifts a whole bunch of responsibilities to the other ledger and most probably the central bank as well a certain regulatory bodies are fine with that and actually will want to have that shift. There are anti-money laundering and CFT regulations and there are regulated activities. For EML CFT there should be certainly proof of compliance mechanisms and on the other hand for regulated activities there are permit obligations, simply put. We won't just willy-nilly allow CBDC to be bridged out to a DLT because we really don't want people or companies to begin to engage in say shadow banking activities. Most probably we don't want to do that. So although on demand auditability will be in theory present. So we can say that the DLT the side chain has to submit time to time cryptographic commitments about its current status and the regulator can go there and look into the books in both fancies into the blockchain as well the actual books. Some form of continuous compliance management probably will be necessary but the specific requirements are still unclear. That being said having a heavily regulated party as either a compliance gateway or as a compliance enforcer and there's a whole, whole interval between the two will be probably necessary. So this is one of the reasons for us going for a architecture where we have a financial institution performing the bridging for some small fee certainly. Now mathematically continuous confidentiality and privacy preserving compliance and proofs of that seem to be also somewhat doable but it's still quite early days. With that I mean that I have a DLT the DLT doesn't want to show that who does what who owes whom, how many millions of Hungarian forints on that ledger. Many of the business confidential aspects are simply not the business of the regulatory bodies. Still can we make some proofs over handling the money the way it should be handled. There is actually some prior art for that with different angles than we are doing. ZK ledger and ZK IRP chain are two which have to be cited. What we did a initial prototype for is an AML CFT related challenge. Let's show that only transactions between all listed addresses have happened on that DLT. So however we are passing around the money in the DLT it touches only hands that have been fingerprinted to drive the parallel a bit further than I should. How it should be done for general purpose requirements for instance have you paid your VAT if you have to pay VAT on that we don't know yet but you can create nice zero knowledge proof based audit protocols for this. We had one prototype for interactive zero knowledge proofs in Zilch that has quite serious limitations. So now we are putting together something in the Zokratis toolkit with ZK snarks. It's still somewhat costly. So on the order of magnitude of the transaction test texts in Hungary that's depending on your point of view, not necessarily trivial. Most probably the solution will be to move away from ketchup and sharp based hashing algorithms in the transactions and use something ZKP friendly but that's hopefully technical for this presentation. So in summary we created this, a hyper ledger fabric based CBDC ledger with ethereum style addresses, pseudonymization. We created a financial institution operated bridge that falls somewhere between notary schemes and trusted relays and should be able to move to our trusted relays. And we have shown unsurprisingly that if we can bridge out CBDCs which remain in the hand of the original owner throughout the way, then we can do very useful stuff using this scheme. Okay, thank you and thank you for staying with me until yes, six o'clock on the second day of this certainly very great but quite dense conference. Do you have any question? Yes, no. Our prototype supports privacy in its current manifestation. And this is a bit dirty engineering trick as much as ethereum supports privacy. So a end user can create multiple pseudonyms and register them possibly with different financial institutions. Okay, who's Alice? The parties operating the role ledger. I didn't want to go into that because that's a quite contentious point for other CBDC solutions too. What we envision is that this is the central bank and a very limited set of parties most probably state parties, state buddies who the central bank trusts, okay? So this is defense layer one if you like. The banks won't have full read access on the ledger because why would they have? They are clients of this ledger. You can see in the clear the ethereum style pseudomized transactions and accounts. You can see the amounts you don't readily know who owns how much. I was planning to, I was planning on doing that. Definitely, that's why I'm actually why I'm staying for tomorrow. But the last time we looked at the Fabric token SDK was more than half a year ago I think or almost a year it wasn't there yet. So I mean from other aspects. So we discarded that quite early but now I will learn the specifics, okay? But as I said, there are schemes for true privacy in the ethereum world which were available. I don't want to make a mistake but Starkware. I think Starkware had a nice privacy enclave. Yeah, sure, but sorry. Yeah, but it's not the verification as the problematic part, computing the proof. Yes, so long story short, there are actual schemes. We left it at that. When we have pseudonyms and when we can have ethereum style transactions and why couldn't we have because of our fabric we can create that and we will see what you actually created. You can plug it in. Part of the question is that you can't say in advance that what's the style and level of privacy that your central bank will want to have. And up until that point it's in this kind of research. It seemed to be a better decision to take a point where we can, from where we can start in many directions. Okay, not maybe there are a bunch of privacy models. If you look at the Canadian Model X challenge, sorry, Challenge X, they had some very nice ideas about the users being completely private but businesses who are receiving the money being completely unprivate. So there's a whole range of options until a central bank decrees that we want this privacy model, who knows. This is a safe play. Okay, we are interested in that aspect but we were content with this for now. Yes, it was a quite long-winded answer. Sorry, any more questions? Yes, yes, yes, yes, yes, yes. It's a question for economists. I love economy but by trade I'm a computer engineer. I don't know, I really don't know. As Chex and I read very nice analysis from the Feds and Louis, they had nice papers on pricing the classic money and CBDC and showing that they run to CBDC should not be possible under the correct pricing. To me, Chex out, but I'm a simple computer engineer. I see the need to introduce limits to conversion. So absolutely, that's in there. To me, the finer details are at the monetary level are somewhat intractable, I don't know. So yes, how this will look like in action. Not this necessarily how CBDCs and creation, conversion, destroying pricing will look like. I don't know. Yeah, yeah, yeah, sorry. In a sense it's the price of the money but again, I'm an armchair economist at the best. Yeah, yes. Actually, what we did is also a sneaky way to trying to integrate what already happens right now with the banks because what we say is that we have a financial institution. They are already doing KYC. Yes, you can do this even remotely and I know it's a big challenge but the good banks have already reason to that challenge practically. So they can attest that who is who then in the CBDC context, let's make them attest to who is who and from that point of view, let lying ducks lie, I think the English say. So yes, that can work but that pretty much plugs in into this where the KYC information comes from that banks or the incumbents already know that. Great question. Yes, yes indeed. Okay, so three things, yes, one. You have to trust your central bank to at least some extent anyhow because why are you a bank if you don't trust your central bank, you know? So you can't, this is not the world when you can make everything on permission then everything based on distributed trust because it's not that world because the state brings the money period. I could put it nicer but that's the gist of it. Two, based on authenticated data structures, they don't know each proofs, yada, yada, yada. There are means to counter check what the central, there should be means to counter check what the central bank says about the current state of the ledger. So they can make cryptographic commitments about its state and give you some material to check it. Think about Bitcoin simplified payment verification. It has its limits. I don't know to what scale it works but should be doable. Actually it was, classically it was called authenticated data structures, that world has morphed. So cryptographic magic, that's solution two. And the, what was the third part? I forgot. If you have access to the state commitment, state commitment and a path along the Merkle tree essentially. So you don't have to have the whole Merkle tree. You may have the whole actually because it won't help you much about the funds of the other people. Just you are doing the hashing. And now I know that, yeah. Yes, almost yes. Yes, to the financial institutions is no different and that was the third part of the answers to your question. DLTs are resilient infrastructures, okay? So if you begin to think about the requirements for a truly critical financial system, then you begin to introduce such requirements that a DLT not fully but pretty much checks out and you would have to build into a non-DLT solution anyhow. This is a very bold statement, I know, and the VIPIN who has quite a bit of experience in that world may reprimand me for that, but I'm the central, let's say I'm the central bank. I have department A, department B, department C, geographically distributed. Put a fabric note there, there, there. Make them all different organizations. Then if I have a single malicious party inside my largest organization who wants to do something with the ledger, they won't really be able to do that because they are doing it from one site. I know that using, that there are database management systems and server systems, mainframes where there are physical and software defenses against that a DLT makes sense, not necessarily for the reasons that they were created originally and if there's such a privacy setting where we can apply privacy preserving techniques, actual privacy preserving techniques over the ledger, then it becomes possible to distribute that layer, the fabric layer, across the financial institutions and then it's a true DLT, okay? Again, tell me your central banks' privacy requirements because if the requirement is that we should be able to see that who's transferring whom, what money after collecting the KYC informations legally from the FIs, then you won't really want to include the FIs in the network because there's such a thing as transaction graph analysis because yes, there is. So let's not give them the whole graph. Yes? Yes? Again, policy question and I'm not a central banker. Actually in this model, all sorts of interesting things at least to an engineer become possible so financial institution right now here means something regulated, classic bank but there are other somewhat trustworthy companies already handling significant amounts of money. The operator, there may be a level of KYC where you just use your phone. You can have million forints on your phone so you don't have to go through a classic financial institution channel to have and access digital money. Now the problem with that certainly is smurfing and that's where I at least personally I see immense potential for SSI because if you have a single government issued let's just say generator key from which you can instantiate your pseudonyms but are cryptographically linked back to that one source that your state gave you. Then at the systemic level, again too many shoots but we should be able to see that how much money does that person have exactly across his or her keys and there are zero knowledge. There should be zero knowledge approaches to that too but that leads quite far. I'm constantly looking for CBDC plus SSI results and right now what's out there is yes the two should be connected. That's what you can see in various official communications. So, but again there should be some quite interesting models and Bakong is actually doing that with cell phones in the I think Cambodian CBDC so that's in and of itself that's not my idea. In our system offline things would be a bit tricky because due to the Ethereum model we are also technical detail using the nonce mechanism of Ethereum so offline payments are somewhat tricky but that should be also doable so it will be a if and when it arrives this will be a potentially very interesting ecosystem made with multiple layers of players so why couldn't your telco operator be a CBDC payment service provider let's call it what it is. So I think we are past the time it's so thank you so much for being here again and hopefully it was useful. Thanks.