Programmability: looking beyond smart contracts

Few topics in the digital currency space are as hotly debated as programmability. It is widely seen as a key feature of tokenization, particularly in digital currencies, transforming money from an instrument of value transfer into a powerful tool for automation, efficiency, and innovation, opening the door to entirely new financial products and services.

However, this promise comes with concerns. Programmability is not just a technological innovation. It also raises fundamental questions about authority, control, and privacy. 

Let’s look closer into what we mean when we speak about “programmability”: “Programmability in payment and settlement systems refers to the ability of computer programs to control and automate system behavior when funds and securities circulate,”¹ stated a Bank of Japan paper in 2022. In the intervening years, that definition has evolved. 

Levels of programmability

There are different levels of programmability when it comes to the transfer of values. To illustrate:

• Cash is not programmable at all.
• Programmable payments refer to the ability to automate when, how, and under what conditions payments are made. For instance, a payment is released upon delivery confirmation. Some retail CBDC designs include programmable payments, while others do not.
• Programmable money goes a step further by embedding the logic and rules to execute payments directly into the assets. Digital money can carry embedded instructions that determine how it can be spent, transferred, or used. For example, it can be restricted to purchasing specific goods. One prominent example is Bitcoin.
• Smart contracts enable full programmability on blockchains. Platforms like Ethereum and Solana are major examples that provide smart contracts.

Programmability can take many forms, clearly. And not every programmable solution truly requires a smart contract.

Before going further, let’s consider smart contracts in some more detail.

The smart contract question

The cryptographer and theorist Nick Szabo coined the term “smart contract” in 1994, when Bitcoin didn’t even exist. He defined it as “a computerized transaction protocol that executes the terms of a contract.”

Over time, the definition has evolved to become more specific. As Lars Hupel, Chief Evangelist at G+D, explained, “a smart contract is immutable code which is executed and whose data is kept wholly within the blockchain.”

An example here helps to illustrate how this works. In Ethereum, a smart contract is a dedicated account with its own identity and balance. It is not attached to a particular person but rather has an identity of its own. It may store any amount of data, such as certain values or account information, and it can also react to external inputs. But it cannot access off-chain data and has no ownership. At least in Ethereum, it does not act by itself. 

A smart contract needs to be triggered by specific events or actions. By contrast, “normal” software typically runs continuously or according to a schedule and can be directly controlled by a user or system. 

The legal status of smart contracts is a topic of ongoing debate.² Some argue they do not constitute legally binding agreements. Their use in retail transactions in Europe, for instance, is limited by requirements like the contracts having to be drafted in the local, natural language. 

Smart contracts are gaining traction in B2B contexts, however. Businesses see them as a tool for modernization. Among other ways, they achieve this by: 

• Automating processes,
• enhancing efficiency through streamlined cross-border operations, and
• reducing costs through the elimination of intermediaries and manual tasks.

This raises the question of whether we absolutely need smart contracts. The answer isn’t clearcut. As with so much else, it depends upon context.

Matching tool to task

Tim Berners-Lee, inventor of the World Wide Web, famously advocated for the principle of least power. This principle calls for the use of the least powerful – that is, the least complex – programming language or technology that can achieve a given purpose. The goal is to promote simplicity and interoperability.

That same principle can be applied to programmability and financial transactions. In essence, using a smart contract in a use case where a simpler solution does the job would be overkill. Let’s look at some examples to illustrate how this would work in practice.

Retail conditional payments are often cited as a use case for smart contracts. In this scenario, a customer would already pay when making the purchase, but the payment is only released to the online vendor when the package arrives.³ But the same outcome can be achieved with a programmable payment.⁴ A smart contract isn’t the best option here as 

1. The smart contract cannot access the actual delivery status, and
2. the customer may not want to lock the payment in a smart contract immediately upon order, instead only paying upon receipt.

Purpose-bound money like food vouchers or targeted subsidies are also an area of interest. Some central banks have proposed using programmable money to achieve this. In this scenario, the money itself would contain conditions that define its use.⁵ As a result, certain items could be purchasable with this currency, whereas others would be restricted. However, this approach undermines one of the fundamental appeals of public digital currency: its “cash-like” characteristics such as universal usability. A “smart wallet” is an alternative here: conditions could be attached to wallets instead of to the money. Once the money has been paid for a specific purpose and transferred to another wallet, the recipient can use it freely for any purpose.⁶

Cross-border payments, where money is sent and received in different currencies, are fraught with inefficiencies. These arise due to different operating hours, lack of liquidity, and long chains of intermediaries. Smart contracts have been proposed to provide instant settlement in foreign exchange. However, this can also be achieved through programmable payments. The payment is split into two parts, for example US dollars and British pounds. Both parts are created as pending transactions, with the GBP payment being completed once the corresponding USD payment arrives.⁷

Programmability is reshaping the landscape of digital currencies and tokenized payment systems. However, it is also clear that not every use case requires the firepower of a smart contract. 

“Smart contracts aren’t always the answer: sometimes a simpler option is still the best,” noted Hupel.

By applying the principle of least power, solutions can be tailored – whether as programmable payments, programmable money, or smart contracts – that match the needs of diverse scenarios. The future will likely see multiple approaches to programmability. Striking the right balance will be essential to unlock the full potential of digital currencies, while preserving trust and user autonomy.

Published: 30/06/2026