“Programmable money” is, without doubt, one of the major buzzwords in the blockchain space in 2020. Even though everyone seems to talk about it, we still lack a clear definition and hence common understanding of this term. In this article, we present a taxonomy of programmable money. In particular, we argue that “programmable money” has to be differentiated from “programmable payments”. To make this distinction as clear as possible, we develop a framework in which we decompose the payments value chain into three pillars: the contract execution system, the digital payment infrastructure, and the monetary unit. — Alexander Bechtel, Jonas Gross, Philipp Sandner, Victor von Wachter
Programmable payments
The terms “programmable money” and “programmable payments” are often used interchangeably, even though they mean different things. Programmable payments are payments that are automatically executed after certain conditions are met. Thus, these payments are automated and follow an inherent, predetermined logic. Programmable payments already exist in today’s banking system, for example, in the form of standing orders and direct debits.
However, it is difficult to implement complex logic into these payments and hence their flexibility is limited. In this context, smart contracts based on distributed ledger technology (DLT) offer more degrees of freedom. With the help of smart contracts, even complex business processes can embed automated payments.
For instance, in the Economy of Things (EoT), autonomous e-cars will drive to the next charging station, negotiate a price, carry out the charging process and then make a payment. The payment will be split directly and transferred to all stakeholders according to a predefined key (e.g., 70% to the electricity provider and 10% each to the charging station manufacturer, the gas station operator, and the car manufacturer). This payment is managed by a smart contract and is therefore automated and programmed.
Three key features of smart contracts
To clarify the understanding of smart contracts, we rely on how smart contracts are realized on the Ethereum platform. In short, such smart contracts mainly have the following three features:
1st feature of smart contracts: programming capabilities. Smart contracts enable programmable payments triggered by arbitrary logic. For the remainder of this article this is the key feature of smart contracts. It means that smart contracts can express any business case while also routing money. For example, interest payments can be computed and routed to the recipient automatically. Alternatively, an escrow-like smart contract awaits incoming assets and — once all incoming flows have been received — the smart contract releases the assets. Other variants take an incoming money flow and route parts of it to different recipients. In the future, this could be necessary, for example, for routing the value-added tax to a tax office while the net amount of the money is routed to the invoicing entity.
2nd feature of smart contracts: defining the properties of money. Smart contracts have the capability to impose tokens with properties. Properties can include whitelisting/blacklisting of recipients or the limitation of transaction sizes. Also, the decimal places of numbers can be specified. With regard to a smart contract-generated Euro token, the decimal places could be restricted to two and transfer restrictions could be imposed to ensure compliance with AML/KYC requirements.
3rd feature of smart contracts: tokenization. Smart contracts can generate tokens. In case of the digital Euro, a token would be generated (technically, “minted”) through the smart contract when additional collateral is deposited. While this sounds trivial from a technical point of view, it might be more complex economically: Multiple variants of the Euro could be generated as tokens. With regard to the US dollar this is already the case as can be seen by stablecoin projects such as USC Coin, Tether, Paxos, Gemini USD etc.
Contract execution, digital payment infrastructure, and monetary units
Figure 1 summarizes our proposal of a taxonomy that integrates the payment value chain with the underlying features of smart contracts. We decompose the programmable payment value chain into three pillars: the contract execution system, the digital payment infrastructure, and the monetary unit. This distinction is based on a joint research project with Agata Ferreira and Geoffrey Goodell, which will be published later this year.
Contract execution system, digital payment infrastructure and monetary unit
The first step in our programmable payment value chain is a contract that automatically triggers a payment. The contract is implemented on a DLT (i.e., a smart contract). We call the environment, where contracts are placed and executed, “contract execution system”. For example, any business logic or a business process can execute such contracts. In the e-car example above, the price negotiation, the charging process, and the initiation of the payment are part of the contract execution system as all these processes are implemented through smart contracts. At this stage, the first feature of smart contracts — the programming capabilities — are at play.
The subsequent payment can be channeled through two main payment rails: It can either be processed using DLT or — with the help of a bridge or trigger solution — using conventional infrastructure such as SEPA, TARGET2 or TIPS. We call these payment rails “digital payment infrastructure”. The infrastructure is crucial for the programmability of money (2nd feature of smart contracts). We discuss this feature in more detail below. The digital payment infrastructure also determines whether the payment asset is account- or token-based (3rd feature of smart contracts). Payments based on accounts require the identification of the account holder. Payments based on tokens require the ability to verify the validity of the token. Tokens realise their full potential when they can be exchanged for other tokens, such as tokenized assets or services. This enables the seamless exchange with immediate transaction finality, also known as “delivery vs. payment”.
Finally, the monetary unit has to be specified. The only available monetary unit in conventional payment and settlement systems is fiat-denominated money (i.e., EUR, USD, etc.). On a DLT, assets with other denominations can be transacted, such as Bitcoin and Ether. Fiat-denominated money can also be transferred directly via tokens on a DLT. There are mainly five ways to tokenize fiat money:
- Central bank digital currencies (CBDC): issued by the central bank as legal tender.
- Synthetic central bank digital currencies (sCBDC): issued by commercial banks or e-money institutes. No legal tender, but backed 100% by central bank reserves. Obligation to exchange for legal tender at any time.
- DLT-based commercial bank money: issued by regulated financial organizations, e.g. commercial banks. No legal tender and only partially backed by central bank reserves (i.e., fractional reserve system). Obligation to exchange for legal tender at any time.
- DLT-based e-money: issued by e-money institutes. No legal tender. Fullybacked by e-money on accounts. Obligation to exchange for legal tender at any time. In the sense of the new MiCA regulation proposed by the European Commission, these would be so-called E-Money tokens (EMTs).
- Fiat-pegged stablecoins: issued by regulated (e.g., commercial banks, payment service providers) or unregulated financial organizations (e.g., companies not having all required licenses in all required countries). Stablecoins are only “fiat derivatives”. They replicate the price of a fiat currency, but are neither legal tender nor is there an obligation to exchange them for legal tender, as in the case of commercial bank money. For this reason, they exhibit counterparty, exchange rate and liquidity risks. According to the MiCA regulation proposed by the European Commission, these would be so-called asset-references tokens (ARTs).
Programmable money
Let us now turn to “programmable money”, which mainly refers to the 2nd feature of smart contracts: defining properties of money. If money is issued on a DLT, it becomes programmable, meaning we can create a token that carries an inherent logic. For instance, we could program this token such that it gains or loses value over time (e.g., to implement interest payments). Alternatively, we could ensure that this token can only be spent on certain things, such as food.
We have to distinguish between the programmability of money and the programmability of payments. The former concerns the ability to endow DLT-based tokens with an inherent logic (2nd feature smart contracts). The latter refers to automated payments, which — even if triggered by DLT-based smart contracts (1st feature of smart contracts) — can be settled via programmable (DLT-based) money or non-programmable money. If other tokens are deployed on DLT systems (3rd feature of smart contracts), seamless exchange of tokens becomes possible. This would apply to securities trading, consumption of digital goods or services etc.
Conclusion
It is important to distinguish between programmable money and programmable payments because they have different use cases. The example of the e-car is a good use case for a programmable payment. However, the programmability of money is not necessary in this case. Instead, programmable money can be used, for instance, to implement targeted aid payments during crises such as COVID-19. By giving the money paid out to citizens an inherent logic, the government could ensure that the subsidies are spent in a timely fashion and only for predefined things such as food, medicine, or clothes.
Co-Authors
Alexander Bechtel is a research and teaching assistant at the Swiss Institute of Banking and Finance at the University of St. Gallen.
Jonas Gross is a research assistant at the University of Bayreuth and project manager at the Frankfurt School Blockchain Center.
Victor von Wachter is research assistant at the University of Copenhagen and analyst at the eToro Lab.
