It ain’t just about programmability – Bits on Blocks

I read with interest JP Koning’s post “Programmable money isn’t new, we’ve had it for ages“. As an independent monetary economist, JP is well worth following on Twitter, and his blog Moneyness is one of the most thoughtful sources of fact-based commentary on how money is evolving.

Although I agree with the post’s content, I feel it’s missing a few key points about public blockchain based money vs the programmability of payment instructions today. This post is a respectful response and addition to the narrative, and should be read after reading and appreciating JP’s post.

Guaranteed execution without bias

JP’s point about Microsoft’s payroll and accounts is that payment instructions are automated from Microsoft to its bank, and from its bank to Fedwire. So – he says – that’s programmable money: computers, not people make the instructions!

But that’s programmable payment instructions, not programmable money.

The bigger point is that every step relies on instructing a service provider which acts as a gatekeeper. Microsoft relies on its bank. Its bank relies on Fedwire.

Microsoft’s bank could change its terms and conditions. Or it could be down, or could refuse to serve Microsoft for ideological or political reasons, and pull the rug on Microsoft. Likewise Microsoft’s bank itself could be cut off from Fedwire for whatever reason.

So although the payment instructions are programmed and automated by the ‘owner’ of the money, the execution of those instructions are completely at the discretion of the service provider.

Public blockchain based money is superior to our current intermediated system in this respect, because your programs are not (well, they do not have to be) reliant on the whims of specific service providers who can change their mind at any time. In a public blockchain there is only one service provider, and that is the miners in aggregate. They receive your programs (smart contracts) and your instructions (transactions). If your transaction is technically valid, it executes without bias.

Designer Money

JP then describes what I would call designer money, or money within schemes that has been designed with constraints for specific uses, whether that is Covid related stimulus spending, government grants, or welfare money.

These schemes described have been expensive and time consuming to build, and only very few powerful actors can actually build them. They have been put together as one-off schemes: top-down driven, requiring collaboration of many parties with different interests. They are not easily, cheaply, and quickly replicable.

There are two points to consider:

1) Fees, glorious fees! The money still moves across the old rails – cards, payment processors, issuers, acquirers, banks, and central banks. Of course it does. The way we build schemes today is by adding another layer on top of our existing financial spaghetti. Each actor takes a cut. They won’t lift a finger unless there’s something in it for them. We should try to do better for the real economy.

2) The pace of innovation. It is slow to innovate like this – relying on the goodwill and effort of others in order to bring a scheme to life. We can do much better starting with a new fabric where anyone can build their own designs, that do not rely on incumbent gatekeepers.

Look, I am a big proponent of tools that can make it easier to implement schemes. There is a role for a a designer money system or platform that enables schemes to be created on demand. For example, once the system is in place, a government should be able to distribute $1,000 to each citizen that can only be spent on domestic tourism-related activities, and must be spent by year-end. With the right system in place, a scheme like this could be operational within in a day.

These designer money systems can be built on top of our existing financial infrastructure, or on new money ledgers such as CBDC ledgers or public blockchains.

Why public blockchains?

What’s the case for building them into public blockchains?

Openness and innovation.

Think about the long tail of smaller schemes that don’t exist today because they can’t. Say, one that a small business might want to dream up, or even that an individual might want to make? For instance perhaps I would like to give some money to a friend, money that can only be spent on their birthday, and only in restaurants. Well, there is no system that lets me do that today.

Eventually, someone will build a tool that makes it easy for anyone to create designer money schemes with constraints on how scheme money could be spent. The constraints can be who, when, how, or based on trigger events or contingencies. This will have to be done on public blockchain based money, because this degree of openness is not compatible with the interests of the existing financial complex. (I’d love to be proven wrong here, please DM me)

Open banking is not as good as composability

JP’s article then describes APIs for payment instructions. In particular, Monzo’s API that any of its customers can use, that allows integrations with other parts of the internet, via the If-This-Then-That (IFTTT) service.

While this is pretty cool, we still have the problem that anyone using Monzo’s API is dependent on, well, Monzo. This isn’t programmable money, this is programmable payment instructions that has been made easier for less technical people.

IFTTT is interesting because it allows customers to share “recipes” (analogous to snippets of code) between one another. You can code up some payment instructions such as “If I spend money at Domino’s Pizza, McDonalds, KFC or the local pub, then move £5 to my penalty pot.”. You can then share this recipe with me, so I can do the same thing or tweak it for my own use.

This is great! This allows people to copy and build on other people’s ideas. But what I can’t do is build on top of your program. I can’t, for example, build a recipe that says “If Bob’s penalty pot reaches £50, then move £10 of my money to Alice”. Nor can I build a recipe that relies on your recipe for inputs.

So while I can build my code using your code, I can’t build my program that runs on your program.

In public blockchain based finance, this ability for one program to interact with another program is known as “composability“. This is incredibly powerful, as it allows exponential improvements because you can trust the foundations on which you build on. This does not exist in traditional financial rails, and probably never will.

That’s another benefit of public blockchains.

Programmable financial services as public goods

A point that JP’s article doesn’t address is the ability to create apps that sit there and just run, doing as they say they do. This is more about programmable financial services rather than programmable money.

In traditional financial infrastructure, these service providers are companies. They are licensed, and they operate behind the shroud of secrecy, revealing only as much information as they are legally obliged to. (If you don’t believe that, try asking your bank for granular details of its balance sheet and trade by trade data).

In public blockchain based finance, these services are called smart contracts. Their operations (code) and balance sheet (state) are completely transparent to everyone.

And anyone can create these services, anonymously, without considering who else in the ecosystem might be annoyed because it eats their lunch and upsets the dynamics.

And it’s not just about annoying the ecosystem: anyone who works at a financial company will intuitively understand the conflicts within different departments of the firm when it comes to new products, because it might shift profits from one department to another. In public blockchain finance, it doesn’t matter. If someone wants to pop up a service, they can. This ultimately benefits the consumer.

And because the source code for these apps are available for anyone to study, reuse and improve upon, the speed of incremental iteration in public blockchain finance is on a different level to the speed of improvements in traditional finance. They are just incomparable.

Banks will never offer more complex programmability

Could a brave bank offer arbitrary programmability, more than just monthly recurring payments? Could they say “Ok any random person can upload code and we’ll run it”? No and no. There are too many reasons why not – they can’t interact with anonymous actors, they wouldn’t be comfortable with the liability, they don’t want to do tech support for “Please sir, my code didn’t work the way I intended, unwind the transaction please”. And the moment your money moves to a different bank, you’re now relying on the next guy to execute the instructions, and they might not want to do that or be able to do that.

No, it’s highly unlikely that this permissionless innovation will come from the existing financial industry: it has to come from outside.

Should regulators let this happen?

We are at the start of a promising evolution in how global finance can work, and I’d imagine that many nation states would want the cradle of innovation to be at home. If they outlaw it, financial innovation will move elsewhere, to another jurisdiction.

Most people working at regulatory agencies don’t want to upset the incumbents because they know their next job will be working for one of them. But today, regulators can be brave and do what’s right, because there are plenty of jobs in the new public blockchain industry. Read the room.

Reflection

Public blockchain based money isn’t just about programmability of payment instructions. Here are some important characteristics that public blockchain finance offers over traditional finance:

Permissionlessness. Innovation in financial services is hampered by barriers and conflicts within companies, the ecosystem, and in some cases, regulation. An unknown person in their pyjamas should be able to write a financial service program, and have anyone use it if they find it useful, given the transparency of operations (code), balance sheet (state), and payment instructions (transactions) in public blockchains.

Open source code. Software development has shown us the benefits of reusing code libraries instead of starting from scratch each time. With public blockchains, you can copy someone’s code and improve on it, providing a new independent, differentiated service. You can’t copy and paste a company as quickly as copying and pasting some smart contract code. This increases the speed of product innovation, resulting in benefits for consumers.

Service composability. Public blockchains give us the ability to build services on top of services. And because the operations of the smart contracts are (or can be) immutable, you can build with confidence that the service you rely on is not going to pull the rug on you, unlike in traditional finance – or for that matter, with traditional internet companies.