Where you are. Lesson 1 showed that no transaction spans two ledgers. Lesson 12 showed the popular workaround and what it costs. This lesson is the answer, and it has been the destination since the module opened.
The buyer has cash on ledger A. The seller has a bond on ledger B. Neither ledger can see the other, and neither party will go first, because going first means handing over an asset and hoping.
The trick is that neither of them has to go first. Both go halfway, and then one act finishes both.
The idea in one paragraph
Each side locks their asset on their own ledger, in escrow, releasable only by whoever presents a secret matching a published hash, and only before a deadline. The buyer, who chose the secret, claims the bond on ledger B, and doing so necessarily publishes the secret there. The seller reads it off ledger B and uses it to claim the cash on ledger A. If the buyer never claims, nothing is ever revealed, both locks expire and both escrows return home. There is no bridge, nothing was copied, and at no point did either party hold both assets or either party’s asset without their own still locked.
Wider than the screen; scroll it sideways.
Why the deadlines are different
The single most important detail is that the two locks expire at different times, and the ordering is not arbitrary.
The seller’s bonds must expire first and the buyer’s cash later. Consider what happens otherwise. If the cash expired first, the buyer could wait until the cash lock expired, refund their own cash, and then claim the bonds with the secret, taking both. The gap between the deadlines is what stops that: by the time the buyer could refund their cash, the bond lock has already expired and been returned to the seller.
The asymmetry is doing all the work. The party who knows the secret must be the one whose refund comes last.
What the exercise proves
Three runs. The happy path settles both legs and leaves each party holding what they wanted. The timeout path, where the buyer simply never claims, refunds both escrows and leaves both ledgers precisely as they began.
Then the two attacks: a claim with the wrong secret is refused, and a claim after the deadline is refused. The escrow stays where it is in both cases.
Notice that no participant is trusted anywhere in this. The seller does not trust the buyer, neither ledger knows the other exists, and there is no third party holding anything. The guarantee comes from the structure of the locks rather than from anybody’s promise.
What is actually running
That gap between the mechanism working and the mechanism being deployed is the honest state of this field, and it is worth holding onto through the next five lessons.
Check yourself
1. Why does neither party have to go first?
Because both go halfway. Each locks their own asset in escrow on their own ledger, and neither escrow can be taken without the secret. The trade completes when one act, claiming a leg, publishes the information that makes the other claimable.
2. Why must the bond lock expire before the cash lock?
Because the buyer knows the secret. If the cash expired first, the buyer could refund their cash and then still claim the bonds, taking both. Making the buyer’s refund the later one means that by the time they could reclaim their cash, the bonds have already gone home.
3. What is trusted in this protocol?
Nothing and nobody. The two ledgers do not know each other exists, no third party holds anything, and neither counterparty relies on the other’s good behaviour. The guarantee comes from the lock structure and the deadline ordering.
4. Both-or-neither is not the same as fair. What is the residual exposure?
Timing and attention. Once the secret is public, the seller must notice it and claim within their window, so they depend on watching rather than on the buyer’s honesty. Implementations run watchtowers for exactly that reason, because “somebody must notice” is a weak thing to depend on.
Do this
Settle the trade, then fail to.
python3 code/htlc_dvp.pyThe starter provides the lock and refund paths and leaves you claim: refuse unless the lock is unsettled, the deadline has not passed and the secret matches the hash; then move the escrow and record the secret on that ledger. The assertions check the happy path settles both legs, the timeout path restores both ledgers exactly, and that a wrong secret and a late claim are both refused with the escrow untouched.
The completed version is in solutions/htlc_dvp.py.
What you can now do. You can settle a trade across two sovereign ledgers with a both-or-neither guarantee, explain why the deadlines are asymmetric, and name what the protocol still depends on. The loop module 3 opened is now closed. The rest of the module builds on top of it.