Where you are. Eleven lessons of money in token form. From here the module widens: not money, but things. A bond, a loan, a warehouse of gold. The mechanics are the same and one new problem appears immediately.
A company issues a bond. It exists: a legal instrument, a schedule of coupons, a borrower who owes money, courts that would hear a dispute about it.
Somebody wraps it in a token. One token, one bond, tradeable on a shared ledger at three in the morning.
Ask the question that matters: if the borrower stops paying, what does the token do?
Nothing. The token is a record on a ledger. It has no view about whether the coupon arrived, because the coupon arrives in a bank account belonging to somebody else entirely.
The idea in one paragraph
Tokenising an asset changes how the claim transfers and settles, and changes nothing about what the asset is, what it is worth, or whether the person who owes you money will pay. Between the token and the asset sit three links that have to work: custody, meaning somebody actually holds the thing; legal claim, meaning holding the token entitles you to it in a way a court would enforce; and servicing, meaning somebody observes what happens to the asset and reports it. Those three are where the difficulty lives, they are all off the ledger, and none of them is a technology problem. The token is the easy part, and that is the whole lesson.
Wider than the screen; scroll it sideways.
Dropping one report
The exercise wraps a synthetic bond and drives four quarters through a servicing feed, dropping exactly one of them.
The borrower pays all four coupons. The token records three, because the feed did not report the third. Nothing failed on the ledger, no posting was wrong, and no arithmetic broke. The token is simply telling a story that is now twenty-five pounds different from what happened in the world.
| run | paid in the world | recorded on chain | gap |
|---|---|---|---|
| feed working | 100 | 100 | 0 |
| one report dropped | 100 | 75 | 25 |
n = 2 trials · four quarterly coupons, one servicing report dropped
What the wrapper genuinely buys
Being clear about the limitation should not obscure the gain, which is real.
The transfer becomes final in one step at any hour, without the chain of intermediaries module 3 built. The claim becomes divisible far more finely than the underlying was. Settlement against payment becomes atomic, which is the property module 3 spent a whole lesson wanting. Those are real improvements to how the claim moves.
They are all improvements to movement. None of them improves the asset, and none removes a single one of the three links.
Check yourself
1. The borrower stops paying. What does the token do about it?
Nothing by itself. The token is a ledger record with no way to observe the world; it learns about the missed payment only if a servicer reports it. The economic consequence lands on the holder exactly as it would have without tokenisation.
2. Name the three links between a token and the asset it represents.
Custody, meaning somebody holds the thing; legal claim, meaning holding the token entitles you to it enforceably; and servicing, meaning somebody observes and reports what happens to it. All three sit off the ledger, and all three are the hard parts.
3. The exercise drops one servicing report. Why is that failure hard to notice?
Because nothing detectable goes wrong. Every posting balances, no invariant breaks, and the ledger’s own checks all pass. The record is simply no longer a true statement about the world, and the ledger has no means of discovering that.
4. Why is “trustless” the wrong description for a wrapped real-world asset?
Because it removes the need to trust a counterparty on a transfer, and leaves every dependency between the token and the asset intact: the custodian, the legal structure and the servicer. For a real-world asset those are most of the trust in the arrangement, so the label describes the smallest part of it.
Do this
Wrap a bond and break its feed.
python3 code/wrapper.pyThe starter wraps the bond on the miniledger and leaves you the quarterly step: the on-chain record only learns about a coupon if servicing_feed reports it. The assertions check that a working feed leaves no gap and that one dropped report leaves the token twenty-five behind the world, with no error raised anywhere.
The completed version is in solutions/wrapper.py.
What you can now do. You can name the three links between a token and its asset, explain why a ledger cannot verify any of them itself, and demonstrate a divergence that raises no error. The next lesson applies this to credit, where the servicing problem is at its worst.