 Good morning, everyone. So welcome to join us for today's CBNDC webinar series. So today, we are happy to have Will Robert, the senior advisor of Atlanta Pat. So he will be the moderator for today's session. So Will is an expert in monetary and banking history. So he just wrote a paper on unstable corn and related history in the early period. So Will, it will be all yours. Thank you for the introduction, Russell. So my job today will be to introduce a couple of people who need no introduction. I think that's why I got the job. The first one will be my long-suffering co-author, Charles Kahn, who will present a paper co-authored with Martin Fanort and Yuzhu. Best before expiring Central Bank digital currency and loss recovery. And Steve Williamson will be doing the discussion. So Charles, you have 30 minutes. Thanks very much. And thank you to the organizers as well for the opportunity to present this. I'm assuming you all can see the slides now. OK, great. This is a great opportunity for us and move. So central banks have in recent years been moving from just talking about central bank digital currency to actually doing something about it. They are now in the process in lots of places of putting together pilot programs. And in several important places are, several important examples are actually introducing central bank digital currencies to their users. And as a result, the research that's been going on has started to move from the questions of whether to issue, that is, what are the pros and cons of the central bank digital currency, to questions of design. There's a whole set of aspects of design that have been researched lately. And in this paper, what we're doing is looking at the question of putting an expiration date on a central bank digital currency. Now, the expiration date we're suggesting is not for the purposes of stimulating spending. That's been looked at before. What we're looking at is the use of an expiration date to enable personal loss recovery from the central bank digital currency. Now, that sounds like a little bit obscure of a topic to be looking at, even in a specialized environment such as this one. So I want to argue that there's actually some important links between this question and more general questions about central bank digital currencies. And to make that argument, I think we need to start with one of the important advantages of physical cash. And that's the advantage of resilience or offline capability. If you have physical cash, you can use it even when there's a power outage or loss of network connectivity. And this is important in lots of cases. And in fact, several of the implementations of central bank digital currencies have been made with the desire of giving similar offline capability in the case of an electronic cash substitute. So if you're interested in that kind of a question, interested in how to make sure that your currency survives under digital catastrophes, then you're going to have to start thinking about questions of how do you make the currency available on a device? How do you make it work on a device? How do you make it work effectively on a device? That brings up the problem. Close that, please. That brings up the problem of double spending. Say you have a store value card or token stored on a mobile phone that you can use for offline payments. How do you make that particular payment system not vulnerable to double spending? To rule out double spending requires two basic pieces to the story. First of all, your device has to be tamper resistant. You got to make sure that no one's going to go in there and undo what the device has done and try to spend the coin a second time. But beyond that, you have to also be sure that you've separated the funds that are inside the device from the rest of the funds of the user. You've got to make sure that separation means that the balance is stored uniquely within the device. To think about those implications, imagine that what you have is a central bank that is connected up with a bunch of stores that it wants to provide online services to. But in that particular country, there are also a large number of providers out there that do not have a ready internet connection. And the central bank wants its currents to be able to service both of those grips. In that case, it's not gonna be possible to let the coins that are on the offline device also appear at the same time in the centralized arrangement. If you were to do that, what would happen would be that an individual goes from the area where he's got the centralized online arrangements and goes off into the woods to pay with an offline gate and then comes back and claims that the same coins can be used to pay online and there's no chance for the guys who are in the, off in the woods to claim that they've actually been spent as well. It's even worse than that because that means you can't even have a record of the coins on the separate location. If I were to put a separate record of my coins out there on an online device, I could always go off and pay offline. And then once I've paid offline, claim that I've lost my phone and go back and use the same records to pay online, okay? So the requirement is that an offline device has to be uniquely storing the coins that could be, have to be separated from any coins that the individual has in an online arrangement. And so as a consequence, the loss of your device means there's a loss of your funds. It's analogous to cash. You lose the cash, it's lost. And the question for us is a question of, if we move over to a digital arrangement, can we reduce these costs? Can we solve the problem of having offline payments meaning that you're going to be losing your coins if you lose your device? And the answer that we give in this paper is that yes, you can do so if you put an expiry date on the coins. You can make it the arrangement such that you automatically reimburse consumers for expired offline balances. In a nutshell, here's how the idea would work. Suppose you have on your phone an app that has a central bank digital currency wallet in it. And in your central bank digital currency wallet, you have balances of $255, say. Most of those are being held online, but you've taken some of those balances, $120 in this case, and taken them offline onto your phone. So they're usable now in the case you're in a situation where you have no connectivity. Okay, those balances are there on your phone. They can be used in emergencies offline, but that means that they're also going to be vulnerable to loss. So what you can do is hit the button that says enable loss recovery. And in the process of doing so, we take those balances and we put an expiration date on it. In this case, the particular app automatically puts a 180-day expiration date on it. And what that means is that if the balances aren't used in the 180 days, they're no longer good on your phone, but you'll automatically be reimbursed for them back in your account, okay? Now, that's a great thing. You've got now some insurance that the balances can't be lost. They'll just come back to you in 180 days if they're not used. There's a bit of a problem with that though, because it might be the case that you don't use your balances very often. And so it's going to get down to the point that five months from now, there's only 30 days left on these balances and that might be not so useful as you'll have to worry about what's going to happen when you get down to the fact that the balances are no good anymore. So in fact, what you can do is have a second option which is to automatically refresh the expiration date. The idea would be that every time you're connected, it automatically renews any balances on your phone so that they're always 180 days away from expiry. Each time you get connected back on, they update all the balances on your account. And so they're always there, safe and good for you for 180 days. In other words, the idea is we're going to have expired cash always get reimbursed to the individual in their online account. Question arises, well, exactly who should be reimbursed? Who is it that lost the cash? And so we consider two different information structures for that particular question in this paper. In the first information structure, the simpler one, we have the online arrangement, sorry, we have the app on your phone, not doing any reporting back to the center about what's going on. In this case, it's always going to be the onus on the payee to make sure that any coins that he's received have been deposited before the expiry date. That's fine, but it also means there's always a problem of perhaps the coins have been spent and we should have been giving the money not back to the guy who originally had them, but to the guy he paid. So you might imagine another situation in which the app checks back and whenever there's been a payment made, it reports back to the center that the payment's been made to somebody. So you can imagine that such an arrangement might keep better track of who actually deserves to get the coins reimbursed and we're gonna examine that kind of an arrangement this way. Here are the results that we have from the story. First of all, lost recovery with an expiry date could have a substantial positive impact on demand for offline balances and on welfare. Secondly, we do some questions looking at the design aspects of such an arrangement and we show that there's some asymmetry in the arrangement that part of the design is deciding what the optimal length of time in the expiry date is. And we show that there's an asymmetry that although it's a great benefit to have an expiry date, if you get the expiry date a little wrong by making it a little too long, that's not too bad. Whereas there could be significant damage to the usefulness of the program if you make the expiry date too short. And finally, we talk about the comparison between the two different kinds of information sharing I just mentioned between consumers and the central bank and that more information sharing can improve lost recovery, but actually more information sharing also provide some incentive problems which might have an ambiguous effect on the social welfare of such a scheme. So Charles, we have a clarifying question from Todd Keister. Sure. Will a merchant who receives a payment be able to see when the coins will expire? Yes, indeed. So when the merchant receives the coins 180 days on it, the merchant knows that when it says that. That brings up some interesting problems of, well, what should we do about coins that have varying expiration dates? As a practical matter, we imagine a story in which we put those expiration dates far enough in the future that they don't have to choose between the various coins available. Think of it as they're sell-by dates on the stuff in the grocery store, but they're all far enough back that it doesn't make a big deal of difference about which one they're using. What we do in the story is put together a couple of models in this paper. First of them is a small model that we're using to understand the trade-offs involved in the trade-offs that are involved in this issue. And then the second model we put together is to understand better what the quantitative impacts are of the story. And so let me start and spend most of the time, in fact, on our smaller model. The goal of the smaller model is to illustrate in the case of offline payments what the trade-offs are in using an expiry date. And since we're talking about offline payments in general, I'm just going to call the medium that we're using for payments. I'm just going to call it cash. I mean by cash any money balance that can be used for offline payments. So I could be cashed literally, or it could be in terms of the application we're really interested in, stored value in a payment card or a smartphone chip. So cash in any of these forms is there to ensure consumption during outages, but it's subject to loss. Here's a timeline of our simple model. It's a four-period model. At T equals zero, the consumer is going to decide on how much cash to hold. And he has to decide how much cash to hold before he knows exactly how much he's going to want to spend in the next period. So the first thing that happens is he makes a choice of cash and then a preference shock is realized which tells whether he wants to actually spend one or two units of cash when the opportunity arises in period one. In period one, two more random shocks are realized. The first of those shocks is an outage that could happen. And if it happens, it will disrupt connectivity for payments. And the second shock that could happen is that the consumer might lose his cash. Now, the consumer is going to be buying goods for producers in period one. If there's no outage, both online balances and cash are available for spending. If there's an outage, the only thing he has to spend is the cash. And how much he can buy is going to be determined by how much cash he's brought into the period. In period two, the outage is going to end. Meanwhile, the producer may have lost the cash himself. Once the outage ends though, there's going to be withdrawals, deposits, the outage is going to be handled up. And then in period three, as Martin likes to describe it, everybody enjoys counting their money. If we're paying with offline payments, there's going to be some costs associated with those costs of losing the stock. And therefore, it's always going to be dominated to be paying with online payments if those are available. In other words, consumers are holding offline money as a precaution in this world in order to facilitate trades during outages. But the holdings are going to be limited by people worry about the chance of losing it and also by the inconvenience or opportunity costs of sequestering that money on their device. And we model that as this interest rate differential. We look at the various possible designs of an arrangement and we want to compare the social welfare of these various designs. And that means we have to think about the question of how do we account for lost cash? And the correct way to do that is to realize that lost cash is a windfall profit for a central bank, but it's, and reimbursing lost cash is a costly to central bank. But when you add up all of the individuals in the story, the net welfare effect of reimbursed cash is going to be zero in the aggregate. So losing or getting the cash back is going to be offset. And so in equilibrium, the only social welfare issue is going to be exact amount of consumption that people are able to do in cases of outages. And so- Charles, just another very basic, yeah, clarifying question. Sure. What prevents double spending when the device is offline? When the device is offline, we're going to be assuming that the device itself is preventing double spending. The device itself won't let you take the coin out of it twice. Once the coin's out of the device, the device doesn't have the coin anymore. So it has to be the same ability that goes on with any stored value card has to have the same arrangements involved in it. You can't use the stored value card to get the value out of it twice. Thank you. So in equilibrium, what you're going to be asking is how much consumption during outages can be encouraged or made possible through the use of this device. And so we compare what's going on in this world when you've got no expiry date with what's going on when you put expiry dates on. So without an expiry date, then customers are going to be trying to look at the cost and benefits of holding extra amounts of money. They compare the cost and the benefits of holding extra amounts of money. And the more money they're holding, the less the benefit's going to be and that is less and less likely that they're going to be wanting to spend the extra amounts because it's less and less likely that they want to be consuming that much. In such a world, reducing the exogenous costs of losing cash increases welfare because it increases buyer's willingness to hold cash and thus increase buyer's willingness to hold cash and thus increases offline trade. Let me think about the question of, well, what happens if you put a shelf life if you put expiration date on the cash? And first we try a dumb expiration date. We say, what if the cash expires before the expires in only one period? In such a world, it's going to be the case that the cash expires before the outages are over and in such a world it's going to be the case that producers are going to reject the cash because they're not going to be able to get it back into the bank in time. So such a world's going to be a very useful one. Nobody's going to use cash because the producers aren't going to be willing to accept it and it's likely not having cash at all. The interesting case is the case where you put an expiry date that's long enough that producers know that the outage will end before the expiry date. So they're willing to accept the cash. And in such a world, you're going to be able to improve social welfare because you're going to reduce the cost of holding cash. The cost of losses of cash is reduced from what it otherwise would be. In a world with, in the normal world, you lose your cash, it's gone for good and that's a full loss. In this world, you're going to be reimbursed although with some delay and that lower cost is going to make people willing to hold the cash more. And so social welfare will strictly improve whenever equilibrium cash holdings are higher. And with the high privacy environment, that's generally going to be the case. In the low privacy environment, it becomes a little bit more complicated because there's now a strategic element for the individual who's purchasing. He's going to ask the question of whether he wants to reconnect his device or not. If he doesn't reconnect, there's always the inconvenience of not having the abilities to engage and get more cash or get interest on the leftover cash. But there's always a chance, as long as he doesn't reconnect, I'm getting a little bit of a windfall. Suppose the seller loses the cash in the meanwhile. If he hasn't reconnected his device, then he might fool the center into giving him back the cash rather than giving the cash the seller who really deserves it. And so it's the case that with a low privacy arrangement, you're going to make a more accurate decision about where the cash should go, but the incentives that come from that could actually cause people to use less cash and so the welfare effects are going to be epic. So the small model has been there to help us understand the economic tradeouts, but it's not useful for talking about the quantitative impacts. And so what we do in the rest of the paper is talk of it more complex model. The more complex model has the same ideas in it, but it's better able to allow us to figure out what the actual magnitudes might be, at least a rough idea of it. The complex model that we put together is one in which there's infinite horizon. There are variable lengths of outages going on and they're still casting. And to put that model together, we need to calibrate it. We need to calibrate with several parameters. Some of those parameters are pretty standard, but one of the parameters that we need is the what's the probability of losses by consumers and producers in this world? What's the problem that they're going to be losing their devices? And to get the right parameters for that, what we did was conduct it. We had an online survey conducted to get a rough idea of what individuals actually do in terms of losing or damaging their cards or phones. And we came up with people replying. Numbers were about 16% of people or lost or damaged their cards in the previous year and 8% of people lost or damaged their cell phones. So we took those numbers as parameters for our story. We also had to parameterize the likelihood of outages and the lengths of those outages. Our parameters were done for that to match the evidence of how much of how much cash people hold relative to their actual usages of it. With those parameters, we figured out what the welfare losses and uses of, what the welfare losses with the consumption and what the demand for cash were going to be as a function of the expiration date that was placed on the cash. And what we found was this, moving from having no expiration date to having an expiration date had put a significant improvement in both the uses of cash and the welfare effects that came of it. From our stories, we would get something like double the amount of consumption going on during offline, during offline events for using an expiration date rather than having no expiration date at all. But we also found that the value of the expiration date, what the right expiration date was, was very asymmetric. As you can see in these graphs, the choice of how much cash to hold varies greatly as long as you're using very short expiration dates. But once you get up to the optimal expiration date, it doesn't matter too much. You don't lose too much by going for the expiration dates too long beyond that. And the reason for this asymmetry becomes from the behavior of the individuals in the model. If you make the expiration date too short, the vendors are going to be unwilling to use the cash. If you make the expiration date too long, it doesn't damage vendors' willingness to use the cash. All it does is make it take a little bit longer to get your cash back. And so the loss from an error in that direction are not as important in terms of welfare effects. So to conclude, what paper is showing is that loss recovery based on introducing an expiration date could have a substantial positive impact on consumer demand for offline digital currency balances. And it also examines two design aspects of that question. Shows that the cost of setting a little longer than optimal expiration date is small, but setting an expiration date that's too short is going to have a large negative impact. And finally, it shows that the other design question that more information sharing between the consumers and the central bank, although it improves loss recovery, can have an ambiguous effect on social welfare because of the incentives it has for people to use, for people to use the cash or not. Thank you very much. Thank you, Charles. And you appear to have actually finished a little bit ahead of time. Oh dear, I'll have to repair that. Okay. And our discussion is going to be given by Steve Williamson. Steve, I think you're muted. Sorry. Yeah. Anyway, so I was saying it's when you didn't hear me. But it's always fun reading Charlie's work because he thinks about things in different ways. So Charlie is, I guess unlike me, I guess he probably doesn't hang around macro people so much. So he doesn't think like a kind of a typical macro person which is refreshing. So I always learn some new things from him. So in this case, I guess the way we want to think about this is that, there are a bunch of important issues that we want to think about to do with CBDC issues and weren't to be issued. And in fact, we could think about how it's used for conducting transactions offline. So it's kind of not clear. Like if you think about the online transactions where I kind of broaden what I'm thinking of as online as could be a case where you're actually buying something with an internet connection from Amazon or something or a physical establishment where everything's electronic. You say you're paying with a debit card. So you think about what could CBDC do in those contexts relative to the existing private payment technologies we have. And maybe it's not so obvious. A lot of people have thought about this. There's issues to do with financial inclusion, the margins on which the CBDC could do better or maybe we could trust the central bank. And because we can't trust the private banks, we have to regulate them and that's costly and maybe somehow the CBDC system will work more efficiently, who knows. So, but a question here maybe is more like, can we work on things that have to do like with the good attributes of currency? Can you provide those with CBDC, like physical currency? But improve on it. So maybe you want to think a little bit about physical currency. So, well, on the one hand, physical currency is a good thing, it's very simple. The way it works is, you hand over cash in exchange for goods and services, the settlement's instantaneous, there's finality. And you get privacy, privacy maybe is a good thing. But there's some bad things about currency. So we can't use it for internet transactions, it takes up space, you get large quantities of its heart to move it around. If someone takes it from you, you can't get it back typically. If you lose the stuff, it's gone. And transactions are private. So privacy can be a good thing, privacy can be a bad thing. And the criminals like privacy too. So main points in the paper are that, well, we can think of designing CBDC to be convertible between two forms. So there's the online CBDC that works like a checking account and offline CBDC, which in some ways is more like physical currency, but of course it's not in that, it's like it's stored on your phone and there's some technology. So this came up in the discussion. The way I thought of it is that there's a technology that permits you to move it to someone else's phone. And so the technology debits it on your phone and credits it on the receiver's phone, even if the power grid's down. So that kind of makes offline CBDC work like physical currency, but maybe you can do, maybe you can prove on the physical currency in the sense that you give it this expiration date so that if the expiration date arrives and the stuff is not observed to be, have been spent, it goes back in your online account. So you keep, so potentially now you can't lose this stuff. You got some kind of insurance against loss. And then the loss could be like, do you drop your phone off a bridge or in the toilet or something? And that's where the loss comes from. Okay, so the models here, so there are two of them and they're gonna serve some different purposes. So there's this finite horizon setup. You got the two kinds of money that are convertible one for one at the beginning of time. And it kind of looks like commodity money. So it's like any money that's unspent, you know, well, any money that anybody has actually in the final period, you can eat it. But there's gonna be some production in like in the second period. And so that's like production of another good and you're gonna exchange this commodity money for the good. Then there's this infinite horizon model. There's two kinds of money, but it's kind of works like cash in advance. You think of it as cash in advance with a fixed aggregate money stock and the money, but the money again comes in two forms that are convertible one for one, one for the other. So the finite horizon model, that's gonna give us most of the analytical results, but it's gonna be hard to earn possible. And that didn't really say anything about the effects of changing the time to expire. So clearly that's gonna be important in practice. And but the infinite horizon setup, we can actually deal with effects of time to expiry and but there they're gonna have to rely on looks like on numerical results. Okay, so finite horizon model, basically it's like you got a fixed stock of something you can think of as gold, the gold's convertible one for one into online money or offline money period zero. Then the second period, there's you're gonna have this exchange between the consumers who have the money in the producers. So the problems here are gonna be one that there's an outage. So I think that was a power outage. The online money's useless in exchange. And the problem with offline money is that you can lose it. So that occurs with some probability, just like the outage does. And not only can the consumer lose, you lose the money before the payment spade, but maybe the payment gets spade and then the producer loses the money. So what can happen here now is that if you have this insurance which has, in fact it's kind of offered, it's not perfect insurance, but it's insurance through the expiration date for the offline currency that can make welfare go up. But then maybe it doesn't, it kind of depends on parameters. So there are two cases, the ones they call like no information exchange. So that's what happens there is the money gets reimbursed to the consumer if the producer doesn't deposit it, but it could be the producer lost it. And so that's a good deal, but it's like you write a check to the furnace repair person and then they don't cash it. So you get a good deal then. Basically you keep your money and you get the stuff. The information exchange case, the central bank can now connect, they can actually learn if the money was actually spent. So in this case, it's like the consumer has the option to put that into effect. So the central bank only learns if the money was spent, if the consumer goes online and then that's how the central bank's gonna learn about the transaction. Okay. So this is my last slide here. So the comments are, so you might wanna think, so if you wanted to broaden it, how you think about this, you might wanna think of offline, it's not just outage, but just the circumstances where the consumers want privacy. And so maybe privacy could sometimes be socially desirable, sometimes maybe it's not. So the same kind of questions of loss come up, but you also have to, then you're kind of a need to address this issue of how much privacy you want, and is the central bank, the institution you want to have to be providing it. The loss could be due to theft, right? So it's not just, I dropped my phone and the road and the car and so over it, but actual theft, and then endogeneity becomes important. So there was just, in the model there's just this fixed probability that you lose the stuff, but now if the offline money, so then the aggregate is ubiquitous, then the cost of theft becomes low and then there's more theft, and then maybe we need to think about like how you invest in security. It's a question of why you can't pay interest on the offline money. That's the assumption in the model. I think what that's doing in there is it's gonna keep you away from these results where maybe people want to just use the offline money for everything. Kind of like a freeman rule or something, but there is this question of why if you can track these things like in this, I don't know, with this case where the central bank has a lot of information, why can't they pay interest on the offline stuff? Then I hope this last comment, I don't just, doesn't sound snarky because I'm just kind of raising, trying to raise more questions or help maybe people think about what's going on here. So if I think that- Steve, you got about one more minute to be snarky. Okay, I'm not being, no, I'm never snarky, never be snarky. Anyway, so that the, so suppose I take the idea seriously, then maybe you want to think about it in the current context where we're, where people might think of people using, holding currency to ensure against outages or I don't know, I'm sure there are conspiracy theorists out there who hold a bunch of cash, but I don't want to keep a lot of cash in the house because I'm probably more worried about theft and being able to buy stuff when there's a power outage. But if I did store a large lot of cash in the house, I'm probably going to get irritated about the expiration because it's probably, I'm thinking there's a low probability that this event where I'm going to need the, where I'm really going to need the cash and then stuff's going to expire in two weeks and that's not going to be too helpful. And then a long expiry date doesn't, that starts to become irrelevant. So anyway, so that's it. Thank you. Thank you, Steve. So we've got a number of questions active in the Q&A and people may want to raise their hand. Let's see. I don't know whether the authors wanted to go back to the, you know, a little more explanation of the double spending offline and how that's prevented or Charlie Martin, I don't know whether you wanted to revisit that. Martin, do you want to do it or do you want me to? Yes, I can definitely do so. Perhaps I can bring up one of Charlie's slides if that's okay. Share screen. So I hope you can all see this. So this was one of Charlie's slides and basically kind of what the slide kind of started to explain in the first place is that you, for offline digital cash, you need two properties but actually three properties in order, if you want to design a system that really prevents double spending. So the first thing is that, well, you need to store balance uniquely in a single device and not on multiple devices. And the other thing is like, you need to separate the funds that you can spend with the device. You need to keep them separate from those that you can spend without the device, for example, because they're in your online account. And then Charlie showed this particular picture to kind of explain these two properties. So the first one is like, well, of course you want to avoid this. These funds need to be separated because like otherwise what you could do is you could store your dollars in your offline device and then use, if the funds are not separated, basically what you could do is you could still spend the same money on Amazon and then go to an offline location with that offline device and spend your money again at that offline location. So that's kind of why you need the separation property. But then the other thing was like this uniqueness property, which is that you can only store the money in a single device offline. And otherwise, obviously you can simply double spend by storing it in two different devices, offline devices. You take each device to a different store. I give one to Charlie, it goes to one offline store. I go with the other device to another offline store. And that's how we get to double spend the money. But then actually something that's hidden there in which like not really relevant for our story is that, but that's what David asked a question about in the Q&A is that, well, what you actually need to do is your device also needs to be temper resistant and it needs to be a temper resistant way to actually make payments. Because otherwise what you can do is like you can, if it's not temper resistant in the first place, but what you can do is kind of, you can pave with your device and then kind of reset your device to the previous state and spend again. But like presuming like temper resistance, that's something you certainly need in the device as David points out in his question. But then what you also need are these two other properties basically that the balance are uniquely stored in a temper resistant device. So it's really only in one device, multiple device, multiple device that allow you to spend it multiple times. And secondly, the funds need to be separated. But then what you're doing is you're effectively creating like a single point of failure because there's this one device with which you can kind of spend the money. But if you no longer have that device and that can be lost, it can be broken, but it could also potentially be stolen, then of course if you lose the device then you basically impair your ability to spend that money in the future. And like the way that we try to solve this is imposing expiration date. And then perhaps also coming back to one of the points that Steve mentioned during his talk as well, what happens if your device gets stolen? So typically kind of what we envision in the paper is that you would need some form of authentication when you make a payment with your device. So it could be balance stored in your telephone. So it could be either a face ID or some password that you have to set in your telephone like Apple Pay for example has kind of great way, right? How to implement that. Or if funds are stored in a payment card it could be simply like a pin code that you have to type in. So in that case you would even have loss recovery when your device is stolen unless of course the person who steals your device is able to breach the authentication. So kind of going back to kind of the real problem that you have to think about as a policy maker that when you wanna think about offline payments is that essentially there's this offline payment trilemma that you have to choose. So suppose you don't wanna allow for offline payments then basically what you can always prevent double spending because you're kind of always checking whether people have the funds. And if people lose their device it doesn't necessarily mean that they lose their funds like when you lose your debit card you don't really lose your funds but whenever you make a debit card transaction actually the bank will be checking whether you have sufficiently amount of balances in a typical setting. But then if you wanna introduce offline payments then basically you have to choose between either no double spending or you have to choose between either no double spending or you have to choose a two situation where your funds are not lost with the loss of the device. So we're kind of presuming in the paper central banks they don't want to have any system that allows for double spending. It's really for example you want a very inclusive system so you don't want to exclude for example criminals so they need to be able to use it. So you really don't want to have any double spending on the system but then we have to do something to allow for loss recovery and expiration date seems to be a kind of a straightforward way to do this. And let me stop sharing my slides. Okay so we have a number of hands raised by the panelists. Let's go to Katrin. And thank you. So I find this a very interesting paper and a very interesting idea. So I tended to think about the loss risk in a different way. So you know that central banks are very worried that people might take up too much central bank digital currency. So being able or have facing the risk to lose the CBDC on a device would limit this take up. And it's probably something that's a better mechanism than imposing heart limits like a cap or transaction limits. So I was wondering, yeah. So everything you can do to hobble CBDC to make it less useful is going to be a way of keeping the demand for it down. And so the question is, is that the one you want to use or is the one you want to use something about limits of how much can be put onto the device? We should know the way of keeping the demand down. You just can't, the device simply won't take more than 500 euros for example or interest charges if you have too much above that as well. So you're absolutely right. We want to think about not only making a currency more useful but in some cases we're going to want to think about also costs of also ways to make a currency less useful. That's just not an issue that we looked at in this paper. I believe Rod Garrett has his hand raised. Rod, have we lost Rod? We exhausted him. We, let's go, Todd also has his hand raised. Oh, Rod's back. Okay. Yeah. Yeah. Hi, Charlie. Great presentation as always. So I just had a quick comment which is it seems to me that one could implement something similar in the crypto world by using a smart contract. So you could imagine that if you hold Bitcoin you can lock your money in a smart contract that says that if the money isn't moved within 180 days it automatically gets sent to someone more responsible than yourself. Yeah. Just a comment. It solves a big play loss kind of problem. Insurance against your own stability and remit and forgetting your password or something. Exactly. Exactly. So just a comment. Yeah. I think it has all sorts of applications there. I think we also have comments from Todd. Yeah. Yeah, hi, Charlie. I just wanted to ask if you guys have thought about like state contingent policies. So if we're thinking about widespread outages like Hurricane Katrina say, if that hits and it's worse than we thought and people didn't adequately prepare for it is there anything that can be done exposed to say, okay, well, we're going to extend all expiration dates. And if people expect they're going to do that does that undermine their decisions ex-ante or what are your thoughts? Martin, you've done that one before, why don't you do that again? I think that's a great question Todd. Thank you for asking this question. So really the hard thing if you think about this if you want to do that type of announcements is in principle, you could think about like, well, that could be an announcement but kind of you still need to kind of transmit this to all the devices if anybody will accept the money. So that's kind of something that you probably would need to do in a manual way given that you would be in an offline situation. But so the short answer is probably it can be implemented. The question is like how practical is it going to be? So if you want to think about like a typical type of outage where you have say like outages of one weeks or two weeks, I'm not sure whether it really kind of whether the faster reimbursement would really actually pay off much by making it really a big hassle to actually extend the expiration date once you are in an outage situation. Also kind of in the model, it seems like, well, second expiration date that's a little bit longer than the optimal level doesn't seem to be that costly. So it's really, so obviously we don't have this in a model but if you think from it from a practical point of view, I would rather kind of aim for having like a little bit longer expiration date to actually to kind of to be able to address these type of contingencies. But it would also always be nice of course if it would be something that you have in the background if there's like a really big issue. And if I could just follow up and maybe I missed this in the presentation but like if you thinking of setting the expiration date longer, if you let that go to infinity then there's no expiration date. And so, at what point would we say, okay, we're setting it long, there's no cost of doing that but that's almost like not having the whole program, right? Yeah, that was the calibration was kind of interesting in that respect where it goes down very slowly but infinitely is very different from what it is. Okay. From 190, that was in that in that in that graph it looks like it's gonna take a long time to get down to the dotted line. Well, it does take a long time. Okay. Yeah. And of course this depends also on the discount rate. So we actually have an additional calibration in the paper where we set the calibration or wherever we set the discount rate much higher. So the discount factor is like 0.76. So that means like a dollar now, a dollar one year from now is 0.76 now. And then what you basically see is like you get the much faster convergence to physical cash in terms of how much cash people would be holding. And of course, like if you set it to infinitely long basically what happens in a model is like it becomes equivalent to physical cash. So kind of in the calibrations you see like in these charts you see the blue line approach this red dashed line which was the line for physical cash. So we also have in the Q&A question from Oshai is this solution unique to CVDC or can it be used with let's say conventional dollars or one of the private apps, Venmo, PayPal, et cetera? And I would append to that if it's such a great idea why hasn't it been implemented already? I think our, oh, go ahead Charlie, sorry. Okay, two pieces of that. Yes, it can in principle be implemented with physical cash. It's just a lot easier to do it with electronic. You could imagine putting an expiry date on every piece of cash that you could imagine you could imagine a world in which all paper dollars come with a deadline on them but it'd be a real mess to try to work with that. The advantage of what we've got here is that you can update these expiry dates on the fly and so you can treat them all as easily restoreable. It could be, in fact, we do see examples of precisely this in a couple of ways. The expiry date that you find on checks is precisely this kind of an arrangement. That is to say when the government sends you a check and says it's only good for six months one of the things that that's doing is allowing the government six months from now if you've lost it to reissue the check and no problem arises from it. So it's not as way out or unused an idea as you might think it is. And I think like one question that Will was asking as well as like why don't we see this for example for commercial digital or electronic cash issuers as we have seen a few of those in the past. But I think like one of the issues is and it's very similar to gift cards one of the parts of the business models of issuers of electronic cash and gift cards is actually the idea that you lose them because that's immediately income for them. So often you would see actually expiration dates on them but basically they benefit from it rather than the consumer. Whereas we are in the central banks we would change that. And the proof of that is that another place you do see it happening with electronic versions is with subway cards with public policy they will allow you to put an expiration date on it, get the money back if the card is a certain amount of time. So I'm just gonna take the cheers prerogative here for one second to see. You can imagine that once something like this comes out that it opens up new avenues for fraud. Can you imagine for example, consumers who have no endowment is only possible payoff is from fraudulent activity colluding with merchants to break some of this protection. Is that something that you thought about in writing this paper? Kind of an organized crime attack on the system. How would it arise I guess is the question because the total amount that's gonna be paid by the government is never more than the only question is who's gonna get it? Whether it's gonna go to the merchant or to the customer. So the money can only be spent one time and given to a merchant, right? It can't be passed person to person, is that the idea? We've been thinking it through mainly under that circumstance but as that is the use case just because it's a little trickier to imagine what it would be for hand-to-hand usage. But I mean the model itself doesn't require that but that's how we were thinking about it. So actually kind of the way that the model is actually avoiding this wheel or actually the idea is like you never reimburse people for lost money until after it expires and only after it expires you give it back to one particular person. So typically it would be the consumer who withdrew the money. So in that sense kind of you're not kind of reimbursing multiple persons in any contingency under this scheme. Otherwise of course there could be potential fraudulent scheme. So really we impose this expiration date to avoid like any double spending. Well, if it could be passed in multiple transactions you can imagine one person saying, oh, I lost mine. And then another person saying, well, I came by it legitimately, I don't know how this other person came by it but I actually gave consideration for transfer of this value. And now you're telling me that this value is not legitimate. No, whoever again it becomes like cash in that respect. There's no questions asked about if it comes in from the last person, that's it. There's no recourse from the guy saying, I lost it. Like of course if you accept money you need to kind of depost it in the central bank. You need to kind of claim it like similar, like with a check. And if you don't do so as an as a merchant before the expiration date, then you kind of forego your claim on that money just the way that you forego your claim on the funds if you don't cash a check in time. So in your scenario, like two things can happen. Like the merchants could show up before the expiration date and then it's obvious that the merchant gets the money just kind of the situation where somebody shows up with a legitimate bank note. Or the merchant shows up after the expiration date and then the money has already be reimbursed to the consumer and the merchant by not showing up in time actually has foregone the opportunity. The window has been closed. So that's kind of how double spending is prevented. And that's also like if you've really started the expiration date, merchants might not be willing to accept that money. So because they might not be able to deposit in time before the expiration date in a model. So that's kind of why it is costly in a model to set a really short expiration date exactly because of this. Well, I see we're coming up on our noon expiry date. And if people would like to stay on and continue the conversation, that's fine. I guess this is the official ending time of the seminar if people want to leave. I don't see any other questions in the Q&A or anyone else have a comment. All right. Well, thank you, Charles, Martin, Steve. Interesting hour spent as usual and it's been a pleasure to be a part of this great series. Thanks. Thank you. Before we close it just a quick reminder. So we will take a summer break and then our next webinar will continue in September 30th. So Hanna, Hanna Buddha will take over and present her work where we'll call. And we also now doing a call for paper for job market candidate workshop. So the deadline will be August 15th. So any candidate are super welcome to submit their work and would like to present in October of this year. So more detail can be found on our website cbnbt.net. So hope to see you soon after the seminar. Thank you. Thank you. Thank you.