Board of Governors of the Federal Reserve System

June 23, 2021

What is programmable money?

Alexander Lee¹

Introduction
Discussions of financial technology have recently started to include the idea of "programmable money," though the specific meaning of the term is often unclear. Different perspectives may presume a particular underlying technology or set of features to be a part of a programmable money system, and lack of agreement on these aspects may lead to confusion. To support clearer discussion of this concept in the central banking community and the financial industry more broadly, this research note offers an investigation into the nature of programmable money. This note focuses on the importance of a mechanism guaranteeing the inseparable functionality of the technical components of a programmable money system rather than prescribing the specific nature of those components. This "coherence guarantee" is crucial regardless of specific technical choices and admits a wide range of potential designs for programmable money. The guarantee also facilitates the view of programmable money as a concrete product, which may provide users with greater certainty about its nature and capabilities than alternative service-oriented models that can automate interaction with particular digital value records.

What is programmable money?
Many observers of financial technology have offered interpretations and discussion of potential use cases of programmable money.² While such references to programmable money typically describe it as being enabled by distributed ledger technology (DLT) or blockchain systems, this is not universally the case, and the term remains ill-defined.³ Two natural components of the definition are a digital form of money and a mechanism for specifying the automated behavior of that money through a computer program (this mechanism is termed "programmability" in this note). However, it is not clear whether these components alone are sufficient for a definition, given that various combinations of similar technology for payments automation have existed for decades. It was only after the advent of public blockchain cryptocurrencies that the term "programmable money" became common parlance.⁴ So what is it about these new systems that has prompted the recent spate of references to the term, and does the answer somehow imply that DLT has to be a part of any "programmable money" system?

One facet of successful public blockchain systems that may provide some clarity is how they closely link digital value and programmability in a single system that only functions properly when both are present. In traditional financial technology systems, digital money is typically defined by database entries. Any "programmability" offered for this money, whether internally to the entity maintaining the database or exposed to its customers via an application programming interface (API), involves another technology system built separately from that database and then connected in some fashion. While newer cryptocurrency systems also use a database (often in the form of a blockchain data structure), a key difference is that the records in such blockchains either directly incorporate some programmable script (as Bitcoin records do, for example), or sit alongside a general programming functionality within the system that allows for direct manipulation of those records (the model used by Ethereum, among others).⁵ In both designs, the value represented in those systems and the programmability of that value are tightly integrated. There is no notion, for example, of "bitcoins" without an associated script governing their spending conditions, whereas a traditional ledger could certainly hold digital records of money without offering a programming interface to those records.⁶

The necessary technical components and the notion of tight integration between those components suggests a definition of programmable money as a unified, coherent product that encapsulates both the storage of digital value and programmability of that value. This note uses the term coherence guarantee to refer to a mechanism guaranteeing that the technical components of the programmable money product are "inseparable" and that those components are consistently functional, such that the product is stable and coherent for users. While nominally "separable" technologies (including traditional technologies that predate DLT) may be used to implement the two core technical components depicted above, the coherence guarantee must ensure that they are not separable as far as the overall product is concerned. Without this guarantee, the individual components are nothing novel: Digital money as a product has existed in many forms for years, as has the ability to write computer software.⁷ With the guarantee, programmable money may be seen as a new product category sitting alongside existing money products such as central bank deposits, demand deposits, nonbank money, and cash. The benefit of stability that this guaranteed inextricability provides users of the product may not be present in other systems relying on services that can be altered by their providers and which may be subject to outages. The idea of the guarantee itself is broadly agnostic to technical choices, allowing for a range of approaches to the design of the digital money and programmability components using a variety of technologies.

Technical designs for programmable money: possibilities and tradeoffs
There are many ways to approach the technical design of a programmable money system. Such designs may incorporate both traditional technologies and newer alternatives like DLT, with specific technical choices being driven by the goals of the system designers. While a technical design can address the necessary components of a programmable money system (digital money and programmability), a coherence guarantee cannot be provided by technology absent some broader reinforcing incentives (which might be economic, legal, or reputational). It is nevertheless important to understand the possible technical approaches for programmable money system designs, some of which are described below along with attendant tradeoffs.

Recordkeeping for digital money
The most basic building block of a programmable money system is a set of digital records representing transactable value. These records will almost certainly be kept in a persistent database of some variety. Many existing financial technology systems use traditional relational databases for this purpose, such as a bank keeping a digital record of customer accounts, while DLT systems typically use a blockchain-style database to store records of value. A notable difference between these technologies is that traditional databases are often general purpose: They may be used for financial applications as a way to store accounts, but they are designed to be flexible enough to be used to store virtually any type of digital record, and they do not have any "awareness" of the implications of the records they store.

DLT database designs, by contrast, are usually purpose-built for financial accounting of their integrated digital currencies and have intrinsic mechanisms for detecting invalid transactions such as doubly spent value or the spending of greater value than is available to a user. In addition to helping maintain correct value records, such mechanisms can complement programmability in those systems, performing fundamental accounting checks regardless of what type of programmatic instruction is issued. In the public blockchain context, these mechanisms help ensure the proper operation of the system and provide additional surety to users when combined with a mechanism such as proof-of-work, which is designed to make the (correctly recorded) records practically immutable. Deployed in a private context, DLT could potentially offer some of the same specialized recordkeeping benefits to the operator of the system (with the notable exception of immutability), if not necessarily to the system's users.⁸

The format in which records of value are kept in a database may have implications for the design of the programmability component of a programmable money system. One recordkeeping possibility is the traditional account format, such as a bank or financial service provider might keep for a customer. The account format has the immediate advantage of being a familiar construct and is the de facto standard for traditional financial technology systems. Some DLT systems use the account format as well, enabling a single account to control a variety of digital assets and to issue programmatic instructions.⁹ A potential drawback of the format is that it makes tracing the history of any particular unit of value more difficult, if this is a desired feature of the system.

The unspent transaction output (UTXO) format, first popularized by the Bitcoin system, more readily facilitates this type of historical transaction record. This alternative recordkeeping model records all discrete amounts of value (the "unspent outputs") in existence at the current time, and associates ownership of that value directly with the amounts.¹⁰ A rough analogy from the traditional financial world might be banknotes in circulation: Owners are identified by current bearers, and individual ownership of any banknote may be reassigned by its bearer at any time. In systems like Bitcoin, ownership is asserted through satisfaction of a conditional script associated with each UTXO, typically requiring a valid digital signature from a specific cryptographic private key. Possession of the correct private key is thus tantamount to "possession" of the value, and for this reason bitcoin has sometimes been referred to as a "bearer instrument," though the analogy is somewhat imprecise.¹¹ Benefits of the UTXO model include conciseness of the records being kept (there is no such thing as an "inactive account" or "empty account" under the UTXO recordkeeping model) and the ability to associate specific (programmable) spending conditions with every discrete UTXO. Drawbacks of UTXO-based recordkeeping include the need to maintain external metadata in order to roll up "account balances" for individual users (if such balances are desired) and the potential abuse of the format to fragment value across many UTXOs, which will need to be tracked by the system.¹²

Enabling programmability
In conjunction with technical decisions about how to store transaction and balance records for programmable money, a system designer must also consider how to enable the programming capability for that money. There are several potential methodologies to choose from, some of which are typically used in conjunction with DLT and others that are more often used for traditional financial technology systems. In some cases, these decisions involve mutually exclusive designs for enabling programmability, but there is usually broad flexibility in how programmability can be enabled.

Public blockchain systems have generally followed one of two strategies for enabling programmability, denoted here as the transaction scripting approach and the virtual machine approach. While these approaches are not mutually exclusive and do not dictate a particular choice of recordkeeping format, certain combinations are logically and technologically complementary. Under the transaction scripting approach, a (small) program is attached to every discrete amount of value tracked by the system, indicating how that amount may be spent. This approach is analogous to having a programmatic spending condition attached to every banknote or physical coin in existence, which can be re-programmed when spent. This "digital cash" model is the approach pioneered by Bitcoin, combining the UTXO recordkeeping format with the transaction scripting model, with one transaction script per UTXO dictating how it may be spent. When a UTXO is consumed as an input to a financial transaction, a new script can be associated with every output of that transaction. Users can control any number of UTXOs and can spend them independently by satisfying the associated transaction scripts.

Figure 2: A simplified schematic of the UTXO recordkeeping format combined with the transaction scripting approach to programmability

By contrast, the virtual machine approach embeds programming capability in the system itself in the form of virtual machine instructions that can recognize and manipulate the value stored in the system. This is the approach taken by Ethereum, which allows transactions to contain programmatic instructions and further allows programs written for its own virtual machine (the EVM) to be deployed to and stored in the blockchain. Programs deployed in this manner may persist indefinitely, and their functionality can be repeatedly used by future transactions. These programs are typically called "smart contracts," a term that predates public blockchains and need not imply any contractual obligation in a legal sense when used in the contemporary DLT context.¹³ This approach is combined with the account recordkeeping format for recording value in Ethereum and several other DLT systems to allow for programmatic manipulation of account balances.

Figure 3: A simplified schematic of the account recordkeeping format combined with the virtual machine approach to programmability

These two designs present different tradeoffs. Potential benefits of the "digital cash" model using programmable UTXOs are the ability to specify spending constraints on any discrete amount of value and a greater facility to trace the provenance of any particular "virtual banknote." Benefits of the account-based model may include greater fungibility of value and efficiencies from reusing smart contract code for frequently desired program functionality. New technological designs may borrow elements of both models and offer a different range of benefits, and the interpretation of what is "beneficial" may depend on the objectives for the system outside of just the technology.

Financial software systems that do not use DLT, for example programmable payment services like PayPal, have typically enabled programmability through an API layer on top of some combination of underlying technology. Because the API is an abstraction of the system that it provides an interface for, DLT could in fact be used behind an API as well.¹⁴ APIs are an example of a component that does not preclude another technology choice, and these interfaces can be layered on top of one another (and often are in practice). Beyond this flexibility, benefits of APIs include established design patterns and general familiarity among system developers, which may not be the case with newer technologies associated with DLT, such as UTXO-based recordkeeping or smart contracts. Drawbacks of APIs include the potential decoupling of the programmability from the digital representation of money if a discrete API gateway were the sole interface for programmatically interacting with that money (for example, a bank's API for programmability might go down while its databases for querying account balances on its customer portal remain up), and an increasing potential for system failure if numerous critical APIs are layered atop one another.¹⁵

Figure 4: A simplified schematic of a traditional software system combining a database with an external API gateway

Another key consideration in the technical design of a programmable money system is how to prevent abuse of the programmability. Even if the mechanism correctly functions to only allow valid commands to be programmed, valid commands may be combined (maliciously or inadvertently) in ways that lead to undesirable consequences. One major form of potential abuse is a denial-of-service attack, in which large numbers of instructions to execute some programmatic function are issued repeatedly by the attacker, forcing the system to perform wasteful computation at the expense of providing service for legitimate requests. Public blockchain systems have implemented multiple deterrence mechanisms out of necessity, lacking any central operator capable of screening out an attacker's traffic: Fees are typically required for every transaction, introducing an economic disincentive for abusive transactions, and the extent of potential program execution is also limited in some fashion.¹⁶ Private DLT implementations may also deliberately constrain program execution, and APIs for existing financial service are often rate-limited to prevent similar abuse; such techniques could be used in conjunction depending on the overall system design. Different designs may present perceived drawbacks to users of the programming facility (such as offering only a limited set of commands), and at a certain level of restriction, whether the system still constitutes "programmable money" may be called into question.¹⁷ Regardless of exact design, however, some level of restriction is likely a necessity to allow the system to operate correctly for legitimate users.

Providing coherence guarantees for programmable money
While the technical design of a programmable money system is important, the technology alone cannot intrinsically provide a sufficient coherence guarantee. The system must also rely on a convincing set of external incentives to uphold the guarantee, lest the overall product not be seen as credible in the eyes of its users.¹⁸ These incentives can be viewed as falling within at least three broad categories of economic incentives, legal incentives, and reputational incentives, though other frameworks are possible. These categories are not mutually exclusive, though certain would-be providers of programmable money may rely more heavily on some of them than on others. In addition, the technical design of a system may lend itself well to reliance on certain types of incentives.

Reinforcing guarantees through incentives
Economic incentives would feasibly apply to almost any offeror of a programmable money product. Contemporary providers of money have a clear economic incentive for simply continuing to offer certain products, such as seignorage from banknote issuance. If a programmable money provider offered a product that had a similar economic benefit to the issuer, this incentive would help guarantee that product's continued provision. While public cryptocurrencies may not have any specific offering entity, they may nevertheless rely on economic incentives to perpetuate the system, as exhibited for example by the subsidies and fees involved in the process of proof-of-work mining, which will be explored further below.

Legal incentives are also likely to apply in some form to nearly all offerors of programmable money, though the structure of these incentives may be highly variable across jurisdictions. From a user's perspective, the nature of what exactly is being legally guaranteed may also be salient. How to legally enforce that a programmable money system be provided on an ongoing basis is unclear, for example, though it is easier to envision a legal requirement that restitution be provided to users of such a system if it were taken offline (at least in cases where the provider is an identifiable entity subject to such requirements in its own jurisdiction, such as a corporation). While restitution in such a situation is certainly preferable to those users receiving nothing at all, it may be the case that some users would prefer to have the programmable money that they believed they had access to, rather than some alternative form of compensation.¹⁹

Reputational incentives are perhaps most variable in importance depending on the offeror of programmable money, and in some cases may factor in only marginally. For example, the creator(s) of Bitcoin remain anonymous, and have different incentives to maintain a reputation than an established company or government looking to launch a programmable digital money might. For certain entities with exceptionally strong reputations, such as governments capable of issuing investment grade debt, or central banks capable of issuing widely accepted fiat currency, an incentive to uphold that strong reputation may in fact be the most important part of a guarantee.

Coherence guarantees in action: practical and theoretical examples
A practical example of a coherence guarantee is that offered by public blockchain systems for their native cryptocurrencies. These systems rely on economic incentives for network participants to guarantee their continued operation and the integrity of the associated transaction ledger. For systems that use proof-of-work consensus, such as Bitcoin and Ethereum, network participants performing transaction validation and construction of the shared ledger receive economic rewards denominated in native cryptocurrency for performing this work (in expectation), and must consume economic resources (in the form of electricity) in order to do so.²⁰ Because validators maintaining the canonical ledger history will reject any invalid transactions, including double-spend transactions, while any attacks on the network and ledger history which involve mining still incur the cost of performing that work, there is a significant economic cost for dishonest miners. The economic cost of proof-of-work is also where the "immutability" of such public ledgers derives from: In order to change the ledger history, an attacker would have to consume enough resources to produce proofs of work for an alternate section of ledger history that would become the longest version of the blockchain.²¹

It is important to note that while these incentives in combination with the technical design of the underlying systems have worked to uphold the coherence guarantee of native cryptocurrencies like bitcoin and ether for several years, the same incentives do not apply to non-native "cryptocurrencies" like ERC-20 tokens built on top of the Ethereum platform.²² While such tokens may rely on the same consensus mechanism as ether when it comes to recording transactions, they do not derive value from that mechanism in the same manner, because miners on the Ethereum network are paid for performing proof-of-work in ether, not in ERC-20 tokens. Thus, while such tokens may be programmable, they may not represent "money" in the system and may subsequently not fall under this note's definition of programmable money.

Another example of a practical system that could feasibly qualify as programmable money is a privately administered system such as a payment service provider or bank offering programmability for digital money through an API. Such systems can offer many of the same technical capabilities as other programmable money systems for their users, but the incentives underpinning the maintenance of those systems may be more complex and the coherence guarantee less robust, possibly to the point where the label may be inapplicable. For example, a large financial services company may have legal incentives to serve its customers well enough to avoid lawsuits, reputational incentives as a provider of a well-known programmable API for payments, and economic incentives in the form of taking fees for its services, and some customers may find these incentives credibly strong enough to qualify the company's services as programmable money. However, such services can still be discontinued at any time in whole or in part if incentives were to change.²³ The relative strength or weakness of a coherence guarantee for programmable money being offered by a private entity may thus be seen to rely on the particular mix of incentives that the offeror has for maintaining such a product, and these incentives may shift considerably over time.

A more theoretical example of a programmable money system is a hypothetical programmable digital currency offered by a public-sector entity already issuing other forms of money. Central banks of sufficient reputation and credible technical capability to offer a programmable money system may be able to offer a coherence guarantee primarily on the basis of their reputations, with an implied incentive for maintaining those reputations.²⁴ This approach is not open to most would-be providers of programmable money systems, but it may be the case that the same authority that allows certain governments to issue widely used fiat money (with its implicit guarantee of continued value in the future enabling its use today) will also allow those entities to issue programmable money "by fiat." Although no central bank has yet offered such a programmable digital currency product, it remains a possible development if general interest in central bank-issued digital currencies persists.

A final note on guarantees
The word "guarantee" in the preceding discussion should always be read with implied quotation marks around it. Public cryptocurrency systems, like Bitcoin, have worked in practice for years, but the behavior of validators in the long run when the incentive structure no longer includes subsidies in the form of block rewards remains an open question, and external factors leading to a loss of confidence in such systems could also affect the guarantee.²⁵ As illustrated in the practical example of privately offered programmable money, such systems may vanish if the offeror decides to discontinue them, technological capability regardless. Central banks could similarly issue and later elect to demonetize a digital currency. Attempting to assess the comparative strength of various coherence guarantees in these situations and others is beyond the scope of this note. Potentially more important than any such hypothetical framework, however, is the credibility of the guarantee for any given programmable money product in the eyes of its potential users. Observing user attitudes towards preexisting services like payment APIs and newer offerings such as open banking APIs and cryptocurrencies may offer insight into this evolving landscape in the coming years.

Conclusion
While "programmable money" as a term may have originated in the public blockchain community, as a concept it need not involve distributed ledger technology at all. There are multiple possible approaches to the design of a technological system offering a digital representation of money with an associated programming facility; what is more important than the specific technical approach is the guarantee that the system will in fact cohere into a unitary product offering, rather than a service offering associated with an otherwise independent non-programmable digital money. This coherence guarantee offers greater stability and consistency of experience to users over "programmability-as-a-service" models, and must be reinforced by suitable incentives, with different providers of programmable money relying on different forms of incentives. The ultimate assessment of the suitability of such incentives and thus the credibility of the coherence guarantee will come from users of these products, and their evaluations of different forms of programmable money may evolve over time as more practical examples are offered to the public.

References

Bechtel, Alexander, Jonas Gross, Philipp Sandner, and Victor von Wachter (2020, September 29). "Programmable Money and Programmable Payments," Medium. https://jonasgross.medium.com/programmable-money-and-programmable-payments-c0f06bbcd569

Carlsten, Miles, Harry Kalodner, S. Matthew Weinberg, and Arvind Narayan (2016). "On the Instability of Bitcoin Without the Block Reward (PDF)," Princeton Economics Working Papers.

Harney, Alexandra, and Steve Stecklow (2017, November 16). "Special Report: Twice burned – How Mt. Gox's bitcoin customers could lose again," Reuters. https://www.reuters.com/article/us-bitcoin-gox-specialreport-idUSKBN1DG1UC

Koning, John Paul (2020, November 19). "Programmable money isn't new, we've had it for ages," Moneyness. http://jpkoning.blogspot.com/2020/11/programmable-money-isnt-new-weve-had-it.html

Lee, Alexander, Brendan Malone, and Paul Wong (2020). "Tokens and accounts in the context of digital currencies," FEDS Notes. Washington: Board of Governors of the Federal Reserve System, December 23, 2020.

Lewis, Antony (2020, April 26). "What Actually is Programmable Money?" Bits on Blocks

Nakamoto, Satoshi (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System (PDF)."

Szabo, Nick (1994). "Smart Contracts."