 Next to the, yeah, yes, that's it. Okay. Thank you so much. Next to the, yeah. So here we are. Okay. And so I give us a lot of audience. And so I think this audience is pretty familiar with the difference between commercial bank money and the far left, which is what most digitized money really is, is commercial bank liabilities, ACH check, wires, etc. Crypto, which is not backed by anything in particular, not owned by any company, not backed by governments or central banks, volatile stablecoins, which attempt to be, it's a cryptocurrency backed by assets that attempt to be pegged to a fiat currency user US dollar. I think stablecoins have great promise, but I think stablecoins are not all created equal than there are issues with a number of them, some of which most people don't understand. And then the far right, we've got such a big digital currency, a liability of these, the Fed in this case, both wholesale and retail doesn't have to be delineated that way. But most payments are delineated between wholesale and retail. And so there's also a lot of misinformation about what CBDC is. So it's not necessarily built on a particular technology. I get a lot of questions about, will it be anonymous because cash is anonymous? And I don't believe we should build something that's based on a property that's based on paper. And so also people conflate Bitcoin with CBDC, we are not going to create a CBDC that is mined by the public. That's not how any central bank would at least begin. We're not going to have proof of work. So we're not going to consume the energy of Ireland or Iceland, whatever the example is in the course of the year by, by burning and minting money. It's also, if we, if we actually created a CBDC, it's not to eliminate cash, at least the retail one. It's also not a PMC. It's not going to solve all the world's problems. And I'm happy to talk about any of these, but I'll keep going. As far as why we're doing this research now, we actually started back in 2016. I actually get the bug back in the 90s when it was Mondex and E-Money and E-Gold and all that. And it's really been focusing on blockchain, DLT, and Bitcoin since the launch of Bitcoin. And we actually did work back in 2016 to create a wholesale CBDC, first with Ethereum, then Hyperlegia Fabric, because they were the only two platforms that existed outside of the Bitcoin blockchain. But then we pivoted in 2019 and started working 20 for some major reasons. First of all, China had announced that they were, will be doing a production pilot of their CBDC, which they started back in 2014. We all know Facebook announced Libra, which changes name to DM and then was sold off to Silvergate Bank, which hasn't yet launched anything. JP Morgan is JPM coins, stable coins growing. So these are all important things to have central banks to be thinking about the implications both of these products, but also the potential for a CBDC and of its own. But most importantly, back in March of 2020, there were two bills that were part of the Cares Act, which was in the US, was our COVID relief bill. And they would have directed the Fed to build a retail CBDC with accounts for citizens. And so when Congress starts to act out, neither of these made the final bill. But when Congress starts to act, it's important that we be ready to react to whatever those laws might be. There's been more legislation introduced. There's a number of bills being considered now, one passed, one introduced recently by a Massachusetts congressman that would have created a cash-like CBDC. So a lot's going on in Washington and all the more reason why the Fed has to be ready. So what I mean by being ready is understanding the technology. And so the analogy would be if we were asked in three years to build a CBDC and we don't start now with three years behind, anybody has built a system or understands payment systems, they're complicated, they take a lot of work, there are a million issues that have to be worked out. So we had to start now. And what we've done is the major part of our plan is we will call Project Hamilton, which is joint research with MIT. So with technology research, we're building a research model. I call it a prototype because that's what it really is, but it's a research model to say, can we build something that works? And not just, I mean, anybody can build a system, move some data around, call it money, and say they did a POC, and that's worth very little. Can you do that scale? And so we're trying to do this at scale with real-world problems we're trying to solve. We have various design options. This is research, so we're not just doing one, we're doing multiple. With technology agnostic, we look at DLT, but we also look at other technologies. And we recently, and hopefully people have read it, published our joint technology research paper on February 3rd, and did something the Fed has never done, which is basically issued an open-source license with MIT for the code, open CBDC. And I understand that a lot of people here have looked into that. It's also important to know that no decision has been made to move to production, but not even to pilot. A lot of people asking, when can I hook up to it? When can we test? When can we pilot with you? And I don't have even an approval to move to pilot. And obviously, there'd be a significant change from just a research effort. But obviously, it could be a step along the way, but not to be determined yet. So, step one on project Hamilton was to build the core engine. So, this is the core engine fermenting and storing and moving the money at scale in a resilient and safe way. So, our goal was 100,000 transactions per second. I've been asked, where did that number come from? And I said, we think it's the sum of all the credit card transactions in the world every second. It seemed like a good place to start. What we were trying to start at some place really high and aggressive, because we want to make sure we can work at scale, and we know that systems slow down when you add more technology to them. So, settlement under five seconds, resiliency, very robust, highly resilient. Now, this is resiliency from technology problems, generally, network issues, not necessarily a full-blown resiliency to cyber attack, dial service, etc. We've not gone that far. In privacy, just some basic privacy, how we built the identification system. Phase two, which is the next phase, we're done with phase one, we'll talk about that. Phase two is getting into different policy choices and design choices. I'll be very clear. I'm the technology guy, I'm not the policy guy. I know the questions. And the policy, as we'll talk later, is being handled by the Board of Governors in Washington. But we know the questions and the thorny issues. So, for instance, privacy versus compliance. That only these hard, but they conflict. How do you try to maximize privacy and still catch the bad guys? A challenging problem even today. For the vulnerability, should it be smart money? Should logic be within the money? Should the external to the money interoperability and cross-border key issues for any payment system and accessibility in an offline? And we're doing these tests for two reasons. One, because when you add code to the system, you'll slow it down. So, are we slowing it down? Are we adding new attack vectors? Are we slowing down speed per second? Or speed of settlement? Or throughput? But also, these conflict, privacy and compliance, as I mentioned, they conflict. And so, are there ways of looking at the newest technologies to try to solve some problems that exist today? AML, counter-terrorist financing is really hard. Not overly effective, my words. Banks hate to do it. It's expensive. It's a high liability. And that's the model we have today that banks do it. Or other payment system providers. So, are there ways of thinking about this differently with technology? In the world of crypto, there's something called a zero-knowledge proof, which allows you to examine data for particular conditions. Like, is this recipient on a bad guy list? Or without seeing the data? And I'm oversimplifying it. But could that be used in a CBDC to help solve some problems? So, we're starting to work on these now. We can talk more about them later. But that's the next phase. And phase two really is endless. It's going to continue as long as we have research we want to do into this particular set of topics. So, Hamilton phase one, I mentioned before we were, this is not a fully functional system. It's a clearing of settlement engine. We built it in C++ because we wanted to understand all the intricacies and nuances of building it. You'll learn a lot more when you do that. And we've learned some important things. We have to handle various policy outcomes. So, we had to make sure whatever we did, we weren't baking in assumptions that couldn't be unwound, like privacy considerations, or how it is distributed. So, it had to be built very flexibly. We had a goal of minimizing data, one for speed, but also for privacy. And for not having to worry about PII in the core engine. Paralyzable, one because that allows you to have better resiliency for multiple copies of the system running, but also for speed. And also, the assumption is, if we ever built this, the Fed would run it. As I mentioned before, we would not have miners, we would not have public people outside the Fed unless there were agents of the Fed. So, we wouldn't need open blockchain type consensus protocols like Group of Work, which obviously simplifies a lot. We do have consensus methods. We have ways of replicating data, but not like on the lines of cryptocurrency. So, here are the results. We ended up with two core engines. We had multiple along the way, one called the atomizer, one called two-phase commit. Now, the atomizer, we had about 170,000 transactions per second with 99% under two. With two-phase commit, we had 1.7 million transactions per second with finality under one second. We stopped at 1.7 only because we ran out of resources in the AWS cloud structure we had. And we know we could have gone faster than that. You say, well, why would you go faster? Well, we'd go faster because when you go faster and break it, you'll learn something. The one difference between these two architectures is the atomizer maintains the order of the transactions as they arrive. Two-phase commit does not. Two-phase commit does not maintain the order of the transactions, although with the speed we have, every transaction is generally done within the half-second, quarter-second of when it comes in, but it's not necessarily an order. And when you do that, you are able to totally paralyze the system because you don't need to have the order going through a single funnel. And that allows you to scale linearly, basically. And that was one of the a-has we had when we first started coding. We said, why would this system have to maintain an order? I couldn't come up with a reason, at least for a retail system. So we relaxed that, took the same code, redesigned it, and came up with Two-phase commit. Both are replicated in the cloud. We're in three different physical data centers across the US and still getting these speeds. And we brought down two data centers and still were able to process pretty much at speed. And the important part of this is that this system actually looks more like Bitcoin than it does a regular payment system. It relies on public-private key peers to identify who the user is. So right now we are able to link to an identity, but the identity is not part of the transaction per se. Just like in Bitcoin, if you understand Bitcoin, the private key is really what you use to identify who owns the public key, not the private key. And also we rely on unspent tokens, UTXO models versus accounts. We don't have accounts. There's nothing that says Jim Cunha has $100. It could be a hunk of money, say $20 that says Jim Cunha has 20 here, one unspent token. He's got 25 here. He's got 55 here. So three different types of, three different pieces of data that represent three hunks of money that I have. And if I want to give it, say, give Karen $10, I'll take the $20 UTXO, destroy it, create a 10 for me and a 10 for Karen. And that's how Bitcoin works. And then, as I said, we're very flexible. And so in a nutshell, that's what we built. This shows the throughput. And as you can see in the top, that shows the throughput. And on the bottom is how many shards is one of the pieces of processing we need. And as you can see with the atomizer, we sort of top out, start to decline with 16 shards at about 170,000 transactions per second, when all the 32 shards, which is 32 copies, up to 1.7 million, pretty much linearly. And so that's the kind of throughput we're looking at for this design. We are still researching whether the order that transaction matters. We've got lawyers and some regulators looking at it. And if anybody in the audience has used case for the retail where it matters, our thought was, you know, it's not like an account where you could kite or you can send multiple transactions on the same money. You have to spend the money discreetly. So each piece of money has to be spent discreetly. You can't spend it more than once. Jim, we just have a question come in in the chat. And I know you said you wouldn't mind us jumping in. Hart, actually, I don't know if you want to come off mute and ask your question or if you want me to just do it. Either way, Karen, whatever is easier. Go ahead. Much nicer to have the engagement. So yeah. Sure. Thanks for your presentation, Jim. I just had a question. Maybe I'm missing something about the model, but what techniques are you using to prevent double spends without a global ordering? So yeah, it gets into the architecture. So it's a multi-tier architecture. And I should have said earlier, if you Google YouTube, I'll give you the link to it later. But we have an hour and a half presentation. We go deep dive into the architecture, including each component, each layer. And what happens the first time it comes in, it's a layer that says, this is a valid transaction. Is it signed, et cetera, et cetera. And it passes to another layer that says, is there money? And once the money is there, it locks the money. So nobody else can actually use that $20 that I had in my example. And so once I have that money locked, no one else can go out with that particular money, even when it's paralyzed, when it has multiple copies running, because that's a two-phase commit, I lock the money. And then when I destroy the original money, and then create 10 for me and 10 for Karen, the old money is gone. So it can't be double spent because of how we lock that particular UTXO record. Was this the webinar on February, on February 11th? Yeah. Okay. I think I found the link. My architects and my lead designer and one of the MIT people also talks more deeply about the open source, you know, how to contribute, et cetera. And so here's just a little bit on the open CBDC. We've got, you know, and I'm not an open CBDC expert, but some who may, you know, MIT actually maintains the open source license for Bitcoin. And our license is based on the same approach and the same structure. So there's different connections here you have in your presentation, which obviously Karen can send out to you. We have people that are constantly manning this. We're creating work groups that can dive into individual problems to say let's figure out, like just say we haven't solved double spend, we'd say let's figure out how to solve double spend under the existing model. We get people starting to work and contribute on that. And eventually you could create code that would make its way into the into the GitHub for this product. So we're hoping that people will actually contribute code. And like I said, the whole process in the open source world, how that works. Now we also, you may have heard also that the Bank of England and the Bank of Canada recently joined MIT's in a bilateral relationship. And we're going to start thinking about how we do our joint work with them in an open source environment. We haven't, we're really thinking about this point, but we think there's ways that we can work together even as central banks in ways that may be open to the public, but we're still working on those. Just one more piece. That's Project Hamilton in a nutshell as far as what we're doing with MIT. We've got some of the great, we have great developers in my team. My architect actually was the architect for USC, USC, circles, contributions to stable coins, and other developers from MIT and MIT's group has, one of the core developers for Bitcoin is on the team that contributes to our code. But as far as we are, we don't believe we have the only solution. So we're also looking at open blockchain solutions, Solano and others that seem to have some promise for speed, hyperledger variations are on our list to look at. But we're also looking at private sector actors to say, are there any solutions that people have built that could meet our needs? This is not a buy versus build decision. This is really just to gather more information about what's out there to say, in case at some point in the future, if we were asked to move forward, what would be the best option? What we build? Maybe what we built on top of a different blockchain or maybe a private sector actor. So that's where we are. This is not the publication. It's really just to understand what these platforms can do and learn from them. And then eventually, once we get to a point, if we do to pilot, who can we work with out of these groups that might have some things to contribute? So from that regard, as the Federal Reserve Bank of Boston, you guys are open to work with other companies that already built something and you'd love to learn from what they've built so far. This is what? Yeah. So what we're doing is we're going to be issuing our RFI request for information. We've been doing our own research into what's available with some bilateral conversations with some companies. We just can't talk to everybody because we're a small team. But with the RFI, we are going to look at who's already built a system that says they can work at scale. And then we'll be examining all of those to see which might be able to meet the needs of the US. Like that kind of throughput, the kind of privacy considerations we might be considering. And then what we do is we'll bring a few in in some form and try to test them in our labs against the same test scenarios that we've been using. So we're very open to how this unfolds going forward. Also, as part of I mentioned a minute, as part of the Board of Governors research into what the, you know, their consultation to the public, we're also trying to understand how can we talk to technology companies beyond just what we're doing in Hamilton to understand what they're doing. What's the landscape? And so there'll be more consultation coming out of the board to technology companies, but trying to do it in a way that is not a thousand meetings. If you understand, but we're definitely open to it. I'm more than open to anybody who has a system, you know, to send me information. Can I email you after the presentation? I don't have an email or any contact that I can. Yeah, I'm fine with my email being given out Karen and the presentation. I always welcome anybody reaching out to me. I would love to reach out to you because we already built something and it's very interesting. We would love to get your feedback as well. Great. Yeah, please do. Thanks. Elisabeth, this is not something we're doing this year and done. This is going to be a process. If anyone's built a payment system and knows that this is a long process and this is much more complicated than most, once you get into all the considerations. So this is definitely a multi-year effort. Yeah, absolutely. I built a number of them and this is the most complex. I understand. Yeah, but we've been working a lot building on the interoperability. We built our own blockchain and we built the cross-border payment, basically settlement blockchain. And also we've built the CBDC or at least we are almost there. If we hope that we're right, but we're also learning and we definitely would love to add value, whether with the feds or somewhere else. Okay. I should imagine too that there's other research going on inside the Federal Reserve system. Most of it is the Board of Governors themselves. They set up a technology group that's mainly, so we're going very, very deep into CBDC. They're going a little, they're going less deep, wider across multiple blockchains and looking at other things like interoperability between chains and things like that. So I'll make sure I pass your information on the Board as well. That would be great, yeah. Because we looked into all those options, basically interoperability and also we looked at the CBDC and we looked at it also from domestic perspective or from the cross-border perspective as well. We looked at a lot of these details and we have built something. So let's maybe move it online and I'll send you. Thank you very much. Thank you, Ahmed. Thanks. So not the policy guy, but I understand. I mean, if you live in the Boston, we were saying, don't pave the cow paths. If you do, you get Boston streets. As you can see on the right, we are not a grid because we've paved cow paths. So what that means to me is as we think forward about this, we shouldn't necessarily build a new payment system to look necessarily like the old ones, nor should we assume that all of the policy considerations are the same. I mentioned one. Can we look at privacy and compliance differently with new technology? Maybe not, but I think it's an opportunity to look at fixing some things and unpaving some roads, if you will. So the next few slides are a bunch of policy questions and we'll not be talking about them, but the main message here is the Board of Governors has issued a public consultation paper January 20th and they're taking comments through May 20th and I highly encourage anybody with an opinion with a good idea. There are, I forget the number of questions there, but they're asking about a lot of the questions I pose here, like with financial inclusion, with interoperability, with intermediate questions. Yeah, 90s there, that's right. I was trying to think of it. It's 62 or 90s. There are a lot of questions, but you can answer them. 22 questions. Yeah, but they're complex questions. But they are asking questions about interoperability and intermediaries and obviously people from different areas have different responses there. So some of the areas that we think about for privacy and I'll just run through them quickly because I want to lead plenty of time for questions. You know, I mentioned privacy versus traceability. How do you catch the bad guys or do you have to? Financial structure. Very important to banks. Who are the intermediaries? Is it direct to the Fed? The Board has come out leaning in a direction that's probably not direct from the Fed. There's no decisions yet, but probably not. So who are the intermediaries? Likely banks, but are there others who are intermediaries? Can a customer custodian or hold their own keys? If this is a public key type of private key. Is there any potential impact on bank deposits where people flood to CBDC? These are real important questions. Interoperability we mentioned, cross-border. I personally think there is promise in cross-border, but it's not a panacea. The Bank for International Settlement, VIS, has a working group looking at cross-border. I think it's called the roadmaps for cross-border. And I believe they have the 16 or 19 different tracks of work, one of which is CBDC, which shows you how complicated cross-border is. So I mentioned double spending, counterfeit, span, how do you stop that? Is it a monetary policy tool? Is there an interest rate or not? Very complex, controversial. One of my personal views, not those necessary with the Federal Reserve System, I think a CBDC could help with financial inclusion if it's a stated goal. If it's a public policy goal that it will, I think we can help. Once again, not a panacea, but I think it can help. Innovation, I truly believe that a CBDC will spur innovation in the private sector and create new tools, new ways of doing things. Should a CBDC be smart? Smart contract. My view is not very. It could just be functionality, but not super smart money. It shouldn't stop me from buying too much bear. It shouldn't be that smart as it's getting in the way of how money should actually work, which is moving from party A to party B. And a lot of questions about wallets. Since it's a wholesale group, I want to at least mention that there's a lot of work going on in wholesale CBDC. By far, the leader is Singapore. Project Urban was going on 616. They worked with Canada and England that had three different blockchains with three different currencies and a currency on blockchain and did PVP and DVP across three platforms. So very robust testing, very, very strong. And they used Hyperledger as one, Corda as one, and I forget the third platform. And the BIS Innovation Hubs, which there are multiple across the world are looking at cross-border. Hong Kong is looking at wholesale cross-border. The New York Fed is spending up some work in wholesale cross-border work a little more narrowly focused called Project Cedar, I believe. So give the name of the person in New York if you're interested in talking about that. So let me end there and then stop sharing and then just get to questions. That was great. 33 minutes and I caught a few questions along the way. Like I said, I want plenty of time for dialogue. Karen, promise me this is a vocal audience. Yeah, I think you've already seen that. I'm more than happy to talk about any of those topics, stablecoins, crypto, Casper. I think Mohan has a question there which says, can CBDC do financial exclusion like in the case of freezing Russian assets? Depending on how it's built, a number of my teammates came from Circle Financials. So they had both a stablecoin before that they had a P2P network and they were able to freeze currencies that they knew were in wallets of bad guys. So by design it can be done. It's basically based on how it's built, how to identify the people in the legal infrastructure. But if this is based on public key infrastructure and you knew the public key was owned by someone on a bad guy list, that's the high part, then you have ways that definitely could design in ways of freezing assets or even destroying assets in a case like that. It's all based on design criteria and then the identity verification. That's the high part, million, all of this. How do you go from the currency to identity? That definitely possible. Hi, Jim. Jumping in with a question. So segue from the last one, talking about identity and privacy. So what are the real hurdles around identity? If you could spend a minute there and then given the way I think about this in a retail sense, there's not really a digital representation of people to tie assets to. So how do you think about that hurdle? Well, we started as I said before with something that was totally flexible. So we have a public private key. So that could be tied to an identity in a directory somewhere. It could be that, I mean, the way it works today is the Fed doesn't have identity, the bank has identity. And the identity is identified. So the bank does the KYC, AM, all that stuff. We get a transaction with information that may identify the person or may have information. That's solely for the bank. We settle with banks, not with individuals. And so it could be that the intermediary we work through, I think the most logical way is the intermediary we work through is able to connect that public key with an identity. And hold the private key if the person wants it held in custody, like you would do with a coin base, or the individual can hold their own private key if that's how it works. But so right now the most likely case is there's an intermediary that connects that public private key pair with an individual. Or the other option is some mega directory that does it. Because otherwise, I don't see the Fed holding the identity. In the U.S., we don't have a national digital identity. If we did, that would be great. That would work for something like this. That'd be a way of trying to connect those things. But right now it's a challenge. Thanks for the answer. Hey, Jim. A quick question. I know in a lot of high availability infrastructures, the goal is four or five nines in terms of availability. I would expect for the Fed that even that might not be sufficient. What are you guys looking at in order to reach that 100% availability that you guys are looking at? I know you mentioned you guys have multiple places where you're hosted, and that the Fed would host all of these. But are you guys satisfied with four or five nines, or what's your plan there? Yeah, we're going to try to push, and that's part of our future testing, is trying to push the envelope there. But definitely, it is parallelized systems, multiple data centers. We've got replication of the data across the entire system, so there's no single copy of anything live. I mean, live data, not a backup, or tertiary backups, things like that. Any other option is, as a failsafe, offline capabilities. How can it work? Just say, now, offline, because the system's not available, it's offline, because you're out of a cell coverage, it's offline because of a natural disaster. It's all different reasons to be offline, but we think offline has to be part of the equation for part of that availability. But we do want to try to, we are starting to talk to some of the leading vendors. I think the most bandwidth in the entire world is used by YouTube. And we're talking to YouTube all throughput, and we're talking to Amazon and others about availability and trying to make sure we're on a leading edge. And then eventually, because this would be important factor, is we bring in the miners and the other, both from a cyber attack and also from resiliency perspective, are there things that we haven't thought of, because four nines used to be okay? So we're going down all these paths at once, because I agree. I mean, I don't want to be de-cached if you follow the Eastern Caribbean, I don't be down for a month because something went wrong. That would be failure. Sure, thank you. By the way, this afternoon, there is a call of OpenCBDC-DX, and they're accepting proposals, right? So right now, they're working strictly on privacy and open privacy compliance, you know, working group. But they are open for other proposals, including for increasing resiliency. In fact, I have submitted, in the process of submitting a proposal for multi-cloud resiliency, not dependent on a single vendor like AWS. So I am in the process of talking to the people in the MIT group on Zulip, which is their chat channel. So you should come there if you have ideas and contribute to them. We're also looking at, and I'm not an expert in this, but how it's containerized and all that, so we can work across multiple clouds. At first, you don't think one cloud vendor's going to be enough. So we are looking at multiple cloud options, and obviously, that's some great work being done there as well. And I should have mentioned that, Trevor, as well as the other way is to contribute. If there are people out there with ideas, or I'm not sure they make up the group as much, I see some CTO titles and some smart looking people, but contributions are always welcome as this starts to unfold. And another question here is, how close or far is regulatory support to pilot the CBDC in the USA? That is from Jody Panapalli, who's from BTCC. And of course, as you know, BTCC has started its own DDP based tests on CBDC. Yeah, I've talked to multiple people that aren't been on panels with them as well. So yeah, I wish I had an answer, but I will quote Chair Powell that says we cannot move forward or wouldn't move forward without congressional support because he believes that it is important enough and not just because it's a very political thing. I don't think politics is necessarily bad, but we really need the support of Congress to help ensure that we get the backing of the country to do something like this because it is non-trivial. And so part of the public consultation and part of the executive order coming out of the Biden administration, as you've seen, is trying to get to a lot of these issues so that they can be debated in a determination way. But I'm not expecting anything in the nearest of terms. Like I said, unless there's some legislation that sort of supersedes some of these efforts. I think there is a question by Sandy, which talks about the offline capabilities in case of cyber attacks or a bug. But more than just cyber attacks or a bug, offline capabilities are an important part of inclusion, I guess. And I think it kind of relates to the question about resilience. Yeah, and I actually have the chat up now because I couldn't present or watch it. Yeah, so offline is important for a number of reasons. One, as I mentioned, that Travis question is about just availability in cases and issue. But also for a cyber attack, is there a ability for an offline, if for some reason we had to move it down, it had to be done from the distributed out of the service. But bug discovery is a very different one because if the bug is replicated obviously across the code, then you may have the same issue in multiple areas, which is why you say smart contract code. I'm not necessarily calling it that. I'm just calling it logic within the core processing engine because I think smart contract code comes with many preconceived ideas. But that's why we're trying to limit the amount of code that would actually be in the processing engine to limit the potential for bugs or malware and anything else. I mean, think about it. If I want to stop myself from spending too much money on beer, and I can do that in a wallet, or if I wanted to have certain other limitations on where the money is spent or other types of controls, I can do that in layers outside of the core processing engine, less just protecting the core processing engine from the potential for bug infiltration or even just bad code. And so that's how we think about it. So I don't necessarily tie offline to bugs other than if the system's down, they would help there. Thank you. Sandy, we can't hear you. At least I can't hear you. Yeah, I cannot either. Okay, you know what? It's okay. We sent you what that I think I would have in the audience. I'll talk to us when I get a question on the chat. Okay, yeah. Yeah, he's on the chat. I want to return to your comment about the wallets, because that's one of one thing that seemed to be I mean, the details seem to be missing in the in the paper, but a lot of the capabilities, especially the verification and interaction between the wallets are necessary for the UHS to function properly, right? I mean, that's what I read from the paper. Yeah. So what we do, we actually built, we actually built the wallet. And I think, I think, I think that our developer came from BitPay who developed the wallet there, if I recall correctly, but that was more for our own testing and trying to understand the interrelationship between the core engine and the wallet. But as I said, this is just the core engine. As we think about building out more capability, eventually we have to think about the UI. And there's multiple scenarios. Would the Fed write a wallet that is distributed in white labeled? Likely not. Would the Fed potentially write some specifications that wallet have to meet from a security perspective? Maybe. Some standards so that wallets are safe and people know that they are. They'd probably be developed by vendors and intermediaries, et cetera, but we definitely need the wallet. We're just not there as far we've gone with our application development yet. The question on FedRAMP standard, you know, right now we're just working in an environment we're totally research-based. We are nowhere inside the Fed's environment. We're really totally just trying to understand what's possible. So right now we're not tying ourselves to what currently works today and any national infrastructure, FedRAMP or anything else. And so we would go beyond what currently is capable. And then if we felt it was determined that we had to have a multi-cloud environment for this to be issued, we'd deal with that when we came to it. Once again, the cow path is how things are designed today. And maybe they're capable today of enough that maybe a CBDC brings us to new needs. So in the FedRAMP question, we're just working outside the current norms to make sure we're not limiting ourselves. CBDC interoperate with the DeFi world. We have to build something, in my view, we have to build something that is flexible enough to be used anywhere. I think that'd be the ultimate. So the ultimate would be if there's an application, like say cross-border, going from one CBDC to another, I think we should be aiming for that. That's not saying it's a policy choice. I'm just saying from a technologies perspective, we should look at it. Many people have asked me, should it interoperate with other payment systems? And I say, why? Because they don't interact today. No payment system actually interacts with another one. You go through an intermediary, with the exception of check in ACH, which is a little bit about a niche issue there. And so for DeFi, I'd say, if there was a valid business reason for a CBDC to be able to be used within a DeFi world, and it wasn't violating compliance rules, and the intermediaries could make it work, I see no reason why not. But like I said, none of the policy makers. Is he frozen for everybody else? Yes, he is. We lost you there for a second. You're back. You're back because you were frozen for a minute. Oh, you're frozen again, I guess. Video off. Hey, Karen, maybe even just a question while we're in for him to come back. So is this, do they have, or is there a specific kind of slack or discord chain in the hyperledger discord around this? Yeah, he's back. This is kind of some of that. Yes, I'm at home, my VPN just bounced. I was hoping it wouldn't. I hope it's done. No problem, Jim. I'll answer your question in the chat, Trevor. That's fine. Thank you. So we missed the last minute of what you said, Jim. Oh, is that in the DeFi world? Yeah, I think that any connectivity that was solving a business case, a valid business case that was working within regulation, I would want to be able to make a connection there. The question would get into other issues of compliance with know your customer, etc. Are those fine? And what's the intermediary? What's the connection between the currency and the DeFi world? Who's the intermediary that's helping to move that money between whatever that smart contract is and the individual? And so I think they're open questions, but I'd always go into this with an open mind to say I'd want to connect to anything where there's a valid business reason and there's no violation of any sort of regulation. But I think that does get into a bit of a policy question about what's the connectivity and does it satisfy all the appropriate rules? You could ask the same thing, can I buy crypto with it? Well, why not? But what are the rules? How do you validate KYC and stuff like that? In my own opinion. So if you look at the sand dollar, for example, which is a small crypto, I mean small Shibirisi, I talked to Richard Douglas there who runs a company called Island Bay and they connect with the ESV, which is the credit card company's standard interface. And that's how they hook up the sand dollar to the ESV. Of course, that means that somebody has to write this, somebody has to manage which is Island Bay. But he also said something very important, which is they implemented standards for wallets. I mean, they asked people to have standards for wallets and other items. And that helped them greatly. Before they started, the private operators got involved, they were forced to adhere to the standards. So in that sense, if you have those standards and then you adhere to them, then probably the rails to other systems like the credit cards, like DeFi itself could be enhanced. Yeah, I think the standards of interoperability are important. And even for a bank, a bank has to understand how a CBDC would interact with its own systems. Its core provider, how would it move money out of a DDA account into a CBDC? It's the same thing with faster payments. In the U.S., the Fed is building FedNow, a faster payment scheme. And the software providers to the banks have to be on board for this to be viable. And so it's the same for CBDC. Who are the wallet providers? Do they have enough information to build wallets early on for banks and other intermediaries to connect? So I think that's a lot of the work is working with those, you know, one step away from the actual CBDC to get it to work. Otherwise, it's not going to work. So the next is, you know, if anybody who has not asked a question yet want to ask questions, please come forward. Mark, I had a question on performance testing. Are those results something that you can share, like how the tests were done, things like that? Yeah, I believe it's actually in the material of the white paper. We built software to actually conduct those tests. And I believe it was every transaction was two inputs, two outputs, just to try to replicate a normal transaction. And we're actually trying to open source the controller that we built to drive the tests so that other people can test in the same way if they want to take the open source code outside or make contributions they can test against the controller. A little challenging, we're not there yet. We're trying to make that software available also for the open CBDC code. Just to give an introduction. I'm sorry to bar Jim, but we are already building some support for JMeter with the open CBDC prototype. It's very nice software. It's just missing that benchmarking part. The student of mine is doing that. Yeah, both Imre and Mark, the prior members of the performance and scale working group in Hyperledger. So Mark works or has worked at Red Hat, so you know something about performance and scale. Imre is a researcher from Budapest. We are trying to open source the controller, which I think would also be something that would be interested in others contributing to our understanding. Because obviously that's an important piece of technology to ensure that what people are contributing is tested in a consistent way. That's the same thing we would use hopefully against private sector actors, but that's also a challenge. Anybody else? I'll mention one more thing since we have a moment, and I usually try to say this, but it takes time. So people sometimes ask with a project Hamilton name comes from, and most people think it's Alexander Hamilton, which it is. It's a nod to Alexander, who was actually the grandfather, I guess, of the central bank. But when my team was coming together, we knew we'd work with MIT, and we called this a moonshot because we really thought we'd been building something important like going to the moon. And so the team did research, and we found that Margaret Hamilton ran an MIT technology lab in the 60s, and her team built the guidance system for the Apollo space probe. So it's as much a nod to Alexander Hamilton as to the better sex, Margaret Hamilton. So just while we had a moment, I think I'd like to put that out there. I highlight that in my Forbes article, and I call them the two Hamilton's. Yeah. In fact, I created a graphic for you guys because you missed Margaret in your main graphic. So I put Margaret on the side, and I created a new graphic for the project Hamilton website. We are open source. Yeah. Yes. So anyway, any other questions, guys? Yeah. Hi, Vipin. It's him right again. Go ahead. I'm sorry for brushing in previously, and I should have introduced myself. I did write a question about privacy. I don't know whether there was an answer to that. Maybe it got buried. Maybe. So the question is that, yeah. So I've been thinking about this a lot, and to me it seems like that using some tricks like SSI and certain ZKPs, you could actually do a CBDC that's just as encumbered as physical caches. So technologically, it seems to be doable if you are willing to share and you may not be anything about the level of privacy that you foresee for a CBDC. I would very much appreciate that. Yeah. Like you said, we try to build as private as possible only because we don't know what the privacy regulation outcome will be. Some countries are saying they'll have a de minimis value that's private under $500, and above that you have to do KYC. So we have not done a lot of looking at it really just to understand that we need to. We are thinking about a relative to programmability because it has implications there, but we're more trying to understand, let's start the minimum information, which is just a public private key pair, and see where the privacy regulation goes because it's a challenge. We have thought about other or limits on ability to hold, et cetera like that. We are not designing it yet because I want to limit limits on holding because that limits the value of the currency. We can put them on, we know how, because we haven't done much work on it yet because of the study with the most open system possible and then going from there. But it's an important issue for sure. Again, I have one last question. We have this privacy working group meeting at 3 o'clock open CBD CTX. So if you're very interested, you can get there. All right. Go ahead, Karen. Sorry, I didn't realize you were adding something to that. Jim, it's really exciting to see how much the Project Hamilton has embraced open source and is putting the technology out there. You're basically the only ones doing that on this topic. As an open source community ourselves, we hope to see more of that around the CBDC research. I wanted to just ask you, aside from obviously participating in the working group meetings at open CBDC, what do you see our community could be doing or could be contributing to the knowledge base and what's useful and helpful to help people understand, help central banks understand, how to implement and figure out this use case? What role do you see us, our community, having and what could we be doing that would be helpful? I think at this early stage, and we are really early, I think it really is contributing to the current platforms that exist in the open source. I know that there's been some spinoffs from open CBDC and I think everything's valuable, so I think that's the first. Communicating with the Board of Governors in the consultation program, because some of those things may affect certain topics. And I don't know whether people have thoughts about whether an open source can help with interoperability or the wallet construction, whatever, I think those would be important comments to make to help the dialogue go forward. And I think as it unfolds, I think we'll see more narrow focus groups looking at privacy or resilience where we'll be able to get more in depth and get, some of those I think would even spin off their own product or their own pieces of open source software that could be components of a CBDC. So I don't know how it will unfold because it's so early, but I could definitely see this growing in the community, both of who's using it and also what open source platforms exist because a lot of it is compartmentalized, whether it's encryption or certain techniques for privacy, like creating a zero and all this proof that works at scale as an open source project. I think things like that I think can be really, really critical. Okay. Well, thank you so much. It's been great. Thanks for the invitation. Great questions. I'm glad the audience was informed and active. And I really appreciate that. Thank you. Yeah. Thank you for the great, for the fascinating discussion. We hope to have you back. Yeah, always a pleasure. Thanks. Thank you, Jen. Bye, everybody. Thank you all for your engagement. Thank you, Jen. Thank you very much.