22 min

The tokenised dollar

A stablecoin is a token whose issuer promises one unit of ordinary money per token, with a real dollar of reserve assets behind each one; sending it fuses the message and the settlement into a single step.

Where you are. Module 0 named the tokenisation claim and left it deliberately untested: that a payment’s message, its settlement and the asset itself can be fused into one transferable object. Lesson 1 built the container. This lesson puts a dollar in it, and the claim starts being testable.

A dealer wires a million dollars to an issuer. The issuer creates a million tokens and sends them to the dealer’s address on the shared ledger. The dealer sends a hundred thousand of them to somebody else, and that person now has them; not a promise of them arriving tomorrow, not an instruction that a bank will act on, but the balance itself.

That last sentence is the one worth pausing on. In module 2 the message and the money were different things travelling on different rails at different speeds, and a great deal of machinery existed to keep them in step. Here they are the same object.

The idea in one paragraph

A stablecoin is a token on a shared ledger whose issuer promises that it is always worth one unit of ordinary money, and holds a portfolio of real assets so that the promise can be met. Sending one is a single posting: the message that a payment is happening and the settlement of that payment are the same event, which is what module 0 meant by fusing them. The token is a liability of the issuer, exactly like a deposit is a liability of a bank, so everything module 1 taught about whose failure you are exposed to applies unchanged. What has changed is the plumbing between you and the person you are paying. What has not changed is that you are holding somebody’s promise.

The invariant, and the check that misses it

The issuer’s balance sheet has tokens on the liability side and reserve assets on the asset side. So far this is just module 1’s picture with different labels.

The interesting part is that the balance sheet balancing is not the promise. A balance sheet balances whenever assets equal liabilities plus equity, and there are many ways to keep that true while the token holders are worse off. Create a token out of nothing and reduce equity by the same amount: the sheet still balances perfectly, and there is now one more token than there are dollars behind it.

So the one-to-one promise needs its own check, separate from the ledger’s own invariant, and the exercise makes that separation concrete. It creates a token with no dollar behind it, balances the sheet with an offsetting entry so the ledger’s own assertion stays quiet, and then shows that only the backing check objects.

What the fusing does not remove

The message and the settlement are fused, and it is worth being precise about where that stops being true.

Inside the ledger, a transfer is one posting and there is nothing left to reconcile. At the edges, nothing has changed. Getting a dollar in means an ordinary bank payment to the issuer over the rails of module 2, with all their cut-off times and their reversibility. Getting a dollar out means the same in reverse. The fused step sits in the middle of an unfused sandwich, and the slow, expensive parts of moving money between the ordinary banking system and the ledger are exactly as slow and expensive as module 2 said they were.

That matters for a claim you will meet constantly: that tokens make payments instant and nearly free. Within the ledger, between two parties who both already hold tokens, that is true. End to end, from one bank account to another, it is true only for the middle leg, and the ramps at either end are the part that has not been fixed.

How big this is

Set that against the deposits in the banking system and it is small. Set it against the reserve assets it implies, and the issuers are collectively among the larger holders of short-dated government paper, which is why lesson 4’s business model is worth understanding and why regulators started paying attention.

Check yourself

1. In what sense does a stablecoin fuse the message and the settlement?

Sending one is a single posting on the shared ledger. There is no instruction that travels separately from the value and then has to be reconciled with it, as there was on every rail in modules 2 and 3. The message that the payment is happening and the settlement of it are one event.

2. The exercise adds a token and reduces equity by the same amount. The balance sheet still balances. What has gone wrong?

There is now one more token in issue than there are dollars of reserve assets behind them. The ledger’s own invariant is about postings balancing, which this respects. The one-to-one promise is a separate property and needs a separate check, which is exactly what the exercise demonstrates by making one pass while the other fails.

3. Why does this course say “reserve assets” rather than following the industry and saying “reserves”?

Because module 1 already used reserves for a bank’s balance at the central bank, and the two are entirely different: different tier, different issuer, different risk. Reusing the word would quietly merge two concepts the course has worked to keep apart. When reading real disclosures you will meet both senses and have to disambiguate them yourself.

4. A holder is exposed to whose failure?

The issuer’s. The token is the issuer’s liability, in exactly the way a deposit is a bank’s liability. The shared ledger changes how the claim moves; it does not change who owes it or what happens to you if they cannot pay. That is why the next lesson is about legal structure rather than technology.

Do this

Build the issuer and try to break its promise.

python3 code/tokenised_dollar.py

The starter leaves you assert_backed, the check that tokens in issue equal reserve assets held, and transfer, which refuses to move tokens a holder does not have. The assertions check that transfers move tokens without creating them, and that a token minted with no dollar behind it is caught by the backing check even though the balance sheet still balances.

The completed version is in solutions/tokenised_dollar.py.

What you can now do. You can build a token issuer on the shared ledger, enforce one-to-one backing as an invariant of its own, and explain why a balanced balance sheet does not imply a kept promise. The next lesson asks where the reserve assets actually sit when the issuer’s parent company fails.

What you can now do

You can build an issuer whose one-to-one backing is checked after every posting, and say why a balanced balance sheet does not check it.