1 Introduction

We deeply thank Editor Wolfgang Härdle for selecting our paper for discussion and Alla Petukhina for organizing the discussion, and are very grateful for the discussants’ time, engagement, commentary, questions, and stimulating feedback on our paper. The written comments offer a broad view on the concepts proposed in our paper and related concepts. They complement our paper with valuable perspectives and insights from a wider community. Although the original project was carried out with a multi-disciplinary project team, both of us authors have a computer science background. In contrast, many discussants have an economics or finance background, and we were very pleased to see that we could communicate effectively with each other. From our perspective, this fruitful exchange yielded new interdisciplinary connections in the topic of programmable money and its associated possible benefits and risks.

Generally, there was positive feedback and encouragement about the work, for which we are grateful. The discussants also some identified avenues for future work that we agree with but which in most instances do not warrant detailed commentary from us. In this rejoinder, we respond to some of the other themes, questions, concerns, and deeper ideas raised in the comments. We do so by first addressing two themes observed across multiple comments, specifically the value of money and concerns around illegitimate use, followed by a discussion of other points from individual discussants.

2 Value of money

We expect that adding programmable conditions to money can reduce its economic value, as we discuss in our paper in relation to previous work on the value of gift cards. We argued that existing budgetary or policy constraints on normal money would likely already have that kind of economic impact today, even if those constraints are not explicitly encoded as programmed rules for money. However, new discretionary constraints able to be attached to programmable money could further reduce its economic value. Note that this is not a decrease in the nominal value of programmable money, only its economic value.

In their commentary, Rodrigues agrees, and Poti notes that programmable money might be worth nothing if its policies are not followed. We would say programmable money would only be worth nothing if its policies cannot be followed, because if its policies are only not followed for a particular attempted payment, then that payment will fail, and the money would still be available to be spent elsewhere.

Rodrigues notes that policy flexibility creates uncertainty about the future value of programmable money. We think it is important that the policies attached to money, and how those will change as a result of a transfer, should be visible and understandable by its owner and potential recipients, to reduce this uncertainty. Moreover, we think that in normal circumstances only the holder of money should only be able to attach new conditions to it (thus reducing its economic value), and no other parties. Nonetheless, regulators, courts, or other authorities may also want to be able to use or change policy-based technical controls over money issued or governed by them. In some ways this is already the case for normal money, which typically has restrictions against use for criminal purposes and which can be frozen or seized by authorities under existing or future potential legislation.

Poti, Osterrieder, and Burda all note that programmable money would be less fungible or tradeable, Rodrigues notes this may impact liquidity, and Burda wonders if this would undermine the role or definition of programmable money as “money”. As computer scientists we are less concerned by the black and white criteria for money, and more interested in whether the tokens can adequately function for their holders, but agree that these variable constraints that we have discussed for money will decrease its functions as money, possibly impacting fungibility, tradability, and liquidity.

Rather than just decreasing the value or supply of money, Osterrieder wonders whether the supply of programmable money cannot be increased, and Poti asks whether we are saying that money with some policies might be worth more economically. Programmable digital tokens are able to behave according to however they are programmed, and in principle this could include provision for the creation of new tokens in specific circumstances, not just by issuers or funders directly, but also perhaps through an intrinsic mechanism for interest, or bonuses of other sorts. This would increase the nominal value of holdings of money but might not increase its overall economic value. We leave to others the question of when or whether this would be a desirable requirement to implement for money. In relation to Poti’s remark, we did not intend to say that policy-encumbered money will normally be worth more than unencumbered money. However, we can imagine scenarios in which money could be uniquely “branded” in such a way as to become collectible or preferential. For example, money branded to only be spent in a particular organic supply chain might come with automatic discounts for payments in that supply chain.

Rodrigues wonders if funders need to pay up-front with loss of capital, if money is not spent? We would say that money in a funding arrangement is already committed. Policy could allow redemption to the funder if not spent. Moreover, if the funding token is not money directly but a derivative instrument akin to an IOU, then actual payment would be deferred until redemption or settlement. Rodrigues wonders for a system with several funders, whether it would be hard to know who should redeem tokens. There would be many possible realizations. If funding tokens were separately identified by their funder, then it would be easy to determine who will redeem them, but widespread acceptance may be more challenging. Alternatively, funding tokens could be all uniformly denominated for easy acceptance and fungibility, but that may require issuance agreements or settlement guarantees between those funders. This is similar to the challenges and systems today for inter-bank settlement of commercial bank money.

3 Concerns around illegitimate use

Osterrieder is concerned that anonymous programmable money might enable illegal activity, whereas Rodrigues notes that programmable money could be used to better prevent illegal and corrupt activity through embedded regulatory policies and through better digital records. We would agree with both positions, but note that programmable money need not be anonymous. For instance, it would be possible to have a pseudonymous system where the identity of participants is known to (at least) one funder.

Osterrieder is also concerned that government policies attached to money might exclude individuals and thus reduce financial inclusion. We would agree that this is a possible but not necessary outcome. More optimistically, judicious finely targeted policies might plausibly safely increase financial inclusion compared to the blanket anti money laundering and counter-terrorism financing (AML-CTF) controls that are currently in place for normal money.

4 Additional comments

One of the most exciting cross-disciplinary observations arising from this discussant process was the relationship to the “incomplete contracts” problem noted by Poti, and similarly to the concept of “stale contingent contracts” noted by Burda. These seem to be an interesting economic concept previously unknown to us, among others related to requirements specification challenges in software engineering. Indeed, it is possible to code the function of intermediaries with programmable money, and blockchain-based smart contracts, to a large degree. However, that may in turn shift the “incomplete contracts” problem, in that the programmed solutions may themselves be incomplete. For situations not covered by the programmed rules, two possible solutions come to mind: first, the option to adapt the policies on the fly for a parcel of money, e.g., by the funder; and second, the system could be equipped with an appeals-and-arbitration mechanism, in which an arbitrator (human or even AI-based) makes a decision if two parties cannot resolve a disagreement.

The policies for our programmable money must be evaluated against data representing the real world, such as the nature of goods, services, and suppliers. This dependency on external off-ledger information was noted by both Burda and Rodrigues. In prior research we have called this issue the “digital-physical parity problem” (Lo et al., 2019), and no complete control for this risk can be entirely digital. The risk is similar to normal risks for fraud in record keeping about expenditure against funding mechanisms, and similar audit controls would be required to mitigate it.

Rodrigues notes possible applications of programmable money for vouchers and voucher markets. Burda similarly notes the possibility of secondary markets for government social support entitlements. We observe that grey markets for government food stamps and controlled stored value cards operate today. Moreover, even policies for programmable money could not eliminate the possibility of such grey markets, albeit using programmable money for a third person is arguably harder than selling them a food stamp. We leave to others the policy question of whether such secondary markets should instead be facilitated.

Burda asks whether the proposal is applicable for cryptocurrencies, DeFi, and central bank digital currency (CBDC). We believe that programmable money has areas of applicability in all three cases, e.g., DeFi loans for a specific purpose or CDBC money for government use cases like the NDIS. Cryptocurrency use cases might include funding from decentralized autonomous organizations (DAOs), e.g., crowdfunding.

Osterrieder and Burda note possible technical challenges with programmable digital money, specifically scalability and performance, and with the ability to work on smart phone. Regarding throughput scalability and latency, we believe programmable money can benefit from advances in blockchain technology itself. For instance, Ripple aims at 1500 transactions per second (tps) (Bach et al., 2018), and the RedBelly Blockchain achieved 30,000 tps in a globally distributed network with a latency of approx. 3 s (Crain et al., 2021). Our prototype include a smart phone-based user interface, which worked well; albeit conceivably there will be limits on the complexity that should be conveyed on a small screen.

Burda is concerned about how much of the perceived value in our user study arose mostly from offering a good user interface. As stated in our report, a significant part of the perceived value arose from the improved user experience, which includes the user interface but also many other aspects. The user experience was also based on policy checks being conducted when a transaction was requested, with immediate feedback. The previous study might be insufficient to clearly separate the degrees of impact between these factors, and additional studies might be needed. As the earlier report notes, whether a blockchain adds significantly to this may depend on whether there is a single central funder, or a collection of funders (each with their own different funding policies) for the same monetary unit.

We would like to thank all contributors and organizers once more for the excellent opportunity to conduct this discussion. As is shown with this discussion, the topic of programmable money offers great potential for interdisciplinary work, particularly between economists, computer scientists. We hope that this paper may lead to interesting research and practical applications around the concept of programmable money.