WEBVTT 00:00:00.000 --> 00:00:04.356 align:middle line:84% [SQUEAKING] [RUSTLING] [CLICKING] 00:00:04.356 --> 00:00:10.722 align:middle line:90% 00:00:10.722 --> 00:00:11.680 align:middle line:90% ROBERT M. TOWNSEND: OK. 00:00:11.680 --> 00:00:18.600 align:middle line:84% So today is this lecture on tokenized and programmable 00:00:18.600 --> 00:00:20.080 align:middle line:90% assets. 00:00:20.080 --> 00:00:24.880 align:middle line:84% We're going to talk about programming asset exchanges 00:00:24.880 --> 00:00:30.920 align:middle line:84% in advance related to the concept of a dynamic ledger. 00:00:30.920 --> 00:00:33.080 align:middle line:84% That's in contrast to what we have 00:00:33.080 --> 00:00:39.240 align:middle line:84% mostly today, legacy systems, where there are trade fails. 00:00:39.240 --> 00:00:42.620 align:middle line:84% Despite the advantages of programmability of assets 00:00:42.620 --> 00:00:45.600 align:middle line:84% there are problems, nevertheless. 00:00:45.600 --> 00:00:49.320 align:middle line:84% But, in turn, there are new solutions 00:00:49.320 --> 00:00:55.398 align:middle line:84% emerging to handle those lingering problems. 00:00:55.398 --> 00:00:57.440 align:middle line:84% In particular, we're going to dig a little deeper 00:00:57.440 --> 00:01:03.540 align:middle line:84% into the meaning of tokenization and conditionality, 00:01:03.540 --> 00:01:07.380 align:middle line:84% then turn to having multiple blockchains 00:01:07.380 --> 00:01:12.060 align:middle line:84% and face the issue of interoperability, which 00:01:12.060 --> 00:01:17.900 align:middle line:84% is related to having blockchains coexisting with legacy systems. 00:01:17.900 --> 00:01:21.860 align:middle line:84% And then think about exchange and contracting platforms 00:01:21.860 --> 00:01:25.420 align:middle line:84% as proposed by various international agencies 00:01:25.420 --> 00:01:27.020 align:middle line:90% and countries. 00:01:27.020 --> 00:01:28.780 align:middle line:84% And central bank innovations, I'm 00:01:28.780 --> 00:01:30.980 align:middle line:84% going to leave for the reading list. 00:01:30.980 --> 00:01:33.580 align:middle line:84% There are some starred articles having to do with the Swiss 00:01:33.580 --> 00:01:36.160 align:middle line:90% National Bank and Brazil. 00:01:36.160 --> 00:01:39.880 align:middle line:84% But that would, I decided, take too much of the class time. 00:01:39.880 --> 00:01:43.720 align:middle line:84% I want to focus on the remaining items. 00:01:43.720 --> 00:01:48.540 align:middle line:84% So asset exchanges programmed in advance-- 00:01:48.540 --> 00:01:52.900 align:middle line:84% introduce this concept of a dynamic ledger, where 00:01:52.900 --> 00:01:54.740 align:middle line:84% ownership and transfers take place 00:01:54.740 --> 00:01:57.220 align:middle line:84% over time, and in principle, conditioned 00:01:57.220 --> 00:01:59.370 align:middle line:90% on states of the world. 00:01:59.370 --> 00:02:02.930 align:middle line:90% An example will be featured. 00:02:02.930 --> 00:02:05.390 align:middle line:84% As is the case in so many of these lectures, 00:02:05.390 --> 00:02:08.570 align:middle line:84% we start with a simple example, which 00:02:08.570 --> 00:02:15.530 align:middle line:84% is trade agreements for asset lending and then atomic swaps. 00:02:15.530 --> 00:02:20.210 align:middle line:84% This whole thing about trade, is it separate from settlement? 00:02:20.210 --> 00:02:24.190 align:middle line:84% These things take place at different points in real time. 00:02:24.190 --> 00:02:26.730 align:middle line:84% Is there a sense in which trade and settlement 00:02:26.730 --> 00:02:30.630 align:middle line:90% can be instantaneous? 00:02:30.630 --> 00:02:34.330 align:middle line:84% So I want to start with-- because we're going to talk 00:02:34.330 --> 00:02:36.690 align:middle line:90% about programmed assets-- 00:02:36.690 --> 00:02:42.590 align:middle line:84% with the Ethereum slides, two of them that I showed last time 00:02:42.590 --> 00:02:44.830 align:middle line:84% and then a little bit more detail. 00:02:44.830 --> 00:02:50.530 align:middle line:84% So Ethereum is the premier or often cited blockchain 00:02:50.530 --> 00:02:52.150 align:middle line:90% that allows contracts. 00:02:52.150 --> 00:02:55.410 align:middle line:84% There are two types of accounts on Ethereum-- externally owned 00:02:55.410 --> 00:03:01.830 align:middle line:84% accounts like Bitcoin, where we have addresses and balances, 00:03:01.830 --> 00:03:06.270 align:middle line:84% and balances get transferred across the households or clients 00:03:06.270 --> 00:03:08.470 align:middle line:90% or nodes. 00:03:08.470 --> 00:03:11.790 align:middle line:84% But we also have contract accounts. 00:03:11.790 --> 00:03:15.910 align:middle line:84% And the contract accounts are nodes on Ethereum, 00:03:15.910 --> 00:03:21.510 align:middle line:84% and they contain code and potentially data. 00:03:21.510 --> 00:03:26.590 align:middle line:84% So the contract accounts receive "transactions," quote unquote, 00:03:26.590 --> 00:03:28.910 align:middle line:90% and update their state. 00:03:28.910 --> 00:03:32.510 align:middle line:84% And they can also send transactions and messages 00:03:32.510 --> 00:03:34.390 align:middle line:90% and so on. 00:03:34.390 --> 00:03:37.910 align:middle line:84% But a contract node can only initiate transactions 00:03:37.910 --> 00:03:41.990 align:middle line:84% as a response to another transaction. 00:03:41.990 --> 00:03:46.910 align:middle line:84% But this I smile at because effectively, the code is not 00:03:46.910 --> 00:03:49.190 align:middle line:90% a person. 00:03:49.190 --> 00:03:55.150 align:middle line:84% It's a passive response to incoming messages, 00:03:55.150 --> 00:03:58.820 align:middle line:84% and then can send outgoing messages. 00:03:58.820 --> 00:04:04.060 align:middle line:84% There is a coin associated with Ethereum, Ether, 00:04:04.060 --> 00:04:08.580 align:middle line:84% in particular, which is like a fee you 00:04:08.580 --> 00:04:16.060 align:middle line:84% pay to execute contracts, and it is intended largely 00:04:16.060 --> 00:04:21.899 align:middle line:84% as a way to economize on the number of users 00:04:21.899 --> 00:04:24.860 align:middle line:84% who want to do something on the Ethereum platform 00:04:24.860 --> 00:04:26.380 align:middle line:90% at the same time. 00:04:26.380 --> 00:04:29.140 align:middle line:90% It's like a congestion fee. 00:04:29.140 --> 00:04:34.540 align:middle line:84% And in your mind, you can imagine setting it to zero, 00:04:34.540 --> 00:04:38.260 align:middle line:90% if you like, to simplify things. 00:04:38.260 --> 00:04:42.820 align:middle line:84% So these are the pictures of the normal user accounts 00:04:42.820 --> 00:04:44.860 align:middle line:90% with addresses and balances. 00:04:44.860 --> 00:04:48.140 align:middle line:84% Currency, for simplicity, would be Ether. 00:04:48.140 --> 00:04:52.020 align:middle line:84% As you'll see, it could be other objects, other coins. 00:04:52.020 --> 00:04:54.580 align:middle line:84% And the code and storage are added 00:04:54.580 --> 00:04:57.600 align:middle line:90% to these contract accounts. 00:04:57.600 --> 00:05:01.720 align:middle line:90% So the transaction structure-- 00:05:01.720 --> 00:05:02.780 align:middle line:90% you have a sender. 00:05:02.780 --> 00:05:04.480 align:middle line:90% You have a recipient. 00:05:04.480 --> 00:05:07.560 align:middle line:84% You have the currency, say, Ether. 00:05:07.560 --> 00:05:08.540 align:middle line:90% That, we're used to. 00:05:08.540 --> 00:05:11.800 align:middle line:84% We've been doing this for a while with Bitcoin and ledgers 00:05:11.800 --> 00:05:13.080 align:middle line:90% and so on. 00:05:13.080 --> 00:05:15.340 align:middle line:84% Then you have the data part, part 00:05:15.340 --> 00:05:19.480 align:middle line:84% of the contract with these values and so on, 00:05:19.480 --> 00:05:22.240 align:middle line:84% and potentially the gas, the ether 00:05:22.240 --> 00:05:24.560 align:middle line:90% that you need for computation. 00:05:24.560 --> 00:05:29.200 align:middle line:84% So all transactions in Ethereum have a sender, a recipient, 00:05:29.200 --> 00:05:33.640 align:middle line:84% and a currency field, although that field could be empty. 00:05:33.640 --> 00:05:37.400 align:middle line:84% And it's an option to have or not the data 00:05:37.400 --> 00:05:40.380 align:middle line:84% part and the contract part and the gas part. 00:05:40.380 --> 00:05:43.600 align:middle line:90% 00:05:43.600 --> 00:05:47.400 align:middle line:90% So Ethereum smart contracts-- 00:05:47.400 --> 00:05:51.520 align:middle line:84% I often get asked, what is a smart contract anyway? 00:05:51.520 --> 00:05:53.620 align:middle line:84% I think you can't really understand 00:05:53.620 --> 00:05:57.740 align:middle line:84% what that means without understanding these next two 00:05:57.740 --> 00:06:02.900 align:middle line:84% slides because it has to way has to do with the way the code is 00:06:02.900 --> 00:06:05.140 align:middle line:90% executed. 00:06:05.140 --> 00:06:10.660 align:middle line:84% A smart contract computes on an Ethereum virtual machine. 00:06:10.660 --> 00:06:13.260 align:middle line:90% What is a virtual machine? 00:06:13.260 --> 00:06:20.100 align:middle line:84% It has CPU, memory, disk storage, and network interface. 00:06:20.100 --> 00:06:25.180 align:middle line:84% And it performs tasks just like a physical machine would. 00:06:25.180 --> 00:06:26.660 align:middle line:84% But it's called a virtual machine 00:06:26.660 --> 00:06:28.860 align:middle line:90% because it's not physical. 00:06:28.860 --> 00:06:32.960 align:middle line:84% It allows administrators to change, in fact, 00:06:32.960 --> 00:06:37.100 align:middle line:84% if they wish, the resources the machine is using, 00:06:37.100 --> 00:06:39.680 align:middle line:90% based on workload intensity. 00:06:39.680 --> 00:06:42.980 align:middle line:84% Another way to put this is that a single server 00:06:42.980 --> 00:06:47.900 align:middle line:84% is allowed to operate many separate machines, each 00:06:47.900 --> 00:06:52.290 align:middle line:84% with their own resources, like partitioning your computer 00:06:52.290 --> 00:06:56.350 align:middle line:84% or having multiple computers in a network. 00:06:56.350 --> 00:07:00.730 align:middle line:84% The EVM is Turing-complete software. 00:07:00.730 --> 00:07:04.850 align:middle line:84% Turing-complete means it's any if/then statement 00:07:04.850 --> 00:07:07.610 align:middle line:90% can be executed in the code. 00:07:07.610 --> 00:07:10.010 align:middle line:84% Not all codes are Turing-complete. 00:07:10.010 --> 00:07:13.590 align:middle line:84% It's also software, meaning what? 00:07:13.590 --> 00:07:15.610 align:middle line:90% That it's not hardware. 00:07:15.610 --> 00:07:18.290 align:middle line:90% It emulates hardware. 00:07:18.290 --> 00:07:21.910 align:middle line:84% But the software is creating the memory, the disk storage, 00:07:21.910 --> 00:07:24.370 align:middle line:90% and the network interface. 00:07:24.370 --> 00:07:29.530 align:middle line:84% So anyone can execute code in this trustless ecosystem. 00:07:29.530 --> 00:07:34.210 align:middle line:84% And when smart contracts are executed on the Ethereum Virtual 00:07:34.210 --> 00:07:41.010 align:middle line:84% Machine, every node is executing the contract code. 00:07:41.010 --> 00:07:44.490 align:middle line:84% It's like every node participant is compiling 00:07:44.490 --> 00:07:48.730 align:middle line:84% the contract, which ensures there's 00:07:48.730 --> 00:07:51.870 align:middle line:90% consistency across the network. 00:07:51.870 --> 00:07:53.810 align:middle line:90% Remember the distributed ledger. 00:07:53.810 --> 00:07:57.510 align:middle line:84% It's as if it were a single common ledger, 00:07:57.510 --> 00:08:01.630 align:middle line:84% but then distributed to all the participants. 00:08:01.630 --> 00:08:04.070 align:middle line:84% The virtual machine, again, is isolated from the rest 00:08:04.070 --> 00:08:05.790 align:middle line:90% of the physical machine. 00:08:05.790 --> 00:08:10.830 align:middle line:84% So execution failures in EVM cannot harm the host computer. 00:08:10.830 --> 00:08:13.730 align:middle line:84% And again, EVM has its native currency, Ether, 00:08:13.730 --> 00:08:19.350 align:middle line:84% which is used to pay for transaction fees. 00:08:19.350 --> 00:08:23.510 align:middle line:84% So smart contracts are self-executing contracts 00:08:23.510 --> 00:08:28.590 align:middle line:84% with the terms of the agreement written into the code. 00:08:28.590 --> 00:08:30.590 align:middle line:90% They run on the EVM. 00:08:30.590 --> 00:08:33.070 align:middle line:90% They're automatically enforced. 00:08:33.070 --> 00:08:36.429 align:middle line:84% They execute the terms of the contract when predetermined 00:08:36.429 --> 00:08:39.110 align:middle line:90% conditions are met. 00:08:39.110 --> 00:08:43.350 align:middle line:84% Contracts can be reached with these transactions called 00:08:43.350 --> 00:08:47.590 align:middle line:84% messages, as I was saying on the first slide. 00:08:47.590 --> 00:08:50.610 align:middle line:84% And a message can change the state of the data 00:08:50.610 --> 00:08:52.290 align:middle line:90% within a contract. 00:08:52.290 --> 00:08:58.450 align:middle line:84% A message could create a new contract or transfer the Ether. 00:08:58.450 --> 00:09:02.530 align:middle line:84% Contracts are written in a computer code language, which, 00:09:02.530 --> 00:09:05.010 align:middle line:90% in this case, is Solidity. 00:09:05.010 --> 00:09:07.810 align:middle line:90% And again, it's Turing-complete. 00:09:07.810 --> 00:09:14.490 align:middle line:84% And then compiled down to bytecode, which is intermediary 00:09:14.490 --> 00:09:17.290 align:middle line:84% code that bridges the gap between this high-level source 00:09:17.290 --> 00:09:20.010 align:middle line:84% code and the low-level machine code. 00:09:20.010 --> 00:09:25.090 align:middle line:84% And machine code is just bits, 0s and 1s, 00:09:25.090 --> 00:09:29.510 align:middle line:84% which is the way the computers electronically do things. 00:09:29.510 --> 00:09:32.330 align:middle line:90% 00:09:32.330 --> 00:09:35.970 align:middle line:84% So we will come back to all of this. 00:09:35.970 --> 00:09:43.610 align:middle line:84% But first, the example, and this comes from a paper with Lee 00:09:43.610 --> 00:09:49.560 align:middle line:84% and Martin, the "Optimal Design of Tokenized Markets." 00:09:49.560 --> 00:09:52.240 align:middle line:84% So the idea is that a distributed 00:09:52.240 --> 00:09:57.480 align:middle line:84% ledger-based settlement system is a technological advancement 00:09:57.480 --> 00:10:01.160 align:middle line:84% or solution, sometimes called a token system. 00:10:01.160 --> 00:10:05.960 align:middle line:84% And there's a lot of hype nowadays about tokenized assets. 00:10:05.960 --> 00:10:09.960 align:middle line:84% So these slides are intended to clarify 00:10:09.960 --> 00:10:12.320 align:middle line:90% the meaning of these words. 00:10:12.320 --> 00:10:17.040 align:middle line:84% Tokenized financial assets on the distributed ledger 00:10:17.040 --> 00:10:19.120 align:middle line:90% technology-- 00:10:19.120 --> 00:10:25.440 align:middle line:84% to anticipate a bit, that's kind of a loaded sentence. 00:10:25.440 --> 00:10:30.840 align:middle line:84% You could have assets that are native to the blockchain that 00:10:30.840 --> 00:10:35.360 align:middle line:84% originate as part of a smart contract, 00:10:35.360 --> 00:10:42.920 align:middle line:84% or you can have preexisting assets which are escrowed, 00:10:42.920 --> 00:10:45.200 align:middle line:84% and then they have a representation 00:10:45.200 --> 00:10:47.540 align:middle line:90% in the code on the blockchain. 00:10:47.540 --> 00:10:50.120 align:middle line:84% So the word "tokenize" could be-- 00:10:50.120 --> 00:10:52.840 align:middle line:84% depending on how the speaker is using it, 00:10:52.840 --> 00:10:55.920 align:middle line:84% he could mean one or the other of these things, 00:10:55.920 --> 00:10:58.020 align:middle line:84% and I'll come back to that later. 00:10:58.020 --> 00:10:59.900 align:middle line:84% The key thing is the programmability 00:10:59.900 --> 00:11:04.300 align:middle line:84% of the assets, as in the smart contract and Ethereum, 00:11:04.300 --> 00:11:10.620 align:middle line:84% enables traders to commit to settlement because you're 00:11:10.620 --> 00:11:12.220 align:middle line:90% locked in. 00:11:12.220 --> 00:11:15.900 align:middle line:84% Once you enter into the contract, that's it. 00:11:15.900 --> 00:11:18.760 align:middle line:84% The code is going to do its thing as written. 00:11:18.760 --> 00:11:21.900 align:middle line:90% 00:11:21.900 --> 00:11:27.060 align:middle line:84% So you commit to, quote, "settlement" 00:11:27.060 --> 00:11:30.420 align:middle line:84% at the time you enter into the contract. 00:11:30.420 --> 00:11:32.980 align:middle line:84% And that's the sense in which trade and settlement 00:11:32.980 --> 00:11:35.900 align:middle line:90% are collapsed. 00:11:35.900 --> 00:11:39.940 align:middle line:84% Now, let me just say, even then, it's a little bit confusing. 00:11:39.940 --> 00:11:43.360 align:middle line:84% Because in the previous lectures, 00:11:43.360 --> 00:11:46.690 align:middle line:84% we've been talking about real time, 00:11:46.690 --> 00:11:49.690 align:middle line:84% and who has what goods at which point in time, 00:11:49.690 --> 00:11:52.570 align:middle line:84% and potentially even at different locations. 00:11:52.570 --> 00:11:56.850 align:middle line:84% So they're agreeing to who is going to have the asset 00:11:56.850 --> 00:11:58.530 align:middle line:90% and at what date. 00:11:58.530 --> 00:12:02.970 align:middle line:84% But those transfers, quote, "temporary ownership 00:12:02.970 --> 00:12:07.610 align:middle line:84% of the asset" is executed under the smart contract. 00:12:07.610 --> 00:12:11.170 align:middle line:84% So it doesn't mean that the assets are actually 00:12:11.170 --> 00:12:15.510 align:middle line:84% transferred when we talk about collapsing trade and settlement. 00:12:15.510 --> 00:12:17.890 align:middle line:84% It means there's no more uncertainty 00:12:17.890 --> 00:12:20.050 align:middle line:90% about what's going to happen. 00:12:20.050 --> 00:12:25.690 align:middle line:84% The settlement part is all preordained in the code. 00:12:25.690 --> 00:12:30.850 align:middle line:84% And so this has the potential of eradicating trade fails. 00:12:30.850 --> 00:12:32.610 align:middle line:90% So here's the example. 00:12:32.610 --> 00:12:36.170 align:middle line:84% There are three risk-neutral traders, agents 00:12:36.170 --> 00:12:41.290 align:middle line:84% A, B, and C. There's one single long-lived asset, 00:12:41.290 --> 00:12:44.650 align:middle line:84% and it's owned initially by agent A. 00:12:44.650 --> 00:12:47.790 align:middle line:84% And the traders have period-dependent payoffs 00:12:47.790 --> 00:12:50.030 align:middle line:90% on holding the asset. 00:12:50.030 --> 00:12:53.710 align:middle line:84% So this is like asset borrowing and lending. 00:12:53.710 --> 00:12:55.110 align:middle line:90% There's also another good. 00:12:55.110 --> 00:12:59.110 align:middle line:84% You've got to pay to have temporary ownership 00:12:59.110 --> 00:13:00.050 align:middle line:90% of the asset. 00:13:00.050 --> 00:13:05.150 align:middle line:84% So there's an underlying monetary asset. 00:13:05.150 --> 00:13:08.150 align:middle line:84% When we talk about prices of contracts, 00:13:08.150 --> 00:13:12.710 align:middle line:84% we're talking about the agreement as to who 00:13:12.710 --> 00:13:15.350 align:middle line:84% is going to hold the asset, but also the amount 00:13:15.350 --> 00:13:20.690 align:middle line:90% that you pay at the time. 00:13:20.690 --> 00:13:22.870 align:middle line:84% But the contract will specify the amount 00:13:22.870 --> 00:13:26.230 align:middle line:90% of the payment in advance. 00:13:26.230 --> 00:13:29.630 align:middle line:84% So we're going to distinguish trading stages 00:13:29.630 --> 00:13:35.390 align:middle line:84% from settlement stages or asset transfer stages. 00:13:35.390 --> 00:13:41.790 align:middle line:84% So the T equal M1 or M2, this is all initial trading stages. 00:13:41.790 --> 00:13:44.490 align:middle line:84% And again, we're going to partition this. 00:13:44.490 --> 00:13:49.170 align:middle line:84% So they're not all together agreeing to everything. 00:13:49.170 --> 00:13:52.170 align:middle line:84% Trader B is going to be the intermediary. 00:13:52.170 --> 00:13:56.170 align:middle line:84% So there's two sequential bilateral meetings 00:13:56.170 --> 00:13:58.650 align:middle line:84% that can happen in this trading stage. 00:13:58.650 --> 00:14:00.410 align:middle line:84% And in the settlement stage, that's 00:14:00.410 --> 00:14:03.730 align:middle line:84% when the asset is transferred between the traders 00:14:03.730 --> 00:14:07.970 align:middle line:84% according to what they have agreed to in the trading stage, 00:14:07.970 --> 00:14:10.410 align:middle line:90% unless there are fails. 00:14:10.410 --> 00:14:16.410 align:middle line:84% So in the trading stage, M1 and M2, A meets B, 00:14:16.410 --> 00:14:20.350 align:middle line:84% and B meets C. B is the intermediary, the broker, 00:14:20.350 --> 00:14:21.570 align:middle line:90% you might say-- 00:14:21.570 --> 00:14:22.810 align:middle line:90% B for broker. 00:14:22.810 --> 00:14:26.850 align:middle line:84% And to make it interesting, the order of these meetings 00:14:26.850 --> 00:14:28.130 align:middle line:90% is random. 00:14:28.130 --> 00:14:32.610 align:middle line:84% It could be 50/50 in terms of who's meeting with B first. 00:14:32.610 --> 00:14:37.810 align:middle line:84% And that's only known to B. So A and C never meet. 00:14:37.810 --> 00:14:43.200 align:middle line:84% All the pairwise meetings are with B. And so B is the, quote, 00:14:43.200 --> 00:14:47.400 align:middle line:90% "intermediary" between A and C. 00:14:47.400 --> 00:14:51.320 align:middle line:84% So up to two trades can successfully 00:14:51.320 --> 00:14:54.600 align:middle line:84% occur in principle in the trading stage, 00:14:54.600 --> 00:14:58.640 align:middle line:84% the transfer of the asset from A to B, 00:14:58.640 --> 00:15:04.000 align:middle line:84% and the transfer of the asset from B to C in some way. 00:15:04.000 --> 00:15:08.680 align:middle line:84% Those asset transfers and the corresponding monetary payment 00:15:08.680 --> 00:15:11.360 align:middle line:84% is happening in the dates 1, 2, and 3. 00:15:11.360 --> 00:15:19.240 align:middle line:84% So for example, if B borrows the asset from A in period 1, 00:15:19.240 --> 00:15:22.320 align:middle line:84% and B agrees to pay a price, P, that 00:15:22.320 --> 00:15:25.480 align:middle line:84% means that A transfers the asset to B 00:15:25.480 --> 00:15:31.040 align:middle line:84% at the beginning of period 1, and B transfers the asset back 00:15:31.040 --> 00:15:35.960 align:middle line:84% to A, in this case, at the end of date 3. 00:15:35.960 --> 00:15:38.240 align:middle line:84% The intermediate date, 2, has to do 00:15:38.240 --> 00:15:43.540 align:middle line:84% with what C is or isn't doing in the process. 00:15:43.540 --> 00:15:48.460 align:middle line:84% So in the token system this bargaining over prices and asset 00:15:48.460 --> 00:15:51.660 align:middle line:84% transfers and the programming that backs it up 00:15:51.660 --> 00:15:56.540 align:middle line:84% is occurring simultaneously as if immediately settled. 00:15:56.540 --> 00:15:59.940 align:middle line:84% So the asset's programmed during the meetings of this trading 00:15:59.940 --> 00:16:04.860 align:middle line:84% stage, and the transfer instructions are self-executing. 00:16:04.860 --> 00:16:09.020 align:middle line:84% Assets are transferred without any further trade or action. 00:16:09.020 --> 00:16:12.500 align:middle line:84% And no trader is able to prevent the program transfer 00:16:12.500 --> 00:16:14.380 align:middle line:90% from occurring. 00:16:14.380 --> 00:16:18.820 align:middle line:84% And we're going to begin taking the point of view of this paper, 00:16:18.820 --> 00:16:21.260 align:middle line:84% that this requires the trader to be 00:16:21.260 --> 00:16:24.660 align:middle line:84% the current holder of the asset at the time 00:16:24.660 --> 00:16:28.040 align:middle line:84% that the contract specifies that it's going to be transferred. 00:16:28.040 --> 00:16:31.560 align:middle line:84% That doesn't mean you have to own the asset initially. 00:16:31.560 --> 00:16:33.680 align:middle line:84% You could contract to get the asset. 00:16:33.680 --> 00:16:39.140 align:middle line:84% B can contract to get the asset from A. 00:16:39.140 --> 00:16:43.050 align:middle line:84% Then B has the ability in this trading period 00:16:43.050 --> 00:16:49.450 align:middle line:84% to make contracts with C. Both parties know this condition, 00:16:49.450 --> 00:16:54.550 align:middle line:84% that A must own the asset to lend the asset onwards, 00:16:54.550 --> 00:16:57.330 align:middle line:90% and B knows that, too. 00:16:57.330 --> 00:17:01.010 align:middle line:90% So here's the timeline. 00:17:01.010 --> 00:17:06.530 align:middle line:84% In principle, I should have had some initial date, zero, 00:17:06.530 --> 00:17:08.650 align:middle line:90% where A holds the asset. 00:17:08.650 --> 00:17:11.010 align:middle line:84% A is the original holder of the asset. 00:17:11.010 --> 00:17:14.510 align:middle line:84% But then over time in dates 1, 2, 00:17:14.510 --> 00:17:24.210 align:middle line:84% and 3, the value of holding the asset is high, medium, or low 00:17:24.210 --> 00:17:27.930 align:middle line:90% or something else in between. 00:17:27.930 --> 00:17:31.050 align:middle line:90% So A no longer really wants-- 00:17:31.050 --> 00:17:34.050 align:middle line:84% A could hold it but gets a low return 00:17:34.050 --> 00:17:36.250 align:middle line:90% from continuing to hold it. 00:17:36.250 --> 00:17:41.990 align:middle line:84% B has a high value for it at date 1. 00:17:41.990 --> 00:17:46.550 align:middle line:84% And C has a high value for it at date 2. 00:17:46.550 --> 00:17:53.850 align:middle line:84% And then, in principle, A wants it back at date 3. 00:17:53.850 --> 00:18:00.150 align:middle line:84% So it's a temporary lending of the asset. 00:18:00.150 --> 00:18:03.910 align:middle line:84% However, there are these other things that are happening. 00:18:03.910 --> 00:18:09.990 align:middle line:84% The value that B places for the asset at date 2 is random. 00:18:09.990 --> 00:18:14.510 align:middle line:84% And it could be medium with a certain probability lambda 00:18:14.510 --> 00:18:17.350 align:middle line:90% sub B or 0 otherwise. 00:18:17.350 --> 00:18:22.590 align:middle line:84% And likewise, the value that C places on the asset at date 3 00:18:22.590 --> 00:18:28.630 align:middle line:84% could be high with a certain probability, but 0 otherwise. 00:18:28.630 --> 00:18:33.550 align:middle line:84% And these random variables, m tilde and h tilde, 00:18:33.550 --> 00:18:35.250 align:middle line:90% are not known initially. 00:18:35.250 --> 00:18:42.770 align:middle line:84% They're random variables that get realized at dates 2 and 3, 00:18:42.770 --> 00:18:45.970 align:middle line:84% and they're private to the agents. 00:18:45.970 --> 00:18:50.890 align:middle line:84% So the target here, given the parameters, 00:18:50.890 --> 00:18:56.210 align:middle line:84% is to have B acquire the asset from A, 00:18:56.210 --> 00:18:59.690 align:middle line:84% hold it with high utility at date 1. 00:18:59.690 --> 00:19:05.010 align:middle line:84% Pass the asset to C, who holds it at date 2. 00:19:05.010 --> 00:19:08.250 align:middle line:84% And then now watch yourself here because it's 00:19:08.250 --> 00:19:10.690 align:middle line:90% a bilateral agreement. 00:19:10.690 --> 00:19:19.484 align:middle line:84% The agreement between A and B means that the asset 00:19:19.484 --> 00:19:24.010 align:middle line:90% has to go back to that-- 00:19:24.010 --> 00:19:25.070 align:middle line:90% let me start over. 00:19:25.070 --> 00:19:31.450 align:middle line:84% C and B have this contract between dates 2 and 3. 00:19:31.450 --> 00:19:34.170 align:middle line:84% And C, if things go, quote, "well," 00:19:34.170 --> 00:19:39.000 align:middle line:84% would pass the asset back to B And then B is executing 00:19:39.000 --> 00:19:42.340 align:middle line:84% the final leg of its contract at date 3, 00:19:42.340 --> 00:19:46.840 align:middle line:84% passing it back to A. So the asset is respecting 00:19:46.840 --> 00:19:51.520 align:middle line:84% the bilateral contracts that they have entered into. 00:19:51.520 --> 00:19:54.880 align:middle line:84% So this is the underlying environment. 00:19:54.880 --> 00:19:57.560 align:middle line:84% And then we're going to consider legacy systems that 00:19:57.560 --> 00:20:02.760 align:middle line:84% allow trade fails and compare that to the token system. 00:20:02.760 --> 00:20:06.680 align:middle line:84% So I'll show you how the current financial system operates. 00:20:06.680 --> 00:20:09.240 align:middle line:84% We'll talk about the magnitude of these trade fails, 00:20:09.240 --> 00:20:13.120 align:middle line:90% including cascades of fails. 00:20:13.120 --> 00:20:17.120 align:middle line:84% So in the same underlying economic environment, 00:20:17.120 --> 00:20:21.960 align:middle line:84% we can think about settlement in the legacy system. 00:20:21.960 --> 00:20:26.600 align:middle line:84% So these traders have entered into the contracts, 00:20:26.600 --> 00:20:31.220 align:middle line:84% in this case, the contract between A and B dates 1 and 3, 00:20:31.220 --> 00:20:36.460 align:middle line:84% and the contract between B and C, dates 2 and 3. 00:20:36.460 --> 00:20:39.860 align:middle line:84% At date 3, that h tilde is realized 00:20:39.860 --> 00:20:46.480 align:middle line:84% for C. And C can decide whether or not to return the asset to B. 00:20:46.480 --> 00:20:51.900 align:middle line:84% Remember, there is this trade agreement between B 00:20:51.900 --> 00:20:56.380 align:middle line:84% and C. And C could fail on it, because it 00:20:56.380 --> 00:21:02.380 align:middle line:84% has a high value for the asset, and refuse to return it to B. 00:21:02.380 --> 00:21:04.660 align:middle line:84% And at date 2, for that matter, when 00:21:04.660 --> 00:21:10.460 align:middle line:84% m tilde, which could be medium or 0, is realized, 00:21:10.460 --> 00:21:16.500 align:middle line:84% B is the one deciding whether or not to transfer the asset to C. 00:21:16.500 --> 00:21:21.580 align:middle line:84% So let me concentrate first on this, the legacy 00:21:21.580 --> 00:21:23.380 align:middle line:90% system in the environment. 00:21:23.380 --> 00:21:27.340 align:middle line:84% There's two contracts here between A and B 00:21:27.340 --> 00:21:33.660 align:middle line:84% spanning dates 1 and 3, and B and C spanning dates 2 and 3. 00:21:33.660 --> 00:21:38.690 align:middle line:84% If things go along the no failure path, 00:21:38.690 --> 00:21:41.390 align:middle line:84% then B here will make a deal with A 00:21:41.390 --> 00:21:44.050 align:middle line:90% and settle it in real time. 00:21:44.050 --> 00:21:46.630 align:middle line:90% And then B has the asset. 00:21:46.630 --> 00:21:50.850 align:middle line:84% B will settle with C in real time and pass the asset. 00:21:50.850 --> 00:21:55.570 align:middle line:84% And then C will settle back with B, 00:21:55.570 --> 00:22:00.490 align:middle line:84% so that B can fulfill the final leg of the trade with A. 00:22:00.490 --> 00:22:05.310 align:middle line:84% But working in reverse, C could settle with B, 00:22:05.310 --> 00:22:09.970 align:middle line:84% but C could fail on the contract and not pass the asset back 00:22:09.970 --> 00:22:13.610 align:middle line:84% to B. So that would be a failure on that branch. 00:22:13.610 --> 00:22:19.390 align:middle line:84% Even if B had settled with C initially to pass the asset, 00:22:19.390 --> 00:22:20.770 align:middle line:90% it doesn't. 00:22:20.770 --> 00:22:24.050 align:middle line:90% It fails to return it. 00:22:24.050 --> 00:22:30.170 align:middle line:84% Or B could fail on its contract with C, 00:22:30.170 --> 00:22:33.630 align:middle line:84% then doesn't give C the asset all along 00:22:33.630 --> 00:22:35.950 align:middle line:90% that they had agreed to. 00:22:35.950 --> 00:22:41.750 align:middle line:84% Or back here, B can fail to execute the agreement that it's 00:22:41.750 --> 00:22:45.670 align:middle line:84% made with A, in which case, of course, 00:22:45.670 --> 00:22:49.350 align:middle line:84% the asset's not going to get transferred to C. 00:22:49.350 --> 00:22:51.890 align:middle line:84% And so both of these contracts are failing. 00:22:51.890 --> 00:22:56.750 align:middle line:84% So this is like a cascade of failures. 00:22:56.750 --> 00:22:58.710 align:middle line:84% This is a bit redundant, but it's 00:22:58.710 --> 00:23:02.150 align:middle line:84% kind of useful, which is just to consider 00:23:02.150 --> 00:23:05.750 align:middle line:84% in isolation the contract between A and B 00:23:05.750 --> 00:23:08.790 align:middle line:84% as if there were no contract with C. 00:23:08.790 --> 00:23:12.230 align:middle line:84% And this is something that wouldn't happen 00:23:12.230 --> 00:23:14.210 align:middle line:90% in the equilibrium necessarily. 00:23:14.210 --> 00:23:18.230 align:middle line:84% But this is a two-period contract between A and B 00:23:18.230 --> 00:23:20.310 align:middle line:84% So C is just out of it, and A and B 00:23:20.310 --> 00:23:23.850 align:middle line:84% agree to do something under that contract. 00:23:23.850 --> 00:23:27.030 align:middle line:90% 00:23:27.030 --> 00:23:30.190 align:middle line:90% So there's a lot going on here. 00:23:30.190 --> 00:23:34.730 align:middle line:84% The main thing to take away is the possibility of failures 00:23:34.730 --> 00:23:37.090 align:middle line:90% because it's the legacy system-- 00:23:37.090 --> 00:23:40.930 align:middle line:84% failures to acquire the asset and pay money for it, 00:23:40.930 --> 00:23:46.010 align:middle line:84% failures to return the asset under the contract. 00:23:46.010 --> 00:23:50.010 align:middle line:84% And it's a dynamic program, so you 00:23:50.010 --> 00:23:53.410 align:middle line:84% have to be both forward-looking in the sense of anticipating 00:23:53.410 --> 00:24:01.290 align:middle line:84% what could happen and assess where you are 00:24:01.290 --> 00:24:05.090 align:middle line:84% in the current timeline relative to your expectations 00:24:05.090 --> 00:24:07.730 align:middle line:90% about the future. 00:24:07.730 --> 00:24:10.630 align:middle line:84% Do we see trade fails in practice? 00:24:10.630 --> 00:24:12.610 align:middle line:90% Yes, absolutely. 00:24:12.610 --> 00:24:14.050 align:middle line:84% The slides are going to highlight 00:24:14.050 --> 00:24:18.170 align:middle line:84% what happened in the great financial crisis with failures. 00:24:18.170 --> 00:24:25.450 align:middle line:84% The settlement fails basically were $400 billion in one day. 00:24:25.450 --> 00:24:27.930 align:middle line:84% This is a trillion dollar market. 00:24:27.930 --> 00:24:30.640 align:middle line:84% People are aware of the failures. 00:24:30.640 --> 00:24:35.720 align:middle line:84% The Fed tried to introduce a charge for failing, 00:24:35.720 --> 00:24:37.540 align:middle line:90% an additional price to be paid. 00:24:37.540 --> 00:24:40.960 align:middle line:84% But the settlement, the failures, continue to occur. 00:24:40.960 --> 00:24:44.180 align:middle line:84% It's not just around the great financial crisis, 00:24:44.180 --> 00:24:48.720 align:middle line:84% although the diagram coming in a minute is going to feature that. 00:24:48.720 --> 00:24:52.040 align:middle line:84% It's an institution and technological failure 00:24:52.040 --> 00:24:55.760 align:middle line:90% of our current legacy systems. 00:24:55.760 --> 00:24:58.440 align:middle line:84% Individual traders submit instructions 00:24:58.440 --> 00:25:01.400 align:middle line:90% to their corresponding bank. 00:25:01.400 --> 00:25:04.040 align:middle line:84% These instructions have to do with the trades 00:25:04.040 --> 00:25:10.120 align:middle line:84% that they've entered into to say to buy securities or sell them. 00:25:10.120 --> 00:25:12.600 align:middle line:84% And then it comes time to execute 00:25:12.600 --> 00:25:16.360 align:middle line:84% the contracts, even just at the end of the day, 00:25:16.360 --> 00:25:19.680 align:middle line:90% and situations have changed. 00:25:19.680 --> 00:25:22.160 align:middle line:84% Incentives to settle may have broken down, 00:25:22.160 --> 00:25:25.600 align:middle line:90% and the trade fails. 00:25:25.600 --> 00:25:33.260 align:middle line:84% So here's a picture of the fails in the great financial crisis, 00:25:33.260 --> 00:25:40.660 align:middle line:84% reaching almost a trillion-- $10,000, $500 billion. 00:25:40.660 --> 00:25:43.440 align:middle line:84% And when this slide was created many years ago, 00:25:43.440 --> 00:25:48.580 align:middle line:84% the Fed was saying that the increase in liquidity 00:25:48.580 --> 00:25:55.780 align:middle line:84% in the system actually helped mitigate subsequent trade fails. 00:25:55.780 --> 00:25:57.900 align:middle line:84% But I really ought to update this diagram 00:25:57.900 --> 00:26:03.900 align:middle line:84% and show you that trade fails have continued in the US. 00:26:03.900 --> 00:26:07.460 align:middle line:84% So "why", quote, do these things fail? 00:26:07.460 --> 00:26:10.460 align:middle line:84% In a little more detail from Garbade, 00:26:10.460 --> 00:26:12.460 align:middle line:84% there's miscommunication possible. 00:26:12.460 --> 00:26:15.260 align:middle line:84% A buyer and a seller may not have a common understanding 00:26:15.260 --> 00:26:17.500 align:middle line:84% of the trade they thought they entered into, 00:26:17.500 --> 00:26:24.420 align:middle line:84% or they may fail to communicate well with their custodian, 00:26:24.420 --> 00:26:28.200 align:middle line:84% or they communicated incorrectly with their custodian. 00:26:28.200 --> 00:26:31.460 align:middle line:84% So another reason for failure is system failure, 00:26:31.460 --> 00:26:36.080 align:middle line:84% as in 1985 with the Bank of New York or 9/11. 00:26:36.080 --> 00:26:40.280 align:middle line:84% There was an initial surge of failures, massive disruption. 00:26:40.280 --> 00:26:44.240 align:middle line:84% But it didn't go away even several days 00:26:44.240 --> 00:26:47.440 align:middle line:84% subsequently because there were insufficient incentives 00:26:47.440 --> 00:26:49.520 align:middle line:90% to resolve the fails. 00:26:49.520 --> 00:26:53.000 align:middle line:84% Again, the seller may not have the requisite securities 00:26:53.000 --> 00:26:56.120 align:middle line:90% in its commercial bank account. 00:26:56.120 --> 00:26:58.280 align:middle line:84% But that's OK, as long as they're 00:26:58.280 --> 00:27:02.240 align:middle line:84% able to acquire the securities by borrowing in order 00:27:02.240 --> 00:27:03.680 align:middle line:90% to deliver them. 00:27:03.680 --> 00:27:06.580 align:middle line:84% With cascading failures, you have 00:27:06.580 --> 00:27:09.840 align:middle line:84% a-- it says sellers, but should be buyer. 00:27:09.840 --> 00:27:12.080 align:middle line:84% Buyer's failure to pay the money leads 00:27:12.080 --> 00:27:14.060 align:middle line:84% to lack of liquidity in the chain, 00:27:14.060 --> 00:27:16.240 align:middle line:90% so the recipient would be-- 00:27:16.240 --> 00:27:19.020 align:middle line:84% recipient of the money doesn't have it in term, 00:27:19.020 --> 00:27:21.640 align:middle line:84% they can't execute other purchases 00:27:21.640 --> 00:27:24.560 align:middle line:90% that they were supposed to make. 00:27:24.560 --> 00:27:30.510 align:middle line:84% It's an odd typo because in Wall Street we, 00:27:30.510 --> 00:27:32.470 align:middle line:84% meaning me as an economist, I often 00:27:32.470 --> 00:27:35.310 align:middle line:84% think of borrowing and lending money 00:27:35.310 --> 00:27:37.810 align:middle line:90% with securities as collateral. 00:27:37.810 --> 00:27:42.110 align:middle line:84% But their language is borrowing and lending securities 00:27:42.110 --> 00:27:45.430 align:middle line:90% with money as collateral. 00:27:45.430 --> 00:27:49.150 align:middle line:90% It's all intertwined. 00:27:49.150 --> 00:27:51.830 align:middle line:84% AUDIENCE: What happens after these failures? 00:27:51.830 --> 00:27:54.490 align:middle line:84% So basically, if the settlement was not made, 00:27:54.490 --> 00:27:57.550 align:middle line:84% then just the other parties have a loss? 00:27:57.550 --> 00:27:59.050 align:middle line:84% ROBERT M. TOWNSEND: They can-- yeah. 00:27:59.050 --> 00:28:00.250 align:middle line:90% AUDIENCE: [INAUDIBLE]. 00:28:00.250 --> 00:28:01.750 align:middle line:84% ROBERT M. TOWNSEND: Well, they could 00:28:01.750 --> 00:28:03.370 align:middle line:90% try to adjudicate the deal. 00:28:03.370 --> 00:28:05.730 align:middle line:84% There are long-term relationships going on. 00:28:05.730 --> 00:28:08.450 align:middle line:90% So you say, OK. 00:28:08.450 --> 00:28:09.430 align:middle line:90% Maybe not. 00:28:09.430 --> 00:28:12.630 align:middle line:84% That maybe at a lower price, some exposed bargaining 00:28:12.630 --> 00:28:13.610 align:middle line:90% is going on. 00:28:13.610 --> 00:28:18.950 align:middle line:90% 00:28:18.950 --> 00:28:22.530 align:middle line:84% But the thing about incentives-- maybe that was a little vague. 00:28:22.530 --> 00:28:24.010 align:middle line:90% But I mentioned this before. 00:28:24.010 --> 00:28:29.010 align:middle line:84% And I always want to look at the State Street over there. 00:28:29.010 --> 00:28:32.190 align:middle line:84% So State Street is one of the largest, of course, 00:28:32.190 --> 00:28:35.130 align:middle line:90% bonded banks in the US. 00:28:35.130 --> 00:28:39.290 align:middle line:84% And they make trades for their clients. 00:28:39.290 --> 00:28:44.530 align:middle line:84% The clients are trading on the Stock Exchange and so on. 00:28:44.530 --> 00:28:49.970 align:middle line:84% And then at the, I think it's 3:00 in the afternoon, 00:28:49.970 --> 00:28:54.450 align:middle line:84% they begin to settle the trades, and it takes a couple of hours. 00:28:54.450 --> 00:28:57.870 align:middle line:84% But obviously, prices have moved during the day. 00:28:57.870 --> 00:29:01.930 align:middle line:84% So things that you agreed to do at 10:00 in the morning may no 00:29:01.930 --> 00:29:02.930 align:middle line:90% longer-- 00:29:02.930 --> 00:29:06.050 align:middle line:84% you may have regrets if you could have gotten a lower 00:29:06.050 --> 00:29:08.970 align:middle line:90% price and so on. 00:29:08.970 --> 00:29:16.610 align:middle line:84% So in principle, the programmed trade on the dynamic ledgers 00:29:16.610 --> 00:29:23.330 align:middle line:84% would not allow fails because you have to execute. 00:29:23.330 --> 00:29:29.800 align:middle line:84% But other problems can emerge, namely, holdup problems. 00:29:29.800 --> 00:29:32.680 align:middle line:84% It's related to the commitment problem. 00:29:32.680 --> 00:29:37.760 align:middle line:84% So B, say, has agreed to lend the asset to C at date 2, 00:29:37.760 --> 00:29:43.580 align:middle line:84% and B's valuation of the asset is high, but not at date 1, 00:29:43.580 --> 00:29:46.000 align:middle line:90% but not subsequently. 00:29:46.000 --> 00:29:48.720 align:middle line:90% Why is B acquiring the asset? 00:29:48.720 --> 00:29:56.360 align:middle line:84% B can acquire the asset because it likes holding it for date 1. 00:29:56.360 --> 00:30:01.000 align:middle line:84% But B is also anticipating, as a broker, 00:30:01.000 --> 00:30:04.920 align:middle line:84% that it can transfer the asset to C. 00:30:04.920 --> 00:30:08.860 align:middle line:84% And these meetings are happening asynchronously, 00:30:08.860 --> 00:30:11.160 align:middle line:90% not simultaneously. 00:30:11.160 --> 00:30:13.520 align:middle line:90% So B is like a market maker-- 00:30:13.520 --> 00:30:21.320 align:middle line:84% commits with A to one side of the chain in advance 00:30:21.320 --> 00:30:27.940 align:middle line:84% and anticipating its deal with C. 00:30:27.940 --> 00:30:32.780 align:middle line:84% In fact, B may pay more than its own underlying 00:30:32.780 --> 00:30:37.580 align:middle line:84% valuation of the asset in order to obtain the asset for C, 00:30:37.580 --> 00:30:41.260 align:middle line:84% and C being willing to pay a high price for it. 00:30:41.260 --> 00:30:45.720 align:middle line:84% Now, the problem is that if C knows that B has the asset, 00:30:45.720 --> 00:30:49.620 align:middle line:84% and so far this is what we're assuming that B can enter 00:30:49.620 --> 00:30:53.700 align:middle line:84% into that contract with C only because B has already entered 00:30:53.700 --> 00:30:56.500 align:middle line:84% into the contract with A and C knows 00:30:56.500 --> 00:31:03.980 align:middle line:84% that, then there is this problem that C could say, oh, I got you. 00:31:03.980 --> 00:31:06.660 align:middle line:90% You've already got the asset. 00:31:06.660 --> 00:31:09.020 align:middle line:84% You don't like it much, and I'm not 00:31:09.020 --> 00:31:11.580 align:middle line:84% going to pay you much for it, kind 00:31:11.580 --> 00:31:16.700 align:middle line:84% of pushing right down to the margin at that time. 00:31:16.700 --> 00:31:20.880 align:middle line:84% So the legacy system does have some advantages. 00:31:20.880 --> 00:31:24.260 align:middle line:84% There's a complete decoupling of trade and settlement. 00:31:24.260 --> 00:31:26.320 align:middle line:84% Traders can enter into any contract 00:31:26.320 --> 00:31:30.400 align:middle line:84% they want without explicit proof that they can fulfill it. 00:31:30.400 --> 00:31:33.040 align:middle line:84% And B, therefore, in the legacy system 00:31:33.040 --> 00:31:38.560 align:middle line:84% can hide from C whether or not he's met A. And hence, is 00:31:38.560 --> 00:31:42.520 align:middle line:84% or is not in control of the asset. 00:31:42.520 --> 00:31:47.040 align:middle line:84% So there is an interplay between trade and settlement here. 00:31:47.040 --> 00:31:49.600 align:middle line:90% Trading occurs asynchronously. 00:31:49.600 --> 00:31:51.400 align:middle line:84% But in the legacy system, there's 00:31:51.400 --> 00:31:55.320 align:middle line:84% no transparency over the history of previous trades. 00:31:55.320 --> 00:31:58.880 align:middle line:84% So taken in isolation, everything is opaque. 00:31:58.880 --> 00:32:04.080 align:middle line:84% Incentive-based settlement is potentially suboptimal, 00:32:04.080 --> 00:32:07.400 align:middle line:84% but they either settle or not what 00:32:07.400 --> 00:32:12.360 align:middle line:84% they've said they would do based on their underlying individual 00:32:12.360 --> 00:32:12.900 align:middle line:90% shock. 00:32:12.900 --> 00:32:17.380 align:middle line:84% So there's flexibility ex-post to do as they wish. 00:32:17.380 --> 00:32:21.750 align:middle line:84% So this decoupling of trade and settlement 00:32:21.750 --> 00:32:25.870 align:middle line:84% actually facilitates the transfer of ownership. 00:32:25.870 --> 00:32:28.910 align:middle line:84% Again, there's no longer a holdup problem 00:32:28.910 --> 00:32:33.630 align:middle line:84% because C doesn't know that B has the asset. 00:32:33.630 --> 00:32:37.430 align:middle line:84% B is entering into the agreement with C, 00:32:37.430 --> 00:32:40.870 align:middle line:84% but C has no way of knowing in the legacy system 00:32:40.870 --> 00:32:45.010 align:middle line:84% whether A and B have already met or not, 00:32:45.010 --> 00:32:47.910 align:middle line:84% that maybe C and B is the first meeting. 00:32:47.910 --> 00:32:51.270 align:middle line:84% And when C and B make this deal, then 00:32:51.270 --> 00:32:54.990 align:middle line:84% A will turn around and get the asset from B. Sorry, 00:32:54.990 --> 00:32:57.430 align:middle line:90% B will turn around. 00:32:57.430 --> 00:33:00.710 align:middle line:84% So there's an advantage in that way. 00:33:00.710 --> 00:33:07.570 align:middle line:84% So this diagram is revealing for parameter values. 00:33:07.570 --> 00:33:09.430 align:middle line:84% In particular, these probabilities 00:33:09.430 --> 00:33:15.430 align:middle line:84% of realizations of valuation, lambda B and lambda C. 00:33:15.430 --> 00:33:18.990 align:middle line:84% Doesn't matter much if you remember or not what they are. 00:33:18.990 --> 00:33:23.250 align:middle line:84% They're just unobserved random variables of valuation. 00:33:23.250 --> 00:33:27.650 align:middle line:84% This diagram maps out when the legacy system would dominate 00:33:27.650 --> 00:33:31.090 align:middle line:84% and when the token system would dominate. 00:33:31.090 --> 00:33:32.690 align:middle line:90% Both can happen. 00:33:32.690 --> 00:33:35.270 align:middle line:84% The token system can improve on efficiency, 00:33:35.270 --> 00:33:40.770 align:middle line:84% but only if that holdup problem goes away. 00:33:40.770 --> 00:33:42.930 align:middle line:90% And the commitment problem is-- 00:33:42.930 --> 00:33:47.352 align:middle line:84% the limited commitment problem is, indeed, a big problem. 00:33:47.352 --> 00:33:48.810 align:middle line:84% AUDIENCE: What's the interpretation 00:33:48.810 --> 00:33:51.210 align:middle line:90% of lambda being close to 1? 00:33:51.210 --> 00:33:55.610 align:middle line:84% It means what random variable becomes likelier to be high? 00:33:55.610 --> 00:33:58.983 align:middle line:90% Like M tilde or what is it? 00:33:58.983 --> 00:34:00.650 align:middle line:84% ROBERT M. TOWNSEND: So lambda-- what's-- 00:34:00.650 --> 00:34:02.490 align:middle line:84% AUDIENCE: That's that M tilde is high. 00:34:02.490 --> 00:34:03.010 align:middle line:90% ROBERT M. TOWNSEND: Yeah. 00:34:03.010 --> 00:34:03.650 align:middle line:90% AUDIENCE: OK. 00:34:03.650 --> 00:34:09.210 align:middle line:84% So if both agree that the asset's going to be high value, 00:34:09.210 --> 00:34:11.850 align:middle line:90% commitment has positive value. 00:34:11.850 --> 00:34:13.708 align:middle line:90% Otherwise, it has none. 00:34:13.708 --> 00:34:14.750 align:middle line:90% ROBERT M. TOWNSEND: Good. 00:34:14.750 --> 00:34:16.130 align:middle line:90% AUDIENCE: Thank you, sir. 00:34:16.130 --> 00:34:17.330 align:middle line:90% ROBERT M. TOWNSEND: OK. 00:34:17.330 --> 00:34:20.100 align:middle line:84% So if one system doesn't dominate the other, 00:34:20.100 --> 00:34:22.239 align:middle line:90% are there solutions? 00:34:22.239 --> 00:34:25.080 align:middle line:84% One solution is direct centralized trading, 00:34:25.080 --> 00:34:27.520 align:middle line:84% and the second has to do with encryption. 00:34:27.520 --> 00:34:32.639 align:middle line:84% So what we featured so far is this intermediated broker-dealer 00:34:32.639 --> 00:34:34.040 align:middle line:90% trading. 00:34:34.040 --> 00:34:40.719 align:middle line:84% But we ran into this problem of asynchronicity and information. 00:34:40.719 --> 00:34:44.679 align:middle line:84% If we combine trade and settlement together and think 00:34:44.679 --> 00:34:47.340 align:middle line:84% about the design of the financial system, 00:34:47.340 --> 00:34:52.040 align:middle line:84% we could jump to the idea of having direct trading. 00:34:52.040 --> 00:34:54.960 align:middle line:84% In effect, having the buyer and seller 00:34:54.960 --> 00:34:57.320 align:middle line:84% be directly matched with each other 00:34:57.320 --> 00:35:00.040 align:middle line:84% if they can come to an agreement rather 00:35:00.040 --> 00:35:02.720 align:middle line:90% than having to go through B. 00:35:02.720 --> 00:35:07.000 align:middle line:84% So in the same notation, but with this alternative trading 00:35:07.000 --> 00:35:12.680 align:middle line:84% arrangement, at the initial trading date, t equal m1, 00:35:12.680 --> 00:35:17.000 align:middle line:84% B and C simultaneously post ultimatum offers 00:35:17.000 --> 00:35:21.060 align:middle line:84% for ownership of the asset at dates 1 and 2, respectively. 00:35:21.060 --> 00:35:24.820 align:middle line:84% And at the second date, trading date, 00:35:24.820 --> 00:35:28.320 align:middle line:84% A chooses whether or not to accept the offers. 00:35:28.320 --> 00:35:33.340 align:middle line:84% So again, probably worthwhile to go back. 00:35:33.340 --> 00:35:38.660 align:middle line:84% So B wants the asset, say, at date one. 00:35:38.660 --> 00:35:44.820 align:middle line:84% Makes a new deal with A. And then likewise, A over here 00:35:44.820 --> 00:35:51.860 align:middle line:84% can make a deal with C for C to have the asset at date 2. 00:35:51.860 --> 00:35:54.540 align:middle line:90% And it doesn't go through B-- 00:35:54.540 --> 00:35:58.900 align:middle line:84% two bilateral arrangements that A 00:35:58.900 --> 00:36:02.780 align:middle line:84% is making with B and C, which does respect 00:36:02.780 --> 00:36:04.740 align:middle line:84% this timeline in terms of if they 00:36:04.740 --> 00:36:08.420 align:middle line:84% come to a deal, who is holding the asset for what dates. 00:36:08.420 --> 00:36:11.540 align:middle line:84% But we're going to call it direct trading. 00:36:11.540 --> 00:36:14.740 align:middle line:84% And just for the sake of argument, 00:36:14.740 --> 00:36:18.460 align:middle line:84% we could imagine that there's some cost for direct trading. 00:36:18.460 --> 00:36:21.300 align:middle line:84% But certainly, if you set that cost to 0, 00:36:21.300 --> 00:36:23.640 align:middle line:90% direct trading dominates. 00:36:23.640 --> 00:36:25.620 align:middle line:84% There's no holdup problem anymore. 00:36:25.620 --> 00:36:28.920 align:middle line:84% You have all the advantages of full commitment 00:36:28.920 --> 00:36:32.120 align:middle line:84% to the agreement you've entered into. 00:36:32.120 --> 00:36:36.120 align:middle line:84% So now maybe the hype surrounding 00:36:36.120 --> 00:36:39.840 align:middle line:84% tokenization and programmed asset trades 00:36:39.840 --> 00:36:44.160 align:middle line:84% is coming into its own in the direct trading 00:36:44.160 --> 00:36:50.320 align:middle line:84% system, more centralized, in some sense, 00:36:50.320 --> 00:36:53.080 align:middle line:90% in the sense of making bids. 00:36:53.080 --> 00:36:58.840 align:middle line:84% But let's come back to tokenization again and think 00:36:58.840 --> 00:37:03.920 align:middle line:84% about fungible and nonfungible tokens on Ethereum Virtual 00:37:03.920 --> 00:37:04.700 align:middle line:90% Machine. 00:37:04.700 --> 00:37:07.760 align:middle line:90% 00:37:07.760 --> 00:37:13.000 align:middle line:84% And then finally, I'll come back to this tokenization 00:37:13.000 --> 00:37:15.470 align:middle line:90% with pre-existing assets. 00:37:15.470 --> 00:37:22.470 align:middle line:84% So what is ERC, Ethereum Request for Comment? 00:37:22.470 --> 00:37:29.030 align:middle line:84% So this was a standard that got created in Ethereum 00:37:29.030 --> 00:37:32.030 align:middle line:84% for fungible tokens created, again, 00:37:32.030 --> 00:37:33.890 align:middle line:90% on the Ethereum blockchain. 00:37:33.890 --> 00:37:37.990 align:middle line:84% A fungible token is one that's exchangeable with another token. 00:37:37.990 --> 00:37:41.390 align:middle line:84% Whereas, other standards ERC-721, 00:37:41.390 --> 00:37:44.050 align:middle line:90% pertains to nonfungible tokens. 00:37:44.050 --> 00:37:48.330 align:middle line:84% Data, for example, is not a fungible token, 00:37:48.330 --> 00:37:51.430 align:middle line:84% but it's part of the Ethereum contract. 00:37:51.430 --> 00:37:53.790 align:middle line:84% So this ERC-20 standards allow you 00:37:53.790 --> 00:37:56.750 align:middle line:84% to create smart contract enabled tokens 00:37:56.750 --> 00:38:00.550 align:middle line:84% that can be used with various products and services. 00:38:00.550 --> 00:38:03.410 align:middle line:84% They are a representation of the asset. 00:38:03.410 --> 00:38:05.870 align:middle line:84% The right ownership access could be 00:38:05.870 --> 00:38:09.590 align:middle line:84% cryptocurrency or anything else that can potentially 00:38:09.590 --> 00:38:11.270 align:middle line:90% be transferred. 00:38:11.270 --> 00:38:16.490 align:middle line:84% The additional capabilities under the ERC-20 standard 00:38:16.490 --> 00:38:21.570 align:middle line:84% has to do with this approve and transfer function. 00:38:21.570 --> 00:38:27.090 align:middle line:84% Let's suppose asset A is on this Ethereum blockchain as a token, 00:38:27.090 --> 00:38:29.530 align:middle line:84% and A is the initial owner of it. 00:38:29.530 --> 00:38:33.250 align:middle line:84% And then with Nicholas Zhang, we return 00:38:33.250 --> 00:38:37.330 align:middle line:84% to the Lee Martin Townsend paper I was just expositing. 00:38:37.330 --> 00:38:41.010 align:middle line:84% A owns the asset initially, in the sense 00:38:41.010 --> 00:38:47.450 align:middle line:84% that it's a smart contract node on the Ethereum ledger. 00:38:47.450 --> 00:38:57.490 align:middle line:84% This is not, quote, "owned by A as a participant," 00:38:57.490 --> 00:39:00.970 align:middle line:84% in the sense of the legacy system of carrying it around 00:39:00.970 --> 00:39:03.330 align:middle line:90% and deciding what to do with it. 00:39:03.330 --> 00:39:08.650 align:middle line:84% It's entirely represented by the code. 00:39:08.650 --> 00:39:11.030 align:middle line:84% And at the moment, A is the owner of it. 00:39:11.030 --> 00:39:14.480 align:middle line:90% 00:39:14.480 --> 00:39:18.800 align:middle line:84% So my emphasis now on the fact that it's a smart contract 00:39:18.800 --> 00:39:21.500 align:middle line:84% has to do with it's a proven transfer function. 00:39:21.500 --> 00:39:23.280 align:middle line:84% And, in particular, when A and B meet, 00:39:23.280 --> 00:39:27.680 align:middle line:84% and they do say meet first, they can 00:39:27.680 --> 00:39:33.120 align:middle line:84% agree on the conditions for B to potentially sell the asset to C 00:39:33.120 --> 00:39:34.540 align:middle line:90% at a later stage. 00:39:34.540 --> 00:39:37.520 align:middle line:90% 00:39:37.520 --> 00:39:40.520 align:middle line:84% But B doesn't want to commit to it. 00:39:40.520 --> 00:39:41.320 align:middle line:90% Why? 00:39:41.320 --> 00:39:43.180 align:middle line:90% Because of that holdup problem. 00:39:43.180 --> 00:39:47.200 align:middle line:90% 00:39:47.200 --> 00:39:54.760 align:middle line:84% B has the right to sell it to C and take it from A, effectively. 00:39:54.760 --> 00:40:00.080 align:middle line:84% So A approves B to transfer one unit of the asset 00:40:00.080 --> 00:40:03.400 align:middle line:90% when B chooses to do so. 00:40:03.400 --> 00:40:07.840 align:middle line:84% But B, of course, could say, I don't choose to do it. 00:40:07.840 --> 00:40:11.580 align:middle line:84% So when B and C meet later, if they reach a deal, 00:40:11.580 --> 00:40:15.380 align:middle line:84% B can acquire the asset to A and then pass it to C 00:40:15.380 --> 00:40:19.500 align:middle line:84% But if they don't reach a deal, if B and C don't reach a deal, 00:40:19.500 --> 00:40:21.700 align:middle line:84% the contract says, OK, we're just 00:40:21.700 --> 00:40:24.900 align:middle line:84% leaving the asset in A's account, and we do nothing. 00:40:24.900 --> 00:40:27.240 align:middle line:84% And A can revoke the approval later, 00:40:27.240 --> 00:40:32.420 align:middle line:84% or there could be a timer that the contract will expire. 00:40:32.420 --> 00:40:35.300 align:middle line:90% There are many options. 00:40:35.300 --> 00:40:39.380 align:middle line:84% So this completely eliminates the holdup problem 00:40:39.380 --> 00:40:43.880 align:middle line:84% because it's a conditional approve and transfer function. 00:40:43.880 --> 00:40:46.060 align:middle line:84% They're committing in advance to what 00:40:46.060 --> 00:40:49.940 align:middle line:84% they would do without loading all the bargaining 00:40:49.940 --> 00:40:56.560 align:middle line:84% advantage to C. If C chooses to play hardball, B says, fine. 00:40:56.560 --> 00:40:57.760 align:middle line:90% I don't have the asset. 00:40:57.760 --> 00:40:58.720 align:middle line:90% You can't hold me up. 00:40:58.720 --> 00:41:02.140 align:middle line:90% I don't even own it. 00:41:02.140 --> 00:41:05.580 align:middle line:84% So this approval allows the token holder 00:41:05.580 --> 00:41:10.200 align:middle line:84% to authorize a designated smart contract to spend 00:41:10.200 --> 00:41:13.780 align:middle line:84% a previously defined quantity of the token from the balance. 00:41:13.780 --> 00:41:16.000 align:middle line:90% Note the language here. 00:41:16.000 --> 00:41:18.860 align:middle line:84% The holder is empowering the smart contract. 00:41:18.860 --> 00:41:20.440 align:middle line:84% We're back to those initial slides 00:41:20.440 --> 00:41:25.680 align:middle line:84% where these messages are being sent to the contract node. 00:41:25.680 --> 00:41:29.080 align:middle line:84% This ERC-20 approved method enables the token holders 00:41:29.080 --> 00:41:33.560 align:middle line:84% to selectively allow spending for specific purposes 00:41:33.560 --> 00:41:38.380 align:middle line:84% or transactions, enhancing the flexibility of the token use. 00:41:38.380 --> 00:41:41.440 align:middle line:84% In fact, in other settings, people 00:41:41.440 --> 00:41:46.460 align:middle line:84% like or dislike a lot this idea of programmed money. 00:41:46.460 --> 00:41:49.220 align:middle line:84% You're putting conditionality onto the object. 00:41:49.220 --> 00:41:52.240 align:middle line:90% 00:41:52.240 --> 00:41:58.520 align:middle line:84% You can only say withdraw so much of it 00:41:58.520 --> 00:42:00.600 align:middle line:84% because we're really not sure as regulators 00:42:00.600 --> 00:42:05.080 align:middle line:84% that we want unlimited amounts of this stuff around. 00:42:05.080 --> 00:42:14.310 align:middle line:84% But in this case, the same approval function in the ERC-20 00:42:14.310 --> 00:42:19.070 align:middle line:84% standard is being used to direct future-- 00:42:19.070 --> 00:42:20.870 align:middle line:84% to controls, consistent with what 00:42:20.870 --> 00:42:22.530 align:middle line:84% they've agreed to in the contract, 00:42:22.530 --> 00:42:25.350 align:middle line:90% the future flows of the asset. 00:42:25.350 --> 00:42:31.510 align:middle line:84% So this is a function, f, a signature approval function that 00:42:31.510 --> 00:42:34.150 align:middle line:90% has the address and the amount. 00:42:34.150 --> 00:42:38.790 align:middle line:84% And it's an approval function, so it's yes, I approve, 00:42:38.790 --> 00:42:40.390 align:middle line:90% or no I don't. 00:42:40.390 --> 00:42:44.290 align:middle line:84% So the spender is the address of the smart contract. 00:42:44.290 --> 00:42:45.530 align:middle line:90% It's not the agent. 00:42:45.530 --> 00:42:48.850 align:middle line:84% It's the smart contract who's the spender. 00:42:48.850 --> 00:42:52.350 align:middle line:90% 00:42:52.350 --> 00:42:54.070 align:middle line:84% And the amount is the amount of the token 00:42:54.070 --> 00:43:00.110 align:middle line:84% that's permitted to be used on behalf of the token holder. 00:43:00.110 --> 00:43:02.750 align:middle line:84% So preview of coming attractions, 00:43:02.750 --> 00:43:07.490 align:middle line:84% and this is premature, but I'll mention it, nevertheless. 00:43:07.490 --> 00:43:11.310 align:middle line:84% These tables, 2 and 3, which we're here, 00:43:11.310 --> 00:43:14.690 align:middle line:84% A is the initial holder, and then 00:43:14.690 --> 00:43:19.130 align:middle line:84% a deal made in the smart contract between A and B. 00:43:19.130 --> 00:43:24.190 align:middle line:84% What the participants are seeing potentially is gobbledygook. 00:43:24.190 --> 00:43:28.170 align:middle line:84% They're just seeing encrypted values. 00:43:28.170 --> 00:43:34.570 align:middle line:84% So this is done under homomorphic encryption, which 00:43:34.570 --> 00:43:37.410 align:middle line:84% intuitively is an isomorphic space 00:43:37.410 --> 00:43:39.770 align:middle line:84% to the underlying true value space that 00:43:39.770 --> 00:43:43.410 align:middle line:84% respects things like addition and multiplication. 00:43:43.410 --> 00:43:47.170 align:middle line:84% So you can do things in the encrypted space with the code. 00:43:47.170 --> 00:43:49.410 align:middle line:84% And the code doesn't really, quote, "know" 00:43:49.410 --> 00:43:51.170 align:middle line:90% it's not even a person. 00:43:51.170 --> 00:43:55.630 align:middle line:84% But if you decipher the underlying function, 00:43:55.630 --> 00:43:58.770 align:middle line:84% you can encrypt the amount, have the function operate 00:43:58.770 --> 00:44:02.730 align:middle line:84% on the encrypted values, and then decipher it back 00:44:02.730 --> 00:44:04.450 align:middle line:90% to the underlying function, f. 00:44:04.450 --> 00:44:08.090 align:middle line:84% So you achieve equivalent results. 00:44:08.090 --> 00:44:11.730 align:middle line:84% And again, I apologize, in a way, that this is premature. 00:44:11.730 --> 00:44:14.750 align:middle line:84% But since I mentioned those values are private, 00:44:14.750 --> 00:44:19.310 align:middle line:84% you may be thinking that there's some information leakage going 00:44:19.310 --> 00:44:20.670 align:middle line:90% on. 00:44:20.670 --> 00:44:23.470 align:middle line:84% But we have the power of homomorphic encryption 00:44:23.470 --> 00:44:26.350 align:middle line:84% to completely obscure the state of-- 00:44:26.350 --> 00:44:28.630 align:middle line:84% there is a true underlying state, 00:44:28.630 --> 00:44:35.030 align:middle line:84% but we're able to partition with encryption to allow subparties 00:44:35.030 --> 00:44:39.150 align:middle line:84% of contracts to know things that others don't know and cannot 00:44:39.150 --> 00:44:40.860 align:middle line:90% decipher. 00:44:40.860 --> 00:44:42.610 align:middle line:84% And we have a whole lecture on encryption, 00:44:42.610 --> 00:44:44.190 align:middle line:90% which is hardly enough. 00:44:44.190 --> 00:44:50.330 align:middle line:84% But I'll go through this in more detail in a couple of lectures. 00:44:50.330 --> 00:44:55.250 align:middle line:84% So let me come back to this interface with legacy assets, 00:44:55.250 --> 00:44:59.550 align:middle line:84% where the digital assets are not native. 00:44:59.550 --> 00:45:04.380 align:middle line:84% There's a lot of questions that would need to be considered, 00:45:04.380 --> 00:45:09.460 align:middle line:84% including rules for issuance of tokenized assets, redemption, 00:45:09.460 --> 00:45:14.980 align:middle line:84% access to them, the underlying funds and claims, transfer 00:45:14.980 --> 00:45:19.400 align:middle line:84% mechanisms, privacy, interoperability and so on. 00:45:19.400 --> 00:45:20.900 align:middle line:90% And you have to make choices. 00:45:20.900 --> 00:45:23.940 align:middle line:84% Depending on those choices, there 00:45:23.940 --> 00:45:28.800 align:middle line:84% are implications for safety and efficiency of the arrangement. 00:45:28.800 --> 00:45:35.660 align:middle line:84% For example, this comes up with these digital dollars, 00:45:35.660 --> 00:45:39.260 align:middle line:84% the stablecoins in circle and so on 00:45:39.260 --> 00:45:44.540 align:middle line:84% are supposed to be completely backed by treasuries 00:45:44.540 --> 00:45:48.000 align:middle line:90% or underlying liquidity. 00:45:48.000 --> 00:45:49.960 align:middle line:84% But if that's not part of the blockchain, 00:45:49.960 --> 00:45:53.140 align:middle line:84% then you have to take that on faith. 00:45:53.140 --> 00:45:55.500 align:middle line:84% But there's simpler backing, which 00:45:55.500 --> 00:46:00.460 align:middle line:84% is you could take, say, an account at the Federal Reserve 00:46:00.460 --> 00:46:07.760 align:middle line:84% that a bank has in its reserve account and put it in escrow, 00:46:07.760 --> 00:46:12.560 align:middle line:84% and issue a corresponding amount of the tokenized asset. 00:46:12.560 --> 00:46:16.320 align:middle line:84% And then you have to trust the person holding it in escrow 00:46:16.320 --> 00:46:19.020 align:middle line:84% to not mess with it in the interim, 00:46:19.020 --> 00:46:22.000 align:middle line:84% so as to guarantee, if you trust it, 00:46:22.000 --> 00:46:25.440 align:middle line:84% the one-to-one convertibility of the underlying asset 00:46:25.440 --> 00:46:27.600 align:middle line:90% with its tokenized version. 00:46:27.600 --> 00:46:31.600 align:middle line:90% So this is written by the BIS. 00:46:31.600 --> 00:46:36.520 align:middle line:84% There needs to be clarity on who has a claim to what 00:46:36.520 --> 00:46:42.000 align:middle line:84% and what the backing relates to and so on-- 00:46:42.000 --> 00:46:45.280 align:middle line:90% CPMI. 00:46:45.280 --> 00:46:49.920 align:middle line:84% So now I want to come to interoperability. 00:46:49.920 --> 00:46:54.120 align:middle line:84% And the blockchain technology as we see it today 00:46:54.120 --> 00:46:58.280 align:middle line:84% is typically fragmented into different blockchains, not just 00:46:58.280 --> 00:46:59.200 align:middle line:90% one. 00:46:59.200 --> 00:47:03.270 align:middle line:84% And in general, they can't communicate or exchange assets 00:47:03.270 --> 00:47:05.590 align:middle line:90% across these chains. 00:47:05.590 --> 00:47:09.830 align:middle line:84% Likewise, crypto exchanges are not operating on the blockchain 00:47:09.830 --> 00:47:11.590 align:middle line:90% at all, typically. 00:47:11.590 --> 00:47:13.750 align:middle line:84% The exchanges maintain liquidity pools 00:47:13.750 --> 00:47:17.750 align:middle line:84% on various of the blockchains and exchange balances 00:47:17.750 --> 00:47:19.350 align:middle line:90% across the agents. 00:47:19.350 --> 00:47:21.790 align:middle line:84% So there, it's a bit like agent B 00:47:21.790 --> 00:47:28.510 align:middle line:84% in the example in the sense of having these intermediaries. 00:47:28.510 --> 00:47:31.070 align:middle line:90% It's not decentralized. 00:47:31.070 --> 00:47:34.550 align:middle line:84% Some decentralized exchanges exist, 00:47:34.550 --> 00:47:37.750 align:middle line:84% but they require some kind of conversion 00:47:37.750 --> 00:47:41.070 align:middle line:84% between an intermediate currency and the consensus 00:47:41.070 --> 00:47:45.230 align:middle line:90% of the intermediate blockchain. 00:47:45.230 --> 00:47:52.190 align:middle line:84% So let me take you through some slides on that. 00:47:52.190 --> 00:47:56.510 align:middle line:84% The centralized exchanges, like FTX was, 00:47:56.510 --> 00:47:59.710 align:middle line:84% you have the two separate blockchains-- 00:47:59.710 --> 00:48:04.010 align:middle line:84% one for Bitcoin, one for Ethereum, and there's 00:48:04.010 --> 00:48:04.990 align:middle line:90% trade going on. 00:48:04.990 --> 00:48:09.810 align:middle line:84% But that's going on in these centralized off-chain exchanges. 00:48:09.810 --> 00:48:13.210 align:middle line:84% There are some decentralized exchanges 00:48:13.210 --> 00:48:17.550 align:middle line:84% in existence, which is like creating a third chain, 00:48:17.550 --> 00:48:20.370 align:middle line:90% an intermediate chain. 00:48:20.370 --> 00:48:23.050 align:middle line:84% They no longer operate like banks. 00:48:23.050 --> 00:48:25.170 align:middle line:90% They don't require trust. 00:48:25.170 --> 00:48:27.690 align:middle line:84% But the state of the art is that they're computationally 00:48:27.690 --> 00:48:30.210 align:middle line:90% expensive to run. 00:48:30.210 --> 00:48:35.090 align:middle line:84% But advances are being made in the design of these DEXes 00:48:35.090 --> 00:48:39.010 align:middle line:84% to allow them to scale up and run more efficiently. 00:48:39.010 --> 00:48:41.370 align:middle line:84% ChainLink is an example of something 00:48:41.370 --> 00:48:44.290 align:middle line:84% having to do with external information. 00:48:44.290 --> 00:48:49.710 align:middle line:84% There's an oracle that gives information to on-chain nodes, 00:48:49.710 --> 00:48:51.890 align:middle line:84% but you have to trust the source. 00:48:51.890 --> 00:48:55.030 align:middle line:84% Or you gather information from multiple sources, 00:48:55.030 --> 00:48:58.610 align:middle line:84% like multiple oracles, and then perform some kind 00:48:58.610 --> 00:49:01.150 align:middle line:90% of consensus operation. 00:49:01.150 --> 00:49:05.430 align:middle line:84% And these oracles are limited to data retrieval. 00:49:05.430 --> 00:49:08.290 align:middle line:84% There's no mechanism for transmission of data. 00:49:08.290 --> 00:49:14.110 align:middle line:84% This is like consulting FX markets to get an exchange rate 00:49:14.110 --> 00:49:18.830 align:middle line:84% and then bringing that into the blockchain. 00:49:18.830 --> 00:49:23.590 align:middle line:84% LayerZero is a decentralized messaging system 00:49:23.590 --> 00:49:27.310 align:middle line:84% that does not require an intermediate blockchain. 00:49:27.310 --> 00:49:30.870 align:middle line:84% It enables currency exchange in arbitrary messages 00:49:30.870 --> 00:49:33.130 align:middle line:90% between two arbitrary chains. 00:49:33.130 --> 00:49:36.990 align:middle line:84% So we have chain A, chain B, somehow 00:49:36.990 --> 00:49:39.750 align:middle line:90% each linked to layer zero. 00:49:39.750 --> 00:49:42.190 align:middle line:84% And the system will allow a message 00:49:42.190 --> 00:49:45.350 align:middle line:84% to be delivered from chain A to chain B 00:49:45.350 --> 00:49:50.150 align:middle line:84% only when something got committed to on chain A. 00:49:50.150 --> 00:49:54.510 align:middle line:84% So it does get a little bit complicated. 00:49:54.510 --> 00:49:58.010 align:middle line:84% Hopefully, this picture conveys a little bit more. 00:49:58.010 --> 00:50:02.580 align:middle line:84% You have chain A, chain B, and they're both part 00:50:02.580 --> 00:50:04.980 align:middle line:90% of LayerZero ecosystem. 00:50:04.980 --> 00:50:11.780 align:middle line:84% So each of these blockchains has a LayerZero node, you might say. 00:50:11.780 --> 00:50:17.540 align:middle line:84% And then also, you've got these relayers and oracles. 00:50:17.540 --> 00:50:19.660 align:middle line:84% And within each chain, you've got 00:50:19.660 --> 00:50:23.140 align:middle line:90% communicators and validators. 00:50:23.140 --> 00:50:27.420 align:middle line:84% So this thing works on something, again, 00:50:27.420 --> 00:50:31.820 align:middle line:84% related to encryption, zero knowledge proofs where 00:50:31.820 --> 00:50:34.940 align:middle line:84% you can prove that something happened on one blockchain 00:50:34.940 --> 00:50:43.300 align:middle line:84% by a series of coded operations without actually seeing directly 00:50:43.300 --> 00:50:45.020 align:middle line:90% what happened there. 00:50:45.020 --> 00:50:48.500 align:middle line:84% So all these things are trying to emulate the strength 00:50:48.500 --> 00:50:51.980 align:middle line:90% of having one centralized-- 00:50:51.980 --> 00:50:55.300 align:middle line:84% one blockchain doing all the operations 00:50:55.300 --> 00:51:01.580 align:middle line:84% where you can control the states and monitor the transfers. 00:51:01.580 --> 00:51:04.240 align:middle line:90% 00:51:04.240 --> 00:51:07.440 align:middle line:84% So this exchange in contracting platform 00:51:07.440 --> 00:51:11.520 align:middle line:84% was something the IMF envisions, which 00:51:11.520 --> 00:51:14.360 align:middle line:84% is to set aside the domestic systems of each 00:51:14.360 --> 00:51:16.000 align:middle line:90% of the countries. 00:51:16.000 --> 00:51:18.480 align:middle line:84% But nevertheless, set up a blockchain 00:51:18.480 --> 00:51:23.240 align:middle line:84% for foreign exchange transactions, XC being exchange 00:51:23.240 --> 00:51:27.280 align:middle line:84% and contracting platform, maybe with an emphasis 00:51:27.280 --> 00:51:29.440 align:middle line:90% on the contracting part. 00:51:29.440 --> 00:51:34.080 align:middle line:84% And I'll say a couple more words about that on the next slide. 00:51:34.080 --> 00:51:36.160 align:middle line:84% The Bank for International Settlement 00:51:36.160 --> 00:51:38.640 align:middle line:84% has now also envisioned something 00:51:38.640 --> 00:51:41.980 align:middle line:84% they call a unified ledger even within countries. 00:51:41.980 --> 00:51:46.160 align:middle line:90% And we'll review that carefully. 00:51:46.160 --> 00:51:52.000 align:middle line:84% And then I'll come to what the Federal Reserve Board wrote 00:51:52.000 --> 00:51:56.200 align:middle line:84% having to do with this coherence guarantee, which 00:51:56.200 --> 00:52:01.590 align:middle line:84% is going to take us right back to essentially the way Ethereum 00:52:01.590 --> 00:52:02.370 align:middle line:90% operates. 00:52:02.370 --> 00:52:05.190 align:middle line:90% 00:52:05.190 --> 00:52:08.630 align:middle line:84% So exchanging contracting platform for cross-border 00:52:08.630 --> 00:52:09.830 align:middle line:90% payments-- 00:52:09.830 --> 00:52:13.290 align:middle line:84% the current state of the system, it's slow, it's expensive, 00:52:13.290 --> 00:52:15.230 align:middle line:90% and it's risky. 00:52:15.230 --> 00:52:17.990 align:middle line:84% You do have these broker dealers who 00:52:17.990 --> 00:52:21.110 align:middle line:84% are intermediating the system, and they 00:52:21.110 --> 00:52:25.030 align:middle line:84% are relying on trusted relationships the clients have 00:52:25.030 --> 00:52:28.910 align:middle line:84% with them and vice versa, trying to deal with the fact 00:52:28.910 --> 00:52:31.790 align:middle line:84% that there's not a common settlement asset, 00:52:31.790 --> 00:52:36.790 align:middle line:84% and there's not common rules for governance. 00:52:36.790 --> 00:52:38.430 align:middle line:90% That's the current system. 00:52:38.430 --> 00:52:41.370 align:middle line:84% I mean, let me just put that in plain English. 00:52:41.370 --> 00:52:45.070 align:middle line:84% We're dealing here with multiple countries. 00:52:45.070 --> 00:52:49.670 align:middle line:84% They're not like states in the US, or even countries in the EU. 00:52:49.670 --> 00:52:51.850 align:middle line:84% There's no central governance unit. 00:52:51.850 --> 00:52:55.590 align:middle line:84% So that has to be agreed to as part of a platform. 00:52:55.590 --> 00:52:57.770 align:middle line:84% And likewise, what do we mean when 00:52:57.770 --> 00:53:02.210 align:middle line:84% we say there's one money, when we have a fiat money for each 00:53:02.210 --> 00:53:05.690 align:middle line:90% of the countries? 00:53:05.690 --> 00:53:10.250 align:middle line:84% So this multilateral platform that we envisioned 00:53:10.250 --> 00:53:16.230 align:middle line:84% allows the fiat money of each central bank, the reserves, 00:53:16.230 --> 00:53:19.670 align:middle line:84% to be tokenized in the sense that I was describing earlier, 00:53:19.670 --> 00:53:24.210 align:middle line:84% and the tokenized objects or what exists on the blockchain. 00:53:24.210 --> 00:53:26.290 align:middle line:84% Then you can write smart contracts 00:53:26.290 --> 00:53:30.710 align:middle line:84% that allow for risk sharing and other financial contracting, 00:53:30.710 --> 00:53:34.410 align:middle line:84% and of course, simple spot exchanges of one 00:53:34.410 --> 00:53:36.330 align:middle line:90% currency for the other. 00:53:36.330 --> 00:53:39.690 align:middle line:84% So we're leveraging the technological innovations that 00:53:39.690 --> 00:53:42.850 align:middle line:84% we've been talking about-- distributed ledgers and smart 00:53:42.850 --> 00:53:45.610 align:middle line:90% contracts and encryption-- 00:53:45.610 --> 00:53:49.010 align:middle line:90% to gain efficiency. 00:53:49.010 --> 00:53:53.630 align:middle line:84% The BIS now is envisioning a unified ledger, 00:53:53.630 --> 00:53:57.610 align:middle line:84% and they meant within countries, not just across countries. 00:53:57.610 --> 00:54:02.070 align:middle line:84% So let's review this BIS proposal. 00:54:02.070 --> 00:54:06.470 align:middle line:84% First of all, the tokenization, which are rules for what 00:54:06.470 --> 00:54:09.810 align:middle line:84% the asset can and cannot do, as in a smart contract. 00:54:09.810 --> 00:54:13.250 align:middle line:84% And hopefully, that's quite clear from the lecture today 00:54:13.250 --> 00:54:14.390 align:middle line:90% so far-- 00:54:14.390 --> 00:54:17.570 align:middle line:84% information about where the asset is, where it comes from, 00:54:17.570 --> 00:54:18.870 align:middle line:90% who owns it. 00:54:18.870 --> 00:54:22.230 align:middle line:84% So tokenization means recording and mirroring 00:54:22.230 --> 00:54:24.670 align:middle line:84% the claims on real or financial assets 00:54:24.670 --> 00:54:27.250 align:middle line:84% that exist on traditional ledgers. 00:54:27.250 --> 00:54:29.890 align:middle line:84% That's this meaning of tokenization 00:54:29.890 --> 00:54:31.790 align:middle line:90% which is not native. 00:54:31.790 --> 00:54:36.470 align:middle line:84% But once they're tokenized, you have the database and the rules 00:54:36.470 --> 00:54:39.830 align:middle line:90% and logic of the smart contract. 00:54:39.830 --> 00:54:44.110 align:middle line:84% The tokenization has its advantages. 00:54:44.110 --> 00:54:47.790 align:middle line:84% It combines messaging, reconciliation, and settlement 00:54:47.790 --> 00:54:49.750 align:middle line:90% in a single operation. 00:54:49.750 --> 00:54:52.550 align:middle line:84% I hope that that is clear now from the example 00:54:52.550 --> 00:54:54.860 align:middle line:84% that we've gone through in the lecture. 00:54:54.860 --> 00:54:57.480 align:middle line:84% It improves efficiency, and with a commitment 00:54:57.480 --> 00:55:02.340 align:middle line:84% we're unlocking new features that enables atomic settlement, 00:55:02.340 --> 00:55:06.220 align:middle line:84% transfers that occur reciprocally, simultaneously, 00:55:06.220 --> 00:55:11.660 align:middle line:84% or transfers where one is a precondition for the other. 00:55:11.660 --> 00:55:15.260 align:middle line:84% It enables contingent performance of actions, 00:55:15.260 --> 00:55:17.580 align:middle line:84% as in that transferability and assignment 00:55:17.580 --> 00:55:20.080 align:middle line:84% that I was going through and other things as well. 00:55:20.080 --> 00:55:22.780 align:middle line:84% It certainly allows for multiple parties 00:55:22.780 --> 00:55:24.500 align:middle line:84% to be doing things with each other 00:55:24.500 --> 00:55:28.220 align:middle line:84% simultaneously, not just bilaterally. 00:55:28.220 --> 00:55:31.520 align:middle line:84% And it expands the universe of contractual outcomes 00:55:31.520 --> 00:55:34.700 align:middle line:84% so that more productive use can be made of resources 00:55:34.700 --> 00:55:37.660 align:middle line:90% which would otherwise be lost. 00:55:37.660 --> 00:55:40.400 align:middle line:84% And if you are on one blockchain, 00:55:40.400 --> 00:55:44.100 align:middle line:90% then you can do this. 00:55:44.100 --> 00:55:45.980 align:middle line:84% But the questions are, what happens 00:55:45.980 --> 00:55:49.100 align:middle line:84% when information comes from outside, as 00:55:49.100 --> 00:55:51.060 align:middle line:90% in that oracle example? 00:55:51.060 --> 00:55:55.240 align:middle line:84% What happens if, as in real life, there are other ledgers? 00:55:55.240 --> 00:55:59.200 align:middle line:84% Who is the custodian of these non-native assets? 00:55:59.200 --> 00:56:04.000 align:middle line:84% Who is synchronizing the asset movements 00:56:04.000 --> 00:56:05.780 align:middle line:90% across the different ledgers? 00:56:05.780 --> 00:56:11.400 align:middle line:90% 00:56:11.400 --> 00:56:14.880 align:middle line:84% So at this point, the BIS paper starts 00:56:14.880 --> 00:56:18.680 align:middle line:84% to talk about tokenizing deposits, 00:56:18.680 --> 00:56:22.120 align:middle line:84% meaning commercial bank liabilities, 00:56:22.120 --> 00:56:24.440 align:middle line:84% and then makes three claims about why 00:56:24.440 --> 00:56:28.000 align:middle line:84% tokenized deposits are better than, say, 00:56:28.000 --> 00:56:30.080 align:middle line:90% asset-backed stablecoins. 00:56:30.080 --> 00:56:33.680 align:middle line:84% First claim-- tokenized deposits help preserve 00:56:33.680 --> 00:56:35.560 align:middle line:90% the singleness of money. 00:56:35.560 --> 00:56:37.600 align:middle line:84% This is the way they think about things. 00:56:37.600 --> 00:56:40.360 align:middle line:84% Second, payments in tokenized deposits 00:56:40.360 --> 00:56:44.200 align:middle line:84% settle in wholesale central bank digital currency, 00:56:44.200 --> 00:56:47.440 align:middle line:84% which ensures finality because they 00:56:47.440 --> 00:56:49.760 align:middle line:90% are claims on a central bank. 00:56:49.760 --> 00:56:52.190 align:middle line:84% By using its own balance sheet as the ultimate means 00:56:52.190 --> 00:56:54.590 align:middle line:84% of settlement, the central bank provides the means 00:56:54.590 --> 00:56:58.510 align:middle line:84% for ensuring the finality of the wholesale payment. 00:56:58.510 --> 00:57:00.870 align:middle line:84% Third claim-- tokenized deposits ensure 00:57:00.870 --> 00:57:04.190 align:middle line:84% that banks could continue to offer credit and liquidity 00:57:04.190 --> 00:57:05.990 align:middle line:90% in a flexible way. 00:57:05.990 --> 00:57:08.910 align:middle line:84% And then, in contrast, tokenized stablecoins 00:57:08.910 --> 00:57:12.190 align:middle line:84% represent a transferable claim on the issuer 00:57:12.190 --> 00:57:15.010 align:middle line:84% akin to a digital bearer instrument. 00:57:15.010 --> 00:57:16.370 align:middle line:90% Stablecoins are tradable. 00:57:16.370 --> 00:57:19.550 align:middle line:84% Their prices deviate from par, undermining 00:57:19.550 --> 00:57:21.510 align:middle line:90% the singleness of money. 00:57:21.510 --> 00:57:24.150 align:middle line:84% And then subsidiary claim-- stablecoins 00:57:24.150 --> 00:57:27.630 align:middle line:90% do not allow elastic liquidity. 00:57:27.630 --> 00:57:29.670 align:middle line:90% This is in the paper. 00:57:29.670 --> 00:57:32.370 align:middle line:84% This is the way, at the time of writing, 00:57:32.370 --> 00:57:35.710 align:middle line:84% the BIS was viewing these things. 00:57:35.710 --> 00:57:40.350 align:middle line:84% But the critique is that they have now 00:57:40.350 --> 00:57:45.390 align:middle line:84% merged the traditional legacy accounting 00:57:45.390 --> 00:57:49.870 align:middle line:84% point of view of money with this new technology. 00:57:49.870 --> 00:57:53.730 align:middle line:84% They're basically saying, look, we understand commercial bank 00:57:53.730 --> 00:57:54.470 align:middle line:90% deposits. 00:57:54.470 --> 00:57:58.290 align:middle line:84% We understand central bank reserves. 00:57:58.290 --> 00:58:02.890 align:middle line:84% Let's try to adopt an aspect of the new system 00:58:02.890 --> 00:58:08.330 align:middle line:84% by allowing only tokenized deposits rather than more 00:58:08.330 --> 00:58:12.410 align:middle line:84% general representation of assets. 00:58:12.410 --> 00:58:17.450 align:middle line:84% What, in particular, does the BIS mean by a unified ledger? 00:58:17.450 --> 00:58:21.930 align:middle line:84% Trying to bring together various central banks, CBDCs, 00:58:21.930 --> 00:58:24.290 align:middle line:84% bring together tokenized deposits 00:58:24.290 --> 00:58:29.330 align:middle line:84% and other tokenized assets on a shared programmable platform. 00:58:29.330 --> 00:58:32.570 align:middle line:84% So this is the larger vision, bringing 00:58:32.570 --> 00:58:35.470 align:middle line:84% to the same venue tokenized assets, 00:58:35.470 --> 00:58:38.270 align:middle line:90% tokenized deposits, and CBDCs. 00:58:38.270 --> 00:58:41.210 align:middle line:84% But what do they mean by this venue? 00:58:41.210 --> 00:58:44.250 align:middle line:84% They seem to suggest there's a role for private platforms 00:58:44.250 --> 00:58:46.090 align:middle line:90% and for central banks. 00:58:46.090 --> 00:58:49.890 align:middle line:84% And they mentioned applied programming interfaces, 00:58:49.890 --> 00:58:53.050 align:middle line:84% but it's really open for interpretation. 00:58:53.050 --> 00:58:56.110 align:middle line:84% It could be a unified ledger, after all, 00:58:56.110 --> 00:58:59.310 align:middle line:84% on a public platform, which could connect 00:58:59.310 --> 00:59:03.310 align:middle line:84% the various distributed ledger technologies to an existing 00:59:03.310 --> 00:59:04.770 align:middle line:90% central bank infrastructure. 00:59:04.770 --> 00:59:08.270 align:middle line:84% For example, within a country and its central bank 00:59:08.270 --> 00:59:11.990 align:middle line:84% and its reserves, convert the settlement system 00:59:11.990 --> 00:59:16.830 align:middle line:84% of real-time gross settlement onto a blockchain. 00:59:16.830 --> 00:59:19.710 align:middle line:90% That is an option. 00:59:19.710 --> 00:59:23.730 align:middle line:84% So then CBDC would mean existing central bank reserves. 00:59:23.730 --> 00:59:27.630 align:middle line:84% It's now a technologically improved system. 00:59:27.630 --> 00:59:29.870 align:middle line:84% Still via a public platform, it could 00:59:29.870 --> 00:59:35.470 align:middle line:84% be there are new central bank distributed ledgers with bridges 00:59:35.470 --> 00:59:38.090 align:middle line:84% back to the private and public tokens. 00:59:38.090 --> 00:59:41.270 align:middle line:84% Or put more succinctly, here central bank digital currency 00:59:41.270 --> 00:59:43.950 align:middle line:84% would mean tokenized central bank reserves 00:59:43.950 --> 00:59:47.260 align:middle line:90% or tokenized Treasury bills. 00:59:47.260 --> 00:59:49.940 align:middle line:84% Or in principle, it could be done, 00:59:49.940 --> 00:59:51.620 align:middle line:84% or it could have the interpretation, 00:59:51.620 --> 00:59:54.360 align:middle line:84% that when they say unified ledger, 00:59:54.360 --> 00:59:57.140 align:middle line:84% they mean the ledgers are unified via regulations 00:59:57.140 --> 01:00:01.460 align:middle line:84% and partnerships, that existing assets are 01:00:01.460 --> 01:00:10.340 align:middle line:84% tokenized with custodians and reconciled by someone, either 01:00:10.340 --> 01:00:13.280 align:middle line:90% a public or a private entity. 01:00:13.280 --> 01:00:16.280 align:middle line:84% For example, in that regulated liability network, 01:00:16.280 --> 01:00:21.060 align:middle line:84% the tokenized commercial bank deposits. 01:00:21.060 --> 01:00:24.300 align:middle line:84% So in that case, the tokenized money 01:00:24.300 --> 01:00:29.100 align:middle line:84% could then be transported to a public distributed ledger 01:00:29.100 --> 01:00:35.620 align:middle line:84% platform, or continue to exist on the private regulated DLT 01:00:35.620 --> 01:00:37.780 align:middle line:90% platforms. 01:00:37.780 --> 01:00:42.660 align:middle line:84% And in this latter case, there's no CBDC at all. 01:00:42.660 --> 01:00:55.440 align:middle line:84% So I realize that my tone is conveying a criticism of the BIS 01:00:55.440 --> 01:00:57.800 align:middle line:90% paper for being unclear. 01:00:57.800 --> 01:01:02.080 align:middle line:84% And indeed, that is the content of these slides. 01:01:02.080 --> 01:01:05.160 align:middle line:84% But you could also interpret it as these 01:01:05.160 --> 01:01:07.800 align:middle line:84% are all decisions that individual countries 01:01:07.800 --> 01:01:10.400 align:middle line:84% and the international community are going 01:01:10.400 --> 01:01:14.120 align:middle line:84% to have to make about whether or not to use 01:01:14.120 --> 01:01:21.120 align:middle line:84% these new technologies and how the system should be configured. 01:01:21.120 --> 01:01:24.400 align:middle line:84% It's indeed pretty hard to have these conversations 01:01:24.400 --> 01:01:27.440 align:middle line:84% without clear definitions of things like tokenization 01:01:27.440 --> 01:01:31.940 align:middle line:84% and smart contracts and understanding legacy systems, 01:01:31.940 --> 01:01:34.700 align:middle line:90% and that was the content today. 01:01:34.700 --> 01:01:38.960 align:middle line:84% So these open questions are, could a retail CBDC 01:01:38.960 --> 01:01:43.960 align:middle line:84% be used as a wholesale CBDC, one unified CBDC? 01:01:43.960 --> 01:01:47.980 align:middle line:84% Should Fed or Treasury tokens-- should they tokenize native 01:01:47.980 --> 01:01:51.060 align:middle line:84% objects to be used on the private platforms-- 01:01:51.060 --> 01:01:56.060 align:middle line:84% Federal Reserve, CBDC-- which is what Switzerland did, actually. 01:01:56.060 --> 01:01:58.900 align:middle line:84% It allowed a representation of its reserves 01:01:58.900 --> 01:02:02.820 align:middle line:84% on a private sector platform and conducted an open market 01:02:02.820 --> 01:02:04.460 align:middle line:90% operation there. 01:02:04.460 --> 01:02:07.420 align:middle line:84% Should the Fed regulate private platforms 01:02:07.420 --> 01:02:11.380 align:middle line:84% or provide a public one, like this regulated liability 01:02:11.380 --> 01:02:12.460 align:middle line:90% network? 01:02:12.460 --> 01:02:18.620 align:middle line:84% Recent US policy guidance suggests doing everything 01:02:18.620 --> 01:02:26.380 align:middle line:84% with private blockchains, stablecoins, in particular, 01:02:26.380 --> 01:02:31.060 align:middle line:90% and is negative about CBDCs. 01:02:31.060 --> 01:02:35.180 align:middle line:84% So that is also stimulating a lot of conversations 01:02:35.180 --> 01:02:40.540 align:middle line:84% these days, both in the US and in other countries. 01:02:40.540 --> 01:02:47.330 align:middle line:84% The main thing is to recognize the power of programmability, 01:02:47.330 --> 01:02:51.130 align:middle line:84% that programmed money is a unified, coherent product that 01:02:51.130 --> 01:02:54.650 align:middle line:84% encapsulates both the storage of the digital value 01:02:54.650 --> 01:02:57.770 align:middle line:84% and the programmability of that value. 01:02:57.770 --> 01:03:03.770 align:middle line:84% This coherence-- this is from the Federal Reserve Board, US. 01:03:03.770 --> 01:03:06.770 align:middle line:84% This coherence guarantees refers to a mechanism 01:03:06.770 --> 01:03:09.330 align:middle line:84% for guaranteeing that the technical components 01:03:09.330 --> 01:03:12.490 align:middle line:84% of programmable money are inseparable, 01:03:12.490 --> 01:03:16.090 align:middle line:84% and that those components are consistently functional so 01:03:16.090 --> 01:03:19.650 align:middle line:84% that the product is stable and coherent. 01:03:19.650 --> 01:03:23.290 align:middle line:84% They could be nominally separable, 01:03:23.290 --> 01:03:28.570 align:middle line:84% as traditional technologies are, and implement 01:03:28.570 --> 01:03:32.930 align:middle line:84% two core technical components, namely, 01:03:32.930 --> 01:03:35.610 align:middle line:84% the storage of the digital value and the programmability 01:03:35.610 --> 01:03:37.170 align:middle line:90% of that value. 01:03:37.170 --> 01:03:39.730 align:middle line:84% But the coherence guarantee must ensure 01:03:39.730 --> 01:03:43.470 align:middle line:84% they are not separable as far as the overall product is 01:03:43.470 --> 01:03:44.010 align:middle line:90% concerned. 01:03:44.010 --> 01:03:47.270 align:middle line:84% Without that guarantee that you get with Ethereum and maybe 01:03:47.270 --> 01:03:51.590 align:middle line:84% other ways, the individual components are not novel at all. 01:03:51.590 --> 01:03:54.870 align:middle line:84% Digital money has been around for many years, 01:03:54.870 --> 01:03:58.430 align:middle line:84% as has the ability to write computer code 01:03:58.430 --> 01:04:00.390 align:middle line:84% and software for commercial banks 01:04:00.390 --> 01:04:02.510 align:middle line:90% and financial institutions. 01:04:02.510 --> 01:04:04.870 align:middle line:84% With the guarantee, programmable money 01:04:04.870 --> 01:04:10.270 align:middle line:84% is a new product category sitting alongside of the more 01:04:10.270 --> 01:04:13.350 align:middle line:84% traditional money products of central bank deposits, demand 01:04:13.350 --> 01:04:16.550 align:middle line:84% deposits, and nonbank money and cash. 01:04:16.550 --> 01:04:20.630 align:middle line:84% But this benefit of the coherence guarantee 01:04:20.630 --> 01:04:25.150 align:middle line:84% is not necessarily present in other systems that 01:04:25.150 --> 01:04:27.750 align:middle line:84% can rely on services and potentially 01:04:27.750 --> 01:04:34.710 align:middle line:84% be of other providers, and can be altered by those providers 01:04:34.710 --> 01:04:37.210 align:middle line:90% as they wish. 01:04:37.210 --> 01:04:41.780 align:middle line:84% So that's the state of the domestic and international 01:04:41.780 --> 01:04:43.820 align:middle line:90% financial system. 01:04:43.820 --> 01:04:47.020 align:middle line:90% There was a lot in this lecture. 01:04:47.020 --> 01:04:50.860 align:middle line:84% We went through programmability, first and foremost. 01:04:50.860 --> 01:04:53.540 align:middle line:84% Carried that in through examples. 01:04:53.540 --> 01:04:58.140 align:middle line:84% Kept coming back to it, as if there, without saying so, 01:04:58.140 --> 01:04:59.200 align:middle line:90% one blockchain. 01:04:59.200 --> 01:05:02.860 align:middle line:84% Then we get into the issue of how powerful 01:05:02.860 --> 01:05:06.980 align:middle line:84% the tokenized assets are with conditionality. 01:05:06.980 --> 01:05:10.680 align:middle line:84% But then recognize that we have multiple blockchains. 01:05:10.680 --> 01:05:14.780 align:middle line:84% We have the legacy system coexisting 01:05:14.780 --> 01:05:17.780 align:middle line:90% with these blockchains. 01:05:17.780 --> 01:05:21.700 align:middle line:84% And we can talk the talk of taking advantage 01:05:21.700 --> 01:05:23.200 align:middle line:90% of the power of the blockchain. 01:05:23.200 --> 01:05:25.820 align:middle line:84% But the devil's in the details in terms 01:05:25.820 --> 01:05:28.900 align:middle line:84% of exactly how to design the system 01:05:28.900 --> 01:05:33.730 align:middle line:84% and what regulations would be appropriate. 01:05:33.730 --> 01:05:41.000 align:middle line:90%