Project Lithium

The DTCC's quest for atomicity

The Depository Trust and Clearing Corporation is a key part of the infrastructure of US capital markets, the largest provider of clearing and settlement services for securities transactions. Last week, DTCC announced Project Lithium, a plan to build a prototype system for exchanging central bank digital currency and tokenized assets on a distributed ledger.

Project Lithium is a sober but significant experimental upgrade to the financial plumbing—not crypto, exactly, even if that is how some of the technology made its debut. DTCC measures its daily flow of securities transactions in the trillions. It is custodian to $90 trillion in securities. And it is very much inside the regulatory perimeter. In other words, Project Lithium joins a group of not-exactly-crypto experiments by the big commercial banks and central banks.

DTCC’s staff surely have their hands full monitoring a $2 quadrillion annual flow of securities transactions. If they are willing to spend time on a prototype, they must have specific benefits in mind. The press release points to DTCC’s delivery versus payment services, and so this post looks at DvP and what Project Lithium hopes to achieve.

The underlying problem: trade credit

DvP solves a special case of a problem that arises in all exchange, not just in capital markets. Any transaction can be thought of in three basic steps (which I learned from Hicks’s Market Theory of Money): the two parties must agree on the terms, the buyer must make payment, and the seller must deliver the item being sold. Agreement cannot easily come after payment or after delivery, but otherwise the sequence is flexible.

These T accounts illustrate. First, an agreement is made, creating a pair of obligations—the seller promises to deliver goods, and the buyer promises to pay. Then (in this example), the seller delivers goods, fulfilling their obligation. Finally, the buyer pays and the invoice is closed out:

Agreement, payment and delivery can happen all at once, as in a spot transaction. Other arrangements are also commonly used. A commercial transaction, for example, might require payment 30 days after delivery. Between delivery and payment, the outstanding invoice is a form of unsecured lending from the seller to the buyer:

Delivery versus payment

For sellers, having to wait for payment is inconvenient and costly, and so various forms of trade finance have arisen over the centuries to bridge the gap. But the same general problem requires more delicacy in the wholesale financial markets served by DTCC: the quantities and values are very large, margins are low, and there is no tolerance for risk.

Instead of extending trade finance, delivery versus payment enforces a close link between the second and third steps in the transaction: delivery (of securities, in this case) and payment (of money). To do so, DTCC holds custodial accounts of both money and securities for both buyer and seller. It places a lock on the buyer’s money and the seller’s securities until both sides have been funded, then posts the two legs of the transaction at the same time. There are several versions (pp. 153ff.) of this idea, differing in how they allow periodic netting of one or both transaction legs.

Tokenization and atomicity

Even though DTCC is well practiced and deals in huge volumes, DvP remains costly to arrange, not unlike the unwieldy chains of correspondent banks that international payments often require. So it having a go at Project Lithium, a test of the tokenization thesis: Maybe a distributed ledger using digital bearer instruments is better than a centralized ledger using identity-based accounts. Maybe not.

Programmable contracts would allow an automatic and verifiable link between delivery and payment, and so enable atomic settlement, creating a deep and inseparable link between the payment and delivery steps of each trade. DvP would then be part of the system’s design, rather than a separate service. Programmable contracts are possible only on a distributed ledger, where both parties independently reach the same result and can verify that this is the case.

The use case is at the core of the financial system, it is a problem needing a solution and not the other way around, and the project is not being particularly hyped. The tide of such projects is rising and seems to need a good name. “Crypto” won’t do anymore, and “enterprise blockchain” is no better. Any suggestions?

Previously on Soon Parted

• Variation margin

• The tokenization thesis

• Project Jura

• JPM Coin