Where you are. You hold the two-tier map from the last lesson: all money is a ledger entry, banks settle in reserves on the central bank’s ledger, and everyone else holds a bank’s IOU. Behind the map sits five lessons of machinery: split tally sticks, circulating receipts, the clearing house, the telegraph that collapsed a message and a ledger edit into one operation. This lesson names the claim the rest of the course orbits: that the machinery can be rebuilt so the message, the settlement and the asset stop being three separate things. You will state the claim precisely, meet the four groups who make it, and count exactly which failures it removes.
Run the tap again
Go back to the card tap that opened this course. The terminal chirped in about a fifth of a second, and five parties stood behind the chirp: you, the shop’s bank, the card network, your bank, the central bank. What actually crossed the system in those 200 milliseconds was a message: an authorisation request out, an approval back.
Now replay the same payment following the money instead. At the chirp, nothing had moved. Your bank placed a hold on your account, an edit that promises a later edit. That night the network totalled the day’s taps and netted the banks’ positions against each other. The next day the banks settled, reserves shifting on the central bank’s ledger, and somewhere after that the shop’s deposit finally grew. Five parties, roughly two days of squaring up, for a payment the message had fully described before you put your card away.
Read that trace the way you would read a distributed system, and one detail nags. The message carried everything: payer, payee, amount. Every party trusted it enough to act. Yet the thing it described happened days later, on other ledgers, in other buildings. The message was never the payment. It was a pointer to money that still had to be moved separately.
So here is the question this lesson exists to name. What if the message was the money?
The idea in one paragraph
The tokenisation claim says the relay you just traced is a design choice, not a law of nature. Every payment in this course so far has been two things travelling separately: a message about money, then a movement of money, later, somewhere else. The claim is that you can build one object that is everything the relay keeps apart - the message, the settlement, and the asset itself, meaning the thing of value being moved, which in this course is almost always a claim on somebody, recorded on a ledger. Put that object on a ledger shared by everyone who needs to be paid in it, and handing it over stops being an instruction to pay. It is the payment, final in the same edit. Stablecoin issuers, commercial banks, central banks and asset managers all assert some version of this; they mean four different things by it; and every version can be tested rather than believed.
Three things, three places, three times
Pull the tap apart and the relay has three components, living in three places, moving at three different times.
The message lived on the card network’s systems: the authorisation in milliseconds, then the clearing files that night. Fast, expressive, and worth nothing by itself; lesson 1’s point was that the network keeps a log but holds no money.
The settlement lived at the central bank: reserves moving between the two banks’ accounts the next day, the moment the payment became final.
The asset - the money you actually spent and the shop actually received - lived on the two commercial banks’ ledgers as deposits: your bank’s IOU to you shrinking, the shop’s bank’s IOU to the shop growing.
Notice that lesson 5’s telegraph already fused two of the three. A wire collapses the message and the settlement into one operation: the instruction to the central bank is the ledger edit. But it fuses them only for reserves, the top tier of the map; only between banks; and only while the system is open. Your deposit cannot make that move. The tokenisation claim is the aggressive generalisation: fuse all three components, for any asset, any holder, any hour.
The object that is all three
You have seen this move before, in paper.
The phrase to press on is shared ledger. Your deposit today is already transferable, but only inside your own bank’s books; the moment the payee banks elsewhere, the relay reappears - messages between banks, then the banks settling at the tier above. A shared ledger is one that both payer and payee can hold entries on directly, whoever they bank with, so a transfer never has to leave it. That is what makes the one-edit fusion possible: the asset lives on the same ledger the payment happens on. How such a ledger is run, and who may post to it, is machinery this module deliberately leaves as a promise; Module 6 builds a working instance.
The first worked instance of the claim, and the one you will build there, is the stablecoin.
Who is making the claim
If tokenisation were one company’s pitch, this lesson would be shorter. It is closer to a claim the industry is making at itself, in four distinct versions.
Run lesson 6’s question over that roster - whose liability is it? - and the four versions come apart. An issuer’s token is a private claim on the issuer. A deposit token issued by a bank is a claim on that bank. Tier-1 tokens would be claims on the central bank itself. A tokenised fund share is a claim on the fund’s assets. The fusion trick is the same in all four; who stands behind the object, and how good their promise is, differs every time. That is why they are four products, not one.
Counting the failure windows
The claim’s sharpest testable content is not speed. Wires are already fast. It is the removal of a class of failure: the stranded, half-done state.
Enumerate the relay’s faults the way you would test any two-step protocol. The message either arrives or does not; the settlement either runs or does not. Four combinations. If the message never arrives, nothing downstream fires: the payment cleanly never happened, which is a failure, but an honest one. If both legs run, all is well. The dangerous state is the remaining one: the message delivered and acted upon - goods handed over, obligations recorded - while the money never moves. One stranded state out of four combinations, and much of the apparatus in the modules ahead, reconciliation, clearing deadlines, unwind rules, exists to manage it.
The fused object has two outcomes: the shared ledger accepts the transfer, delivered and settled in the same edit, or it rejects it and nothing happened at all. No input combination leaves a half-done transfer, because there is no gap between legs for one to live in.
Wider than the screen; scroll it sideways.
Check yourself
1. State the tokenisation claim in one sentence. What exactly fuses, and where?
A payment’s message, its settlement and the asset itself fuse into one transferable object on a shared ledger. Handing over the object is the payment, final in the same edit; it is not an instruction that a payment should happen elsewhere, later.
2. Lesson 5’s wire already collapsed the message and the ledger edit into one operation. What is left for tokenisation to claim?
Two extensions. Fedwire’s fusion covers only reserves - the map’s top tier - only between banks, and only in operating hours. The claim adds the third component, the asset itself (a deposit, a fund share), and extends the fusion to holders outside the banking tier, around the clock. The wire proves the fusion works for tier-1 money; tokenisation claims the trick generalises to everything below it.
3. Four classes of institution make the claim. Why are their versions four different products rather than one?
Ask lesson 6’s question of each token: whose liability is it? An issuer’s stablecoin is a private claim on the issuer; a bank’s deposit token is a claim on that bank; tier-1 tokens would be claims on the central bank; a tokenised fund share is a claim on the fund’s assets. The fusion mechanics are identical, but who stands behind each object differs, and what you hold is the claim, not the mechanics.
4. The relay has four fault combinations but only one stranded state. Why is “message lost, settlement runs” not a stranded state?
Settlement is downstream of the message: if the instruction never arrives, nothing triggers the money leg, both legs stay untouched, and the payment cleanly never happened. A clean nothing is a failure, but not a dangerous one. The stranded state is the message delivered and acted on while the money never moves - the gap between the legs, which is the only thing fusion removes.
5. Why does this lesson refuse to either endorse or dismiss the claim?
Because at map level the claim is not yet testable, and an untestable claim endorsed or dismissed is marketing in one direction or the other. It becomes testable once there is machinery to run it against: module 6 builds the fused object and stresses its promise, module 7 scores what fusion changes and what it cannot touch. The course’s register is to postpone the verdict until it can be computed.
Do this
Open code/transfer_race.py. It models the relay as relay_transfer(message_arrives, settlement_runs), two legs that can fail independently, exactly as in the section above. Your job is the # TODO(you) marker: implement fused_transfer(ledger_accepts) as one atomic step. Either the shared ledger accepts the object, delivered and settled in the same edit, or nothing happened at all; no input may strand a half-done transfer.
Before you run it, predict which of the relay’s four fault combinations will strand.
cd module-00-orientation
python3 code/transfer_race.pyThe starter raises NotImplementedError until you fill in the function. When your version is right, both assertions pass and the final line reads:
fused: 0 stranded state(s) out of 2 fault combinationsThe line above it reports the relay: 1 stranded state out of 4 fault combinations. If your prediction disagreed with the printout, work out which of you is wrong before moving on. The completed version is in solutions/transfer_race.py.
What you can now do. You can state the tokenisation claim precisely - message, settlement and asset fused into one transferable object on a shared ledger - rather than gesturing at “crypto” or “faster payments”. You can name the four classes of institution asserting it and tell their versions apart by asking whose liability the token would be. And you can count what the fusion removes: not slowness, but a class of failure - the one stranded state a two-leg relay can always produce and a one-edit transfer cannot. The next lesson shows how this course keeps a claim like this honest: every perishable fact dated, every asserted behaviour runnable.