Decision Support Systems 144 (2021) 113508

Contents lists available at ScienceDirect

Decision Support Systems

journal homepage: www.elsevier.com/locate/dss

Bringing transparency and trustworthiness to loot boxes with blockchain

and smart contracts
Arthur Carvalho *
Farmer School of Business, Miami University, Oxford, OH, United States

A R T I C L E I N F O A B S T R A C T

Keywords: The ever-increasing reliance on loot boxes by the video game industry has attracted scrutiny from consumer
Blockchain groups and regulators. For example, this practice of selling random assortments of virtual items for a price has
Design science been criticized for its lack of transparency since, before purchasing a loot box, players do not necessarily know the
Ethereum
possible items they can win and the associated probabilities. Even in the rare cases when the list of items and
Loot boxes
Online video games
probabilities are available, there are no guarantees that a game is actually using that information when randomly
Smart contracts drawing an item, which naturally results in a trust problem. We draw from decision theory to explain the
transparency and trust issues faced by loot boxes, and from a recently proposed decision model by Pedersen et al.
(2019) to motivate the use of blockchain technology in this context. Following the design science research
framework (Peffers et al., 2007), we then explain how loot boxes can be coded as smart contracts running on a
blockchain network, and why this solution effectively tackles the transparency and trust problems we mentioned
above. We illustrate the use of the proposed smart contract by developing a decentralized application (DApp)
that mimics the process of purchasing and opening a loot box. We carefully analyze our solution by considering
its computational complexity, accuracy, security, and cost aspects. We further discuss topics related to gover­
nance and deployment so as to help the video game industry with a potential real-life implementation of our
solution.

1. Introduction trustworthiness. Issues related to psychological manipulations have also

Loot box is a term used in the video game industry to describe certain
in-game rewards that contain a random assortment of virtual items.
Among other motivational factors, these items can help a player to
further progress in a game and/or be used to customize a game avatar.
Players often purchase loot boxes using virtual currencies that might be
earned within the game or bought with real money. As a consequence,
loot boxes have been a strong and robust source of revenue for game
developers. For example, in the case of Activision Blizzard, a US-based
gaming company, approximately 56% of its revenue of US$7.16
billion came from “in-game net bookings” in 2017, which covers loot
boxes and other in-app purchases [1].
Because the content of a loot box is randomly generated, finding rare
and valuable items is often expensive for players and lucrative for game
developers since, oftentimes, players cannot be certain about the content
of the loot boxes or the probability of finding the items they hope to
acquire. The gaming industry, therefore, has been heavily criticized for
indulging in such business practices that lack in transparency and
been raised. The propensity of players to continue gaming and pur­
chasing loot boxes is considered by many psychologically akin to
gambling [12,16,28,35,36]. This is especially troubling for minors since
adolescents tend to have poorer impulse control than adults, which
potentially increases their vulnerability to gambling mechanics and
behaviors [27]. It has indeed been suggested that there exists a link
between loot box engagement and gambling problems among adoles­
cents [26,37]. As we elaborate on later, the use of loot boxes as a major
revenue generation strategy has also become a matter of concern among
regulatory bodies.
Despite the growing concerns and impending regulatory actions
against loot boxes, their use has continued to increase. In fact, reports
suggest that if not precluded by stringent regulations, loot boxes are set
to drive the online gaming market to US$160 billion by 2022 since, as a
report by Juniper Research suggests, “by monetising the random genera­
tion of items, developers are effectively encouraging a form of in-game
gambling, extending both the lifecycle and engagement of games titles to
their audience.” [18]. However, because of concerns surrounding loot

* Corresponding author.
E-mail address: arthur.carvalho@miamioh.edu.

https://doi.org/10.1016/j.dss.2021.113508
Received 9 July 2020; Received in revised form 8 December 2020; Accepted 19 January 2021
Available online 26 January 2021
0167-9236/© 2021 Elsevier B.V. All rights reserved.
A. Carvalho
boxes’ transparency and trustworthiness aspects, and the looming reg­
ulatory restrictions, some important alterations to loot box-driven dig­
ital business strategies and practices may be inevitable.
Against this backdrop, our research objective is to redesign loot box
mechanisms so as to make them transparent and trustworthy. At the
core, our solution represents a loot box mechanism as a smart contract,
thus enabling a video game to invoke computational functions that are
executed in tandem by computational devices (nodes) in a blockchain
network. Each smart contract stores a list of predefined items and
probabilities. The smart contract also has a draw-item function, where
the input is the identifier of a player (e.g., a screen name) and the output
is a single item randomly drawn from the list of items. Not only is the
code of the smart contract stored by the nodes of the blockchain
network, but also is any function call together with the associated inputs
and outputs. By using a public blockchain, anyone can at any time
visualize the code of the smart contract, the list of items and probabil­
ities, as well as the input and output for any function call. This allows
players to verify whether the randomization mechanism is behaving
appropriately.
We underscore that our proposed solution is transparent in a sense
that a player has access to the list of items and probabilities inside the
smart contract before the purchase of the underlying loot box. Regarding
trustworthiness, instead of trusting one central entity (i.e., the game),
trust in our solution is achieved by sharing transaction data across a
large network of untrusted nodes controlled neither by players nor by
game developers. Cryptographic primitives make the data storage
immutable because, computationally speaking, it is prohibitively
expensive to change the data in the blockchain, i.e., once deployed to the
blockchain, the code of the smart contract representing a loot box and
the inputs and outputs of function calls become virtually unchangeable.
This effectively makes blockchain an append-only, tamper-proof data
structure. Because each blockchain transaction is timestamped, a player
can know whether a transaction happened when it was supposed to
happen, i.e., whether the game is indeed calling the smart contract. With
this solution, gaming companies can be more transparent and, thus,
more compliant and arguably more ethical in their practices connected
to loot boxes. In the extreme, when that does not happen, the player or
the appropriate regulatory body will have enough evidence to pursue an
individual, or even a class action, lawsuit against the company because
smart contracts are now starting to be considered valid legal contracts in
various geographical areas [10,19].
In terms of theoretical foundations, we draw from decision theory to
motivate our pursuit of transparency and trustworthiness in loot boxes.
In terms of methodology, we follow the design science research framework
(DSRF) proposed by Peffers et al. [31]. This is illustrated by the orga­
nization of the rest of this paper. After this introductory section, Section
2 addresses the first step in the DSRF, namely problem identification and
the motivation for a solution, where we explain the transparency, trust,
and legal issues faced by loot boxes, and we draw from decision theory
to explain the need for new loot box mechanisms. In Section 3, we define
the objectives for a solution, which is the second step in the DSRF. In that
section, after defining blockchain and smart contracts, we motivate the
suitability of blockchain-based loot boxes by following the decision
model proposed by Pedersen et al. [30]. In Section 4, we design and
develop a solution, which is the third step in the DSRF. In particular, we
introduce our main artifact, namely an algorithm that codes loot boxes
as smart contracts. We also discuss important issues concerning the
design of our algorithm, such as computational complexity and (pseudo)
random number generation in blockchains. We demonstrate our solu­
tion in Section 5 (fourth step in the DSRF). Specifically, to highlight the
features of our main artifact, we develop a decentralized application that
uses the Ethereum blockchain network and mimics the process of buying
and opening a loot box. In Section 6, we address the fifth step in the
DSRF by evaluating our solution in terms of accuracy, security, and cost.
We also discuss governance- and deployment-related topics aiming at
helping gaming companies to implement our solution. We finally
2
Decision Support Systems 144 (2021) 113508
conclude in Section 7.
2. Problem identification & motivation
The first step in the design science research framework is to both
“define the specific research problem and justify the value of a solution”
([31], page 52). The two main problems we identify with current
practices involving loot boxes are the lack of transparency and trust­
worthiness. Specifically, loot boxes are not always transparent in that the
potential items a player can be awarded with as well as the corre­
sponding probabilities are not necessarily available before the purchase
of a loot box. Even when the probabilities and potential items are
available, there is no guarantee that the video game’s randomization
mechanism actually uses that information in practice. For example, a
video game might display the probability 0.1 for a specific item, but then
internally set that value to 0 when randomly drawing an item. This
naturally leads to trust issues.1
One can solve the above-mentioned trust issue by, for example,
inspecting a video game’s source code or by statistically analyzing
several items obtained from similar loot boxes. We argue that these
solutions are not feasible since the source code of video games are
traditionally closed. Moreover, a statistical analysis of the collected
items requires several purchases of the same loot box and/or coordi­
nation among many buyers. One can frame the latter approach as a
wisdom-of-crowds trust verification method. The practical challenges
with such an approach are insurmountable since several players have to
coordinate simultaneous purchases of the same loot box and report the
outcomes to an entity that shall then perform a statistical analysis.
Clearly, the validity of such an analysis is dependent on whether players
are behaving appropriately, i.e., that they are indeed reporting the items
they received honestly. Although there are techniques to incentivize
honest reporting of private information [6], we argue that the extra
complexity required to coordinate players and to create incentives as
well as the cost of buying several loot boxes to perform an ex-post
analysis result in a more burdensome and less efficient approach than
the technology-based trust verification process we suggest in this paper.
As we discuss later, our solution to the transparency and trust issues
relies on disentangling the randomization mechanism from a video
game’s source code. In other words, the randomization code is executed
by third-party computational devices whose manipulation is computa­
tionally intractable. The above said, our overarching research question
is:
“How can one develop a loot box mechanism that is transparent and
trustworthy?”
In the next subsections, we further motivate the need for new loot
box mechanisms from two different perspectives, namely a legal view­
point and through the theoretical lens of decision theory.
2.1. Loot boxes, gambling behavior, & regulatory efforts
Loot box is a term used primarily in the video game industry to
describe any type of digital container that randomly generates rewards.
Loot boxes play upon players’ desire to acquire the most sought-after
and prestigious in-game items, be they items that help with game pro­
gression or cosmetic goods. Loot boxes often rely on game design and
gamification elements to lure players. For example, opening a loot box is
traditionally accompanied by visuals (e.g., fireworks) and audios (e.g.,
drumrolls) to boost excitement. Artificial scarcity is another common
element, where the items players can receive range from very common
to very rare [24]. This scarcity is oftentimes promoted when certain
items are only available for certain periods, thus creating the sense that
1
See, for example, the thread “Nintendo, Sony, Microsoft to require loot box
odds disclosure” on Reddit (2019) [32] for a sample discussion about loot boxes
and trust within a video-game community.
A. Carvalho
players have to either get them now or never again. The combined sense
of urgency and rarity can strongly influence consumers’ purchase de­
cisions [21].
Although a rather common practice now, loot boxes have frequently
received fierce criticism. For example, loot boxes that offer items that
can directly affect a player’s ability to compete with others have been
criticized as “pay-to-win mechanisms.” These mechanisms are
commonly tied to game-design choices that promote and encourage
players to purchase loot boxes. Traditionally, video games have been
seen as “games of skill,” rather than “games of chance.” As such, they
have escaped gambling-related regulations. More recently though, there
have been suggestions that loot boxes display many of the elements that
characterize gambling activities [12,23,33]. These findings have led to
increasing legislative efforts concerning fair disclosure of information
and sales restriction on games containing loot boxes. For example, since
2017, games sold in China must explicitly state the draw probability of
all virtual items and services in loot boxes [29]. In 2018, a report by the
Netherlands Gambling Authority found that loot boxes offering tradable
items are illegal and, hence, the underlying games cannot be sold
without an appropriate license [33]. Even for games that do not allow
for the trade of winnable items, the Dutch entity stated that “... loot boxes
could nevertheless foster the development of addiction, these games are at
odds with the objective of preventing addiction to organised games as much as
possible.” [33]. A similar conclusion was also reached by the Belgium’s
Gaming Commission in a report released soon after the release of the
Dutch report [23]. Within the United States, several legislative efforts
have been made at the state level. For example, separate bills were
introduced in Hawaii’s and Minnesota’s state legislatures concerning
new warning labels for games containing loot boxes and the prohibition
of sales to young players. At the federal level, a bill titled “The Protecting
Children from Abusive Games Act” was introduced in the United States
Senate in 2019 to “ban loot boxes and pay-to-win microtransactions in
games played by minors.”
Another significant recent development was the loot box related
workshop hosted by the Federal Trade Commission (FTC) of the United
States in August 2020, when the issue of enforcement concerning the
proper disclosure of items and probabilities was extensively discussed.
For example, “panelists and some commenters expressed concern about the
transparency of loot box odds, particularly if a game uses dynamic odds that
may vary by player or time” [17]. Moreover, FTC “staff advises that
disclosure of loot box odds must be accurate and nonmisleading to avoid a
Section 5 violation.”2 [17]. In other words, game developers whose
games’ loot boxes do not follow the reported probabilities when drawing
items may face the risk of unfair business practices litigation. Within this
context, the proposed solution in this paper provides a way of un­
equivocally proving whether video games are indeed drawing items
based on the disclosed probabilities.
Besides governmental bodies, video-game associations are also
trying to prevent unethical practices concerning the use of loot boxes.
For example, the Korea Association of Game Industry (K-GAMES)
consistently monitors loot box mechanisms employed by the most
popular video games at a given time. Non-compliant practices can lead
K-GAMES to publicly “name-and-shame” games and game developers
[25]. Hence, besides the financial aspect, unethical loot box practices
might harm a game developer’s reputation.
If loot boxes are deemed illegal because, say, they constitute (online)
gambling, then the video game industry might suffer drastic revenue
losses. One potential path to avoid government intervention and regu­
lation is for the industry to develop self-regulating principles concerning
the use and monetization of loot boxes. An example of self-regulatory
initiatives is coming from platforms where games can be downloaded
from, such as Google’s Play Store an Apple’s App Store. For example,
2
Section 5 of the FTC Act 15 (USC §45) prohibits unfair or deceptive acts or
practices in or affecting commerce.
3
Decision Support Systems 144 (2021) 113508
Play Store requires that “apps offering mechanisms to receive randomized
virtual items from a purchase (i.e. ‘loot boxes’) must clearly disclose the odds
of receiving those items in advance of purchase” [20]. Following a similar
path, the major console makers, namely Sony Interactive Entertainment,
Nintendo, and Microsoft announced plans to roll out new policies that
will require games developed for their platforms to disclose information
on the odds of obtaining virtual items from paid loot boxes [14].
As we stated above, banning loot boxes might hurt the video game
industry. Consequently, players will also be affected since they will have
access to fewer games due to companies potentially going out of busi­
ness. One can argue that the inclusion of loot boxes in (online) video
games is justified due to a publisher’s ongoing cost concerning the
maintenance of the game servers. Moreover, loot boxes provide an extra
revenue source well after the release of a game. At the same time, the
issues regarding proper disclosure of information must be dealt with. We
argue that regulations mandating video games to display lists of items
and probabilities are not enough since there are no guarantees that the
video game is taking the displayed items/probabilities into account
during the item-draw process. That said, we see our solution as being of
great value to the video game industry’s self-regulatory efforts since it
provides provable guarantees that a video game is indeed using specific
probabilities and items when randomly drawing items.
2.2. A decision theory perspective on loot boxes
From a theoretical perspective, one can analyze loot boxes through
the lens of decision theory. Consider a set of outcomes O =
{o1 , o2 , …, on }, where each outcome represents an item that can
potentially be part of a loot box. Each item oi is associated with a
probability value pi, for i ∈ {1, …, n}, which in turn describes the like­
lihood of a player receiving that particular item. Hence, ℙ = {p1, p2, …,
pn} represents a probability distribution over the n potential items that
can be in a loot box. Both O and ℙ can be known or unknown to a player
before that player makes a decision on purchasing a loot box. When the
player purchases and “opens” the loot box, one item is randomly drawn
from the set O. That said, using conventional notation from decision
theory, a loot box L can be defined as a lottery: L =
[o1 : p1 , o2 : p2 ,…, on : pn ].
The classic expected utility framework posits that the value a deci­
sion maker (player) derives from a lottery ticket L is given by the
∑n
following equation: U(L) = i=1 pi × U(oi ), where the function U(⋅)
represents the decision maker’s risk attitude, e.g., a convex function U(⋅)
implies that the decision maker is risk seeking, whereas a concave
function implies that the decision maker is risk averse. Knowing the
potential outcomes and probabilities, a player can then decide on
whether or not to purchase a specific loot box. For example, say that a
loot box costs $1. Then, according to the expected utility framework, a
rational player will only buy the loot box if U(L) > U(1).
Not having access to potential outcomes and/or probabilities means
that players’ purchase decisions cannot be analyzed under the ratio­
nality assumptions implied by expected utility theory. Nevertheless,
other concepts from decision theory can be used to analyze the above
scenarios. For example, the term ambiguity attitude has been commonly
used to designate differences in decision making under known and un­
known probabilities [11]. It has been suggested that humans tend to be
ambiguity averse, meaning that a lottery (such as a loot box) with a
known probability distribution over plausible outcomes is often
preferred over a lottery whose probabilities are unknown [13,22]. In
other words, given two loot boxes with similar items, a player would
likely value the loot box having a known probability distribution higher
than the loot box whose probability distribution is unknown.
From a theoretical perspective, the above discussion illustrates the
need for a solution to the transparency and trust problems faced by loot
boxes. Such a solution aids in the decision-making process players face
by giving them more information about the underlying product. As
A. Carvalho
suggested by King and Delfabbro [24], a transparent loot box mecha­
nism “help[s] the player to make better decisions about the value proposition
of the in-game monetization system.” This in turn is not only more likely
preferred by the players, as the discussion on ambiguity attitudes sug­
gests, but it also allows players to follow rationality constructs as defined
by expected utility theory. That said, a transparent and trustworthy loot
box mechanism has as a decision support component in a sense that it
helps players deciding on whether to purchase a loot box. In the
following section, we explain how public blockchains and smart con­
tracts provide an ideal solution for the aforementioned transparency and
trust problems.
3. Definition of the objectives for a solution
The second step in the design science research framework is to “infer
the objectives of a solution from the problem definition and knowledge of
what is possible and feasible” ([31], page 55). In our specific context, this
means designing a loot box mechanism that not only displays lists of
items and associated probabilities, but also provides formal guarantees
that a video game is actually using those lists when randomly drawing
items. As we elaborate on in Section 4, we achieve our goal by defining
loot boxes as smart contracts and running them on a public blockchain. In
what follows, we motivate the need for a blockchain-based solution by
adapting and using a recently proposed decision model concerning
blockchain adoption. Before doing so, we first define blockchain and
smart contracts in the following subsection.
3.1. Blockchain & smart contracts
For our purposes, the blockchain technology can be defined as a
distributed and decentralized append-only database. Although not
consensual, our definition of distribution relates to the redundancy
created by replicating the same database across several computational
devices, whereas decentralization has to do with ownership in a sense
that those computational devices are not necessarily controlled by the
same entity. In this context, it is important to distinguish users from
nodes. Nodes create a peer-to-peer network, and they are the computa­
tional devices responsible for data storage, whereas users create data/
transactions to be stored by the nodes.
Beyond transaction data, some blockchain models allow for the
nodes to store and execute algorithms proposed by users. One of the
advantages of such a computational model is that not only the under­
lying code is immutable, but also is any input or output produced after a
node executes the code. Such algorithms are now called smart contracts.
The idea of smart contracts was first proposed as the analog of legal
contracts, but with automated enforcement. A more modern perspective
of a smart contract takes the idea of putting data in a secure ledger and
extends it to computation. That is, it is a consensus mechanism for the
correct execution of a given algorithm. As we explain in Section 4, our
solution to the transparency and trustworthiness issues surrounding loot
boxes involves coding each loot box as a smart contract. Hence, when­
ever a user (player) buys and opens a loot box, behind the scenes an
algorithm is executed in tandem by blockchain nodes to determine the
item to be received by the player. Hence, trust in our solution is achieved
by sharing transaction data and algorithms across a large network of
nodes controlled neither by the player nor by the game developer.
Finally, concerning applications, one can categorize blockchain
models into two categories: public and permissioned blockchains [5].
Public blockchains are open to anyone, and no special permissions are
required to join the network as a user or node. Unlike public block­
chains, permissioned blockchains focus on business networks of known,
vetted participants operating under a well-defined governance model, i.
e., special permissions are required to join the network as a user and/or
node. The goal of permissioned blockchains is to secure and share the
transactions among a group of participants who know, but might not
fully trust each other.
4
Decision Support Systems 144 (2021) 113508
3.2. A decision model concerning blockchain adoption
We further motivate the use of the blockchain technology to solve the
aforementioned issues with loot boxes by following the decision model
in Fig. 1. In particular, we borrow from the model by Pedersen et al.
[30], which in turn provides a ten-step decision path to determine
whether an application merits a blockchain solution and, if it does,
which kind of blockchain application is more suitable. The first seven
questions in Fig. 1 are the same as in the model by Pedersen et al. [30],
and they are used to define whether the blockchain technology is useful
and feasible in a given domain. The last question in Fig. 1 captures the
last three questions in the original model by Pedersen et al. [30] and
tailor them to better reflect our own definitions of public and permis­
sioned blockchains. That last question helps a decision maker to choose
between a public or a permissioned blockchain.
The first decision question reflects the nature of the blockchain
technology: “is there a need for a shared common database?”. For billing
and auditing purposes, it is clearly desirable for every transaction
involving loot boxes to be stored in a database. A database shared by
many is crucial to enhance trust since, for example, governmental and
regulatory agencies as well as the gaming community can access loot
box related data and check for potential misuses by game developers.
The second question is about whether multiple users interact with
the blockchain: “are multiple parties involved?”. The answer is positive in
our setting since several players might purchase loot boxes from several
games. External users, such as regulators, should also have read access to
the database. Regarding the third question (“do the involved parties have
conflicting interests and/or are they trusted?”), if all participants can trust
each other, then a decentralized database, such as blockchain, is not
necessary. Trust issues arise in the context of loot boxes because even
when a game displays the winnable items and corresponding probabil­
ities, the players still do not necessarily know whether those attributes
are taken into account when the game randomly draws items. This is in
part due to the fact that video games traditionally have proprietary,
closed source code.
A potential solution to the above-mentioned trust issue is to have a
third-party entity responsible for the monitoring of loot box mecha­
nisms. Such an entity could be, for example, a nonprofit organization
created by industry members (such as K-GAMES) or a public body trying
to prevent unhealthy gambling practices (such as the Netherlands
Gambling Authority). Despite the regulatory pressures we discussed in
Section 2.1, we argue that having a third-party entity responsible for
monitoring loot box mechanisms may not necessarily alleviate the trust
and transparency problems since players must still trust that the entity
will behave benevolently, efficiently, and effectively. This implies a
positive answer to the fourth question (“can or do the participants want to
avoid a trusted third party?”). As suggested by Pedersen et al. [30], “one
advantage of blockchain systems is that they enable peer-to-peer transactions
without relying on a trusted third-party service.”
The answer to the fifth question, namely “do the rules governing system
access differ between participants?”, is positive since the video game, as a
blockchain user, and players have different roles. Specifically, the video
game must handle the logistics behind the drawing of items, e.g., calling
appropriate procedures that will write data to the blockchain, moni­
toring results, etc. The players must be able to check the legitimacy of the
performed computations and results and, hence, they do not necessarily
need all the system access that the video game has, e.g., writing access.
These rules remain largely unchanged over time, as do the rules gov­
erning transactions, meaning a positive answer to the sixth question (“do
the rules for transacting remain largely unchanged?”). Conceptually, the
transactions involving loot boxes do not change over time: a player in­
dicates the desire to purchase a loot box and the video game randomly
draws an item and displays the result back to the player. This immuta­
bility aspect is crucial since, given the append-only nature of block­
chains, the code of a loot box deployed as a smart contract cannot be
deleted and/or updated.
A. Carvalho
Fig. 1. Decision model regarding blockchain adoption. Adapted from the work by Pedersen et al. [30].
The next question inquires about the need for immutability: “is there
a need for an objective, immutable log?”. This is clearly positive in the
context of loot boxes in that an immutable (and trusted) log system can
unequivocally show that a player’s item was randomly drawn at a
certain time. Moreover, any user should be able to audit the smart
contract stored in the blockchain to undoubtedly prove that the
randomization mechanism is behaving appropriately.
Having established that blockchain is a suitable technology for
solving the trust and transparency issues faced by loot box mechanisms,
the last question, namely “is open access and public transactions
required?”, determines the type of blockchain to be used, i.e., public or
permissioned. As we previously discussed, permissioned blockchains
require one to obtain permissions to join the network as a node or user,
whereas public blockchains allow for universal access. In our context,
allowing for universal access and public transactions further enhances
trust and transparency. For example, auditors, regulators, players, par­
ents, etc., can all have immediate access to transaction data regarding
loot boxes, and even help to maintain the underlying infrastructure as
nodes.
The previous answers suggest that a public blockchain can effectively
solve the trust and transparency issues with loot boxes. As we explain in
the following section, the objective of the blockchain nodes in our so­
lution is twofold: 1) independently perform the computations required
to randomly draw items; and 2) independently store the inputs/outputs
concerning the above computations.
4. Design & development
The third step in the design science research framework is to design
and create the underlying artifact, which in turn can be constructs,
methods, or models [31]. Our main artifact is represented by an algo­
rithm that codes a loot box as a smart contract. In particular, whenever a
player decides to purchase a loot box, the underlying video game will
invoke the associated smart contract, which in turn performs all the
computations required to return an item. That said, our solution disen­
tangles the computations required to randomly draw items from the
game’s code and, remarkably, it does not require the entire game to be
open source. Fig. 2 illustrates a high-level perspective on the process of
Fig. 2. The process of buying and opening a loot box under our proposed solution.
5
Decision Support Systems 144 (2021) 113508
buying and opening a loot box using our proposed solution.
The purchasing process starts after a player indicates s/he wants to
buy a loot box. In practice, this can be done by, for example, clicking on
appropriate menu items. Thereafter, the video game displays the items,
associated probabilities, as well as the identifier (address) inside a public
blockchain of the smart contract that encodes the loot box. The player
may then use the smart contract’s address to verify important attributes,
such as whether the previously displayed items and probabilities
correspond to the items and probabilities in the smart contract. This
latter step illustrates the transparent nature of our solution. If the player
decides to proceed with the purchase of the loot box, the game then
invokes a function in the smart contract to draw an item. At this point,
all the nodes in the blockchain network run the same algorithm and
return the same output (drawn item). The video game retrieves and
returns that output to the player alongside an identifier representing the
function call (transaction). Based on that identifier, the player can
eventually verify whether the video game actually invoked the appro­
priate smart contract and whether the output displayed by the video
game corresponds to the output generated by the nodes in the block­
chain network. This latter step illustrates the trustworthiness aspect of
our solution.
The core of our solution lies in defining a loot box as a smart contract.
Algorithm 1 shows the pseudocode of such a smart contract. In the first
two lines, the smart contract explicitly defines the winnable items
alongside the associated probabilities. Access to the content of these lists
should be freely available to any user of the underlying blockchain. The
smart contract also defines a function called drawItem, whose argument
is the screen name of the player buying the loot box. That function starts
by running a random number generator (RNG) function using the player’s
screen name and a timestamp as the seed to generate a random number.
We further elaborate on the RNG function below. Thereafter, the smart
contract produces an output based on the drawn value. Specifically, the
smart contract uses a traditional technique from evolutionary compu­
tation called the fitness proportionate selection, also known as roulette
wheel selection. Under this technique, the items are represented as non-
overlapping “bins” proportional to their associated probabilities, and
the random value from the RNG function defines a single bin.
To illustrate the behavior of Algorithm 1, consider the following
A. Carvalho
example, which is recurring throughout the paper. Let items ← [“Com­
mon Sword”, “Silver Sword”, “Dragon Sword”] and probabilities ← [70,
30, 10], where probability values are represented as percentages.
Moreover, assume that RNG returns values in the range [0,100). As we
explain later, the reason for using percentages is that Solidity, the pro­
gramming language we used to develop a fully functional prototype,
does not support fixed-point numbers yet. After calling the function
drawItem, say that the result from the RNG function is r = 92. During the
first iteration of the loop, the smart contract checks whether r is greater
than or equal to 0 and below 70. If this condition is true, then the first
item, namely “Common Sword”, whose associated probability is 0.7, is
returned to the player. Since that condition is not satisfied, the algorithm
then checks during the second iteration of the loop whether r is greater
than or equal to 70 and below 70 + 20 = 90. This previous condition
defines an interval of length 20, which represents the percentage asso­
ciated with the second item “Silver Sword”. Since the second condition is
also false, the algorithm finally checks whether 90 ≤ r < 100. This
condition is true, and the drawItem function returns the item “Dragon
Sword”.
There are two important points to highlight regarding Algorithm 1.
First, the drawItem function is efficient since it runs in polynomial time.
Specifically, its complexity is O(n), where n is the total number of
winnable items. Algorithmic efficiency is crucial in the context of smart
contracts because the same code is executed by several nodes in the
network. Moreover, as we soon discuss, some blockchain networks
charge users based on the complexity of the executed smart contract.
The second important point to highlight concerns randomization,
which is a naturally challenging task in distributed environments such as
blockchain. In our specific case, because the smart contract representing
a loot box is processed in parallel by many nodes, a poorly designed
randomization process might then imply that different nodes randomly
draw different items for the same player buying a loot box. To solve this
problem, our solution uses a pseudorandom number generator based on
hash functions. Specifically, the RNG function in Algorithm 1 can be
defined as follows:
RNG(screenName, timestamp) = H(timestamp|screenName)%c (1)
where H(⋅) is a hash function, the vertical bar ∣ represents the concate­
nation operator, and c is a constant used to determine the upper bound
of RNG. To illustrate the RNG function in Eq. (1), assume a player called
Alice purchases a loot box, and the respective timestamp is Dec-09-2019
07:40:32 PM. Moreover, let c = 100 so that this example is in agreement
with our running example. Finally, assume that H(⋅) is the popular SHA-
256 hash function. The random value resulting from RNG in this setting
is then equal to H(“Alice”| “Dec − 09 − 201907 : 40 : 32PM”) % 100 =
84.
6
Decision Support Systems 144 (2021) 113508
Hash functions are deterministic, meaning that they always produce
the same output given a fixed input. That said, to produce the same
output, we need to make sure that the nodes all have access to the same
input when calling RNG. The reason for using both a player’s screen
name and a timestamp as input to RNG is that this allows for two players
to draw different items at the same time, and the same player to draw
different items at different times. The only missing piece now is how to
define a universally-accepted timestamp. Clearly, nodes cannot use their
own local time as a timestamp when calling RNG since these computa­
tional devices might be located in different regions. Moreover, time­
stamps should not be predictable, otherwise players can effectively
define the items they receive by buying loot boxes during suitable times.
For example, it is easier for players to time their loot box purchases and
acquire a desired item when timestamps contain time information up to
minutes only than when timestamps encode up to fractions of a second.
We suggest implementations of Algorithm 1 to use the time the most
recent block was proposed as a timestamp. It is often the case that a node
timestamps a proposed block when the node proposes a block to be
added to the blockchain. All the other nodes verifying that block have
now access to a universally-accepted timestamp. Given that every call to
the drawItem function defines a transaction to be added to a block, a
major implication of the above suggestion is that a single player is
limited to buy only one loot box per block. Otherwise, if a player buys
several loot boxes and the respective transactions are added to the same
block in the blockchain, then that player will receive the same item
several times since neither his/her screen name nor the block’s time­
stamp have changed. This is not a significant constraint for most
blockchain networks that support smart contracts. For example, at the
time of writing, Ethereum has an expected block production time be­
tween 10 and 20 seconds. Given the different timestamps for different
blocks, the hash value that defines the item a specific player receives
then changes every 10 to 20 seconds on Ethereum.
5. Demonstration & evaluation
The fourth step in the design science research framework is to
demonstrate the proposed artifact [31]. This task might involve showing
the use of the artifact in simulations, experiments, and/or case studies.
In our particular case, we develop a decentralized application (DApp) that
mimics the process of buying a loot box, as described in Fig. 2. A DApp is
an application that relies on services provided by a decentralized
network, such as BitTorrent or blockchain. In our demonstration, our
DApp relies on the Ethereum blockchain, which we elaborate on next.
A. Carvalho
5.1. Ethereum
Ethereum is a decentralized computational platform that runs smart
contracts. In other words, besides transactions involving the native
cryptocurrency called Ether, users in this public blockchain can also
create transactions that deploy or run smart contracts, which in turn are
traditionally developed using a programming language called Solidity.
Transactions in Ethereum might require nodes to perform computations
that change the state of the blockchain, e.g., to update a user’s balance.
Ethereum “charges” the transaction creator for the computational costs
of a transaction. Specifically, gas is a unit that measures the amount of
computational effort it takes to execute a transaction. At the time of
writing, the average gas unit is equal to approximately 1.15 × 10− 8
ethers [15]. Every Ethereum transaction requires at least 21,000 gas, i.e.,
approximately 2.4 × 10− 4 ethers on average or US$0.12 given the cur­
rent exchange rate of US$504.50 per Ether. Naturally, more complex
transactions, such as deploying a complex smart contract, cost more gas.
Ethereum users must use the Ether cryptocurrency to pay for the gas
required to perform a transaction. There is no fixed exchange rate; it is
up to the sender of a transaction to specify any gas price s/he likes. What
prevents users from setting the gas price equal to 0 ethers is that the
nodes collecting transactions use that price when determining trans­
action fees. In particular, the transaction fee collected by a node pro­
posing a block is equal to the total amount of gas it takes to run the
transaction times the gas price suggested by the transaction creator. In
this way, the higher the suggested gas price, the more appealing a
transaction will be to a node. That is, the quicker a transaction will likely
be added to a block.
5.2. DApp
As we suggested before, we demonstrate our proposed ideas by
developing a proof of concept that runs on top of Ethereum. The
resulting decentralized application (DApp) mimics the process of buying
and opening a loot box under the proposed solution, as Fig. 2 illustrates.
In practice, this DApp would be part of a video game using smart con­
tracts to randomly draw items. Fig. 3 shows a high-level description of
the interaction among players, DApp, and the Ethereum blockchain.
Before effectively running our DApp, we need to first appropriately
code the smart contract and deploy it to the Ethereum blockchain. The
appendix shows the smart contract in Algorithm 1 coded using the
version 0.4.25 of the Solidity programming language.3 The smart con­
tract encodes the loot box we discussed when explaining Algorithm 1 in
the previous section, i.e., it has three winnable items, namely “Dragon
Sword”, “Silver Sword”, and “Common Sword”. The probabilities asso­
ciated with the items are represented as percentages (respectively, 10,
20, and 70) since, at the time of writing, Solidity does not support fixed-
point numbers yet.
We note that Algorithm 1 as well as our implementation in the ap­
pendix could be more generic. For example, using different data struc­
tures, one could have a single smart contract storing information about
many different loot boxes from a single or even across many video
games. The main drawback of such an implementation choice concerns
costs. In particular, extra transactions could be required to submit items
and probabilities to the smart contract. Moreover, extra storage space
would be used by the blockchain nodes since identifiers of games and/or
different loot boxes would be stored for each purchase. The increased
number of transaction calls as well as the extra storage space cause the
deployment of and interaction with the smart contract more expensive.
Looking at the code in the appendix, both the list of items (line 5) and
probabilities (line 6) are publicly available to any Ethereum user. The
smart contract uses a data structure called blockLastPurchase that maps a
3 4
The source code of the DApp and smart contract are available at htt
ps://github.com/arthurgcarvalho/lootbox.
7
Decision Support Systems 144 (2021) 113508
screen name to a numerical value (line 9). This information is eventually
used to prevent players from trying to draw more than one item per
block (line 15). The smart contract also defines an event called Draws,
which stores relevant data in the blockchain (line 25). The stored data
are defined as a 2-tuple representing a drawn item and its owner, i.e., a
player’s screen name. Our RNG function returns natural numbers be­
tween 0 and 99. It uses the predefined function keccak256 (line 35),
which is an implementation of the Secure Hash Algorithm 3 (SHA-3).
Finally, the drawItem function can only be called by the user whose
address is listed in the smart contract (line 16; line 7), i.e., the game
developer itself. This latter point prevents some cybersecurity attacks, as
we elaborate on in Section 6.2. For testing and evaluation purposes, we
deployed the smart contract to Ethereum test network called Ropsten.
Different software, including our proposed DApp, can now interact
with the smart contract after the same has been deployed to the Ether­
eum blockchain. Our DApp is a web-based application that simulates the
in-game process of buying and opening a loot box. The main purpose of
the DApp is to demonstrate how our ideas can be applied in practice, and
to emphasize idiosyncrasies of blockchain-based loot box mechanisms.
The DApp was developed using the HTML and JavaScript languages
together with the web3 library. The player interacts with the DApp using
any browser. The DApp, in turn, interacts with the smart contract in the
Ethereum blockchain via an API provided by the company Infura.4
Finally, the player interacts with (reads data from) the Ethereum
blockchain via the blockchain-explorer services provided by Etherscan.5
We emphasize that we are using existing services as part of our proof of
concept and, as such, we made no effort to optimize user interfaces. This
human-computer interaction element is clearly a crucial component of
our solution due to the novelty of some concepts (e.g., blockchain ad­
dresses), but designing and evaluating suitable interfaces is beyond the
scope of our work. We expect game developers to greatly improve us­
ability when moving beyond the proof of concept we suggest in this
paper.
We next illustrate the process a player faces when buying a loot box
under our proposed blockchain-based solution. Whenever appropriate,
we reference the underlying steps in Fig. 2, which describes the process
of purchasing and opening a loot box. Before the purchase actually
happens, the player has the chance to look at the list of winnable items
and associated probabilities (Fig. 4a), which is the second step in Fig. 2.
Before committing to the purchase, the player can verify whether the
shown items and probabilities are the same as the ones coded in the
smart contract (step 3 in Fig. 2). By clicking on “Check the Blockchain”,
the player is redirected to the smart contract’s page on Etherscan, which
in turn provides a blockchain-explorer service. In that page, among
other things, the player can check whether the smart contract’s code
does indeed include the items and probabilities previously displayed to
the player (Fig. 4b).
The player can then click on the “Buy Loot Box” button to perform
the purchase (step 3 in Fig. 2). Our proof of concept abstracts all the
payment details and, instead, it focuses on the subsequent interactions
between the DApp and Ethereum. Behind the scenes, the DApp creates,
signs, and submits a transaction to the Ethereum blockchain via the API
provided by the company Infura. In that transaction, the drawItem
function in the smart contract’s code representing the loot box is called
upon (step 4 in Fig. 2). The argument of that function is the player’s
screen name, e.g., “PlayerX” in the example in Fig. 4. Throughout the
above process, what the player sees is simply a loading screen (Fig. 5a).
The “Buy Loot Box” button is disabled on purpose to prevent the player
from purchasing another loot box before receiving his/her previous
item. In practice, a game can have animations to better entertain the
player while waiting for the outcome.
Eventually, the created transaction is added to a block, and the block
https://infura.io/
5
https://etherscan.io/
A. Carvalho
Fig. 3. High-level description of the interaction among players, DApp, and the Ethereum blockchain.
Fig. 4. Potential actions before the purchase of a loot box. The steps inside parenthesis refer to the purchase process in Fig. 2.
added to the blockchain, when the result from calling the drawItem
function becomes available to the DApp (step 5 in Fig. 2). The DApp then
shows the resulting item to the player alongside a link to the trans­
action’s page on Etherscan (Fig. 5b), which is the sixth step in Fig. 2. By
following that link and, hence, the seventh step in Fig. 2, the player can
see when the transaction was created and whether the smart contract s/
he saw before (Fig. 4b) was actually called upon (Fig. 5c). The player can
also confirm whether the item the game displays is the same as the item
resulting from the drawItem function (Fig. 5d).
Our solution is able to effectively create a transparent and trust­
worthy loot box mechanism by displaying lists of items and probabilities
ex ante alongside ex-post proofs that these lists are used during the
randomization process. Nevertheless, there are different aspects of our
solution that merit a thorough discussion, such as its accuracy, security,
and costs. We further evaluate our solution under those criteria in the
following section.
6. Evaluation
The fifth step in the design science research framework concerns the
evaluation of how well the proposed artifact supports a solution to the
identified problems. Such an evaluation might “include quantifiable
8
Decision Support Systems 144 (2021) 113508
measures of system performance ... [and] any appropriate empirical evidence
or logical proof” ([31], page 56). By making both the list of items and
probabilities publicly available, our proposed blockchain-based loot box
mechanism satisfies the transparency aspect we discussed before. We
argue that by disentangling the randomization mechanism from a video
game’s source code, our solution boosts the trust players have in the
system. This latter point implicitly relies on several assumptions un­
mentioned thus far, such as: 1) the calculations by the smart contract are
accurate; and 2) the blockchain must not be manipulated by any user/
node. Moreover, if our proposed solution is to be adopted, the under­
lying financial costs and running time must both be reasonable. To
address the above assumptions, one clearly needs to evaluate a well-
defined proof of concept, as opposed to an abstract idea. As such, we
elaborate on the above assumptions by analyzing the DApp (proof of
concept) we suggested in the previous section.
6.1. Accuracy
Moving the computations regarding the random drawing of items to
a blockchain is unreasonable if those computations are inaccurate. In
other words, the trustworthy characteristic we claim our solution sat­
isfies is invalid if the empirical (observed) distribution of items does not
A. Carvalho Decision Support Systems 144 (2021) 113508

Fig. 5. Events after the purchase of a loot box. The steps inside parenthesis refer to the purchase process in Fig. 2.

match the displayed (theoretical) distribution presented to a player (theoretical) distribution of items. To do so, we call the drawItem func­
before the purchase of a loot box. We test the above equality by per­ tion a number of times for the same player, namely “PlayerX”. The
forming statistical inferences. Table 1 shows the data we use to test number of calls is determined after a power analysis, which in turn al­
different hypotheses. The data represent draws from the same loot box lows us to define the sample size required to detect an effect of a given
we discussed in previous sections, i.e., it has three winnable items, size for a given power and degree of confidence. In particular, we as­
namely “Dragon Sword”, “Silver Sword”, and “Common Sword”, and the sume the traditional significance level and power equal to, respectively,
associated probabilities are, respectively, 0.1, 0.2, 0.7. 0.05 and 0.8. The degrees of freedom is equal to 2, i.e., the number of
We first analyze whether the empirical distribution of the items winnable items minus one. We then define the ideal sample size based
purchased by a single player is statistically equivalent to the expected on the possibility of obtaining effect sizes as small as 0.1, the “small”
effect size value suggested by Cohen [9] for chi-square tests (which we
Table 1 perform next). Given the above, we find that the ideal sample size is
Frequencies concerning winnable items for a total of 1000 draws. equal to approximately 963. To simplify the expected frequencies con­
cerning different items (see the second column in Table 1), we round
Item Expected Single-player Multiplayer
frequency frequency frequency that ideal value up to 1000, which enables us to obtain even smaller
effect sizes. The third column of Table 6.1 shows the frequency of the
Common 700 692 696
sword
obtained items after calling the drawItem function 1000 times for the
Silver sword 200 214 200 screen name “PlayerX”. We can now perform a hypothesis test where the
Dragon sword 100 94 104 null hypothesis is: “there is no significant difference between the single-

9
A. Carvalho
player and the expected frequencies”. The result from a chi-square good­
ness-of-fit test shows that we do not have enough evidence to reject the
null hypothesis (χ 2 = 1.4314, df = 2, p-value = 0.4888).
Next, we determine whether the empirical distribution of the items
purchased by multiple players is statistically equivalent to the expected
distribution of items. To do so, we call the drawItem function 1000 times
using the screen name “Player?”, where the question mark symbol (?) is
actually a number randomly drawn from the discrete uniform distribu­
tion U(0,999). The observed frequency of items is available in the last
column of Table 1. This scenario represents the case where each player is
expected to buy a single loot box. The null hypothesis for our second
hypothesis test is: “there is no significant difference between the multiplayer
and the expected frequencies”. Once again, the result from a chi-square
goodness-of-fit test shows that we do not have enough evidence to
reject the null hypothesis (χ 2 = 0.18286, df = 2, p-value = 0.9126).
Finally, we combine all the aforementioned 2000 draws to create a
scenario where a few players purchase several loot boxes, but the vast
majority purchase just a few. We formulate our null hypothesis as “there
is no significant difference between the observed and the expected fre­
quencies”. Clearly, the expected frequency is now twice what is listed in
the second column of Table 1, whereas the observed frequency is ob­
tained by summing the third and fourth columns. The result from a chi-
square goodness-of-fit test shows that we do not have enough evidence
to reject the null hypothesis (χ 2 = 0.61286, df = 2, p-value = 0.7361).
The above results show that we have strong evidence that the RNG
and drawItem functions work correctly in our Ethereum-based proof of
concept. In other words, the calculations regarding the random drawing
of items appropriately use the probabilities the players have access to.
6.2. Security
Given the append-only nature of blockchains, it is crucial to have an
error-free development and deployment of smart contracts since, after
deployed, a smart contract can no longer be deleted or have its source
code updated [7]. An incorrect code might lead to unexpected behavior
and even financial losses. For example, smart contracts deployed to the
Ethereum blockchain have been subject to several types of attacks due to
code errors [2], the most high-profile being the “DAO attack”, where an
attacker was able to take control of over US$60 million in Ether. To
prevent similar issues, it is crucial to scrutinize every smart contract
before deployment. In our case, we performed static, dynamic, and
symbolic analysis using the tools Securify [34] and MythX6 to find po­
tential issues in our smart contract before deployment.
We argue that the code we report in the appendix is a suitable
starting point for gaming companies contemplating the use of
blockchain-based loot boxes since, according to the above tools, the
same is free of major technical and security issues. Before achieving this
status, we did follow some suggestions by Securify and MythX regarding
improvements. For example, we initially forgot to check whether the
blockchain user calling the drawItem function equates to the address
representing the game developer (line 16). Securify then issued a
warning stating that, as it was, any blockchain user could change the
data structure that stores information about the last purchase by a player
(line 18). When analyzing that warning, we realized that by successfully
calling the drawItem function, any blockchain user could on behalf of
any player add information resulting from a purchase of a loot box to the
blockchain. Again, we have fixed this security issue by only allowing the
user representing the game developer to successfully call the drawItem
function.
The above discussion emphasizes the importance of getting the smart
contract representing a loot box right from the beginning since tradi­
tional patching operations, such as over-the-air updates, are not possible
for blockchains. But security issues go beyond code safety. One must also
6
https://mythx.io/
10
Decision Support Systems 144 (2021) 113508
consider the security and integrity of the underlying network. For
example, if a game developer or any malicious entity joins the block­
chain network as a node, can that entity prevent transactions repre­
senting calls to the drawItem function from being processed?
Theoretically, the previous attack is possible in blockchain models that
follow the proof-of-work consensus mechanism.7 For example, by con­
trolling 51% of the computational resources, i.e., the majority of the
computing power on the network, an attacker can effectively dictate in
the long run the transactions that will and will not be added to the
blockchain. These so called 51% attacks are not likely to happen in well-
established public blockchains, such as Ethereum, the blockchain
network we chose to deploy our smart contract to. The reason for this is
that the attacker would need to acquire an unreasonable amount of
computational power in order to be able to manipulate the network. This
point highlights the importance of appropriately selecting a blockchain
network to deploy a solution to. Immature networks might be more
susceptible to network-level attacks, such as 51% or distributed denial-
of-service attacks, which can effectively prevent a blockchain-based loot
box solution from working.
A final security aspect worth discussing concerns the interface
players access when verifying the smart contract before a purchase and/
or the correctness of a transaction after a purchase. In our demonstration
in Section 5, we used a blockchain-explorer service offered by Etherscan.
In practice, such an interface should be as intuitive as possible so as to
require the least amount of technical knowledge from players. At the
same time, the interface must faithfully reflect the information that is in
the smart contract. A relatively simple attack would be to have the
graphical interface displaying misleading information, e.g., sets of items
and probabilities that do not correspond to what is in the underlying
smart contract. Although researching human-computer interfaces is
beyond the scope of this paper, the above point nonetheless reinforces
the importance of using a public blockchain in the context of loot boxes.
In particular, any player can join a public blockchain, such as Ethereum,
as a node and store smart contracts and transactions. This allows any set
of honest nodes to confirm whether the information displayed on a
graphical user interface reflects what is inside the corresponding smart
contract’s code stored in the blockchain.
6.3. Costs
The last evaluation point of our proposed blockchain-based loot box
mechanism concerns the costs of running the solution. Focusing on the
Ethereum blockchain network, we elaborate on two different costs: 1)
the price of deploying the smart contract; and 2) the price of creating
transactions. Focusing on the former first, we note that the gas value
regarding the deployment of a smart contract is fixed. In particular, at
the time of writing, it costs 663,405 gas units to deploy the smart con­
tract in the appendix to the Ethereum network. Deploying a smart
contract is done via a transaction. As we discussed in Section 5.1, any
user proposing a transaction must also define a gas price, i.e., how much
Ether the user is willing to pay for a gas unit. The proposed gas price
often determines how quickly the transaction is added to a block and,
subsequently, to the blockchain.
For the sake of illustration, assume that the game developer suggests
a gas price of 4 × 10− 9 ethers when deploying the smart contract. This
means that a transaction should be added to the blockchain in about 80
seconds at the time of writing. Alternatively, for a gas price equal to 25
× 10− 9 ethers, that transaction should be processed in about 11 seconds.
Given the current exchange rate of US$504.50 per Ether and the total
cost of 663,405 gas units required to deploy the loot box contract, the
deployment cost concerning the slower case is then 4 × 10− 9 × 663,405
× 504.50 ≈ US$1.34, which is a reasonable cost given that each contract
7
We refer the interested reader to the work by Bano et al. [3] for a review on
different consensus mechanisms.
A. Carvalho
representing a loot box is deployed only once.
The second source of cost we consider concerns the creation of
transactions involving the deployed smart contract. We note first that
some user requests are free of charge since they neither change the state
of the blockchain nor require complex computations. For example, any
user can freely request from a node the value of the public attributes that
store information about items and probabilities (see lines 5 and 6 in the
appendix). Alternatively, a transaction calling the drawItem function
requires several computations, and that function changes the state of the
blockchain by storing extra information in it. It is not possible to
pinpoint the precise cost of calling the drawItem function since it de­
pends on a series of factors, e.g., how long a screen name is and the
number of iterations required to draw an item by the fitness propor­
tionate selection mechanism (see line 23 in the appendix), which in turn
is defined by a random value. In our experiments, calling the drawItem
function cost on average 52,040 gas units. We deliberately chose the gas
price of 10− 8 ethers to get each transaction processed in about 40 sec­
onds at the time of writing. Given the exchange rate of US$504.50 per
Ether at the time, the above cost is equal to 10− 8 × 52,040 × 504.50 ≈
US$0.26 per transaction. That is, the video game must currently pay
about 26 USD cents to randomly draw an item and store the relevant
information in the blockchain in about 40 seconds.
Although the above discussion is rather specific to our proposed
smart contract running on Ethereum, there are nonetheless important
managerial lessons one can draw regarding the deployment of
blockchain-based loot box mechanisms. In particular, by using a public,
general-purpose blockchain, such as Ethereum, video game companies
might lose control over the costs of running the proposed solution. For
example, nodes can naturally request more money to process trans­
actions when the total number of proposed transactions in the block­
chain network goes up. This situation happened with Bitcoin in
December 2017, when at certain point the average fee to process a single
transaction was over US$30. In the context of Ethereum, transaction fees
are determined by the suggested gas price, which in turn should repre­
sent a dynamic equilibrium between the number of outstanding trans­
actions, the number of transactions nodes can handle at a time, and the
cost of handling one transaction. A potential solution to avoid spikes and
wild fluctuations in transaction fees is to create a public blockchain that
is dedicated to process loot boxes. As a public blockchain, anyone can
still join the network at any time as a user or a node. However, some
decisions, such as the structure of transaction fees and gas costs, should
be defined by a council/committee overseeing the operations of the
blockchain. Such a council can have representatives from the video
game industry, e-sports and players associations, regulatory bodies,
consumer protection agencies, etc. From a technical perspective, there is
no need to completely engineer a blockchain technology from scratch;
given that several blockchain frameworks/projects, such as Ethereum,
are open source [8], the dedicated blockchain can be simply one of those
projects tailored to the needs of the video game industry. For example,
the resulting blockchain can replace Ether with a stablecoin, i.e., a
cryptocurrency whose value is pegged to stable assets/currencies, e.g.,
fiat money. This would simultaneously reward nodes for keeping the
network infrastructure alive while avoiding the high volatility most
cryptocurrencies currently face. To illustrate this latter point, the price
of of a single Ether skyrocketed to about US$1400 on January 12th,
2018, subsequently dropping to approximately US$87 on December
11th, 2018. More recently, the exchange rate of US$504.50 per Ether is
due primarily to a renewed interest in Ethereum driven by decentralized
finance (DeFi) applications as well as the potentially associated specu­
lative bubble.
7. Conclusion
Traditional loot boxes are not transparent in that players do not
necessarily know the winnable items and associated probabilities before
a purchase. Even in the unusual cases when items and probabilities are
11
Decision Support Systems 144 (2021) 113508
available, there are no guarantees that a video game is actually using
that information when randomly drawing an item, which results in a
trust problem. In this paper, we applied a problem-centered design
science research approach to develop a blockchain-based solution that
addresses the transparency and trust issues currently faced by loot box
mechanisms. Our solution does not require game developers to open the
source code of an entire video game. Instead, it disentangles the com­
putations required to randomly draw items from the video game’s
source code. Those computations are now performed by a smart contract
running on a public blockchain. As such, anyone, including players and
regulatory agencies, can check the list of items and probabilities ex ante,
i.e., before a purchase, as well as whether the randomization mechanism
is behaving appropriately ex post, i.e., whether the video game is indeed
calling the smart contract.
Using the Ethereum blockchain network, we developed a decen­
tralized application that mimics the process of buying and opening a loot
box. This proof of concept illustrates how gaming companies can
leverage our ideas in practice. When evaluating our proof of concept, we
discussed how accurate, secure, and inexpensive the proposed solution
is. We also offered suggestions regarding deployment, e.g., the impor­
tance of choosing an appropriate blockchain platform and to clearly
define an overseeing committee able to define important parameters,
such as transaction fees.
The latter point above concerns blockchain governance, a topic that
has received considerable attention over the last few years [4,7]. In the
context of a blockchain dedicated to process loot boxes, as we suggested
in Section 6.3, there are important questions to be addressed beyond
committee composition, e.g., how are decisions made and conflicts
resolved in the underlying ecosystem? What does the cost structure look
like? For example, who will pay for (and can propose) software updates?
Finding answers to these questions constitute a valuable research op­
portunity whose outcome has managerial value beyond the video game
industry.
Besides governance-related questions, we have also discussed other
relevant future research directions throughout the paper, e.g., how to
best visualize information inside smart contracts in a way that requires
the least amount of technical knowledge? Although our solution has not
addressed the growing concerns regarding gambling, we note that future
research work can investigate how blockchain-based loot boxes can
alleviate gambling problems. For example, a dedicated blockchain
network enables the creation of disruptive information technology fea­
tures that are capable of controlling unwanted gambling patterns in
games. Specifically, if nodes realize that a certain player is purchasing
loot boxes too often, they can then raise the number of blocks required in
between purchases for that specific player. Or even further, players’
screen names might be added to a blacklist stored in the blockchain and,
hence, only players not in the blacklist are allowed to purchase loot
boxes. These examples illustrate what King and Delfabbro [24] referred
to as “breaks in play or cooldowns” in their blueprint for ethical video
game monetization schemes. Moreover, the above examples highlight
how one can possibly tweak blockchain protocols to prevent, or at least
reduce, gambling patterns, which is an exciting research direction.
Finally, it is important to study the financial implications of a
transparent and trustworthy loot box mechanism. On the one hand, one
can argue that video game developers may suffer revenue losses since
players will now know how unlikely it is to obtain some desirable items,
which can lead to fewer loot box purchases. Alternatively, one can argue
that a transparent and trustworthy loot box mechanism might actually
increase game developers’ revenue due to probabilities driving pur­
chases up by defining expectations in terms of the number of loot boxes
required to obtain a certain item. A behavioral study involving the loot
box mechanism presented in this paper is required to understand
players’ purchasing decisions and the impact on game developers’
revenue.
A. Carvalho Decision Support Systems 144 (2021) 113508

Credit Author Statement

This paper is solo-authored. All credit goes to the single author.

Appendix. Sample loot box smart contract

References [11] S.G. Dimmock, R. Kouwenberg, P.P. Wakker, Ambiguity attitudes in a large
representative sample, Manag. Sci. 62 (5) (2015) 1363–1380.
[12] A. Drummond, J.D. Sauer, Video game loot boxes are psychologically akin to
[1] Activision Blizzard, 2017 Annual Report, Retrieved from, https://investor.activ
gambling, Nat. Hum. Behav. 2 (2018) 530–532.
ision.com/static-files/ace1c2fc-c2c8-4461-b9fe-157d7fd1e9c2, 2018. Last
[13] D. Ellsberg, Risk, ambiguity, and the savage axioms, Q. J. Econ. 75 (4) (1961)
accessed: Sun Jan 24 21:05:58 2021.
643–669.
[2] N. Atzei, M. Bartoletti, T. Cimoli, A survey of attacks on ethereum smart contracts
[14] Entertainment Software Association, Video Game Industry Commitments to
(SoK), in: Proceedings of the 6th International Conference on Principles of Security
Further Inform Consumer Purchases, Retrieved from, https://www.theesa.com/per
and Trust, 2017, pp. 164–186.
spectives/video-game-industry-commitments-to-further-inform-consumer-purch
[3] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn,
ases/, 2019. Last accessed: Sun Jan 24 21:05:58 2021.
G. Danezis, SoK: consensus in the age of blockchains, in: Proceedings of the 1st
[15] Etherscan, Ethereum Average Gas Price Chart, Retrieved from, https://etherscan.
ACM Conference on Advances in Financial Technologies, 2019, pp. 183–198.
io/chart/gasprice, 2020. Last accessed: Sun Jan 24 21:05:58 2021.
[4] R. Beck, C. Müller-Bloch, J.L. King, Governance in the blockchain economy: a
[16] M. Fauth-Bühler, K. Mann, Neurobiological correlates of internet gaming disorder:
framework and research agenda, J. Assoc. Inf. Syst. 19 (10) (2018) 1020–1034.
similarities to pathological gambling, Addict. Behav. 64 (2017) 349–356.
[5] Carvalho, A. (2020). A permissioned blockchain-based implementation of LMSR
[17] Federal Trade Commission, FTC Video Game Loot Box Workshop, Retrieved from,
prediction markets. Decision Support Syst., 130.
https://www.ftc.gov/system/files/documents/reports/staff-perspective-paper-loot
[6] A. Carvalho, S. Dimitrov, K. Larson, Inducing honest reporting of private
-box-workshop/loot_box_workshop_staff_perspective.pdf, 2020. Last accessed: Sun
information in the presence of social projection, Decision 4 (1) (2017) 25–51.
Jan 24 21:05:58 2021.
[7] A. Carvalho, J.W. Merhout, Y. Kadiyala, J. Bentley II, When good blocks go bad:
[18] L. Foye, Future games market: market sizing & forecasts 2018-2022, Juniper Res
managing unwanted blockchain data, Int. J. Inf. Manag. 57 (2021) 102263.
(2018). Retrieved from, https://www.juniperresearch.com/researchstore/content
[8] A. Carvalho, C. Sambhara, P. Young, What the history of linux says about the future
-commerce/future-games-market. Last accessed: Sun Jan 24 21:05:58 2021.
of cryptocurrencies, Commun. Assoc. Inf. Syst. 46 (2020) 18–29.
[19] J. Gilcrest, A. Carvalho, Smart contracts: legal considerations, in: Proceedings of
[9] J. Cohen, Statistical Power Analysis for the Behavioral Sciences, 2nd edition,
the 2018 IEEE International Conference on Big Data, 2018, pp. 3277–3281.
Routledge, 2013.
[20] Google, Monetization and Ads, Retrieved from, https://play.google.com/about/mo
[10] O. Demchenko, Electronic commerce in the gaming industry. Legal challenges and
netization-ads/payments/, 2019. Last accessed: Sun Jan 24 21:05:58 2021.
European perspective on contracts through electronic means in video games and
[21] S. Gupta, J.W. Gentry, ‘Should I buy, hoard, or hide?’ - Consumers’ responses to
decentralized applications, Pecs J. Int. Eur. Law (2019) 58–68.
perceived scarcity, Int. Rev. Retail Distrib. Consum. Res. 29 (2) (2019) 178–197.

12
A. Carvalho Decision Support Systems 144 (2021) 113508

[22] Y. Halevy, Ellsberg revisited: an experimental study, Econometrica 75 (2) (2007) [33] The Netherlands Gambling Authority, Study into Loot Boxes: A Treasure or a
503–536. Burden?, Retrieved from, https://kansspelautoriteit.nl/english/loot-boxes/, 2012.
[23] Kansspelcommissie, Loot Boxen in Drie Videogames in Strijd met Last accessed: Sun Jan 24 21:05:58 2021.
Kansspelwetgeving. https://www.koengeens.be/news/2018/04/25/loot-boxen-in [34] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Bünzli, M. Vechev, Securify:
-drie-videogames-in-strijd-met-kansspelwetgeving, 2018. Last accessed: Sun Jan 24 practical security analysis of smart contracts, in: Proceedings of the 2018 ACM
21:05:58 2021. Conference on Computer and Communications Security, 2018, pp. 67–82.
[24] D.L. King, P.H. Delfabbro, Video game monetization (eg,‘loot boxes’): a blueprint [35] D. Zendle, P. Cairns, Video game loot boxes are linked to problem gambling: results
for practical social responsibility measures, Int. J. Ment. Heal. Addict. 17 (2019) of a large-scale survey, PLoS One 13 (11) (2018), e0206767.
166–179. [36] D. Zendle, P. Cairns, Loot boxes are again linked to problem gambling: results of a
[25] Korea Association of Game Industry, Criteria on Implementation of Self-regulation replication study, PLoS One 14 (3) (2019), e0213194.
for Healthy Game Culture, Retrieved from, http://www.gsok.or.kr/regulations [37] D. Zendle, R. Meyer, H. Over, Adolescents and loot boxes: links with problem
-on-self-regulation/?uid=290mod=documentpageid=1, 2018. Last accessed: Sun gambling and motivations for purchase, R. Soc. Open Sci. 6 (6) (2019).
Jan 24 21:05:58 2021.
[26] S. Kristiansen, M.C. Severin, Loot box engagement and problem gambling among
Arthur Carvalho is the Dinesh & Ila Paliwal Innovation Chair and an Assistant Professor of
adolescent gamers: findings from a national survey, Addict. Behav. 103 (2020).
Information Systems & Analytics at Farmer School of Business, Miami University. Before
[27] I.D. Lussier, J. Derevensky, R. Gupta, F. Vitaro, Risk, compensatory, protective, and
joining Miami University, Dr. Carvalho worked as an Assistant Professor at Rotterdam
vulnerability factors related to youth gambling problems, Psychol. Addict. Behav.
School of Management, Erasmus University. He received his Master’s of Mathematics and
28 (2) (2014) 404–413.
Ph.D. in Computer Science from the University of Waterloo in 2010 and 2014. Dr. Car­
[28] J. Macey, J. Hamari, ESports, skins and loot boxes: participants, practices and
valho’s research interests lie at the intersection of Artificial Intelligence, Information
problematic behaviour associated with emergent forms of gambling, New Media
Systems, and Decision Analysis. In particular, Dr. Carvalho works on the development and
Soc. 21 (1) (2019) 20–41.
deployment of artificial intelligence techniques and statistical methods as well as
[29] A. McAloon, Online games will be required to disclose random loot box odds in
blockchain-based systems aiming at improving business processes and decision making.
China, Gamasutra (2016). https://www.gamasutra.com/view/news/287258/Onli
Dr. Carvalho has collaborated with several companies through research work, consulting,
ne_games_will_be_required_to_disclose_random_loot_box_odds_in_China.php. Last
and/or joint student supervision, including Microsoft, KPMG, IBM, PwC, Cardinal Health,
accessed: sun Jan 24 21:05:58 2021.
and Unilever. His research has been published in academic journals such as Decision
[30] A.B. Pedersen, M. Risius, R. Beck, A ten-step decision path to determine when to
Support Systems, Decision Analysis, International Journal of Information Management, Journal
use blockchain technologies, MIS Q. Exec. 18 (2) (2019) 99–115.
of Cleaner Production, among many others. Dr. Carvalho’s views have been featured in
[31] K. Peffers, T. Tuunanen, M.A. Rothenberger, S. Chatterjee, A design science
outlets such as Bloomberg, Inside Higher ED, and Poets & Quants. Due to his dedication to
research methodology for information systems research, J. Manag. Inf. Syst. 24 (3)
students and new educational endeavors, Dr. Carvalho has received prestigious teaching
(2007) 45–77.
awards, including the Professor of the Year Award at Erasmus University, a Miami Uni­
[32] Reddit, Nintendo, Sony, Microsoft to Require Loot Box Odds Disclosure, Retrieved
versity’s President Medal, and the Richard K. Smucker Teaching Excellence Award.
from, https://www.reddit.com/r/Games/comments/cn7704/nintendo_sony_mi
crosoft_to_require_loot_box_odds/, 2019. Last accessed: Sun Jan 24 21:05:58 2021.

13