The principle of least power

In 1998, Tim Berners-Lee, inventor of the World Wide Web, outlined the principle of least power: Applications and systems should be designed using the least powerful technology that supports the intended purpose. In other words, don't use a sledgehammer to crack a nut.

The same is true for financial transactions. Let's talk about programmability.

What is programmability?

Some distributed ledgers, such as Ethereum, have the capability to deploy and run smart contracts. The oft-cited definition by Nick Szabo, who coined the term, goes as follows: a smart contract is “a set of promises, specified in digital form, including protocols within which the parties perform on these promises.” This definition predates public blockchains, and Bitcoin specifically, which is why it does not reference (distributed) ledgers. Arguably, Ethereum, which was introduced in 2013, refined and popularised the concept of smart contracts.

Put simply, rather than transactions that merely move assets from A to B, Ethereum introduces two new kinds of transactions: creating a smart contract and executing a smart contract. With the benefit of hindsight, Xu, Weber and Staples define smart contracts as “programs deployed as data in the blockchain ledger and executed in transactions on the blockchain.” Crucially, these programmes are “immutable once deployed.”

In practice, the data managed by smart contracts is typically organised around the concepts of “ownership” and “assets”. Therefore, we can think of Ethereum participants as owning a set of assets, with smart contracts governing their transfer, usage, and management.

Smart contracts vs. programmability

Despite Szabo's definition of smart contracts being relatively old, they are often associated with DLT, and are sometimes even declared to be one of its defining characteristics. However, smart contracts—or more broadly, programming capabilities—can also be considered independently of the nature of the ledger. Similarly, the CPMI notes that DLT is “one of the technologies” that enable programmability.

It is therefore natural to arrange different programmability “styles” in a hierarchy. The highest tier would offer the strongest technical capabilities, whereas the lowest tier would provide no programmability at all.

The following diagram shows such a hierarchy, based on definitions in the literature (Lee; Bindseil, Coste, and Pantelopoulos).

Some examples:

• Cash is not programmable, nor are RTGS typically (unless you count queueing mechanisms).

• Some—but not all—retail CBDC designs envision programmable payments, such as the digital euro. Platforms that allow for automating deposit transactions also fall into this group.

• Specific stablecoins are programmable money, as is Bitcoin. Ethereum allows anyone to create their own stablecoin or stablecoin-like asset.

• Ethereum and Solana are major smart contract platforms.

Don’t use a sledgehammer to crack a nut

The principle of least power applied to programmability gives rise to an exceedingly simple rule: use the lowest possible tier in the hierarchy.

More specifically, if a use case can be implemented using mere programmable payments, it should not be implemented using smart contracts.

To illustrate the spirit of this rule, let me provide a financial analogy.

Consider interbank settlement: between two domestic banks, settling obligations with central bank money directly is preferable to using correspondent accounts, clearing houses, or other bilateral arrangements. This also explains why private instant payment systems are increasingly being complemented with systems backed by central banks. It is only when multiple currencies are involved that more complexity is required. Similarly, two foreign banks would prefer to settle in USD using Federal Reserve accounts if available; and only if not, fall back to using Eurodollars.

A more involved example involves a swap. As Perry Mehrling describes, “[t]he first [...] swaps were arranged as parallel loans, and this parallel loan construction remains the most straightforward way to understand them.” Take an interest rate swap, where one party borrows at a fixed rate and lends at a floating rate, and vice versa. This can be constructed by two parties lending each other the same principal at different interest rates (parallel loans). Consequently, the net flows in the contract would be to the difference between the floating and fixed rates, which would change over time.

This works, but has a significant drawback: even though net flows are much smaller than the principal, the parallel loan structure expands “both balance sheets, and so the apparent leverage and counterparty risk exposure.” A better solution is to agree to pay the difference in rates only, because the principal nets to zero. This removes the principal amount from the balance sheet, thereby reducing exposure.

Principle of least complexity

The principle of least power can also be equivalently called the principle of least complexity, because power begets complexity. In the above example, it means that a swap is preferable to a parallel loan structure due to its smaller footprint on balance sheets and lower risk. In other words, unless there is a good financial or economic reason, the least complex instrument should be used.

The same is true of programmability, where it is compounded by the fact that users of a smart contract platform cannot opt out of the high complexity. Specifically, it is not possible to interact with a stablecoin on Ethereum as if it were unprogrammable. Moving assets onto a programmable ledger imposes this complexity on all users.

Smart contracts can’t do everything

Many financial instruments involve multiple transactions, such as payments, over time. For instance, bonds may incur fixed monthly coupon payments, while futures may incur variable daily margin adjustments. Sometimes, these transactions include sub-transactions that must occur at the same time: in a repurchase agreement, a cash payment and a security delivery happen simultaneously at time T (purchase), and reversals happen simultaneously at time T + 1 (repurchase).

Unless all (sub)steps are funded in advance, smart contracts cannot guarantee full execution—i.e., uphold all promises to pay—over time.

Therefore, any financial agreement where a party might default on their promises cannot benefit from risk reduction through programmability. To wit: for a bond implemented through a smart contract, lenders could still fail to collect coupons because the borrower simply does not have enough funds in their wallet.

It appears that the financial literature is slowly coming to this conclusion, too. Bindseil and Malekan point out that arrangements implemented in smart contracts are usually overcollateralised to allow for liquidation. This works for a repo, but not for a bond.

Conclusion

Financial market infrastructure is undergoing dramatic changes. Existing systems are gaining new features and completely new systems are being designed. Often, this is technology-driven: if we have DLT and smart contracts, why not use them?

These technologies have advantages. They have the potential to automate many types of financial transactions, including intricate contracts.

However, I have argued that this also comes with disadvantages. Greater capabilities also introduce greater complexities that can be harder to manage. They also introduce novel financial risk.

Rather than a technology-driven approach, I suggest a use-case-driven approach. From that perspective, we can apply the principle of least complexity. This principle serves the World Wide Web well; and it will serve financial markets well, too.

This post has also been published on LinkedIn.