Conference PaperPDF Available

Programmable Money: Next-Generation Conditional Payments using Blockchain - Keynote paper

Authors:

Abstract and Figures

Conditional payments allow the transfer of money only when predefined 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 digital 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 accounts , 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 flows 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.
Content may be subject to copyright.
Programmable Money: Next-Generation Conditional Payments using
Blockchain – Keynote paper
Ingo Weber1a, Mark Staples2b
1Chair of Software and Business Engineering, Technische Universitaet Berlin, Germany
2CSIRO’s Data61, Australia and School of Computer Science & Engineering, UNSW, Australia
{first.last}@tu-berlin.de, {first.last}@data61.csiro.au
Keywords: Blockchain, DLT, Smart Money, Programmable Money, Conditional Payment, Keynote
Abstract: Conditional payments allow the transfer of money only when predefined 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 flows 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. Blockchain1breaks 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-
ahttps://orcid.org/0000-0002-4833-5921
bhttps://orcid.org/0000-0003-3284-5385
1In this article, we say ‘blockchain’ as a short-hand for
blockchain and other distributed ledger technologies.
distributed way by a collective of thousands of nodes.
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 specific 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
by utilising blockchain capabilities, first 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 confirmed 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 benefits 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 first 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 fixed conditions on payments
from controlled accounts, policies for programmable
money can instead be dynamically attached to and
removed from money that flows 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 fixed when the tokens are issued. In con-
trast, our concept of programmable money comprises
not only the checking of conditions specified in flexi-
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 tech-
nology 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 benefits. However, once more than one use case
should be implemented, blockchain is the more suit-
able technological basis for the following reasons:
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.
(i) there would often not be a single authority (e.g.,
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 efficiently 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 fiat 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 defines 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 fulfilled (lines 4-6).
This often includes a check whether the recipient is
allowed to receive funds for a specific purpose, e.g.,
only registered physiotherapists can receive payments
for physiotherapy. Each policy specifies 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 simplified 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-
1f u n c t i o n t r a n s f e r ( p ar c e l , r e c i p i e n t , s e r v i ce , am ou nt )
2require ([...]) ; // in i ti a l ch e ck s : sp e nd er aut h o ri z ed ? A mo un t a va i la 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 ce l . p o l i c i e s )
5i f ( ! p o l i c y . c h ec k ( sender , r e c i p i e n t , s e r v i c e , a mo un t ) )
6r et u rn f a l s e ;/ / if th e p ol i cy f or b id s t he t ra ns f er , te r mi n at e
7else
8 n e w P ol i c i e s . a pp e nd ( p o l i c y . g e t N e x t P o l i c i e s ( sender , r e c i p i e n t , s e r v i c e ,
amo un t ) ) ;
9 p a r c e l . s u b t r a c t ( a mo un t ) ; // r em ov e am ou n t f ro m ol d pa rc e l
10 n e wP 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 , am ou n t ) ; / / n e w p a rc e l w i t h n ew
policies
Listing 1: Pseudo code of policy-aware transfer function
mained unchanged, the physiotherapist could them-
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 flagged 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-modifiable poli-
cies provide a high degree of flexibility. 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 notifi-
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 confidential-
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-specific 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. Specifically, 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-defined 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
(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.
providing specific 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-
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 definition of a REST
API, specified 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 confidentiality, 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 fulfilled. For the existing centralised
NDIS system used in production, payment success
rates are reported publicly2and 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
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). Confidential-
ity and privacy were partly treated by having separate
pseudonymous identifiers 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-
2https://www.ndis.gov.au/about-us/publications, see
“weekly payment summaries”; accessed 2021-02-20.
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
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) identified
potential benefits 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-defined. 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 verification 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.
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 significantly restricting
its functionality may be required to achieve full
scalability. In our view these on-ledger costs are
unlikely to have a significant 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 confidentiality 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 significant 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 flows 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 specific 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 sufficient level of understand-
ing of the policies attached to the money?
How can horizontal scaling be achieved for nodes
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 specific 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 verification 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.
... In our study, we were able to generate insights of value to the business. In more detail, we provide a clear view of how Augur is used, verify its design mechanisms, and check for unintended behavior and bugs in the (immutable) code; immutability poses a challenge from a business process management (BPM) perspective [20], and software engineering in general [28]. The usefulness of the insights was confirmed by anecdotal evidence of Augur's chief architect, particularly in terms of understanding user behavior and code validation, which is especially relevant for security aspects in an open-source application that can be invoked (and thus potentially attacked) by anyone with Internet access. ...
... From his perspective, using process mining for the analysis of blockchain applications generally, and Augur, in particular, provides value in three ways. First, it helps to verify the design mechanisms and check for unintended behavior and bugs in the (immutable) code; immutability poses a challenge from a BPM perspective [20] and software engineering in general [28]. Second, process mining provides a clear view of how an application is used, which is also helpful for designing updated versions of an application. ...
Chapter
Through its smart contract capabilities, blockchain has become a technology for automating cross-organizational processes on a neutral platform. Process mining has emerged as a popular toolbox for understanding processes and how they are executed in practice. While researchers have recently created techniques for the challenging task of extracting authoritative data from blockchains to facilitate the analysis of blockchain applications using process mining, as yet there has been no clear evaluation of the usefulness of process mining on blockchain data. With this paper, we close that gap with an in-depth case study of process mining on the popular Ethereum application Augur, a prediction and betting marketplace. We were able to generate value-adding insights for application-redesign and security analysis, as validated by the application’s chief architect and revealed blind spots in Augur’s white paper.
... In our study, we were able to generate insights of value to the business. In more detail, we provide a clear view of how Augur is used, verify its design mechanisms, and check for unintended behavior and bugs in the (immutable) code; immutability poses a challenge from a business process management (BPM) perspective [20], and software engineering in general [28]. The usefulness of the insights was confirmed by anecdotal evidence of Augur's chief architect, particularly in terms of understanding user behavior and code validation, which is especially relevant for security aspects in an open-source application that can be invoked (and thus potentially attacked) by anyone with Internet access. ...
... From his perspective, using process mining for the analysis of blockchain applications generally, and Augur, in particular, provides value in three ways. First, it helps to verify the design mechanisms and check for unintended behavior and bugs in the (immutable) code; immutability poses a challenge from a BPM perspective [20] and software engineering in general [28]. Second, process mining provides a clear view of how an application is used, which is also helpful for designing updated versions of an application. ...
Conference Paper
Full-text available
Through its smart contract capabilities, blockchain has become a technology for automating cross-organizational processes on a neutral platform. Process mining has emerged as a popular toolbox for understanding processes and how they are executed in practice. While researchers have recently created techniques for the challenging task of extracting authoritative data from blockchains to facilitate the analysis of blockchain applications using process mining, as yet there has been no clear evaluation of the usefulness of process mining on blockchain data. With this paper, we close that gap with an in-depth case study of process mining on the popular Ethereum application Augur, a prediction and betting marketplace. We were able to generate value-adding insights for application-redesign and security analysis, as validated by the application's chief architect and revealed blind spots in Augur's white paper.
Preprint
Full-text available
The rise of open and permissionless blockchains has introduced novel platforms for applications based on distributed data storage. At the application and business levels, long-established query languages such as SQL provide interoperability that can be complemented by blockchain-based data storage today, enabling permissionless and verifiable data storage along with decentralized execution across tens of thousands of nodes. However, when accessing one or more blockchains, interoperability is not provided today, posing challenges such as inhomogeneous data access in addition to different features and trade-offs, e.g. in data and distribution, scalability, and security. Towards interoperability in data access among the increasing number of blockchain platforms, this paper introduces a cross-chain query language for data access across blockchains. Similar to SQL, the language abstracts from implementation based on a data model compatible with the largest open and permissionless blockchains (OPB) today. The language, data model, and processing architecture are demonstrated and evaluated with an implemented prototype, aiming to contribute to the discussion on blockchain interoperability among OPB. [© 2022 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.]
Chapter
Robotic process automation (RPA) is a technology that is presented as a universal tool that solves major problems of modern businesses. It aims to reduce costs, improve quality and create customer value. However, the business reality differs from this aspiration. After interviews with managers, we found that implementation of robots does not always lead to the assumed effect and some robots are subsequently withdrawn from companies. In consequence, people take over robotized tasks to perform them manually again, and in practice, replace back robots—what we call ‘re-manualization’. Unfortunately, companies do not seem to be aware of this possibility until they experience it on their own, to the best of our knowledge, no previous research described or analysed this phenomenon so far. This lack of awareness, however, may pose risks and even be harmful for organizations. In this paper, we present an exploratory study. We used individual interviews, group discussions with managers experienced in RPA, and secondary data analysis to elaborate on the re-manualization phenomenon. As a result, we found four types of ‘cause and effect’ narrations that reflect reasons for this to occur: (1) overenthusiasm for RPA, (2) low awareness and fear of robots, (3) legal or supply change and (4) code faults.KeywordsRobotic process automationRPASoftware robotInvestmentInformation systemsWork manualization
Chapter
The main aim of this paper is to present the results of a process-project maturity assessment of large organizations in Poland. The paper consists of two main parts: a theoretical part, which primarily outlines the rationale supporting the prospects and the need for an orientation towards process and project organizations, and an empirical part, presenting an attempt to integrate the MMPM and PMMM maturity models, in order to assess organizational level of process-project maturity. The empirical research carried out on a sample of 90 large organizations shows that vast majority of the organizations surveyed are characterized by low levels of process and project maturity, and 13 of the entities examined can be described, based on the assumptions adopted, as a process-project organization (level 4 of process-project maturity). Further, the research conducted has led to an outline of the factors supporting the recognition of process management as a method fundamental to the designing a process-project organization. Maturity model integration has demonstrated the levels of process and project maturity as well as a statistically positive correlation between the degree of process maturity and project maturity. The original character of this paper primarily concerns the need to fill the literature gap, consisting in the scarcity of publications describing integration of process and project management methods and the deficit of works presenting process-project maturity results.KeywordsProcess-project oriented organizationBPMProcess managementProject managementMaturity
Chapter
Blockchain has been proposed to facilitate the enactment of interorganisational business processes. For such processes, blockchain can guarantee the enforcement of rules and the integrity of execution traces—without the need for a centralised trusted party. However, the enactment of interorganisational processes pose manifold challenges. In this work, we ask what answers the research field offers in response to those challenges. To do so, we conduct a systematic literature review (SLR). As our guiding question, we investigate the guarantees and capabilities of blockchain-based enactment approaches. Based on this SLR, we develop a taxonomy for blockchain-based enactment. We find that a wide range of approaches support traceability and correctness; however, research focusing on flexibility and scalability remains nascent. For all challenges, we point towards future research opportunities.KeywordsBlockchainBusiness process enactmentBusiness process executionInterorganisational processesTaxonomySLR
Article
Full-text available
Conditional payments allow the transfer of money only when pre-defined 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 digital 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 accounts, but instead to money itself. Policies here specify the conditions when money may be spent, and can be automatically checked by the money as it is spent. Policies can also define auxiliary actions to be taken as part of payment transactions, including side-payments. Policies can be dynamically added to and removed from money as it flows through an economy. These policies could be budget rules for tied funds, but could also enable new forms of “values-based money” that respect ethical or other rules which relate to societal values or social norms. We report on some of our experiences and insights regarding blockchain architecture, software engineering with blockchain, and blockchain-based programmable money. We also identify opportunities and open research questions in these areas.
Article
Payment systems, and interoperation within and between them, are complicated, making analysis and dialogue among analysts, technologists, and members of the public challenging. Given the emergence of new payment mechanisms, like CBDC and private digital currency, these discussions are increasingly important to identify opportunities and challenges. This paper proposes a four-step framework and provides several tools policy analysts, technologists, and interested members of the public can use to interpret and discuss payment system interoperation. First, we provide an overview of payment system interoperation and why it is important. Next, we describe our four-step framework. Then, we apply the framework by describing the potential results of a hypothetical fit-for-purpose interoperation discussion where both a hypothetical central bank digital currency (CBDC) and stablecoins, a type of private digital currency, could co-exist in a payment system.
Chapter
Due to growing digital opportunities, persistent legislative pressure, and recent challenges in the wake of the COVID-19 pandemic, public universities need to engage in digital innovation (DI). While society expects universities to lead DI efforts, the successful development and implementation of DIs, particularly in administration and management contexts, remains a challenge. In addition, research lacks knowledge on the DI process at public universities, while further understanding and guidance are needed. Against this backdrop, our study aims to enhance the understanding of the DI process at public universities by providing a structured overview of corresponding drivers and barriers through an exploratory single case study. We investigate the case of a German public university and draw from primary and secondary data of its DI process from the development of three specific digital process innovations. Building upon Business Process Management (BPM) as a theoretical lens to study the DI process, we present 13 drivers and 17 barriers structured along the DI actions and BPM core elements. We discuss corresponding findings and provide related practice recommendations for public universities that aim to engage in DI. In sum, our study contributes to the explanatory knowledge at the convergent interface between DI and BPM in the context of public universities.
Article
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.
Technical Report
Full-text available
How can ‘smart money’ better enable conditional payments? This project has sought to answer this question, motivated by the progression of blockchain technologies in recent years. What is smart money? Smart money, or programmable money, is money that can be programmed to be spent only when certain conditions are met and remember how it has been spent. This project created programmable money by attaching smart contracts to blockchain tokens that can be redeemed for payment in Australian Dollars (rather than through a programmable currency). Once programmed, smart money can know who it can be spent by, what it can be spent on, when it can be spent, how much of it can be spent and any other conditions that may be set by the party funding the payment. As smart money is designed not to be misspent, it can reduce friction and enable funders to empower spenders in conditional payment environments. For example, it can reduce the need for funders to assess payments after-the-fact when checking for compliance with spending rules. In addition, as smart money remembers how it has been spent, this can assist with budget management for spenders, and payments reconciliation for businesses. This project developed a smart money proof of concept and applied it to a use case of the NDIS. The NDIS involves highly personalised payment conditions. Since the NDIS was first envisaged in 2011, and even during its ongoing rollout, payments technology has progressed considerably. This includes research into the application of blockchain technology and smart contracts as well as the introduction of Australia’s New Payments Platform.
Conference Paper
Full-text available
This paper reports on a co-speculative interview study with charitable donors to explore the future of programmable, conditional and data-driven donations. Responding to the rapid emergence of blockchain-based and AI-supported financial technologies, we specifically examine the potential of automated, third-party 'escrows', where donations are held before they are released or returned based on specified rules and conditions. To explore this we conducted pilot workshops with 9 participants and an interview study in which 14 further participants were asked about their experiences of donating money, and invited to co-speculate on a service for programmable giving. The study elicited how data-driven conditionality and automation could be leveraged to create novel donor experiences, however also illustrated the inherent tensions and challenges involved in giving programmatically. Reflecting on these findings, our paper contributes implications both for the design of programmable aid platforms, and the design of escrow-based financial services in general.
Conference Paper
Full-text available
This paper presents a qualitative study of the recent integration of a UK-based, digital-first mobile banking app-Monzo-with the web automation service IFTTT (If This Then That). Through analysis of 113 unique IFTTT 'recipes' shared by Monzo users on public community forums, we illustrate the potentially diverse functions of these recipes, and how they are achieved through different kinds of automation. Beyond achieving more convenient and efficient financial management, we note many playful and expressive applications of conditionality and automation that far extend traditional functions of banking applications and infrastructure. We use these findings to map opportunities, challenges and areas of future research in the development of 'programmable money' and related financial technologies. Specifically, we present design implications for the extension of native digital banking applications; novel uses of banking data; the applicability of blockchains and smart contracts; and future forms of financial autonomy.
Article
Full-text available
(Note that we have updated the paper to the accepted version on 23 Jan 2018) Blockchain technology offers a sizable promise to rethink the way inter-organizational business processes are managed because of its potential to realize execution with- out a central party serving as a single point of trust (and failure). To stimulate research on this promise and the limits thereof, in this paper we outline the challenges and opportunities of blockchain for Business Process Management (BPM). We structure our commentary alongside two established frameworks, namely the six BPM core capabilities and the BPM lifecycle, and detail seven research directions for investigating the application of blockchain technology to BPM.
Conference Paper
Full-text available
The integration of business processes across organizations is typically beneficial for all involved parties. However, the lack of trust is often a roadblock. Blockchain is an emerging technology for decentralized and transactional data sharing across a network of untrusted participants. It can be used to find agreement about the shared state of collaborating parties without trusting a central authority or any particular participant. Some blockchain networks also provide a computational infrastructure to run autonomous programs called smart contracts. In this paper, we address the fundamental problem of trust in collaborative process execution using blockchain. We develop a technique to integrate blockchain into the choreography of processes in such a way that no central authority is needed, but trust maintained. Our solution comprises the combination of an intricate set of components, which allow monitoring or coordination of business processes. We implemented our solution and demonstrate its feasibility by applying it to three use case processes. Our evaluation includes the creation of more than 500 smart contracts and the execution over 8,000 blockchain transactions.
Chapter
Blockchain technology and distributed ledger technology (DLT) offer a secure, distributed, and tamper-proof way to store and exchange information. However, apart from standard cryptocurrency-based networks, innovations and process improvements based on the blockchain technology have mostly remained on the conceptualizing stage and have not yet reached mass adoption. There is a high demand for practical experiences from developing blockchain and DLT based systems in various domains outside FinTech. This work seeks to contribute to this gap by presenting real-world experiences from developing a proof of concept for automatizing conditional payments in social benefits and healthcare domains. We found that the key conditions for making these blockchain-based solutions viable are (1) attaining technological maturity and competences, (2) ecosystem thinking and adequate governance of these ecosystems, and finally (3) achieving legal and regulatory predictability. Furthermore, we discuss technological choice, business, and ethical considerations relevant to practitioners and research communities.
Article
Purpose The purpose of this study hopes to encourage further research into the topic of local currencies, as well as specific research into increasing the efficiency of these systems through the use of blockchain technology. There is currently a lack of available research into the topic, which poses barriers for those who wish to study it, so the paper provides a general overview to be used as a starting point for those wishing to broaden their knowledge of local currency systems while also introducing a working implementation of a proof-of-concept for the proposed system. Design/methodology/approach A literature review of available studies on local currencies is conducted to provide an overview of the current systems and their shortcomings. Subsequently, blockchain technology is briefly introduced and an Ethereum-based model is proposed, which helps overcome the problems identified. The section exploring the Ethereum-based model draws code written by the author to simulate the features. Findings The paper concludes that blockchain technology can significantly help improve efficiency, transparency and security of local currency systems, while also helping cut costs associated with the implementation of a complementary monetary system. In the medium-term, local currency systems will most likely use a blockchain protocol as the underlying technology for the network. Originality/value Local currencies are an understudied topic by itself and the intersection between them and blockchain is a nearly non-existent research space. Thus, the paper takes a multidisciplinary approach, aiming to bridge the fields of computer science and economics to provide a foundation for further research.
Book
This book addresses what software architects and developers need to know in order to build applications based on blockchain technology, by offering an architectural view of software systems that make beneficial use of blockchains. It provides guidance on assessing the suitability of blockchain, on the roles blockchain can play in an architecture, on designing blockchain applications, and on assessing different architecture designs and tradeoffs. It also serves as a reference on blockchain design patterns and design analysis, and refers to practical examples of blockchain-based applications. The book is divided into four parts: Part I provides a general introduction to the topic and to existing blockchain platforms including Bitcoin, Ethereum, and Hyperledger Fabric, and offers examples of blockchain-based applications. Part II focuses on the functional aspects of software architecture, describing the main roles blockchain can play in an architecture, as well as its potential suitability and design process. It includes a catalogue of 15 design patterns and details how to use model-driven engineering to build blockchain-based applications. Part III covers the non-functional aspects of blockchain applications, which are cross-cutting concerns including cost, performance, security, and availability. Part IV then presents three detailed real-world use cases, offering additional insights from a practical perspective. An epilogue summarizes the book and speculates on the role blockchain and its applications can play in the future. This book focusses on the bigger picture for blockchain, covering the concepts and technical considerations in the design of blockchain-based applications. The use of mathematical formulas is limited to where they are critical. This book is primarily intended for developers, software architects and chief information officers who need to understand the basic technology, tools and methodologies to build blockchain applications. It also provides students and researchers new to this field an introduction to this hot topic.
Article
Smart contracts might encode legal contracts written in natural language to represent the contracting parties’ shared understandings and intentions. The issues and research challenges involved in the validation and verification of smart contracts, particularly those running over blockchains and distributed ledgers, are explored.