 So Russell, you have started to wrap it up. Right. So maybe let's get started. So thank you, everyone, for joining us today. So today, we have Peter Hoffman from ECB holding this session. Peter, it's all yours. All right. Thanks a lot, Russell. It's a pleasure to be here. Let me just jump in right away. So today, we have Martin Fanort presenting work on the demand for programmer payments together with Charles Kahn. The discussion will be Jonathan Payne from Princeton University, housekeeping, as usual, presentation about 25 minutes. And we have a discussion for about 10 minutes by Jonathan, and then it's followed by a Q&A for about 20 minutes. So Martin, the floor is all yours. Thank you, Peter. Thank you for the introduction. My name is Martin Fanort. I work at the Free University of Amsterdam. The paper that I will be presenting is joint work with Charles Kahn, who is also on this call. And then the topic of the paper is to demand for programmable payments. So really, what we do in his paper is we ask the question when you introduce a new payment mechanism. So what we do is we really take a step back and ask a question like, why do we actually pay the way that we do? And if you think about the way that we pay, it varies widely across the different situations in which you have to pay. So for example, we'll give two examples. So first, if you think about the purchase for a house, if you buy a house, then there's a lot of effort, actually, that goes into the institutional arrangements that ensure that the house changes ownership and also that the funds change ownership and that not either one of the two occurs alone, because then you would be in some serious trouble. And depending on the jurisdiction, the arrangements that would be in place would either be with a notary or there would be real estate lawyers involved in financial escrow accounts. Now that's an arrangement where you do a lot of effort to make sure that both the transfer and ownership of the house occurs and the transfer and ownership of the funds is widely different from the way that we pay in an arrangement where you subscribe to a newspaper after buying the house. So typically, if you have a newspaper subscription, you pay at a quarterly basis or at an annual basis. And the newspaper gets delivered every day on your doorstep. And there is really not a lot of effort to going to make sure that the money only goes to new paper just at the moment when the newspaper is delivered. And understanding the differences in the way that we pay for these different economic situations is very important to understand what could be the potential impact of a new payment mechanism on the economy. So what we are going to focus on is programmable payments. So what's a programmable payment? Well, we borrowed from various definitions. And basically, we have defined a programmable payment as a transfer of funds that is automatically executed conditional upon preset objective criteria. And what's a nice feature of a programmable payment? Well, basically, what it can do is can provide assurance to both a buyer and a seller. So how does it work? Well, basically, the buyer needs to pre-commit funds. But the release of that funds is delayed until the moment that services or goods are delivered. So the seller doesn't have to worry about getting paid in the end. And the buyer doesn't have to worry about whether our services or goods are delivered or the house for that matter. Now, this could be enabled, but does not necessarily require programmable money. So programmable money is a much broader concept. Can, for example, be used to make money expire or to limit the use cases of money and for the implementation of various smart contracts. That being said, so you do not necessarily need require programmable money in order to implement programmable payments. But that being said, cryptocurrencies, they really have spurred innovation in the area of programmable payments. And for various reasons. So cryptocurrencies, they've implemented mechanisms that allowed automation of programmable payments. And also with cryptocurrencies, the way that these programmable payments have been implemented, they basically took away the need for a custodian. So you don't need a third party, say the notary or the bank that keeps the money in escrow. And both of these aspects, they can lead to the cost reductions in programmable payments. So there are various examples of advocated use cases of programmable payments. So you can think about automated escrow services. There's optimistic clearing and settlement for security transactions in the wall sill setting. Similarly, if you have central banks that each have their own ledger with central bank digital currencies, if you wouldn't wanna do a forex transaction, then programmable payments can actually allow you to do that in a risk less manner, just very much like the way that the COS bank works today. And then finally, another interesting use case is the enabling micro payments for paper use concepts. So a typical example that people would give is that you would hook up your electrical car and the electrical car would basically pay on the go as it is taking electricity from the vehicle charging station with funds that are preloaded upon the car. Now programmable payments, they've also been raised as a potential desirable feature of central bank digital currency. So there are a variety of central banks here. I think all of them are represented on this call. But I would wanna raise, for example, the statement that was made last January by the finance ministers in the euro zone, the euro group, which basically raised six in their statement, in their statement on the digital euro, they had six bullets. And one of the bullets was that one thing that should be explored is actually implementing programmable payments in the digital euro, in a potential digital euro. But while these banks have kind of, while all these central banks have kind of raised the potential incorporation of this feature in a central bank digital currency, it actually has already been implemented for the digital UN of the People's Bank of China. So last September, they launched an enhanced payment solution which has been phrased as UN Stuart and basically the use case that was highlighted by central bank officials was a situation where you pay the tuition of your child. So you could think, for example, for your driving driver lessons to the driving school and then the money would be released to the school as your child was taking the actual sessions. So many enthusiastic accounts about programmable payments and those often focus on the technological ability, but they really ignore the motivation for making payments. And what we wanna do in this paper is we wanna actually look at the economic motivation for making payments. And then we say, we observe that there are some very interesting questions that are raised by these technological developments. First, if programmable payments become really cheap, compared, for example, if they would have a comparable cost as normal payments, would programmable payments basically become the new default mode of making payments? Our programmable payments just better, but perhaps just a little bit expensive at the moment because you have to make use of escrow and manual work. And secondly, if you have all these technological developments in the payment space, which could potentially reduce the cost of making payments, would we observe that you would actually have an explosion in the number of payments? So would you, for example, get a minute by minute payroll in the future, where every minute that you work, you actually get a little bit of money credited to your bank account? So what we do in this paper is basically set up a formal economic framework in which we analyze the desirability of programmable payments. In the framework, we have both a buyer and a seller, and the seller is selling a service or goods to the buyer and we're basically, they only have to figure out how to arrange the payments. So basically what they have to solve is the optimal payment arrangement. What's the best way to pay? And basically what we will do is we will have a framework that allows for programmable payments and also normal payments. And then we will kind of ask the question, when does the optimal payment arrangement, when does it actually rely on programmable payments? Because these are the situations where you can expect improvements from programmable payments. And while we're doing that, we're actually going to stack the cards in favor of programmable payments. So we're going to assume that's a really high degree of automation so that the transaction cost of a programmable payment has fallen to a level that's comparable to that of a simple direct payment. So we're just gonna make the environment really favorable for programmable payments. And also we're going to assume that there's no legal records. So the assurance that the programmable payments can provide in such an environment is particularly valuable. Now, what do we observe as results in this environment? Well, first of all, programmable payments, they are desirable in situations where economic relationships are of short duration. But even though we set up this framework in a way that's very favorable to programmable payments, we actually observe in our framework that for long-term relationship, the optimal payment arrangement consists predominantly of simple direct payments. So why is that the case? Well, if you have a long-term economic relationship, then both for the buyer and the seller, there are stronger incentives to actually keep their promises because they want this economic relationship that provides them with surplus to continue. And if you have stronger incentives for either counterparties to live upon their promises, then it is not really necessary to lock up funds. So you don't need programmable payments. And then why are simple payments, simple direct payments better? Well, if you lock up funds, then there's a liquidity cost involved over the period that funds are locked up in a programmable payment. So if you can avoid that cost, then you would be better off as a trading pair. So simple direct payments, they avoid at liquidity cost. So in situations where you actually can trust each other, for example, because you have a long-term trading relationship, then actually simple direct payments will simply be better. And then finally, on the number of transactions in the economy, as we observed that there's a payment as the cost of transactions goes down, what we observe is that there's actually a different impact along the extensive margin, like with whom you trade, compared to the intensive margin, like the number of payments that occur within an existing trading relationship. Now, there have been a few papers, just a few papers on the economics of programmable payments. And particularly I wanna highlight the papers by Bax and Aliburda, Kong and Hei, and Gans. And they basically always look at a single programmable payment, an environment where you have a single programmable payment and they ask the question, how can that improve economic outcomes? And what we do differently from those studies is that actually we allow for endogenous timing of payments and we allow for repeated payments. So we're actually going to allow for multiple payments within an existing payment arrangement. Let me move to the model environment. So in the model, we have continuous time, there's a risk neutral buyer and a seller and there are four parameters. So the first parameter is the discount rate, which is the same for everybody row. Then there is the cost of providing the service C and there is a benefit of enjoying the service on the side of the buyer B, which is gonna be a function of time. And then finally, the fourth parameter in the model is the transaction cost K. So the transaction cost will basically be the cost of making a single payment and that can both be a normal simple direct payment or programmable payment. The model is set up in a very simple way, but even then the proofs are actually quite hard. So we have no asymmetric information, there are no government enforcement powers and there's no intrinsic uncertainties or there's no uncertainty about the parameters. The only thing that you might be worried about is whether people actually keep their promises. Now we're going to analyze the outcomes in this environment in this, we're going to build those up slowly. So we just start with a single payment arrangement. So consider a single payment arrangement. So you're only allowed to make a single payment, what would be the optimal way to pay? And we're going to assume that the benefit of the buyer of enjoying the service is gonna be an horizontal line and then drops to zero at some known point in the future. And what we're going to ask is what is the optimal way to pay? And that basically means solving three choice variables, namely the optimal amount to pay, when to commit the funds and when to release the funds. So when you look graphically at this problem, more or less looks like this. So there's a moment that you commit the funds, then there is a moment that the funds are going to be released. And in between those two points in time, the funds are going to be locked up. And then there's a period where the service is supplied by the seller. Now, of course, economically or technically, it is possible in this framework to do a simple direct payment, because if you commit the funds at the same time as when you release the funds, then what you get is basically a simple direct payment. So these are the payments that we use every day. But even though these are technically possible in this framework, if you're looking at a single payment arrangement, it is not going to be economically feasible. And the reason is quite simple. If there is no legal enforcement, then basically if you were to wait all the way with the simple direct payment all the way until the end, so you first have the seller providing the service all the way until the end, then the buyer at this point in time really has no incentives anymore to buy the seller because the buyer has already enjoyed the service. And similarly, you can also not move the payment earlier in time because once the buyer has paid with a simple payment, then the seller has no incentives to continue providing the service. So programmable payments will be very useful in this particular environment. But we have to look at the feasibility of payment arrangements. And basically for a payment to be feasible, it needs to be self enforcing, which requires two conditions to hold true. First, on the side of the seller. So the seller needs to be willing to supply the service, which means that the cost of making the payments discounted until the moment that the funds are released to the seller, that that needs to exceed the cost of providing the service from the start of the arrangement until the end of the arrangement. And secondly, we have a constraint on the side of the buyer. So the buyer has... So the cost of making the payment to the buyer, which consists both of the amount to pay plus the transaction cost, discounted from the moment then the money is committed, that needs to exceed the remainder, the benefit of continuing to enjoy the service for the remainder of the period of the time. So in particular, this integral here, it goes from when the money has to be committed until the moment when the benefits are released to the seller when the arrangement ends. So the benefit for the remainder of the time is to exceed the cost of making the payment. Now, from these two conditions, you can actually derive when trading is feasible. And actually that expression is quite easy to understand. So trading is feasible if and only if the benefit of enjoying the service on the buyer's side exceeds the cost of providing the service. So that is what you would observe in any economic model where you don't really account for the economics of payments. But then there's an additional aspect which relates to the cost of making payments. And that component that basically has two parameters in it. The first one is the transaction cost. So how much does it cost you to make a payment? And the second is the liquidity cost of locking up funds. So basically what you need for trading to be feasible is the benefit needs to exceed the cost, the square root of the cost plus the square root of the cost of the making payments. And what we will do, so this is about a single payment arrangement but what you will observe from the research that this condition it actually transits to any programmable or any chain of payments that you could potentially think of. Now we know when payments arrangements are feasible, let us now look what is the optimal payment arrangement. So if we take the perspective of the buyer, basically the buyer would need to maximize the benefit of enjoying the service from the start until the end of the arrangement minus the cost of making the payment at a time and when the time comes to make the payment. Now you can look at that solution just in a graphical manner. So here on the horizontal axis, you will observe the length that the buyer actually wants to enjoy the service. And on the vertical axis in the chart on the top, you will see the timing of the payment. So the moment that the funds are committed and the moment that the funds are released to the seller. And on the bottom panel, you will observe the amount that is being paid and the surplus that the arrangement generates. Now, if you look at really short arrangements, then there's basically no, then if the buyer only wants to enjoy the service for a really short period of time, then it's not really economically feasible to have a trading arrangement because the transaction cost is too high. So nothing will happen. But then once you pass a certain threshold, basically the length of the relationship will be limited by the length of time that the buyer actually wants to enjoy the service. So that's why you see this black line increasing when the buyer wants to have a longer, the service for a longer period of time. But then what you observe as well in the optimal payment arrangement, at some point in time, the arrangement no longer grows any longer. So at some point in time, there's actually no longer optimal to increase the length of the relationship or the length of the arrangement. So and why is that the case? Well, if you think about it intuitively, like the buyer is getting the benefit which kind of linearly increasing in time, but then there's also the liquidity cost of the arrangement and that liquidity cost involves two things. First, the amount that is committed which will be increasing as the length of the relationship becomes longer. And secondly, the funds that are committed must be locked up for a longer period of time. So you can think about this as that the liquidity cost in some sense increases with an order two. So at some point it's not optimal to choose a longer relationship. So there's a limited duration of a single payment relationship. But then you can ask the question, what do optimal change of multiple payments look like? And to kind of explore that, we will start looking at the two-payment arrangement. And from the two-payment arrangement, I can actually also explain to you what will happen in a multi-payment arrangement. And we will look after looking at the two-payment arrangement. So with the two-payment arrangement, basically there are two possible solutions. So the first solution looks like this. So both payments would be programmable payments. So here you see like the timeline for the optimal payment arrangement with two payments. There's the timing. For both payments, you observe that the funds are committed before they are released. So they are both programmable payments. And actually for the last payment, the solution for the last payment is exactly identical to the solution for the one, the optimal solution for the single payment arrangement. So the final part looks all the same as the optimal single payment arrangement. But where there's a difference is actually the first payment. So what you observe is that the funds in the first payment, they are locked up for a shorter period of time. Why is that? Well, the thing is that it has everything has to do with trust and the continuation value of the relationship. So because the seller knows for this first payment that actually the relationship is going to last longer, he or she knows that the buyer can be trusted more that the buyer has stronger incentives to actually make the first payment. And as a consequence, it is fine from the seller's perspective because he knows that the buyer really wants to continue the relationship. It is fine from the seller's perspective if the buyer commits the funds just a little bit later. And as a consequence, the first payment is locked up for a shorter period of time than the second payment. Now, that intuition, if you extrapolate it, you also get to the second case because you could ask the question, well, suppose now that it's final payment creates even more trust, then what would happen for the first payment is it could have been locked up even for a shorter period of time. So you could actually move the D1 a little bit further to the right. And if you move it all the way to the right until the moment that the funds are released, then basically the first payment would be a direct payment. So that's basically the second case with the optimal two payment arrangement. If the second payment creates a sufficient amount of trust, then actually the first payment can be simply a direct payment. So basically what you have about five minutes. Thank you. So if you think about this from the intuition, basically what we learn is that the future relationship, it creates trust. And actually we can make this an economically measurable variable. So this trust, we can measure as the present value of the remainder of the relationship to the buyer immediately after a payment is released to the seller. So we can denote that with a variable called W. And basically what we observe for multi-payment arrangement, so if we go beyond two payments, is that for multi-payment arrangement, if this W is sufficiently high, then any earlier payments would optimally be direct payments. So that's the first result that we obtain in a multi-payment arrangement. Now on top of that, we actually obtain a stronger results, which says that for any relationship that lasts sufficiently long, at some point this W will be sufficiently high. So every optimal chain of payments will start with direct payment as long as the horizon is sufficiently remote. So for this long-term relationship, you would expect them to predominantly be paid with direct payments, even though they may end with programmable payments. Now, you may also ask the question, well, what happens if you have like an infinitely long-lasting relationship? And basically for that, we observe that you can actually reach the optimum just by only direct payments. So you would never actually need these programmable payments in the optimal payment arrangement. Now, I also promised you to tell a little bit about the results for what happens if there's a change in transaction cost, how it affects the frequency of payments. Well, we found two different results, which both, one of them talking to the extensive margin and one of them talking to the intensive margin. So what we observe from the feasibility condition is that when the transaction cost goes down, that then actually trading with more pairs in the economy, for more potential trading pairs in the economy, this condition will be non-binding. And as a consequence, a trading becomes feasible for more trading pairs, so you would expect more payments. But on the other end, within an existing trading relationship, we know that basically the total surplus, is the net benefit of enjoying the surface minus the cost of payments. And we know if the cost of payments goes down, that then actually the surplus within a trading relationship increases. And if the trust increases, you actually trust each other more, so you actually need to make fewer payments. You can wait just a little bit longer and make fewer payments to reduce the transaction cost even more. So within a trading relationship, we would expect that actually the frequency of payments to decrease as the transaction cost goes down. In other words, there's kind of an ambiguous effect of the transaction cost of the number of payments made in the economy. Now let me quickly move to the concluding remarks. So the starting point of the ag, if the analysis was really what the payment is accomplishing is central to understanding the potential demand for a new payment mechanism. And what we observed from our results is the programmable payments that come into play when the need is large, but temporary. And we found that repeated interactions in the prospect of future gains and for service proficient and debt repayment and this trust mechanism reduces the need for programmable payments. Now what we did in the paper is we focused on an extreme case where there are no external sources of trust. And in a model, that means no residual continuation value. Like there's really nobody's gonna punish you if you don't make the payment after enjoying a service. But this is actually not essential for our results. So in reality, you can think about several factors that contribute to trust. There can be legal recourse. There are settlement techniques and card networks which convert small relationship into larger levels of trust. So for example, you might not interact very often with one particular supermarket or one particular store in a big city which you interact frequently with the provider of your credit card. And there are reputation mechanisms in reality such as credit scores and ratings of companies. And basically the extended results that we have in the paper they show that the residual continuation value they further reduce the need for programmable payments. So even though we set up this framework in a way that's very favorable to programmable payments we found that programmable payments we don't expect them to take over all payments although they can come in handy for a particular type of arrangements. And that is basically the conclusion of the paper. Thank you very much for attending. And here's the paper link. Perfect, thanks a lot Martin. So the discussion is Jonathan Payne and you have 10 minutes and we can see your screen. Can you hear me fine now? Yes. Great. So thank you very much for inviting me to discuss this paper. I enjoyed reading it a lot and yeah I think I learned a lot from it. So in short, as you heard the paper studies the optimality of what the authors are gonna call programmable payments which are really like a form of automated escrow account where buyers send funds into the payment system and then the payment system at some later date releases the funds to sellers. So essentially what they're doing is they're introducing a payment system that gives some degree of costly limited commitment into an environment where otherwise you wouldn't necessarily have any kind of commitment. Okay, so I have two high level comments before I get into the details. So one is that I really liked the paper was precise about how programmability improves commitment. We have a lot of papers on sort of broadly in the smart contracting area that make fairly vague claims about that. This paper is very precise I think about what the gain is. And I also really like that it thinks about what is the cost of that commitment. I think we need more papers in the dynamic contracting literature to think about why commitment is costly. Okay, so that's one comment high level to start off with. The second comment is that ultimately the paper is motivated a lot in terms of payments and discusses the payments literature a lot. But really what they're writing down is a dynamic contracting model, particularly a continuous time contracting model. And I think what might be helpful for the paper would be to better understand how this relates to standard dynamic contracting models where there's limited commitment. Okay, so that's the high level. Let's get into the details. So it's a continuous time economy. There are two risk-neutral agents who each have the same discount rate. One agent is a seller who can provide a flow service at flow cost C. And then there's also a buyer that values this service at some flow utility BT, where in most of the examples the authors are going to think about essentially that the buyer only values the service for some finite amount of time. Okay, so it's constant and then zero after some time cap T. There's no asymmetric information and there's no legal systems. This is a problem with two-sided non-commitment. And then when they think about trying to characterize the optimal contract, they're going to think about a world where the agents contract to maximize buyer value. So I think this is a world where the buyers make a take it or leave it offer. And then the buyers and sellers have an outside option of zero if they leave the contract. Okay, so that's the environment. If I was just gonna write this down as a two-sided no-commitment contracting problem, in general, I'd write it down in the following way. So the buyers really choosing two things. They have to choose some kind of payment process to the seller and some kind of stopping time for when the contract is going to end or they're going to break apart. So in choosing this, they're implicitly giving a continuation value to the seller that they get if they stay in the contract under this set of choices that the buyer is making. They wanna choose this to maximize the welfare of the buyer since the buyer is the one deciding in the terms of the contract here. So the buyer gets some flow benefit while the contract is in operation from zero to S. And then they have to make payments for whatever this payment process is to the seller and they lose utility from that. And then there's a continuation value of the seller for staying in the contract which depends on the effort cost that they exert and then also whatever payments are received. There's no commitment in this world. So we'd have to have two participation constraints, one that the buyer wants to keep participating over time and the other one that the seller wants to keep participating over time. So this being the continuation value for the buyer of staying in the contract and W being the continuation value of the seller for staying in the contract. Okay. So these models with two-sided no commitment and repeated interactions are much studied. And then there's also a bunch of extensions with reputation and this is a long literature. Okay. And this literature is very worried about how could you sustain some kind of cooperation between the agents by having everybody resort to some outside option when the contract breaks apart. The authors are gonna take a different direction instead of trying to think about how you could sustain cooperation without any commitment. They're going to insert a payment technology into this economy that's going to give a form of limited commitment, a costly limited commitment to the agents in this world. So the way this payment technology is going to work is the buyers can use this technology to submit payments. So they use DI to denote the size of a payment or there's a series of payments, it's payment I and they choose when they wanna submit this payment to the payment system at time TI. The seller observes all payments, then the payment technology observes everything that's happening in the economy and releases funds to the seller at some later date S conditional on whether the seller has provided the service and the payment technology charges a fee per payment of K. So I think that the natural interpretation of this is something like an escrow account where the payment is held until the seller provides a service. And essentially the buyer is choosing the terms for when the payment would go into the escrow account and when the payment would leave the escrow account. Okay, in terms of the terminology of the paper, they wanna think about a direct payment as being when you release the funds as soon as you make the payment, right? So there's no difference between the time when the buyer puts the funds into the escrow account and when the funds are released and a programmable payment is when there's some gap. So you release the funds at some point after the funds have been put into the escrow account. From a contracting point of view, what this does is it introduces a form of commitment that is costly into the economy. So how does that end up changing the problem? Okay, so I'm just gonna do the contracting problem with one payment, although the authors as was explained in the talk, they do a series of extensions where they think about two payments and then multiple payments but I only have 10 minutes and only five minutes left. So I'm gonna stick to the one payment example in my discussion. So if you're making one payment then essentially what the buyer is going to choose is T1, the time at which they submit the payment to the payment system. S1, the time at which the payment system releases the funds to the seller and in this case, the contract ends and D1, which is the size of the payment to the seller. So now the problem becomes something like this, right? So the utility for the buyer, the maximizes these three objects, they get benefit from zero until the time when the contract ends and they break apart. They get some flow benefit and then at time T1 they have to make this payment and they pay D1 as the payment to the seller and they have to pay this transaction cost for using the payment technology. Again, we have two participation constraints. So on the buyer side, the buyer has to want to submit the payment at time one when they do it. So this means that the remaining value of the service at time T1 minus the cost of making the payment has to be greater than their outside option. And from there's also the seller participation constraint that they have to want to provide the service. So their payment to the service has to be greater than, sorry, the payment they get at the end has to be greater than the value that the cost they're incurring for providing the service. Okay. So as the authors, I think characterize very nicely. You can get a very clean characterization of what this looks like. So I think this was explained well in the previous discussion. So if we think about TM being the length of time for which the buyer actually values the service that seller has been giving on the X-axis. And then we have the timing of the contract on the Y-axis. We can see that if the length of time that the buyer values the contract is very small, then given the fixed cost, you wouldn't want to start the contract at all. And then as the length of time the buyer values the service gets larger, eventually people want to start contracting. And then we end up with this arrangement where at some time, T1, the buyer wants to commit the funds and then at some time, S1, they get released. Okay. So we get a very nice characterization of what this optimal contract looks like. All right. I've got a couple of minutes left. So I want to make a couple of comments. So first of all, I'll comment briefly on the contracting setup. And then I'll make some more general comments about the sort of environment and programmable payments. So just in terms of the contracting setup, I think the payment technology they introduced puts a lot of restrictions on the contracting problem. So a lot of structure there. So in particular, they want to think about discrete lump sum payments with a fixed cost per payment. And then the sort of choosing in some sense when you would make these lump sum payments. I would agree this gives a very clean problem when there's one payment and it's got very nice characterization and clear intuition. However, I would say that I think it gets fairly complicated once they want to generalize to multiple payments because we have quite a complicated structure in the sense that you have all these lump sum payments coming in. And I'm not sure it necessarily delivers a huge amount of insight given the kind of complexity of trying to characterize this environment. I think one thing the authors could think about is whether they'd like to use a more general payment technology, particularly for the multiple payment case or when they want to open it up. So one thing they could think about is allowing the buyer to commit to a sequence of payments at time zero but require the buyer to maintain a balance in this escrow account that could deliver the promised value to the seller that would open up a much broader range of the contracting space. They could also allow the buyer to commit to a sequence of payments at time zero but impose a cost as a function of the continuation promise. In some sense what the authors really want is they want to say in this two-sided no commitment problem, they want to relax this constraint, this buyer participation constraint but when they do that, they want to force a cost so that as you try to back load the contract and you're going to promise more in the future it becomes costly for the buyer to do that even though they can commit to that. And they could think about a more generic way of imposing costs on the continuation promise that the buyer is making to the seller. Okay, so there are my comments on the contracting setup. In terms of the more general setup and how we'd interpret it in terms of programmable payments. The first comment I'd say is that I think perfect information is a fairly strong assumption here. So this payment system needs to be able to see whether or not the seller has provided the service. It also needs to see the buyer payments but I think that's probably less controversial here but I think it is a fairly strong information assumption to say that the payment system can observe everything about whether the seller is providing the service or not. And I think this does make it a little bit tricky to try to think about their preferred interpretation as something like an automated escrow system because unless this payment system is being run by a retail platform or some kind of trading platform it's not very clear that the payment system would have the right trade information to be able to execute this contract. I think this is sort of why in practice when we see a lot of escrow accounts in the world they're often intermediated by trusted agents who can verify the actions to release the funds from the system. So I think it'd be worth thinking a little bit more about what information is really required or how could we feed information into this payment system to be able to automate the kinds of contracts that have in mind. And then I think finally the big question to my mind it's sort of sort of broader than this paper but I think the big question in my mind is whether these programmable payments or smart contracts can really allow a greater pre-commitment of future income not just a way of escrowing payments. And I think the big to me I think the big promise of having this programmable payments is if we do combine them something like a retail platform or some other kind of trading platform where you do have a lot of information then maybe you are able to pre-commit future income in a way that gives commitment that otherwise you wouldn't have and maybe you open up a whole range of contracts that otherwise it'd be very hard to get. Okay, so that's the end of my remarks. In conclusion, I really enjoyed the paper. I think I learned a lot about the structure of these payments and how much you want to front load and back load them. And I think ultimately it'd be helpful to have a bit more discussion to the dynamic contracting literature. But thanks very much. That's the end of my remarks. Excellent Jonathan, thanks so much. Before I open the floor, Martin I don't know whether you want to sort of briefly react to Jonathan's discussion. Maybe if you do just keep it very brief in the interest of time so that we have some time for Q&A as well. I know, thank you Peter and especially Jonathan for the discussion. A lot of really, really good comments. Link with the dynamic contracting literature without limited commitment should be spelled out more in the paper. I think like you touched upon a few things like and I think that's typically I think in a dynamic contracting literature it's much easier to allow for different types of way that you settle payments. But I think like in practice you really face these problems that payments in practice really are lump sum transfers. So that creates a lot of technicalities in terms of proving things. And thank you for acknowledging that which makes those are kind of really hard to find the optimal payment arrangements. I agree with you that perfect information is very strong. And I just want to respond to two aspects of that. One is about the wholesale environment. So for example, if you think about the clearing of securities, clearing a settlement of securities to mention like on this wholesale setting that perfect information whether securities delivered or not or whether funds are delivered is more realistic similarly in terms of forex transactions. And then on the retail side I think there's actually kind of growing literature that's kind of looking at how information ends up on blockchains or in digital ledgers. So actually the three papers that I quickly referred to actually they all have different mechanisms. So one of them uses kind of internet of things sensors. Another mechanism, another paper uses consensus mechanisms by the crowd basically. And a third paper, the one by Joshua Gans uses certain game to make sure that the buyer and the seller agree on the information that ends up on the ledger. But that's definitely like particularly in that non-financial retail side is going to be an important aspect of implementing program or payments in practice and as well in the model. Thank you. Great. So then let's open the floor for discussion. So panelists are free to just jump in while if there's any other questions from the audience please post them in the Q and A as already indicated by Johnson and I'll be happy to read them out. So Martin, I'm sorry. So I cannot raise my hand. So let's jump in. Yeah. So I'm wondering what happened if the relationship, the TM is stochastic. So it is unstable and uncertain random over time. So that could be useful for S-Cow account, right? So you load enough money just in case the relationship end and then you can cash in from the account. So that might be interesting. So another thing would be the TM is endogenous. Maybe the programmable payment will promote a longer relationship and build up to process one. I'm just wondering how complicated a problem like that could be. So how complicated, it would become more complicated. So the current paper just kind of give you a little bit background. It's about like, it's about 25, 30 pages and then there's like 40, 50 pages of proofs. So kind of we kind of started with what we felt was kind of the most simple setup that touches kind of all the major, the most important features. And then we thought after doing that, we can actually add like potential additional best bells and whistles, like for example, stochasticness in terms of whether the buyer actually wants to enjoy the service. And basically, once we finished the paper, we were so happy that we got very, we got, that we never really thought about kind of also adding stochasticness on top of that. But it's a really good question, something that should be done. But I would say in the next paper, to be honest. One of the things that might be possible though is that value of the relationship could become a stochastic variable itself because the expected value of the relationship becomes the shadow value of the continuation. And so if we expect the relationship to be of high value, we don't need anything in the in the escrow. But if the expected value starts falling, we need to keep putting something into it. That's the hope that something clean like that comes out but we don't have any guarantee of it. So if nobody else has a question, I, so thanks for the nice presentation. I have, so I have one thing I don't understand is you have this result that in the multiple payments, you have this result where direct payments are optimal and even the last one, but I don't quite understand. Okay, so that's, I see that Charlie said it's wrong, but, because I don't understand how this works in the sense that, you know, if the direct payments comes at the very last of the relationship, I have no incentive to make it. But if it comes before the end of the relationship, then the seller has no incentive to provide the good. So how, so how does that work? Your intuition is 100% correct, Cyril. So sorry for the unclearity during the presentation, but I never meant to say that the last payment would be a direct payment. So for finite relationships, you always will end up with a programmable payment or two programmable payments. And then at some point, anything before will be a simple direct payment. It's only when you have like a relationship that lasts infinitely long, then you can just get the optimum with just simple direct payments. Just for that clarity. And thank you for highlighting that, otherwise the gate, like the arrangement unravels. Right, thanks. So I have another question, which is more open. So you guys must have thought about programmable money. So you just mentioned it at the very beginning, I guess. And so I was wondering about your thoughts about programmable money relative to programmable payment and whether your framework could be used to think about programmable money and its potential benefit of our drawbacks. You take that one, Charlie, or should I? I wouldn't touch that with a 10th at all, actually. It actually does not work too well because there are lots more things that go into programmable money. Lots of issues that you'd want to think about, like restricting the use of the money for particular kinds of goods than other kinds of goods or restricting the length of time that it's going to be used, things like that. All sorts of things that would be possibly of interest, for example, to a government for how it's going to provide funds to direct people's use of them and the framework just doesn't have any of that in there at all. I think the answer is also partly given by the politicians. So if you look at the statement by the Eurogroup, the ministers of finance, kind of when they touch upon programmable payments, they do a lot of effort to explain that they actually don't want the digital euro to be a programmable money because programmable money is also associated, at least in the political context, with a lot of features that people are really worried about, like the populations really worried about, like limited purpose money, expiring money. So if you read the statement by the Eurogroup, they actually do a lot of effort to actually explain like, well, these programmable payments, which are really just conditional payments, they don't require programmable money. Now, one of the things that makes it really nice, if you can have a programmable payment in a currency that is issued, a digital currency that is issued by the central bank, is actually that you don't need to trust its third party. So for any escrow arrangement, you need basically a trusted third party that is actually safekeeping the funds and that both counterparties trust. And that also, like the fact that you need to have that trust in an economic world basically means that it's never going to be a very competitive market. So in reality, there's just a number of institutions that can provide that trust. And if you can actually have this programmable payment if you can program the digital currency, if you can condition the payment actually in the money itself, then basically you no longer need that trusted third party because your counterpart can basically observe that that money that was issued by the central bank digital currency will end up in their account if they do whatever the condition requires. So that's I think one thing that's really nice if you actually create it into the payment system as it were. Although as Jonathan says, you'll still need to have some mechanism out there to get the information into the system in the first place. Absolutely. Okay, your hand is up, just jump in. Yeah, that's what I was about to say. So of course, I think what the central bank can provide is kind of an interface where you can put up your programmable payment. But I don't think that the central bank would be able to provide the trust into the payment itself. So it would probably provide a trusted mechanism that the observation whether the payment conditions are fulfilled, they would not be monitored by the central bank. So I wouldn't see such a large difference between yeah, in a scroll account and the programmable payment. I think it's an automation of payments, but it's probably not something that is exclusively linked to a central bank digital currency. I think in practice, of course, indeed, you can set it up in different matters. The only thing is, for example, if you look in trade finance, like if you need to say you need to order like a machine that creates chips, which might cost you like a hundred million dollars. And you really want to make sure that you get the machine after you transferred the money. Like basically what you need to find in the current system is a counterparty that you will trust with a hundred million dollars to actually as a safekeeper and that they don't run away with it. Now, if you can actually program that into the payment system already, even though you use the interface of a financial institution, that could kind of reduce the search of actually finding a counterparty that you actually trust with a hundred million dollars. So that's kind of the potential benefit that I see over there. But indeed, probably like the payment interface is going to be provided by a third party, like a financial institution. Yeah, I guess you would still need to trust the person that releases the hundred million dollar or the one that provides the information that the machine has been delivered. Yes. Maybe I have a question. So is it one of the friction here is that once when you put the hot money in the SQL account, it's generating not generating return. So that's generating the cost. But in principle, if it's run by a smart contract potentially, why can it try to earn some return during keeping the fund in the SQL? Would that help mitigating? It would, it could, but it was still going to have a problem of the opportunity cost of those funds not being usable elsewhere. So no matter what you do in terms of putting an interest on it, those funds are still in some sense tied up. If it were the case that the interest had gone up so much that we didn't even care where the funds were tied up, then we've got a new paradox here because there's no reason not to put everything into that service system as well. So as long as there's some restriction on the usage of the funds, you're going to have an opportunity cost there that's going to work. But it is indeed the case that you'd like to think about the comparative statics of putting interest rates in that story as well. Makes sense. So Michael Christof, I don't know who was first. Well, Michael, you're on put it. So just jump in. It's fine. So my question is also related to this liquidity cost. There was this very interesting result on the extensive and intensive margin related to transaction costs. And I was wondering how it looks like, whether you looked into a similar result for changes in the liquidity cost. We didn't and we should. We got that sort of a place where since we had realized that we could simply that there was always going to be a liquidity cost, we didn't do that as the first step. But it is a good comparative, a good comparative tax to be thinking about. And we need to put that in there. So my question is more thinking about the distinguishment between payments and collateral. In this kind of escrow type environment, you could imagine that any form of collateral, if it's posted and provides the provider with the ability to withdraw or take the collateral conditional on nonpayment, similar effect would hold. And the duration for when collateral is posted will be similar to the timing of having these programmable payments. And so do you see a feature here with respect to payments that would look different from how we typically think about the use of collateral for maintaining or supplementing credit and reputation? I'm not 100% sure, Michael, that I 100% get a question, sorry. I guess I'm speaking more generally. Today, you could imagine that if we can post collateral to a service provider and allocate contingent rights to seize collateral if there is nonpayment, that's very similar or sounds more similar than to the programmable payments that you've described here. And I wonder if there are certain insights that I'm kind of leaning over. When I'm thinking about this in the context or interpretation of programmable payments, that's not captured in an environment where we're thinking about the use of collateral to support these long-term relationships. I think the mechanisms are very similar. I think that if you put a world in which you could put collateral in and then make the condition that the collateral comes back to you if a payment is made, I think it's going to work out very much the same. Yeah, I think I agree. I think only the typical type of questions that you've seen in the literature might be, or the typical questions of answers will be different in different literature. So for example, with collateral, there's a clear reason that you want to centralize the collateral in one place where you can use for multiple situations. And we're looking here more on the dynamics, so we're very much looking at the kind of, with a single counterparty, you want to minimize as it were kind of the amount of collateral that you would need to post. And you're kind of trading off here the amount of collateral versus the number of payments that you make. But it's definitely closely related economically. But there might be something interesting, like maybe the programmable payment is more like a production technology for collateral. So now you can convert an income stream into a collateral, like you are committing some of the payment into your S-card account. So now with the programmable payment, now you have a technology to produce collateral. That might be good to sustain relationship or payment, any other thing. There might be one good way to think about it, but thank you, Michael, that might be interesting. I would say my reading was that you could replace escrow with the word collateral, and you would really get a lot of the same kind of dynamics that the authors are thinking about, because my reading at the paper. I think, so just to jump in, I think one big difference between collateral and this escrow account is that usually collateral you could reuse. But here if the seller can reuse collateral, this might undo all the incentive effects of the escrow. The difference is that you have collateral, but it's seized in the condition that you don't pay with presumably some other funds. And so whether you actually use the collateral to pay or not, I think is more about interpretation. One thing I think is kind of interesting is to think about these types of programs more generally as just expanding the set of permissible types of collateral. It's fairly difficult to collateralize cash right now, whereas with these programs you can actually have the same effect of creating more collateral. I think that's a very interesting viewpoint, Michael, and I do agree with Cyril on the recollecturization that basically you, because you don't know whether the seller is actually going to do the effort of providing the service, that's why it becomes hard to actually recollecturize that if you were to use the same collateral. Peter, are we done with time? We are technically out of time, but also technically nothing can stop us from hearing good questions. No, it's more a thought. I was just thinking it's not really about specifics of the paper, but you is very related in the sense that you could think about endogenous relationships and how payments shape those relationships, these limitations on payments, and then the fact that you're introducing these kind of, maybe and you're thinking about the cost of doing things like these are going down and what would be the impact on the existing relationships. You see what I'm saying? Kind of what I'm going the other way, and it was something really interesting to think about. Thank you. Please go ahead, Charlie. Oh, I was going to say that, yes, that's the direction that I think that this extensive and intensive margin that Martin was talking about at the end is going towards thinking about which kinds of, as these payments, as the cost of these payments change, what kinds of relationships start growing, what kinds of relationships become more assumed to not need the payments in such complicated ways. It's an interesting direction to go with this in the future. Thanks. Okay. If there are no further questions, Russell, do you want to ask something else? No, no, no, but up to you. No, up to you really. I wasn't going to ask anything. So I don't know, do you want to say something? Because otherwise I can close it here and I can just hand it back to you. Yeah, so I just want to, yeah, conclude after you, but maybe right time to do it. So yeah, thank you for everyone, Peter, for moderating it. Martin for presenting and Jonathan for discussing a paper. So our next meeting will be May 19, Crystal Booth from West Bank will present a stable connet adoption and fragility. We will be discussed by the Electoral Wadulaki of the Board, Federal Reserve Board, and will be moderated by Larry Wall of the Atlanta Bank. So hope to see you next time. Have a good weekend. Excellent. Thanks a lot. Thank you. Thank you so much. Thank you for all the questions.