20 min

Putting credit on-chain

Tokenised credit runs a spectrum from receipt tokens with off-chain servicing to payment waterfalls executed in code, and the problems that remain are human ones: pricing illiquid loans, suing defaulters, and borrowers who still pay by bank transfer.

Where you are. You know a token is a wrapper and that the links to the world are the hard part. Credit is where those links are hardest, and it is also the second largest category of tokenised assets, so it is worth doing properly.

A fund lends to fifty small businesses. It wants to sell slices of that loan book to investors, and it wants those slices to move like tokens.

There are two quite different ways to do this, and the gap between them is where all the interesting engineering lives.

The idea in one paragraph

At one end, the token is a receipt: the loans and their servicing stay exactly where they were, a servicer collects payments into a bank account, and the token’s on-chain record is updated to reflect what the servicer reports. At the other end, the borrower’s payment arrives on the ledger itself and a program splits it down the priority order automatically, so the waterfall module 5 taught executes without anybody running it. The first is easy to build and inherits every reporting lag. The second removes the lag and demands that the money actually arrive on the ledger, which for a small business paying by bank transfer it does not. Most real implementations sit somewhere between, and where exactly they sit determines what can go wrong.

Measuring the gap

The exercise models both ends and measures the difference between what happened and what the chain knows.

A borrower pays on day five. At the on-chain end, the payment arrives at the program and the chain knows immediately: the gap is zero. At the receipt end, the servicer reports on day twelve, and for seven days the chain’s version of the world and the world disagree.

Seven days is not a rounding error when the token is being traded. Somebody bought or sold during that window at a price derived from a record that was known to be stale by whoever was doing the servicing.

What does not get fixed

Three problems survive every design on the spectrum, and they are the reason this category is harder than tokenised Treasuries.

Pricing is the first: a loan to a small business has no market price, so somebody has to value it, and tokenising it does not create a market that was not there. Enforcement is the second: when the borrower defaults, recovery means lawyers and courts in the borrower’s jurisdiction, and no program can repossess a delivery van. And the last mile is the third: the borrower pays from an ordinary bank account, on ordinary rails, with all the timing of module 2.

Why it grew anyway

Despite all of that, tokenised private credit is the second largest category on chain, which is worth explaining rather than dismissing.

The reason is that the buyers wanted access more than they wanted the plumbing. Private credit is an asset class that was hard for smaller investors to reach, held in funds with long lock-ups and high minimums. A tokenised slice is reachable and transferable, and both of those are genuine improvements even when the servicing behind them is exactly as manual as it always was.

That is the honest version of the tokenisation case here: the wrapper improved distribution, and distribution was the binding constraint.

Check yourself

1. Describe the two ends of the spectrum.

At one end the token is a receipt: loans and servicing stay off the ledger and the on-chain record is updated from a servicer’s reports. At the other, payments arrive on the ledger and a program executes the priority waterfall directly. The distance between them is how far the money is from the ledger.

2. A borrower pays on day five and the servicer reports on day twelve. What is wrong during those seven days?

The chain’s record and the world disagree, and anyone trading the token during the window is pricing a record that is stale. Nothing is broken in any detectable way; the record simply describes a state of affairs that ceased to be true on day five.

3. Name a problem in credit that no point on the spectrum fixes.

Any of three: pricing an illiquid loan with no market price, enforcing against a defaulting borrower through courts in their jurisdiction, or the borrower paying from an ordinary bank account on ordinary rails. All three are outside the ledger and none is a technology problem.

4. Given all that, why is tokenised private credit one of the largest categories on chain?

Because the binding constraint was distribution rather than servicing. Private credit was hard for smaller investors to reach, held in funds with long lock-ups and high minimums; a transferable slice solves that, and it solves it whether or not anything behind the token was automated.

Do this

Model both ends and measure the lag.

python3 code/credit_on_chain.py

The starter gives you both tiers and leaves you reconciliation_gap: the number of days during which the chain’s view and the world’s view disagree, which is zero when the report is not late. The assertions check that a same-day report leaves no gap and that a report on day twelve for a payment on day five leaves seven.

The completed version is in solutions/credit_on_chain.py.

What you can now do. You can place a tokenised credit design on the spectrum, measure the reconciliation gap its position implies, and name the three problems no position fixes. The next lesson asks what has actually been tokenised, in numbers.

What you can now do

You can model both ends of the spectrum and measure the reconciliation gap the receipt end leaves.