Where you are. Lesson 12 wrapped an asset that existed elsewhere and found three fragile links. This lesson removes the elsewhere: the security is issued on the ledger in the first place, so there is no underlying to keep in step.
Module 4 introduced the post-trade chain and module 5 added the clearing house. Recall the shape: a trade is agreed, a broker handles it, a clearing house nets it, a depository holds the definitive record, a custodian holds it for you, and settlement lands the next day.
Every link in that chain exists to solve a problem that a shared ledger solves differently. So what happens if the security starts life as a token?
The idea in one paragraph
A natively issued token security puts ownership in the contract itself, so the depository’s record and the custodian’s record and your record are the same record, and the chain of institutions maintaining separate copies of who owns what disappears. Settlement against payment becomes one transaction that either completes on both legs or neither, which is module 3’s delivery-versus-payment property achieved by construction rather than by a settlement system. What does not disappear is everything about the security being a regulated instrument: it still has to be registered, transfer restrictions still have to be enforced, and somebody still has to check that a buyer is allowed to buy. Those move into the transfer path rather than vanishing.
Wider than the screen; scroll it sideways.
The rule in the code path
The exercise issues a security with a whitelist and settles a purchase against the module’s own token dollars.
The interesting part is where the rule lives. In today’s arrangement, “this buyer is permitted to hold this security” is checked by a broker, a transfer agent or a custodian, at some point in a process, by a system that could in principle be bypassed. Here it is in the transfer function: a transfer to an address outside the whitelist raises rather than settles. There is no path around it, because the transfer and the check are the same operation.
That is a genuine improvement and it is narrower than it sounds. The rule is enforced perfectly; deciding what the rule should be, and who belongs on the list, is exactly as manual and as judgement-laden as it ever was.
Both legs or neither
The settlement half reuses module 3’s rule directly.
The exercise funds a buyer with token dollars, settles a purchase of units against them, and checks that both sides moved. Then it attempts a second purchase the buyer cannot fund, and checks something more specific than a refusal: that the cash ledger is byte for byte what it was before the attempt. A partial settlement that moved the cash and failed on the securities would be the exact failure module 3 named after Herstatt, and the assertion is written to catch it rather than to catch a mere exception.
The ramps are still the ramps
One number in the exercise is worth noticing because it is doing quiet work: the buyer pays with token dollars that were already on the ledger.
That is where the settlement’s elegance comes from and where its limit sits. Both legs are on one ledger, so both can move in one transaction. Get a leg off the ledger, and the atomicity goes with it: paying for a token security from an ordinary bank account means an ordinary payment, on module 2’s rails, with a gap between the two legs and somebody carrying the risk across it. The property being demonstrated is a property of assets that share a ledger.
That is why this module built the token dollar before it built the token security. It is also why module 7’s final problem is the interesting one: two assets on two ledgers that cannot see each other, and the same both-or-neither guarantee to establish across them.
What survives, and why
Three things survive every design in this space, and they are worth naming because they are what turns an interesting demonstration into a usable market.
Registration survives because a security is a regulated instrument and somebody must be answerable for the register. Transfer restrictions survive because the reasons for them, sanctions, investor eligibility, lock-ups, are legal rather than technical. And intermediaries survive in a reduced form, because somebody has to onboard the participants, decide the whitelist and answer when it is wrong.
What has genuinely gone is the reconciliation. Several institutions each keeping their own copy of who owns what, and a daily process to make those copies agree, is the part the single shared record removes.
Check yourself
1. What does native issuance collapse, and what is the property it gains?
It collapses the chain of institutions each maintaining a separate record of ownership into one shared record, and it gains atomic delivery against payment: both legs complete or neither does, by construction rather than by a settlement system arranging it.
2. The whitelist check sits in the transfer function. Why does that matter more than where it sat before?
Because the check and the transfer are the same operation, so there is no path that performs one without the other. Previously the check ran alongside the transfer in a process that could in principle be bypassed. Enforcement becomes structural rather than procedural.
3. The exercise asserts that a failed purchase leaves the cash ledger unchanged. Why is that stronger than asserting it raised an error?
Because the failure worth catching is a partial settlement: cash moved, securities did not. An exception can be raised after one leg has already been posted. Comparing the whole cash ledger before and after is what actually establishes that neither leg happened.
4. Name something that does not collapse.
Registration, because somebody must be answerable for the register of a regulated instrument; transfer restrictions, because their reasons are legal rather than technical; and the ramps at either end, which are module 2’s rails with module 2’s timing. What genuinely disappears is the reconciliation between separately held records.
Do this
Issue it, restrict it, and settle against cash.
python3 code/security_token.pyThe starter leaves you transfer: refuse when either party is outside the whitelist or the sender lacks the units, and post it otherwise. The provided settlement function does both legs or neither. The assertions check that a transfer to an unknown address is refused, that a funded purchase settles on both sides, and that an unfundable one leaves every cash balance exactly as it was.
The completed version is in solutions/security_token.py.
What you can now do. You can issue a security whose transfer rules are enforced in the transfer path, settle a purchase atomically against token cash, and say precisely which parts of the post-trade chain collapse and which do not. The next lesson sorts everything this module has built into two questions that are constantly confused.