MIT OpenCourseWareLecture 5: Tokenized and Programmable Assets
MIT OpenCourseWare
Lecture Overview And Agenda 0:00
The lecture covers asset exchanges programmed in advance, built around the idea of a dynamic ledger, where ownership and transfers happen over time and can be conditioned on states of the world. Robert Townsend contrasts this with legacy systems, which suffer from trade fails. He outlines the plan: dig into tokenization and conditionality, then multiple blockchains and interoperability with legacy systems, then exchange and contracting platforms proposed by international agencies. Central bank innovations, including starred readings on the Swiss National Bank and Brazil, are left for the reading list rather than covered in class.
Ethereum Accounts And Contracts 2:02
Ethereum, the blockchain most associated with smart contracts, has two account types: externally owned accounts, like Bitcoin addresses with balances, and contract accounts, which contain code and data and update their state in response to incoming transactions. A contract cannot act on its own; it only responds to messages sent to it. Ether is the platform's currency, used mainly as a congestion fee to limit how many users try to act on the network simultaneously. Every transaction has a sender, recipient, and currency field, plus optional data, contract, and gas components.
Smart Contracts And Virtual Machines 5:33
A smart contract runs on the Ethereum Virtual Machine, a software emulation of a physical computer with its own CPU, memory, storage, and network interface, isolated so that failures inside it cannot harm the host computer. The EVM is Turing-complete, meaning it can execute any if/then logic, and every node on the network runs the same contract code, keeping the distributed ledger consistent across participants. Contracts are written in Solidity, compiled into bytecode, and ultimately reduced to machine code. Because contract terms are written directly into self-executing code, they run automatically once conditions are met, which is the core of what makes them "smart."
Tokenized Markets Three Trader Example 9:32
Drawing on a paper with Lee and Martin on optimal design of tokenized markets, Townsend distinguishes assets native to a blockchain from preexisting assets that are escrowed and represented on-chain, both loosely called "tokenized." The example has three risk-neutral traders, A, B, and C, with A initially owning one long-lived asset whose value to each holder changes over time. B acts as intermediary, meeting A and then C in two sequential, randomly ordered bilateral meetings, with only B aware of the meeting order. In a token system, bargaining and asset programming happen simultaneously during these meetings, so transfers are self-executing and cannot be blocked once agreed, though a trader must actually hold the asset to lend it onward. B hopes to hold the asset at high value at date 1, pass it to C at date 2, then have it returned through B back to A at date 3.
Legacy System And Trade Fails 19:52
In the legacy system, the same contracts exist but settlement is separate from trade, so any party can simply fail to deliver: C might keep the asset from B, or B might fail to pass it to C or fail to return it to A, producing cascading failures. Real-world evidence shows this happens: during the financial crisis, settlement fails reached nearly a trillion dollars in a single day, and despite the Federal Reserve introducing a penalty fee for failing, fails have persisted. Garbade's explanations include miscommunication between trading parties or with custodians, system failures like the 1985 Bank of New York incident or the 9/11 disruption, and sellers lacking the securities they promised, sometimes resolved by borrowing them. State Street's practice of settling trades hours after they are agreed, after prices have moved, illustrates why parties may have regrets and default.
Holdup Problem And Direct Trading 29:01
Programmed dynamic-ledger trades prevent fails but introduce a holdup problem: if C learns B has already secured the asset from A, C can lowball B knowing B is already committed. The legacy system avoids this because trade and settlement are decoupled and opaque, letting B hide whether it has already met A, so C cannot exploit that knowledge. Whether the token or legacy system performs better depends on parameters like the probabilities lambda B and lambda C, representing how likely each valuation is to be high, and commitment only has value when both sides are likely to see high asset value. One proposed fix is direct centralized trading, where B and C simultaneously post ultimatum offers to A rather than trading through sequential bilateral deals with B as broker, which eliminates the holdup problem when direct trading costs are low or zero.
Fungible And Nonfungible Token Standards 36:32
Townsend turns to Ethereum's token standards, ERC-20 for fungible tokens, which are interchangeable with one another, and ERC-721 for nonfungible tokens. The ERC-20 standard lets developers create smart-contract-based tokens representing ownership or access rights to an asset, cryptocurrency, or anything transferable, and it includes an approve-and-transfer function. Applying this to the earlier three-trader example, when A and B meet, A can approve B to transfer one unit of the asset to C later without B being forced to commit immediately, which sidesteps the holdup problem. If B and C then reach a deal, B draws the asset from A and passes it to C; if they don't, the asset simply stays in A's account, and A can revoke the approval or let a timer expire it.
Conditional Approval Solves the Holdup Problem 40:32
The ERC-20 approve function lets a token holder authorize a designated smart contract to spend a set quantity of tokens for a specific purpose, rather than handing control to another agent directly. Because the holder commits in advance to this conditional approve-and-transfer arrangement, no one can exploit bargaining leverage later, since the asset simply is not theirs to hold hostage. This is the same mechanism regulators sometimes call programmed money, where conditionality is written directly onto the asset, and it previews the encrypted, homomorphic computation that lets parties compute on hidden values without revealing them.
Fragmented Blockchains and Interoperability Fixes 47:31
Blockchains today are fragmented, and most crypto exchanges, including one like FTX, operate off-chain, matching balances across separate ledgers for Bitcoin and Ethereum rather than settling on a shared chain. Decentralized exchanges exist but are computationally costly, oracle systems like ChainLink bring in outside data but require trusting the source or combining multiple sources, and LayerZero offers a decentralized messaging layer that lets two arbitrary chains exchange value and messages using node relayers, oracles, and zero knowledge proofs without an intermediate blockchain. These are all attempts to recreate the coherence of a single controlled ledger across a fragmented system.
BIS Unified Ledger and Tokenized Deposits 51:04
The IMF has proposed a cross-border exchange and contracting platform, XC, while the Bank for International Settlements envisions a unified ledger even within countries, tokenizing central bank reserves, commercial bank deposits, and other assets on one programmable platform. The BIS argues tokenized deposits are preferable to asset-backed stablecoins because they preserve the singleness of money, settle in wholesale central bank digital currency for finality, and let banks keep offering flexible credit, whereas stablecoins can trade off par and limit elastic liquidity. Yet the paper leaves open what a unified ledger actually means in practice, whether new central bank digital currency, tokenized reserves, or simply better regulatory coordination, and open questions remain about retail versus wholesale CBDC, Fed and Treasury tokenization, and whether regulation should target private platforms or build a public one, with current US policy leaning toward private stablecoins over CBDCs.
The Coherence Guarantee Behind Programmable Money 1:02:31
The Federal Reserve Board describes a coherence guarantee as what makes programmable money a single, stable product rather than two separable pieces, the storage of digital value and the programmability of that value. Without this guarantee, as in traditional systems where software and money are handled by different, alterable providers, the components are nothing new, since digital money and programmable code have existed for years. With it, as Ethereum demonstrates, programmable money becomes a genuinely new category alongside central bank deposits, demand deposits, and cash, though achieving this coherence across a fragmented, multi-chain legacy system remains the real design challenge.
AI-generated summary. It can be wrong or incomplete - check anything that matters against the original.
