Clearing Is a Distributed System Problem and That's Bad News for Stablecoins

That all financial transactions rely on trust is nothing new. Just how far we need to trust the other party however, makes all the difference. Banks trust each other by default when they blindly accept the results of some externalised clearing process. We all trust the stock-exchange to be an impartial arbiter of races. This is why front running is illegal and why so many feel cheated by high-frequency trading.

Ever since payments have been exclusively digital, we haven’t dealt with the problem of money moving between different systems. Internally, (well-designed) systems can make good sense of how a transaction affects two counterparties, but these promises break down as soon as we need to step outside. Enter clearing. Clearing means we trust some central third-party to be an impartial judge. They shoulder the responsibility of knowing the other side our transaction well enough to trust with the amount of money being exchanged or (if some threshold is exceeded) reject the transaction.

With banks, that’s a clear setup with well established institutional boundaries. Stablecoins however, are a different matter. They are defined by the GENIUS Act as

(6) DIGITAL ASSET. — The term “digital asset” means any digital representation of value which is recorded on a cryptographically-secured distributed ledger.

Some people take this to mean a completely decentralised crypto-platform like Bitcoin, but the text doesn’t go this far. “Ledger” implies that it needs to be appendable, but it doesn’t state that it needs to be appendable by anyone, the way cryptocoins are. This makes all the difference, but the reasons for this are not very intuitive.

If a Digital Asset can be openly traded by anyone owning a piece of the value it represents, this means that anyone following this ledger must be able to tell genuine (trustworthy) transactions from failed (untrustworthy) ones. This is mostly what crypto-protocols are about. This setup however, only guarantees that payments made between two counterparties participating on the same platform can be verified, not that transactions between different platforms can.

So, what are the options here?

Make everyone have a presence on each Digital Asset

Joe wants to send money to Jill, but Joe has a wallet on A and Jill has one on B. What if we auto-generated an account for Joe on B when he initiates payment? If Stablecoins are like crypto, we can presume we can ignore the “know your customer” rules in banking and we can just create new accounts at will.

Joe starts the payment process. A makes a request to B. This creates Joe’s temporary account on B with the provided cash amount and deducts the money from Joe’s account on A. Once the new account was created (on B) the rest is entirely A’s problem, which we know how to deal with. Problem solved, right?

No, unfortunately. This transaction implies two steps on A. First: ring-fencing the amount from Joe’s account, then waiting until B has cleared the transaction, after which A can decrease the balance of Joe’s account. This process is called earmarking and is the fundamental building block of transaction-correctness in payments.

It’s also nonviable here.

Clocks, time and changes

To use earmarks, we need a way to know when to free up the ring-fenced amount in case a failure occurs. Failures can (and often do) happen in payments due to a number of reasons. Communication-channel problems are the most frequent, but what if upon receiving the request from A, B finds that Jill doesn’t even have an account on its platform? B would send a response to A to cancel the transaction, but what if B’s answer doesn’t reach A? What if a bug in the system that should be actively responding to A’s request stops the response from going out?

This is a well-known problem in computer science, called The Two Generals Problem. The fact is, we can’t (and we don’t in real banking systems) rely completely on external signals to complete our payment process.

To address this, we do two things in traditional banking. We establish some mechanisms that make sure that payments which failed in this way are known to our responsible staff and make sure that (in the end) a real (trustworthy) human decides what eventually happened with the money by picking up the phone and calling the other (trustworthy) human to figure out if the payment was made or not.

Imagine doing this with Bitcoin transactions.

Solution

We have two fundamental problems here:

• We don’t want to involve humans in the clearing process, since that implies a central authority looking over these transactions, which is anathema to the spirit of the law
• We don’t have a shared concept of “time” between different ledgers, which would allow us to identify “failed” transactions the way we do now in payments

If the problem comes from decentralisation, the solution must also come from that. Luckily, both of these problems have established solutions, but they require a new kind of computer science: one that doesn’t rely on exclusivity of information anywhere in the system.

More on that in our next article.