 My name is Mark Rikmalovic. I'm with Oracle. We have been a member of Hyperledger since, I think 2017 when we joined and have participated actively, particularly in Hyperledger Fabric. We have built and brought out to market some products based on Hyperledger Fabric technology, Oracle Blockchain Platform specifically. We've been in the market for about four years since 2018 when we first launched the cloud version and subsequently on-premises version as well. Recently over the last year, maybe a year and a half, we have started seeing opportunities in central bank digital currency space. Oracle has a number of central banks as our customers, of course commercial banks as well. Some of those conversations have started reaching into the CBDC space. We have become more active in the space and I'm going to share with you a little bit of what we see as our landscape and perspective in that space. Our sandbox solutions that we have put together as a project we use and really focus and do a little bit of a deep dive onto some of the specific challenges that come in the area of scalability. Particularly we're talking about retail CBDC, running digital currency system for a few hundred to maybe a few thousand. Financial institutions is not that hard from a scalability perspective. When you talk about running it for a country with 100 million people or places like India, which is over a billion people, that becomes a different category of a problem. And we'll also deep dive into the topic of privacy and confidentiality and how to balance those expectations. All of us here, right when we're doing cash transactions, it's completely anonymous and so on. But at the same time, if it's a central bank currency then there's obviously regulatory oversight that comes with that. And so you have to be able to balance it too. And hopefully we'll have some time for questions as well in the end. So just to start with, let's see if it's, here we go. All right. So there has been obviously a lot of exploration in this space, right? Over 90 countries have been exploring CBDC whether it's writing white papers, doing research, running pilots and so on. But there's actually 10 countries that have launched digital currency. There is obviously, we know about the work done in China, Eastern Caribbean, there's been a few. And the session this morning that was supposed to include a person from Nigeria as well because they have launched recently. I think it was last year, just last year in the fall, happily the fabric-based digital currency environment. So there's a lot of drivers. I'm not going to go into all of the business discussions about why CBDC is becoming an important topic for many central banks. Just briefly to summarize, there are concerns about impact of cryptocurrency on the sovereignty of money and currency management in various countries. There is obviously presence with Bitcoin, with Ethereum, with many other cryptocurrency environments. And in some countries, they're beginning to have a significant impact and impact the national economy. So central banks are concerned about monetary policies that they must control and must remain in their hands. So sovereignty is a big issue. The sovereignty of the monetary system is also important, particularly during the COVID pandemic times, when many banks struggled. When you think how we handle electronic payments today, whether it's debit cards, credit cards, funds transfer. A lot of that depends on not central bank money, but commercial money. Money that's created by the commercial entities, commercial banks, financial institutions. Through the loan deposits coming in, the loans going out. And if that part of the bank is going to suffer and the bank is not going to be able to maintain its role in that space and they're going to have issues with loans not being paid and so on, that's going to bleed an impact into the ability to handle payments as well. And so some central banks are thinking about how to separate the payment making capability, which is a critical to functioning of the economy, from the more money creation capability and lending capability, investment capability of the banks and not necessarily ties it together. So CBDC offers some of those new capabilities. And then the third area is financial innovation, the ability to create in an economy, particularly in many developing countries, capabilities that would attract investment, would attract e-commerce and FinTech industry and all of those things. And that depends in part on having those kind of digital currency capabilities. But again, within the control and on the oversight of a central bank. Now, when we talk about central bank digital currency, right? We have to make a few definitions here. There is this what's called money flower, which is a work that was done a few years ago to describe the different types of money and then highlight, you know, the intersection of token and central bank issued versus digital or widely accessible categories and place central bank digital currency within this money flower, right? So you typically have, you know, tokens that can be issued by central bank, right? In a value based economy or there could be account based, right? There is both token and account based money systems out there. And the main thing they have all to be issued by the central bank, they all have to be digital, right? So there's this within the green and blue ovals. But they could be token or account based and they could be widely accessible in a retail case or just interbank when they're not widely accessible. They're just for financial institutions to transact with one another. So this is kind of some basic definitions of what constitutes CBDC. When you start dealing with the banks and talking to them, there is a lot of issues that they have to address though. It's not just the question of how do I implement one of the things. There are policy controls, right? How do you control the amount of money? Is it a price control, which we know as interest rates? Or is it quantitative control where you specify certain accounts can have only up to certain limits of CBDC? What role should the central bank play versus commercial entities? We've heard earlier on the panel today that this is a big topic for Bank de France and the euro system in general. Because they want those banks to participate. Obviously, we're talking about the numbers of people in a retail CBDC environment in Europe, for example, that the central bank ECB is not going to be able to handle and provide those direct services. So it's going to be an indirect system, two-tier system, and those commercial banks probably want to participate. Or central banks can create new regulated entities, typically referred to as payment service providers or payment interface providers, which could operate on the different charters and not be allowed to engage in any lending or other kind of risky activities, but strictly be there just for the payment. So there's a lot of policy issues, right? But then there is also technology questions. Do you implement it using a GLT or blockchain platform, or do you use more traditional centralized ledgers built on a database? How do you ensure resilience and safety? Do you use an account or token-based money system or try to bring the two together to maximize the benefits? Privacy and anonymity is very important obviously for acceptance. I mean, if you create a system where a central bank can actually see every single transaction between Alice and Bob, Alice and Bob are going to go elsewhere. They're not going to want to use it. But at the same time, the bank has to be able to regulate, right? I mean, we all know about money laundering regulations, sanctions controls, you know, all the rest of it. And so certain transactions have to be overseen. They have to be able to understand who's involved in those transactions and so on. That's a balancing. Scalability is obviously very important, particularly when we want to ensure that there is immediate finality in a payment, right? If Alice makes a payment to Bob, it won't Bob to be able to use those funds to make his own payments. So that immediate finality is something that requires very low latency. But in order to ensure scalability, you want to parallelize the environment. You want to shard the ledger, if you will, and then cross-shard transactions begin to cause, to have challenges with regard to latency and so on. There's also coexistence with other payment mechanisms and rails, monitoring and those other things, right? So all of those are very specific topics of discussion that we're having with a number of banks. Now, hyper ledger community has been very active in CBDC space. There are other DLTs and other blockchain technologies out there. Corda's been participating in quite a few. There has been a quorum and a couple other implementations as well. But if you look at the map here, hyper ledger, fabric, Iroha, Bezu have been very active in this deployment map, if you will, of CBDCs out there. And the things that will continue because hyper ledger brings together some of the most advanced technologies needed for bank grade implementations. And so I'm going to talk to you a little bit about how we are approaching it and the work we've been doing, particularly around hyper ledger fabric, what it looks like. So just a few examples of some engagements. We are participating with both Bank of England and European Central Bank in various technology discussions. There is standing technology forum that Bank of England established since they published their white paper and we've been participating in those conversations. As well as with ECB, they have raised a set of topics. They invited vendors to respond to them and Oracle partnered with a company called SW7 to respond specifically on two topics. One about privacy preserving technologies and retail payments. And another one was about how to fund and defund digital wallets in a manner that does not link the fiat account from which you're funding it, bank account, with the anonymized CBDC account. So we've had those discussions. We've also been involved with RBI in India, some initial discussions focusing on their goal of deploying an interbank CBDC later this year or maybe in 2023 at the latest. We actually created a prototype implementation based on Oracle blockchain platform and some of our other technologies. And also been working to extend it kind of in a 2T architecture bringing in the capabilities we have in Oracle database as well for more scalable retail portion of that. We've also been working with Central Bank of Philippines BSP on their intercompany. They started with a wholesale approach initially through a number of presentations, demos and so on. They're beginning now a phase one POC where they're bringing in 10 to 15 financial institutions to be able to participate in this rollout. Initially it's going to be essentially issuing transferring CBDC currency on a 24-7 basis because they have today a system internally that has basically limited hours in the RTGS implementation. And their concern is that what happens out of those hours when the banks cannot settle. There is potential risk. So they want a 24-7 equivalent basically of that. The second phase will actually integrate with that system and allow the financial institutions to transfer between fiat currency and Central Bank digital currency as well. Basically digital PESA in Philippines. So involved in that one, we've also been working with Central Bank of Kenya through a number of proposals and discussions. Kenya is quite interesting. If you know a little bit about their payment systems, they have something called IMPASA which is a mobile payment system which covers around 50% of payments in the economy. It's very popular. It's very scalable. It's been built initially by their telecom providers and widely used in the country. It's also used in cross-border payments between people in Kenya and in other countries as well in East Africa. So one of the questions they're trying to address is how to introduce a CBDC system that would in some way collaborate with rather than replace the IMPASA systems they have today. Rather to focus the CBDC on domestic payments which impasses sort of handles today with a lot of inclusions. They have been able to do some really amazing things in terms of bringing up the levels of financial inclusion in Kenya or to introduce CBDCs as more cross-border based because there's still significant cross-border costs involved. And we've been working with a bunch of banks also in the Middle East and other places, Jordan, Iraq, Morocco in terms of just understanding where they want to go, helping provide our point of view and looking at discussions related to security, privacy, scalability, all of those things. So just to give a little bit of a sense of what we've seen over the last, I would say, 18 months or so. When we talk to many banks, they are trying to put together a roadmap of what a CBDC rollout could look like. And so we propose basically a roadmap that starts first with interbank payments. Interbank payments, wholesale CBDC in some sense is simpler. It brings up a subset of issues, subset of requirements compared to a retail one. So that's an easier, simpler place to start and prove the capabilities where you have only participating banks or other financial institutions. And initially it becomes payment versus payment implementation followed by delivery versus payment, where fixed income security settlement between the banks is done through the central bank as well, through something about digital currency. You can then extend it to allow large companies, enterprise B2B kind of payments, to start working through that system as well. And then you can also introduce that cross-border if the central bank is able to and willing to collaborate with other banks as well, where they have a lot of trade. And then you extend that into a retail world. And some of the interesting discussions we had in the retail world, again, there is multiple phases involved. One of the interesting things in discussions we had in India in particular is that there is a lot of government payments, government to people, whether it's from central government or through the state government. So it's government to government to people. And the traceability that CBDC could enable in that area is quite interesting. So they've been thinking about that as a separate phase from ultimately bringing in, you know, P2P portion to portion retail payments, which would be, you know, sort of the last level of scalability. So when you start looking at this kind of roadmap, the banks are first and foremost, the central banks, are really careful to ensure that whatever they do, they don't create problems for the existing systems, right? I mean, at the end of the day, the economic well-being of the country depends crucially on stability of the current system, right? And when they introduce something new, they want to be able to make sure that there is systemic stability as it persists. So it kind of broke this down into five different areas that impact systemic stability. Of course, it's financial architecture, right? You know, is digital currencies that central bank reduces going to be convertible with their current currency, with their fiat? In most cases, the answer is yes, right? Is it going to wholesale or retail-focused? Are you going to implement it based on the one-tier ledger when all transactions live in one ledger? Or are you going to have a two-tier ledger where you essentially have central bank maintaining the ledger that's aggregated across the participating payment institutions or banks, and then each bank maintains its own retail ledger that rolls up into their central bank ledger. So there are different schools of thought on that in different countries. There are policy choices. Again, how do you control the supply? Is it quantity-controlled or is it price, which equivalent means essentially interest rates? And what does it mean for bank accounts? You obviously don't want to undercut and have people pull money out of the commercial bank accounts, right? There are privacy issues, financial inclusion issues, roles of central bank versus private institutions. Was they existing commercial banks or newly created institutions, you know, FinTech institutions that would be responsible for actually handling payments? The different money systems, which is essentially how you store and exchange the value. And this is where we get into the topics of accounts, which are token-based systems, token also known as bearer systems. And then how do you implement the technology, whether it's based on a DLT, blockchain technology, permissioned public, other technologies, and how you handle offline as well, when you want to make sure that you prevent any kind of double spend so you need to have protocols that allow two people who are hiking in the woods without any cellular connection to be able to exchange payments, right? There is a merchant maybe in a portion somewhere without connection and then be able to settle that into this update into CBDC ledger at a later point, but ensuring that, again, nobody can refute the payment and at the same time you cannot double spend. So there are some interesting protocols. Visa has published a very interesting paper on the topic, which we are following, suggesting some mechanisms for that. Now, you look also at the broad impact of CBDC technology across the different aspects of the financial system. It's not just the central bank. You're going to have either commercial banks or payment service providers involved and they're going to need to participate in employee technology and the regulators as well, right? Sometimes financial regulation is within the central bank and other countries it's a separate function. So we kind of broke down the stack into a few levels here. If you will, the usual layer cake diagram here with basic infrastructure of the cloud on premises, then the actual ledger technologies that support the transaction layer which could be based on a permissioned blockchain network or in some cases database that can provide equivalent capabilities and we have done some work as a sidebar in Oracle Database to provide blockchain tables which have similar capabilities in terms of tamper proof and immutability and so on. Then you have the money system on top, oversight and regulatory surveillance. So the banks and payment interface providers don't need to worry about it but financial regulators and central banks definitely do. And then you have various applications that will need to be deployed across the entire ecosystem, whether it's financial crime and risk management applications, customer experience, currency management which is over the central bank application and so on. And finally you have the actual user experience whether it's a mobile device or in a web application and so on. So in this kind of a stack, we start by essentially positioning Oracle blockchain platform which is top of the fabric that we have imbued with a lot of additional capabilities and functionality. So if you're familiar with top of the fabric, you have the PNO that maintain copies of the ledger on smart contracts. It's responsible for creating the blocks by aggregating user transactions. And there is Fabric CA which provides membership services. It essentially manages identities and creates X599 certificates for everybody. We have added operations capability for monitoring, management, etc. API gateway for integrations through the rest APIs and events to make it easier to integrate with this environment and pre-assembled all of the underlying capabilities that you need to make this really work in one environment. So it's kind of blockchain as a service, if you will, level offering that is available in Oracle Cloud as well as on-premises. It's open in terms of interoperability with other non-oracle Hyperledger Fabric nodes. So we have a number of customers today who are deploying across multiple clouds or multiple Fabric providers, if you will. A lot of integration capabilities in addition to rest API events, open source client SDKs that come from Hyperledger Fabric as well as various integration adapters for many systems in Oracle and third-party systems on-premises in the cloud. A lot of automation. And then most recently we've created some development tools. We're actually going to do a demo after lunch. We have a session on low-code tool called Blockchain Upbuilder that also supports the organization in addition to other kind of interesting use cases. So come to that one if you want to know more about it. We've done a lot of work to enhance Fabric over the years and we've started working on it in 2017. So it's been about five-year investment in sort of deep technology capabilities around management, scaling, automatic redundancy, high availability, dynamic scalability, extending security and auditability, identity management integration attached on the API gateway capabilities, a low-code Blockchain Upbuilder, and data management as well as most recently some capability around providing atomic updates across channels with a two-face commit protocol because sometimes you might have data and chain codes that need to be coordinated and you want an asset-like properties or atomic updates but not only across channels within Fabric but also with XA Support, XOpen XA Standard that allows us to be able to update blockchain and databases in a coordinated atomic transaction as well, which is kind of interesting. And I've been pretty highly rated by these analysts. So we have started working on CBDC after this came out with the Deconization Support. In earlier session, Michael Klein from Accenture talked about token taxonomy framework. That's what we are actually using as a specification layer in our Blockchain Upbuilder to be able to define fungible tokens and later on non-fungible tokens. And based on the templates that you can specify and you can select specific behaviors, you can add custom properties and so on, and then generate them automatically or to generate the entire set of chain code methods necessary for the token life cycle. So minting, issuing, transferring, burning, et cetera, as well as all of the upfront initialization accounts, the top role management that's built in. So we generate these token capabilities in a core SDK that's deployed automatically and then there's a set of wrapper functions on top of that, which also has been extended to go beyond fungible tokens into NFTs and ERC721 based non-fungible tokens. So now that you have this kind of capability, we can easily customize it to support actual CBDC environments and roles. In a central bank environment, you have multiple parties typically involved in minting, issuing, approval processes, transfer to the commercial banks and all of that. So we have to cater to users' multiple roles with role-based security and the ability to also extend it on a custom basis for particular integration requirements that might be important. So in the wholesale platform, the sandbox I mentioned earlier, right, we essentially have four main parts. There is an onboarding where the accounts can be opened and set up and roles assigned. There is core money system management to be able to issue and burn or retire funds and of course monitor the status and central bank once a lot of statistics about that. Then there's actual payment transactions between the accounts, the entities, whether it's banks or individuals. And then finally, fraud prevention, AML, CFT monitor, counterfinancing, something like that. And so there is a lot of regulatory capabilities and components as well that are very important for central banks. And so the token systems that we provide essentially creates all of those APIs and chain code methods out of the box. You might have to do some integration customization for specific bank, particularly if, like in Philippines, they want to integrate it with the RTGS system. Oracle has this solution that's called Oracle Payments Hub, which is often used by banks to integrate a variety of messaging, financial messaging, right? And so we can integrate with that to be able to have the RTGS system interact with the CBDC system. The sandbox consists of a few different services in Oracle Cloud. So this is basically a cloud-based deployment primarily, starting with a blockchain platform. We are database and analytics, identity management, of course. And then some tools for integration and visual builder is a local development tool for web UIs, mobile UIs, or whatever applications need to be developed in that environment. And then you have connectivity to both central bank on-premise systems and individual participating banks. When we deploy it, then the blockchain network we add nodes to the, for financial institutions that are going to be participating. And there's different application flavors based on roles for central bank as well as for financial institutions, right? The central bank has the roles to be able to issue the currency and mint it, retire the currency, monitoring, auditing specific to central bank. And then on the financial institution side, there are interfaces and APIs to be able to handle transfer as well as monitor the transaction history of all transactions that they participate in. And so this is kind of the sandbox architecture that we have put together. And then within the sandbox architecture we have the application that handles those four main capabilities that I described before. Now, this is all good and well when you talk about a single T environment, but when you have to think about hybrid models or pooled models, right? In a direct model, you basically have all of these users and their ledger transactions all appear at the central bank. The central bank can see every single transaction. In a hybrid model, you sort of have the same thing, but not in real time. So the banks maintain their own ledgers and then they synchronize them out to the central bank. If one of these banks fails, there is a time window when their transactions are not yet available to the central bank which creates some risks, right? So you kind of want to make sure that that synchronization happens fairly frequently, right? You know, at the level of seconds and minutes. You then have a pooled model, a bank of England called the pooled model, where you only have at the central bank the ledger representing the bank balances and the individual account and the individual ledgers here are maintained by the individual institutions. And then there's CBDC backed in money which is sort of a really misnomer. I don't even want to spend time on that. That creates the most amount of risk in the system, right? When the retail banks allow to use CBDC to create their own money basically, right? So they get that in reserve in CBDC and they can create 10 times, 100 times as much. Nobody will trust that. That's theoretical capability but not really one that we've seen anybody interested in. So if you look at the financial architecture, let's build this out, where we want to scale this. We want to be able to take the central bank distributed ledger and we want to be able to short it, right? For parallelization so that we can, you know, support this in an environment where we have millions and hundreds of millions of transactions and entities. Typically, right, in the two-tier system like this, you're going to have retail users who have access to the individual providers here and those institutions serving those retail users can provide additional services, right? Not just to facilitate the payment interaction but they can also provide value-added services, conditional payments and other things on top of that, right? There could be either existing banks or central bank had decided to make them a separate chartered bank kind of a different charter where they're not allowed to engage in lending or monetizing transactions or other things. But all of these things like scalability, resilience, all of those are important considerations and so in order to be able to short this, we have to create a system that can allow multiple shards to exist and run in parallel but at the same time we have this tension because we want to provide immediate finality. So if Alice makes a payment to Bob and both of the accounts are on the same shard, that's easy. You just make an atomic update on that shard. But what happens is the accounts are on different shards, right? So they go through the different payment interface providers. So that's a challenge, right? Immediate payment finality and cross-shard updates don't usually work together very well. So in order to solve this, we need to come up with a system that allows us to essentially provide immediate finality without waiting for the cross-shard update, right? And so we work with a partner to create this set of capabilities that combines an account-based and token-based money system in a hybrid environment. Essentially what it does is that the global state and the accounts are shardable across the multiple channels, let's say, if you use capital-edge of fabric as an example. But at the same time, there is no cross-shard update required for the actual payment at the time of payment in order to achieve the finality. We have essentially a single immediate settlement within a single shard. And to do that, we maintain two forms of an object and account which presents accumulated balance, right? So you're like your total wealth. And something called a check which is like a token. It represents a transfer of certain amount. So the ways that this, you know, fundamentally works is that, let's say you have shard A where Alice has account and shard B where Bob has an account. So when you're doing an immediate payment, you're essentially, you know, deducting whatever the delta payment is from Alice's account and you're creating a check and transferring the ownership of that just like you do in a token-based system to Bob. So all of the green boxes are owned by Bob and all of the purple ones owned by Alice. So at this point, Bob has multiple checks floating around different shards, plus Bob has his own account, of course, right? And so there is a merge phase following the immediate payment phase that consolidates all of those checks on a regular basis. This could be as frequent as, you know, seconds or depending on the circumstances and the requirements into Bob's account. So when Bob needs to make a payment, if the application he is using has access to be able to scan and find all of those checks. You could use that check and just, you know, assign ownership to somebody else, let's say, you know, Bob is paying to Chris. Or they could make a payment from their account as long as there's sufficient balance there. And so this combination is really something that allows us to provide scalability with multiple shards without necessarily, you know, delaying the payment introducing additional latencies. So, you know, we are solving essentially the payment finality issue here. The, you know, checks are merged on whatever policy control frequency you want. There is basic messaging streaming kind of a capability that can be used to consolidate the checks back into the balance for each account on a very, you know, rapid basis. In some cases, it may be important. In other cases, you know, it may not be that important. But when you think about it, when you combine the token and account system together and you get this hybrid, you have the benefit of both worlds. You have the immediate finality and scalability which you cannot get with a direct, with just account by system. But at the same time, if you're using just token system, you also have some issues that you don't know at any given time with the total balances. Therefore, you cannot impose any kind of caps or limits in order to maintain the total amount of currency per account. Let's say some country might decide they're going to issue central bank digital currency and individuals may be allowed to maintain up to, let's say, 10,000 units, whatever it is. Right? But you cannot manage that effectively because you're going to have as well distributed across multiple shards to have an account by system, then it's much easier to do that. Something if you want to calculate and apply some interest, right, as a way to control the quantity. The other area is contextual privacy which we'll talk about in a minute because, again, in order to apply that, you need to be able to have ability to link the account on an exception basis to somebody who's gone through a KVC process, know your customer, and that's going to be important. So this hybrid system really helped us to find ways that solves all of those challenges. Now, the privacy and confidentiality is very important, right? So if you look at it in an environment where you have complete privacy in crypto world today, you have essentially cryptographically secured privacy. It's secured through actual cryptography. In traditional payments in the banks, you rely on the institutional integrity, right? So it's a policy of the banks that they're not going to disclose your information, but it's only a policy. A rogue employee who has access to the data could actually leak the data, right? There is no cryptographic controls necessarily, right? And it could be easily recoverable. So it relies on processes and controls, but it doesn't rely on cryptography. So what we wanted to come up with is a solution in the middle that's what we refer to as contextual privacy where the privacy is cryptographically secured at one point using pseudonymous accounts. So you have essentially accounts controlled by users. But at the same time, there is ability to request a linking or a decryption, if you will, of that pseudonymous account in a manner that's transparent and auditable in order to avoid any kind of abuses, right? And it enables privacy for a vast majority of transactions, but at the same time allows banks, central banks in particular, to apply AML rules and regulatory regimes, particularly when they have, you know, legal enforcement and other things, warrants, what have you for various investigations. They have a process that allows them to get access to the information links that pseudonymous account, but in a manner that will be transparently visible and non-refutable so that will provide a control, if you will, to protect against any abuses. So this is based on what's called privacy-preserving accountable decryption, PAD, from SW7 and implemented in our blockchain platform. There is basically a mechanism that involves trustees and multi-party computations. There is the keys that Alice uses to essentially set up initial accounts. The private key is sharded across multiple trustees. And then there is a request, let's say in this case, Bob, some kind of government regulator needs to request a decryption. They send a request and there is this blockchain ledger where the request is submitted so that it's visible, et cetera. And then trustees can provide using threshold encryption mechanism, sufficient number of shards to satisfy the decryption request. So when we apply it to CBDC, basically we allow users to generate the pseudonymous accounts. Still Alice will go through a KVC process normally. The payment service provider will have that information associated with her identity. But then when the account is set up, it's not linked. But at the end, Alice can regenerate those pseudonyms if she needs to. And when she talks, she uses the pseudonymous account information. But the regulator can request a decryption when necessary and then again they're held accountable through the blockchain. The way that the mechanism works is on-boarding process where the user initially comes in and uses his payment interface provider and goes through the KVC process and then there is an anonymous process to set up a pseudonymous account sharing the keys with a trustee system which could be regulated by a variety of other regulators and so on. And then there is an unlocking request. Let's say you have a rule in U.S. for example banks have to disclose any transactions that exceed $10,000. So let's say we have a payment here $12,000 payment being made while the payment interface provider here can put a request to find the owners of the account from and to and they get back then the key is necessary to decrypt as they get the decryption and then they can check with the AML system sanctioned systems, et cetera is this okay, allowed or not and then they can go ahead and send the transaction forward to the blockchain ledger using those pseudonymous accounts if it's fine and at that point they can also do logging, et cetera if they need to. So this is an exception based if you will of contextual privacy and of course you want to use blockchain for it not necessarily a public blockchain it could be permissioned blockchains it's operated by certain regulators based on legislative rules and so on but users also can be provided access so if Alice has accounts been subject to that she can be provided access to see who, what, why, when and so on. So you need to protect privacy when you're funding an account so when you are transferring initial money into a CBDC account you don't want that to be linked with your bank account from which you're transferring so this mechanism today when you're doing it without the SPAD system bank has this association Alice with her bank account transferred money into this anonymous account but in this environment with SPAD we can actually contribute fund to a bank owned account that's done without any protection privacy protection but then she has her own account she can request, she gets a claim check and then she can use her pseudonymous account to request transfer from that PAP account and that becomes an anonymous so we have put together the sandbox that essentially brings together all of those capabilities in the central bank network you can extend it for retail capabilities you have this SPAD system that manages the secrets and then you have the regulator as well with the applications and so on and you can kind of go through this entire life cycle I'm running a little short on time here so I'll just summarize here what we tried to do was to essentially solve real world problems talking to banks, talking to central banks in particular we find what worries them the implementation of CBDC and where we can provide pre-built out-of-the-box solutions we try to do that so we're starting with Hyperledge Fabric which provides very strong capabilities to begin with learnings foundation best practices, the community flexible identity management transaction verification model configuration control privacy models which are much stronger than in any other blockchain framework and then we layer a lot of strategic enhancements we have done for bank-grade platform with flexible PKI banks often prefer to use their own PKI rather than self-sign we support that, dynamic scale-up fault tolerance built in streaming for off-chain into Oracle database for things like analytics, machine learning built in auditing, block integrity verification configuration auditing, all of those things and then the specific novel capabilities with contextual privacy multi-TSBDC ecosystem hybrid account and borrower systems that combines together in a way that brings the benefits of both to solve the particular problems with scalability, with charging without impeding the finality requirements and ensuring then that users also can benefit by having quick balance they can check on you could impose per-account limits as a matter of policy the bank wants to do interest rates on the SCBDC that can do that as well it's really more of a policy question so I'll post here help take a few questions if I don't know depending on how much time we have yeah, yeah, so in hyperledger fabric everything that you do on the ledger itself is implemented as a smart contract, right? smart contract is a business logic and our token system is implemented using smart contracts so the transfers, minting, issuing that's all methods in chain code smart contracts, you can then add additional complexity on top of that with, you know, payment mechanisms if you will contextual or contingent payments or other things, right? through smart contracts running on top of the core SDKs that we provide so our smart contracts that we implement and we generate from the blockchain outbuilder, in fact I'll invite you to the session in the afternoon we're going to be generating some smart contracts essentially an SDK layer if you think about it that way and then you can implement your own smart contracts on top invoking those methods so the idea is that you don't need to do an atomic transaction across the shards so you have separate smart contracts on different shards different channel and then you have an application an orchestration layer that can coordinate between them or across them right and there is an orchestration we basically have a two phase commit protocol that we've implemented, we have an API gate where it sits on top of Hyperledge Fabric environment if you will and it can orchestrate across multiple channels and multiple shards with two phase commit okay, so first of all we have role based control so Alice can only see can only query the data for her account right and any checks that she owns various shards as well is enforced by the role by status control okay, it's underlying ledger yeah, so it's underlying ledger of course is encrypted I mean data and storage is of course always encrypted and if you just look at it as file blocks she will only see encrypted blocks also data and transfer is always encrypted so yeah so we can support private keys in two ways right, one is using custodial accounts where we actually manage the private keys for the user most users who are outside of a crypto world actually find the process of managing crypto keys reissuing them and all of that quite complex right so we try to provide custodial capabilities but we also have the capability Oracle Cloud has this Oracle World KMS where users can create their own keys and then they can maintain them and they can sign all the transactions outside and send them through the Hyperledger Fabric client as the case so the SDK allows for external sign externally signed transactions so private keys and always remains under users control okay, so when you register an account you actually send a certificate request in Hyperledger Fabric as there is a CA right, so you generate your public key pair you create a CSR with the public key you register as a client and then your identity with that certificate and the public key is stored and available in the blockchain so then, you know, based on that identity when your transaction comes in you sign it with the private key the peer node can then detect the identity verify against the public key yes so high reliability is achieved by replicating the environment for resilience across multiple data centers in Oracle Cloud environment we typically in each region like Major City for example, right London we support multiple data centers usually like 20 kilometers apart and they create what we call availability domains right, so when we deploy the blockchain platform we have two flavors, one of them just small development environment but the enterprise environment automatically distributed across those three availability domains out of the box in addition, you could have multiple instances across multiple geographies and you can create an ordering cluster with ordering nodes that are collected from multiple instances and that ordering clusters and becomes geo redundant if you will provide resiliency across the geographic regions anything else yes, please so, I think it depends on scalability, we do have a two-phase authentication where you can do a rollback but in the environment where you need to be able to support massive scale, millions of transactions per minute I don't know, I haven't thought about the numbers I have to go back and figure out if this gets adopted in India with 1.3 billion people, what kind of scale we're going to talk about over the next few years but you can also do compensating transactions as well if necessary and in a retail environment that might scale better but generally, again, the messaging and the orchestration of those checks by adding them into account balance that whole process is resilient on its own so, of course nothing is counted percent in computer science, we always live a little room, something that can always happen but generally that process itself is built to be resilient with multiple checks and with parallelization as well so that for each target chart there's separate streaming queue and that itself is backed and replicated in a different availability domain and so on so I mean it's really built as a bank rate system alright, well thank you for attendance and taking the time we have more information available if you're interested on oracle.com's blockchain there's also blogs at oracle.com and then you can also go and actually play with some of the blockchain technology free in our cloud, we have free sign ups I think it's something like 30 days $300 credit you can experiment and you can download, we have a non-premises version as well with the call OPP Enterprise Edition there are customers who may not choose to go with Oracle Cloud so we have a version available that is you can deploy on VMware oracle virtual box and technologists like that and you can play with that as well thanks