Programmable Money: Next-generation Conditional Payments

using Blockchain

Ingo Weber

1 a

and Mark Staples

2 b

Chair of Software and Business Engineering, Technische Universitaet Berlin, Germany

CSIRO’s Data61, Australia and School of Computer Science & Engineering, UNSW, Australia

Keywords:

Blockchain, DLT, Smart Money, Programmable Money, Conditional Payment, Keynote.

Abstract:

Conditional payments allow the transfer of money only when predeﬁned rules hold. Example uses could

include welfare payments, employee expenses, insurance payouts, or tied donations. Normally, conditions

are checked manually in reimbursement or pre-approval/audit processes, either at accounts before funds are

distributed, or using account records after distribution. Blockchain’s capabilities for smart contract and dig-

ital assets can be used to implement next-generation conditional payments, on a decentralized ledger. We

conducted a project with an industry partner where we conceptualized, implemented, and evaluated a novel

programmable money concept using blockchain. In the system, programmed policies are not attached to ac-

counts, but instead to money itself. Policies here specify under which conditions money may be spent, and can

be automatically checked by the money as it is spent. Policies can be dynamically added to and removed from

money as it ﬂows through an economy. Here we report on some of our experiences and insights regarding

blockchain architecture, software engineering with blockchain, and blockchain-based programmable money.

Selected open research questions are listed at the end of the paper.

1 INTRODUCTION

Disruptive technologies break assumptions about lim-

itations of systems and business models, creating

new architectural options and challenges for solu-

tion development. Blockchain

breaks assumptions

that a high-integrity register of digital assets must

be centrally administered by a trusted party. How-

ever, blockchain also has a variety of technical chal-

lenges for their development and performance in op-

eration, some of which are characteristic of only some

blockchain platform technologies, whereas others

are in part inherently unavoidable for decentralised

shared ledgers. Software engineering for blockchain-

based systems must adapt to respective new architec-

tural and development challenges (Xu et al., 2019).

Bitcoin demonstrated a solution to the problem

of digital cash, using a single logically-centralised

ledger of cryptocurrency transactions operated in

an organisationally-decentralised and physically-

distributed way by a collective of thousands of nodes.

https://orcid.org/0000-0002-4833-5921

https://orcid.org/0000-0003-3284-5385

In this article, we say ‘blockchain’ as a short-hand for

blockchain and other distributed ledger technologies.

Modern blockchains support many kinds of data and

digital assets, and allow transactions to record small

programs (“smart contracts”) and their execution.

Smart contracts allow developers to create bespoke

high-integrity abstractions. Tokens are an example

— digital assets created using smart contracts, imple-

menting high-level interfaces for digital asset transfer,

but which can have highly customized behaviour.

In collaboration with a large bank, we conducted

the “Smart Money” project, to conceptualize, imple-

ment, and evaluate systems for blockchain-based pro-

grammable money (Royal et al., 2018). This is a

novel concept where policies can be dynamically as-

sociated with money, and checked and updated as

that money is transferred. The project was motivated

by Australia’s National Disability Insurance Scheme

(NDIS), a large sophisticated system providing gov-

ernment support to people with disabilities. Each

NDIS participant has speciﬁc funding conditions tied

to individual budget lines, based on a tailored plan

of supports. An example policy in our approach may

thus specify that money from a budget line for physio-

therapy can only be spent for such services, offered by

registered physiotherapists. In the project, we showed

that programmable money can be implemented well

Weber, I. and Staples, M.

Programmable Money: Next-generation Conditional Payments using Blockchain.

DOI: 10.5220/0010535800070014

In Proceedings of the 11th International Conference on Cloud Computing and Services Science (CLOSER 2021), pages 7-14

ISBN: 978-989-758-510-4

by utilising blockchain capabilities, ﬁrst and foremost

smart contracts.

In the literature, the term programmable money

has, among others, been used to differentiate

blockchain-based money (including Bitcoin) from

other forms of digital money, like database tables

in a banking system “holding” money digitally (Ma-

juri, 2019). Using the terms programmable money

or smart money to refer to money which checks that

given conditions are met before it can be spent is a

recent phenomenon, and the literature on that topic

is as yet thin. A short discussion paper by Avi-

tal et al. (2017) summarized the key advantages of

smart money, which can control when, where, and

by whom it is spent, to whom it is paid, and for

what. This has also been articulated in a presenta-

tion by Hedman (2019). In the above-mentioned col-

laborative project, we explored the concept of smart

money in the context of welfare payments to dis-

abled people (Royal et al., 2018). The usefulness of

smart money in this context has been conﬁrmed in

a study by Rodrigues and Cardoso (2019). Another

case study (Kolehmainen et al., 2021) aims at “digi-

talizing and automating processes in enterprise legacy

systems” and includes conditional payment, building

on our earlier work. A special case of programmable

money could comprise programmable donations, as

explored in an interview study (Elsden et al., 2019b).

Central banks have begun to investigate the poten-

tial beneﬁts of programmable money for Central Bank

Digital Currencies, and have considered various solu-

tion concepts and their design tradeoffs (BoE, 2020;

BIS, 2020). As such, the research on the concept

has been very limited, and with this paper we aim to

provide a spark for more work in this interesting and

promising direction.

This paper reports on highlights from the “Smart

Money” project (Royal et al., 2018), and expands on

some of the software engineering challenges and re-

search opportunities arising from the project. To this

end, we ﬁrst present the conceptual solution in Sec-

tion 2. Then we discuss implementation concerns in

Section 3 and summarise the evaluation in Section 4.

Finally, lessons learnt are described in Section 5 be-

fore the paper is concluded in Section 6.

2 CONCEPTUAL SOLUTION

Conditional payments are important and common.

Welfare, insurance, grants, donations (Elsden et al.,

2019b), and corporate expenses are all examples.

Conditions are usually checked manually, after pay-

ments are made. Some existing schemes use con-

ventional technology to dynamically check payment

conditions, but only allow payments from centrally-

controlled accounts. In contrast, our project stud-

ied blockchain-based conditional payments with end

user-controlled accounts, by devising a form of smart

contract-backed programmable money. In the follow-

ing, we describe the architecture and the realization

of the core functionality in smart contracts.

2.1 Architecture

The Smart Money project investigated a new con-

cept of blockchain-based programmable money.

Rather than checking ﬁxed conditions on payments

from controlled accounts, policies for programmable

money can instead be dynamically attached to and

removed from money that ﬂows through a pay-

ments system. Previous authors use the term “pro-

grammable money” for single-use conditions attached

to cryptocurrency. Tokens on blockchains may carry

reusable conditions and can also be used as digital as-

sets (perhaps as “money”), but normally these condi-

tions are ﬁxed when the tokens are issued. In con-

trast, our concept of programmable money comprises

not only the checking of conditions speciﬁed in ﬂexi-

ble policies, but also that new policies can be attached

to money by its owner, policies by default remain at-

tached to money as it is paid, and policies can up-

date or remove themselves during execution. To our

knowledge, this concept of programmable money is

novel. The desired novel features created a host of

technical challenges, among others:

• How to ensure that relevant information is present

on the blockchain at the time when needed to eval-

uate a policy?

• How to best attach the dynamic policies to the

money?

• How to enable delegation, such that a nominee of

an NDIS participant can spend tokens on behalf

of the latter?

• How to handle agreements for recurring pay-

ments, such as regular physiotherapy treatment?

To realise the desired features, blockchain technol-

ogy with smart contract capabilities forms a natu-

ral base. Alternative, centralized realisations without

blockchain as a base can be considered, and have been

in the project’s analytical evaluation (Royal et al.,

2018). For a single use case, e.g., a system only

addressing NDIS in isolation, they may offer simi-

lar beneﬁts. However, once more than one use case

should be implemented, blockchain is the more suit-

able technological basis for the following reasons:

(i) there would often not be a single authority (e.g.,

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

Delegate

Blockchain

Funder

Spender

Business

(seller of goods,

provider of

services)

Pouches

of tokens

Policies

Redeem

tokens for fiat

currency

Token-

based

payment

attached

check

Figure 1: Solution overview, showing policies attached to

money (pouches of tokens), transferable between parties,

and optionally redeemable.

one government agency in charge) for the multiple

use cases, (ii) end users would not need multiple

accounts and multiple different processes to interact

with the different use cases on different systems, and

(iii) cross-links between the use cases could be im-

plemented with relative ease on a joint platform. This

discussion is continued in Section 5, including a con-

crete example. Whether or not blockchain is the best

choice should always be evaluated critically, on a

case-by-case basis, see e.g. (Xu et al., 2019, Chap-

ter 6), but not neglect a big-picture view such as the

above-mentioned realisation of multiple use cases.

An overview of the chosen on-chain architecture

is depicted in Figure 1. Payments are done on-chain

using underlying tokens, where, e.g., 1 token is worth

$1. To efﬁciently attach policies to tokens, the tokens

are grouped into pouches, or parcels, and the funder

(e.g., a government agency in our use case) distributes

pouches to eligible spenders (e.g., NDIS participants).

How the tokens are managed in pouches with attached

policies is the subject of the next subsection.

Spenders might delegate rights (e.g., to carers or

family members). Spenders or delegates then pay for

services or goods with the tokens. The payment only

succeeds if all the policies are followed. Recipients

might then spend or redeem the tokens, i.e., trade the

tokens for a corresponding amount of ﬁat currency,

to be transferred to their conventional bank accounts.

Whether or not tokens can be redeemed of course de-

pends on the policies attached to the tokens, which

shows the need for dynamic attachment and removal

of policies.

The on-chain architecture is complemented with a

blockchain trigger as per (Weber et al., 2016), i.e., a

component that translates between on-chain and off-

chain invocations, as well as front-end components

to serve the different types of users with suitable,

mobile-friendly UIs (see also Section 3). More details

on all components can be found in (Royal et al., 2018,

Chapter 5). Next, we focus on the core of the back-

end, i.e., the on-chain realization of programmable

money with smart contracts.

2.2 Realization in Smart Contracts

In the chosen design, one smart contract deﬁnes the

framework logic for programmable money. This con-

tract holds all parcels of money, and each parcel is

subject to a (possibly empty) set of policies. When

money from a parcel is spent, the logic for funds

transfer is executed as illustrated in the pseudo-code

in Listing 1. In summary, the transfer only succeeds

if funds are available, the spender is authorized (line

2), and all attached policies are fulﬁlled (lines 4-6).

This often includes a check whether the recipient is

allowed to receive funds for a speciﬁc purpose, e.g.,

only registered physiotherapists can receive payments

for physiotherapy. Each policy speciﬁes what hap-

pens after funds are transferred (“getNextPolicies”,

line 8), and the “next” policies are attached to the re-

sulting parcel of money, created in line 10 with the

recipient as owner. Policies may also be removed

during this step (not shown in this simpliﬁed pseudo-

code). Finally, the funds are subtracted from the origi-

nal parcel (line 9). As such, the original parcel is split

into two with each transfer. Parcels with the same

policies and owners could be merged subsequently.

An alternative solution would be to manage the to-

kens in higher-level groups, where all tokens in such a

group are subject to the same policies, and one would

store the ownership of these tokens. In such a case,

each group of tokens could implement a (slightly ex-

tended) ERC-20 contract interface or similar. How-

ever, this alternative would have the downside that

changing the policies attached to a token would re-

quire transferring said token from one token registry

to another. This would be harder to manage and ver-

ify, and would exceed the scope of token standards

(like ERC-20) for the most central operation, i.e., to-

ken transfer.

Generally speaking, whenever tokens are used as

money, they should only be accepted if they can be

used or redeemed. In our solution, policies update

themselves to facilitate this. For instance, imagine a

physiotherapist is paid with money that can only be

spent on physiotherapy services. If the policies re-

mained unchanged, the physiotherapist could them-

Programmable Money: Next-generation Conditional Payments using Blockchain

1 f u n c t i o n t r a n s f e r ( p a r c e l , r e c i p i e n t , s e r v i c e , amount )

2 r e q u i r e ( [ . . . ] ) ; // init i a l check s : spe n d er a u t hor i z ed ? Amount a vaila b le ?

3 n e w P o l i c i e s [ ] = [ ] ;

4 f o r e a c h ( p o l i c y i n p a r c e l . p o l i c i e s )

5 i f ( ! p o l i c y . check ( se nder , r e c i p i e n t , s e r v i c e , amount ) )

6 r e t u r n f a l s e ; // if the polic y forb i d s the tr a nsfer , term i n ate

7 e l s e

8 n e w P o l i c i e s . a ppe nd ( p o l i c y . g e t N e x t P o l i c i e s ( sen de r , r e c i p i e n t , s e r v i c e ,

amount ) ) ;

9 p a r c e l . s u b t r a c t ( amount ) ; // r e m o v e amount f r om old parcel

10 ne w P a r c e l = P a r c e l ( r e c i p i e n t , n e w P o l i c i e s , amount ) ; // new par c e l with new

pol i c i es

Listing 1: Pseudo code of policy-aware transfer function.

selves only use that money for physiotherapy. In our

solution, such a policy would remove itself when paid

to a physiotherapist.

Finally, the challenge of handling recurrent pay-

ments is addressed with “service agreement con-

tracts” as follows. Upon agreeing on recurring ser-

vices and respective payments, like regular physio-

therapy treatments, a corresponding amount of tokens

is calculated based on the frequency, price per treat-

ment, and the maximum number of treatments, and

this amount is provisionally ﬂagged for payment to

the chosen provider. As the services are delivered

over time, payments are enabled and executed accord-

ingly.

Programmable money enables powerful forms of

conditional payments. Dynamically-modiﬁable poli-

cies provide a high degree of ﬂexibility. Conditions

can be about the service or asset paid for, a pre-

vious payment, or the status of another account or

money (thereby also comprising a form of higher-

order money). Conditions might refer to time, place,

or reliable data obtained from the ledger or as an

input. When the actions are performed on pro-

grammable money, the associated policies might in-

voke other actions, such as making auxiliary pay-

ments (including self-taxing money), sending notiﬁ-

cations, or triggering other business processes (Weber

et al., 2016). Furthermore, programmable money can

also be designed to enable strong forms of data an-

alytics, including comprehensive access to accurate

real-time data, while respecting suitable conﬁdential-

ity requirements.

3 IMPLEMENTATION

We implemented the concept in a working proto-

type. The research organisation (CSIRO) developed

the back-end and blockchain architecture, and the

bank developed the front-end domain-speciﬁc user in-

terfaces. The prototype was used for end-user testing

and achieved a high degree of usability (Royal et al.,

2018). Selected screenshots of the prototype’s UI are

shown in Figure 2. Speciﬁcally, the overview screen

for NDIS participants (Figure 2a) lists the main fea-

tures, including treatment plan, budgets, goals, nom-

inees, services, and payment requests. On the latter,

the red circle with a “1” indicates one new payment

request. Below the main features follows a list of re-

cent activities. The budget view (Figure 2b) shows

the spent and remaining amounts, as well as any pre-

viously committed portions, e.g., for recurring service

accounts as described above. When booking a new

service (Figure 2c), a map and a list view show avail-

able providers, including their star rating. Payment

requests (Figure 2d) list the details of the request and

allow the user to authorise the payment; doing so cre-

ates a signed blockchain transaction, which in turn

leads to the evaluation of the policies attached to the

parcels of money, and the payment is only successful

if the policy checks evaluate to true.

In the following, we summarise the back-end

implementation and deployment. Given the devel-

oper community, maturity, and prior experience of

the project team, we decided to use the Ethereum

blockchain platform. The system used an Ethereum

deployment on a private proof-of-authority (PoA) net-

work. The money was implemented as special kind of

token smart contract (about 300 lines of code). This

catered for dynamically establishing pouches of to-

kens and attaching budget policies as additional smart

contracts (base policy contract: about 200 lines of

code), as described in the previous section.

For our use case, NDIS, we pre-deﬁned a set of

(parametrised) policies, which were used for the dif-

ferent budget types and purposes of NDIS. Automated

approvals were only given for registered businesses

providing speciﬁc services or goods matching a par-

ticipant’s budget policies. To enable policy checks by

the money, we implemented a registry of businesses

in another smart contract. Spenders and their del-

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

(a) Overview screen (b) Budget overview (c) Booking a service (d) Payment request

Figure 2: Screenshots of the UI. Source: (Royal et al., 2018); © CSIRO, reprinted with permission.

egates in the project interacted with the blockchain

through a mobile app, which also managed the key-

pairs for authorisation. Integration with the frontend

was achieved through the joint deﬁnition of a REST

API, speciﬁed using Swagger.

4 EVALUATION SUMMARY

The research goal was to investigate the concept and

usability of programmable money, so we accepted

limitations in scope to not give complete treatments

for conﬁdentiality, performance, and reliability. We

conducted various end-user, analytical, and techni-

cal evaluations; full details can be found in (Royal

et al., 2018, Chapter 7). Most of the nine end users

(all NDIS participants or carers) who participated in

the respective part of the study were highly positive

about the features. This positive regard is expressed

among others in a net promoter score of 89%. One

aspect particularly valued by the end users is the abil-

ity to make direct payments with certainty that the

policies were fulﬁlled. For the existing centralised

NDIS system used in production, payment success

rates are reported publicly

and the most recent report

at the time of writing covers the week ending Sun-

day 07 February 2021, with a 96.7% success rate of

https://www.ndis.gov.au/about-us/publications, see

“weekly payment summaries”; accessed 2021-02-20.

payment requests out of approx. 1.3M requests; pre-

cisely 44,377 payment requests were unsuccessful in

that week. More than half of those failures were be-

cause the claimed amount was greater than was avail-

able. The desire of NIDS participants to have imme-

diate payment certainty is hence very understandable.

In the analytical evaluation, we compared our

blockchain design with three alternatives, one with

currency-on-blockchain and two based on conven-

tional technology (current and latest). Conﬁdential-

ity and privacy were partly treated by having separate

pseudonymous identiﬁers for each budget line, where

the mobile app integrated those identities for each par-

ticipant.

As for the technical evaluation, we considered

among others throughput performance. Based on the

respective analysis, we believe that the system could

be made to scale to adequate levels of throughput

for the NDIS use case across Australia. The start-

ing point of this analysis was an estimation from the

NDIS of an average load of 2.17 payments per sec-

ond for July 2020. Based on latest actual numbers

(see Footnote 2), the average load was about 2.2 pay-

ments per second. In our solution, some payments

would require more than one transaction, so we es-

timated that on average a payment results in approx.

1.5 blockchain transactions, and therefore an average

throughput of 3,3 blockchain transactions per second.

Even though peak demand will be higher, this could

likely be handled by a deployment like the public

Programmable Money: Next-generation Conditional Payments using Blockchain

Ethereum network (if NDIS were the only applica-

tion): the average number of transactions has been

above 10 since mid-2020. Achieving higher through-

put in a private deployment is not hard in our experi-

ence.

Finally, we conducted additional technical tests,

not all described in the project report. These included

negative tests – tests supposed to fail – such as at-

tempting to submit transactions to the blockchain di-

rectly that violated the policies. These tests resulted

in exceptions as intended, demonstrating that policy

integrity is enforced by the blockchain. Therefore, al-

ternative user interfaces could be developed without

impacting integrity.

5 LESSONS LEARNT

We report on learnings about programmable money

on blockchain, and about software engineering for

blockchain-based systems.

5.1 Programmable Money on

Blockchain

The project report (Royal et al., 2018) identiﬁed

potential beneﬁts for the funding agency, service

providers, and participants. These included improved

control by participants over funds, reduced risk of

misuse of funds, better visibility of budget status, and

improved data analytics.

However, from the users’ perspective, a solution

for a single funder using a blockchain would have

little difference compared to one using conventional

technology. Although uncommon today, centralised

databases can support user-programmable bank ac-

counts (Elsden et al., 2019a). Users interacted with

our system using web or mobile interfaces, so back-

end technologies are hidden.

Nonetheless, a blockchain-based system could

better integrate multiple funders. Consider a vet-

eran with a disability and other medical conditions.

They may want to access combined funds from sepa-

rate agencies, each having different funding policies.

Blockchain-based infrastructure could readily enable

this integration, while funders retain strong levels of

control.

A key challenge for users is to know what poli-

cies are attached to money. Some policies might

be universal, imposed by regulators (e.g. blacklist-

ing sanctioned recipients), but others might be tem-

porary and user-deﬁned. Policies written in a Turing-

complete programming language could have arbitrary

and undecidable behaviours, or be inscrutable byte-

code. Self-modifying policies and interactions be-

tween policies increase this complexity. There are

many possible approaches to dealing with these chal-

lenges. Valid policies might be restricted to regulators

or their delegates, or to a registry of “safe” policies.

Integrity-checking functions could wrap risky poli-

cies, formal veriﬁcation might be used (Magazzeni

et al., 2017), and declarative smart-contract languages

may make analysis easier. There should also be valid

human-readable explanations of the policies.

Finally, we note that the concept requires more

than programming the money itself. The policies run

as smart contracts, and so can only use information

on the ledger or input during payment. In the project,

we included a service provider registry on the ledger,

so that the policies could check whether a payment to

a given provider was allowed.

5.2 Software Engineering for

Blockchain Systems

Blockchains are almost always components in larger

systems incorporating conventional technologies, in-

cluding for key management, user interfaces, commu-

nication, and systems integration. As a component,

a blockchain functions as a database, a communica-

tion mechanism, a compute platform, and often as

a mechanism for asset control and management (Xu

et al., 2019, Chapter 5). Software engineering with

blockchain is similar in many ways to conventional

technologies, but there are differences.

Some things remain similar for software engineer-

ing with blockchain:

• Usability and user experience remain critical. Our

project demonstrated through end-user testing that

blockchain-based systems can be highly usable,

despite programmable money’s conceptual and

architectural complexity.

• In our system, the blockchain was invisible to

users, and we believe this will be typical for many

blockchain-based systems.

• Front-end development is largely unaffected by

blockchain, because user interfaces often access

blockchains through normal APIs.

• Clear integration APIs and testing are critical to

combine architectural components, including the

blockchain. We used conventional REST APIs

written in Swagger for this purpose.

Some things are different:

• Blockchain ledgers are immutable, but this is

where smart contracts are deployed and executed.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

Facilities to enable updates of smart contracts

must be provided for in the design.

• Architectural decisions about allocation of func-

tions to components remain critical, but for

blockchains this includes deciding what data and

functions should be on-chain (Xu et al., 2019). In

particular, moving business logic on-chain might

allow process redesign (Mendling et al., 2018).

• How to horizontally scale components that cre-

ate and submit transactions on behalf of a sin-

gle party is not necessarily trivial: an Ethereum

account is associated with a key pair, which can

be supplied to multiple machines, but each trans-

action has a unique number, the nonce. This

nonce can be thought of as a transaction sequence

number for a given account, and transactions are

processed in the order of the nonces and only

when all previous nonces have been processed.

Each nonce may of course only be used once.

This creates synchronization concerns if multiple

machines should create transactions originating

from a single account. While the transactionality

should be resolved by the consensus mechanism,

it may complicate users’ experience.

• In other work (BIS, 2020), authors have been con-

cerned about scalability in respect of the compu-

tational cost of smart contracts “on ledger”, and

have suggested that moving this computation to

independent modules or signiﬁcantly restricting

its functionality may be required to achieve full

scalability. In our view these on-ledger costs are

unlikely to have a signiﬁcant unresolvable impact

to scalability of throughput or latency, but it is an

open question.

• For smart contracts to check policies, data must

be on-chain or supplied during invocations; typi-

cally smart contracts cannot directly invoke exter-

nal APIs. This impacts the design of data storage

and component interactions.

• Similarly, test data must also be on-chain, and re-

running tests requires re-establishing the test en-

vironment. In our project this was achieved by

re-creating the entire blockchain for each test run.

Now-available emulation tools like Ganache can

be of help.

• Key management is critical for authorisation in

blockchain systems, and this is more complex and

risk-prone architecturally and for users than cen-

tralised credential management.

• Blockchain ledgers are transparent, so the oper-

ating collective can cross-check ledger integrity.

This makes conﬁdentiality hard to achieve. De-

sign tactics to use pseudoanonymity and encryp-

tion may not stop linking attacks. Yet, regulators

or courts may require access to “private” data; and

consumers often value transparency. These trade-

offs have also been recognised by others (BIS,

2020). Resolving these issues is a signiﬁcant de-

sign challenge in blockchain projects.

6 CONCLUSIONS AND OPEN

RESEARCH QUESTIONS

Blockchain gives software engineers new options

when developing systems to solve user problems, but

also brings new challenges for software engineer-

ing practice like those listed in the previous section

and in Section 2. We have described some of our

experiences and learnings from our “Smart Money”

project (Royal et al., 2018), which developed and

tested a novel concept of programmable money on

blockchain.

In our concept, policies can be dynamically at-

tached to and removed from pouches of money. These

can be checked when payments are made, and can

stay attached to the money as it ﬂows through a

payment system. Rather than just checking condi-

tions, the policies can also perform actions such as

making auxiliary payments, or updating or remov-

ing themselves. This concept could not be readily

implemented using conventional technologies, but is

reasonably straightforward to implement using smart

contract tokens on a blockchain.

Although the concept seems complex, user testing

demonstrated that the experience can be easy, even

for non-technical users. Just as with any software,

achieving this kind of outcome depends on good user

experience design, front-end implementation, and it-

erative feedback.

Blockchain as a component is always combined

with other components, for key management, user

interfaces, communication, and systems integration.

Although architectural practice remains broadly sim-

ilar, there are speciﬁc considerations when using

blockchain. Architects must accommodate non-

functional limitations on performance and security,

and understand the constraints of data storage and

smart contracts on immutable ledgers.

A number of research questions remain open:

• What is required to gain user trust in pro-

grammable money? How can non-technical users

be equipped with a sufﬁcient level of understand-

ing of the policies attached to the money?

• How can horizontal scaling be achieved for nodes

Programmable Money: Next-generation Conditional Payments using Blockchain

creating transactions for a single blockchain ac-

count (as per the challenge mentioned in Sec-

tion 5.2)?

• Is there a broader opportunity for new solutions

that use dynamic rule-based systems for digital as-

sets or other high-integrity constructs?

• Can the concept of programmable money be ap-

plied to implement alternative money systems,

which may have speciﬁc desirable economic

properties?

ACKNOWLEDGEMENTS

We thank the co-authors of the project report, the

project team, reference group, and all who helped us

understand the NDIS and test the system.

REFERENCES

Avital, M., Hedman, J., and Albinsson, L. (2017). Smart

money: Blockchain-based customizable payments

system. Dagstuhl Reports, 7(3):104–106.

BIS (2020). Central bank digital currencies: foundational

principles and core features. Report, Bank of Interna-

tional Settlements.

BoE (2020). Central bank digital currency: Opportuni-

ties, challenges and design. Discussion paper, Bank

of England.

Elsden, C., Feltwell, T., Lawson, S., and Vines, J. (2019a).

Recipes for programmable money. In Proceedings of

CHI. ACM.

Elsden, C., Trotter, L., Harding, M., Davies, N., Speed, C.,

and Vines, J. (2019b). Programmable donations: Ex-

ploring escrow-based conditional giving. In Proceed-

ings of CHI. ACM.

Hedman, J. (2019). Smart money. Presentation at the mobey

forum, Stockholm.

Kolehmainen, T., Laatikainen, G., Kultanen, J., Kazan, E.,

and Abrahamsson, P. (2021). Using blockchain in dig-

italizing enterprise legacy systems: An experience re-

port. In Klotins, E. and Wnuk, K., editors, Software

Business, pages 70–85.

Magazzeni, D., McBurney, P., and Nash, W. (2017). Vali-

dation and veriﬁcation of smart contracts: A research

agenda. Computer, 50(9):50–57.

Majuri, Y. (2019). Overcoming economic stagnation in low-

income communities with programmable money. The

Journal Of Risk Finance, 20(5):594–610.

Mendling et al., J. (2018). Blockchains for business process

management – challenges and opportunities. ACM

Transactions on Management Information Systems

(TMIS), 9(1):4:1–4:16.

Rodrigues, J. and Cardoso, A. (2019). Blockchain in smart

cities: An inclusive tool for persons with disabilities.

In Smart City Symposium Prague (SCSP’19), pages

1–6.

Royal, D., Rimba, P., Staples, M., Gilder, S., Tran, A.,

Williams, E., Ponomarev, A., Weber, I., Connor, C.,

and Lim, N. (2018). Making money smart: Empow-

ering NDIS participants with blockchain technolo-

gies. Report by CSIRO and Commonwealth Bank

of Australia, https://data61.csiro.au/en/Our-Research/

Our-Work/SmartMoney. Accessed: 18/2/2021.

Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev,

A., and Mendling, J. (2016). Untrusted business pro-

cess monitoring and execution using blockchain. In

Proceedings of BPM. Springer.

Xu, X., Weber, I., and Staples, M. (2019). Architecture for

Blockchain Applications. Springer.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science