Hansika Shishodia

RECORDING VOLUNTEERING EFFORTS ON
B LO C KC H A I N
Submitted by:
HANSIKA SHISHODIA
Supervisor:
PROF. DIRK PESCH
Second Reader:
DR JOHN HERBERT
MSc in Computing Science

Computer Science Department
University College, Cork
September 1, 2019
Hansika Shishodia: Recording Volunteering Efforts on Blockchain, MSc in Com-
puting Science, © September 1, 2019
ii
Abstract
Volunteering is a way of contributing to the society. However, reports

show that it is decreasing gradually and especially, amongst the youth.
What if we can design a system that will motivate the people to volunteer?
This project focusses on increasing volunteering rate by providing future
payback benefits of current work. It aims at developing a prototype ap-
plication that will reward the volunteers with credits for today’s efforts in
providing services to the older generation. These earned credits can either
be transferred to some family member for utilizing volunteering services
or the volunteers can save and redeem the credits for themselves in their
old age.
The credits are earned as tokens on the blockchain which makes them
tamper-proof and everlasting. The monetary value of blockchain tokens
is highly influenced by the inflation/deflation of currency. Therefore, this
application rewards volunteers with its custom-created tokens which are
awarded for the number of hours spent in volunteering. As earned, these
tokens can be redeemed in the future for hourly services. Taking time
as a parameter to reward the work ensures that the approach is cashless
and does not lose its value over the years. The thesis finds that Ethereum
blockchain, inspite of being a new technology going through its own devel-
opment, can facilitate custom token creation which can then be used as
alternate currency in various sectors as volunteering, the one used in this
project.
Declaration
I confirm that, except where indicated through the proper use of citations and references,
this is my original work and that I have not submitted it for any other course or degree.
Signed:
Hansika Shishodia
September 1, 2019
iii
Acknowledgements
Firstly, I would like to express my sincere gratitude to my supervisor Prof. Dirk Pesch
from University College Cork, for the continuous guidance and accurate feedback
throughout my research and development. He helped me to understand the require-
ments better and frame the work, without his rigorous comments the thesis would not
have been of the same technical and scientific quality.
I would also like to thank Patrick Mulvihill from Independent Living Ireland(ILI)
organisation who was always there to help and support my work by providing his insight
from the business perspective. His precise and detailed directives provided me impor-
tant guidelines concerning the architecture of the volunteering system application.
iv
Contents
Contents v
List of Tables vii
List of Figures viii
1 Introduction 1
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Personal Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Report Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Literature Review 5
2.1 Community Currencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Alternate Currencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Loyalty Reward Points System . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 General Blockchain Concepts . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Types of Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Ethereum Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Loyalty Points: Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Existing Real-World Systems . . . . . . . . . . . . . . . . . . . . . . . 18
3 Analysis 20
3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Project Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Ethereum Blockchain Platform . . . . . . . . . . . . . . . . . . . . . . 23
3.3.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Design 24
v
Contents vi
5 Implementation 29
5.1 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1 Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2 Volunteers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3 Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Components outside the blockchain . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1 Node.js Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 Front-End Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.3 Firebase Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Blockchain components for smart contract . . . . . . . . . . . . . . . . . . . 36
5.3.1 Ethereum Testnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.2 Metamask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.3 Etherscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.4 Remix IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4.1 Token Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Testing and Evaluation 45

6.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.2 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.3 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3.2 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3.3 Society Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7 Final Conclusion 50
A Developer’s Manual 52
A.1 VOGen Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.1.1 SafeMath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.1.2 IERC20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1.3 Owner Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1.4 VOGen Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.2 Web3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.3 Firebase Database Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 55
Bibliography 57
List of Tables
2.1 Types of Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
vii
List of Figures
2.1 Time based currency working. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 BlockChain working. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Ethereum working. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Volunteering System Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Registration Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Completion Request Approval. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Completion Request Rejection. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5 Volunteering Request Rejection. . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 General Token Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 Volunteering Opportunities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Organisation Registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Adding Volunteering Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 Firebase Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 Realtime Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.7 Metamask Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.8 Metamask Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.9 Etherscan Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.10 Volunteering Completion Request. . . . . . . . . . . . . . . . . . . . . . . . . 42
5.11 Tokens Transfer Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.12 Metamask Confirmation Interface. . . . . . . . . . . . . . . . . . . . . . . . . 43
5.13 Successful Transfer Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1 No "from" Address Fetched . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1 SafeMath Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.2 ERC20 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3 Owner Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4 Token Transfer Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.5 Web3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A.6 Firebase Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
viii
Chapter 1
Introduction
The elderly population in the world is increasing remarkably. Presently, as per the United
Nations report, Europe is the greatest contributor with 25 percent of the total population
aged 65years or above. Ireland is getting older at an even faster pace. The number of
older people in Ireland has increased by 32.8 percent since 2007, a faster rate of growth
than other EU countries. By the year 2031, there will be nearly a million people in the
country aged 60 years and above.
As people grow old, they need extra care and support. In general, Ireland’s community,
voluntary and charity sector make a very substantial contribution to society. The sector
has combined annual turnover of over €14.5bn, benefits from the voluntary work of
over 50,000 volunteer board members/directors and the work of over half a million
"operational" volunteers, (valued by the Central Statistics Office(CSO) at around €2bn
per year) [Ryan 2018].
However, the reliance of this sector on the capitalist economy makes it susceptible
to market fluctuations and economic crisis. In a report by Indecon International Eco-
nomic Consultants, John Farrelly, Charities Regulator Chief Executive said "At one end
of the scale there are large hospitals and universities with budgets funded by the Ex-
chequer, extending to hundreds of millions of euro, and hundreds of paid staff. Many
of these are large charities engaged in delivering critical health, education, and social
services. On the other end of the scale, there are completely volunteer-led organizations,
providing services at the community level, with small budgets."
This statement describes the situation of volunteering in society. As already noted

that the older population is growing, there is an alarming need for better services and
support in this dimension. The need for healthcare can be decreased if we can provide
improved and more self-care services through volunteering. This study focusses on find-
ing ways to encourage contribution to the older population and designing a prototype
model that can demonstrate how today’s volunteering can be rewarded as payback in
the future.
1.1 PROBLEM STATEMENT 2
1.1 Problem Statement

Ireland has numerous volunteer programs and communities especially dedicated to
the elderly group. All the various kinds of volunteering work in the country involves
more than a quarter of the population. However, the contribution from the youth is
the least and the maximum is done by people in their forties and fifties. As per the
Charities Regulator report [Ryan 2018], there is a need for the infrastructure to support
volunteering in registered Irish charities, particularly in the 18-34 age groups.
The changing lifestyles, lack of motivation, work stress and work-life imbalance
are the personal barriers that refrain people from contributing to society. In addition
to these, searching for opportunities on multiple websites and maintaining various
user accounts with different organizations are also prominent reasons behind reduced
volunteering.
1.2 Research Question

A research question is a starting point to frame the project and define the central focus
around which the research evolves. Based on the above-mentioned issue of decreasing
motivation for volunteering among the younger generation, this study focusses on:
"What role can technology play in improving the volunteering in Ireland through the
integration of an alternate payback currency?"
The subsequent decomposition of this question will give a clear understanding of

the topics that need to be researched as part of this thesis. Firstly, an understanding
of the prominent role played by volunteers in the society will allow developing a sys-
tem that can appreciate the efforts put in social services. Secondly, volunteers can be
encouraged with an alternate form of currency as a reward for volunteering. Lastly, all
the registered organizations can be provided with a single platform to announce the
need for volunteering so that people can have a single account for all rewards earned by
doing the noble deed.
This will have a dual advantage as it involves mental satisfaction of doing something
meaningful for the society as well as being appreciated for that, in the form of some
currency that can be utilized for self-care in the future.
1.3 Aims and Objectives

The goal of this thesis is to come up with an idea and implement it to motivate and
encourage people to volunteer today for their own better future. This way of payback
volunteering will have two-way benefits as it will not only help the current older popula-
1.4 PERSONAL CONTRIBUTION 3
tion to age gracefully by being a part of the society but also demonstrate to the younger
generation about the benefits of aging in the community. It will improve the quality of
life of the aged population along with building and maintaining trust, compassion, and
cooperation in the society.
Since this is a research and development work, the research on the existing work
done in this field initially shapes the project. The present thesis work is motivated by the
will to clarify the power of the blockchain technology and use it in the volunteering sector
as a loyalty point reward system. It is motivated by the purpose of using state-of-the-
art technology to improve upon the traditional system, which lacks risk management,
immutability, transparency, and privacy.
1.4 Personal Contribution

This project aims at encouraging volunteers through a future payback system. The idea
is to provide a system that rewards people with credits that can be used in the future to
buy services for themselves. Since the system requires a technology that can make the
rewards last a lifetime, blockchain technology is the proposed solution wherein tokens
will be awarded for any volunteering done in helping elderly people. As these tokens are
stored at an individual’s blockchain address, they are tamper-proof and will last forever.
In addition to this timelessness, the system is also expected to be cashless in a way

that the value of today’s rewards should not vary with time. The credits earned today
should be redeemable in the future for the same value. Therefore, there is no monetary
equivalent value assigned to these tokens, rather, the tokens are given to volunteers as
a reward for the duration of volunteering and can be redeemed similarly in the future.
For example, if twenty tokens are awarded for 2 hours of volunteering today then in the
future 2 hours of self-care services can be availed for exactly twenty tokens. The tokens
are custom created for this system and can be used and transferred to others holding an
account at the application.
1.5 Report Structure

Chapter 1: Introduction
This section is used to introduce the growing problems faced by the charitable sector
in Ireland. The importance of this sector in Irish society is unquestioned and alternative
models of support are necessary to ensure they continue to operate in the future.
Chapter 2: Literature Review

Further understanding of this topic is gained from extensive review of literature
on existing work done in the direction of addressing the above mentioned problem at
hand. This review acts as an exploratory phase of the study further helping to frame the
1.5 REPORT STRUCTURE 4
problem under investigation.
Chapter 3: Analysis
This section presents the approach that can be taken in dealing with the questions
mentioned in the report. It describes the various functional and non functional require-
ments of the project. Also, the brief discussion about the technologies to be used and
their suitability for this type of work is being analysed in this segment.
Chapter 4: Application Design

The application design section sets out the approach and high level design that
will act as a base platform to develop the final prototype application. It provides a
clear understanding of the application users, communication amongst them and the
sequential flow of the application.
Chapter 5: Implementation
As this is a research and development paper, the development chapter will give
detail on the technical aspects of the project that help to realise how every requirement
is addressed and tried to be resolved in the volunteering sector. It is proposed that this
system can be developed on beyond the prototype phase to support the volunteering
sector in Ireland.
Chapter 6: Testing and Evaluation

The testing section deals with various kinds f testing performed during the devel-
opment of the prototype application. It also addresses the challenges faced during the
development of the system.
The evaluation section of the paper is the researcher’s critical understanding of all
of the information gathered together in the chapters listed above. This section presents
a series of headings deemed as the most important outcome of the research.
Chapter 7: Conclusion
The research paper concludes with a final opinion on the project in terms of the
researcher’s learning and contribution. It also deals with the future scope of this project
that requires further investigation.
A full bibliography and appendix completes the paper.

Chapter 2
Literature Review
This research is seeking to understand the role of blockchain technology in helping and
encouraging the volunteering sector. Numerous approaches across the globe have been
made in the form of alternate currencies, volunteering and reward points to support
various social and financial causes. In this literature review we will see the various
alternate currencies that prevail in the society to solve different issues: the reward point
system and how can these be transformed digitally in a blockchain system to ensure
trust and transparency.
2.1 Community Currencies

These are the currencies in the form of tokens or tickets that prevails among a group of
people agreeing to trade goods and services for these tokens rather than the state-issued
monetary currency. These were initially started to either support a social cause or due
to the economic hardships in the society. However, in modern society, they are used
along with a government-issued currency to make financial benefits.
2.1.1 Alternate Currencies

The Japanese system of "Fureai Kippu" got recognized internationally for its huge suc-
cess in dealing efficiently with the challenges related to an aging society. This model
uses a system of earning ’caring currency’ for every hour of support and service provided
today and then redeeming it in their retirement [Hayashi 2012]. These can also be used
to buy person to person services by their relatives in other parts of the country.
The "Spice Time Credits" is another example of a time-based alternative currency

that became a success in the UK. The belief lies in the power of people to make a positive
change. The time credits are earned by serving the community and can be redeemed
for an activity at the same place or in local business across the UK network. Moreover,
these credits could be transferred as a gift or thank you to others [Spice Time Credits:
2.1 COMMUNITY CURRENCIES 6
Impact June 2015].
The time based credits can be earned and redeemed for the hourly services provided
and received. This can be explained as in Figure 2.1 below.
Figure 2.1: Time based currency working.
It is not just the social challenges that lead to the rise of alternative currencies.
There are many forms of it, including the existing commercial loyalty points, which are
the largest alternative currency systems today, the most widespread of which are the
airlines’ programs. The following section presents some existing reward points systems
prevailing in the society, which might be used in my project implementation.
2.1.2 Loyalty Reward Points System

The loyalty programs are used in the commercial industry, specifically retail, travel,
and hospitality. These programs are meant to retain the customer base as they earn
reward points for their purchase online, at the retail store or for using other industry
services. There are various types of reward schemes that are presently prevailing in
society [Agrawal et al. 2018]. Some of those are Points Loyalty Programs, Punch Cards,
Tiered Programs, Fee-based Loyalty Programs, Non-Monetary Reward Programs.
In spite of adding and maintaining the targeted customer base, these traditional
approaches do have some challenges and limitations from the perspective of both the
customers and the company [Agrawal et al. 2018].
2.1 COMMUNITY CURRENCIES 7
Challenges for Companies
• The first and foremost challenge is to appropriately estimate the liabilities at the
time of redemption of the loyalty points.
• Secondly, the selection of the right loyalty program that will best suit the com-
pany needs is a challenge as providing the loyalty points does not guarantee the secured
share market. Thus, the loyalty point system can be considered just as a way to entice
loyalty in a customer.
• Finally, managing a database for all the customers and their purchases is an extra
overhead due to the additional infrastructure and maintenance needed.
Challenges for Customers
• The inconvenience of creating accounts and registering is a major issue faced by

the customer.
• Furthermore, the limitations and the conditions of utilizing the points are not
always mentioned initially but are presented upon the successful registration with the
program.
• Additionally, the customers tend to sign for multiple companies for the reward
points on offer and often end up in neglecting the points as the desired limit is not
attained to redeem for the desired product/service or at times the tracking system is not
clear enough to keep going.
• Moreover, the loyalty programs might create switching cost for the customers,
that is, often at times there are better deals available elsewhere on a given product/service
but since the customers has enrolled to a loyalty program they opt for the loyalty pro-
gram service to earn the points.
• Lastly, customers have to keep themselves updated on the changing terms and
conditions of the company. This discourages customers to participate in the programs
due to misunderstandings and disappointments.
These loyalty points have become tired and need to be reinvented for more person-
alized, relevant and exclusive customer experiences. Hence, building the loyalty reward
programs on top of the blockchain will resolve the majority of issues and provide a new
exciting experience for the customers as well the companies. Blockchain is just a system
facilitator and not a replacement of the existing system.
2.2 BLOCKCHAIN TECHNOLOGY 8
2.2 Blockchain Technology

2.2.1 General Blockchain Concepts
Blockchain technology was introduced with bitcoin application in 2008 by Satoshi
Nakamoto (Pseudonym- like the one used in blockchain to maintain anonymity). Due
to its initial application in the cryptocurrency, it is often associated with bitcoin and
for a large population, the two terms are the same and used interchangeably. Although
blockchain was initially developed as part of the digital currency, bitcoin is just one
of the several hundreds of applications built using the blockchain technology. How-
ever, in 2015, Vitalik Buterin, the co-founder of Bitcoin, set out to build another public
blockchain, Ethereum, which has a wide range of applications other than the cryptocur-
rency. Ever since then blockchain has found its implementation in a lot of other finance
and commerce sectors. There are ongoing studies for its use in digital record keeping as
well as the healthcare sector.
Blockchain is a distributed ledger that is shared on all the nodes connected in the
network and is cryptographically immutable. It ensures transparency and unlike the
banking systems, the technology is decentralized.
The transformation of blockchain technology has been very impressive over the last
decade and it will be intriguing to see where the next decade takes us.
[A] Blockchain Environment

The blockchain lives in a distributed environment, a peer-to-peer network. This net-
work is composed of individual machines, called nodes, which provide computational
resources directly for all the other members of the network, without the presence of a
central authority. Figuratively, it is similar to a fully democratic ecosystem, where every
node is equal to every other for rights and roles; as a result, potentially, every node can
choose to be a consumer and a producer of resources, without any limit.
Peer-to-peer systems musst satisfy some requirements to work properly:
• the coordination between and among members;

• the use of a communication protocol for sending, receiving and processing
messages;
• the existence of a network; hence so, of a communication protocol
• the proper computational capacity of the members to solve a computing prob-
lem;
• the guarantee to answer adequately to several security problems
The advantages of using a peer-to-peer network are:
• less time and less money for the interaction with contractual partners;
• the removal of a central governing authority, which is a single-point-of-failure
[B] Blockchain feature Analysis

Blockchain is a ledger where the transaction is saved inside blocks which upon valida-
tion by network nodes, are attached in temporal order to the main chain. The blockchain
ledger is distributed, shared and cryptographically immutable.
Ledger:
A blockchain is a digital form of any traditional physical paper-based ledger where
all the records are maintained. These records are stored to keep a track of the transaction
history that was ever done on the blockchain network.
Distributed and Shared:

The blockchain ledger is distributed in a way that it is not held and controlled by a
single central authority. The ledger is shared between all the nodes on the blockchain
network. All the nodes in the network, theoretically, hold a single and same version of
the ledger.
Cryptographic immutability:
The blockchain ledger is cryptographically immutable in a way that whenever a
transaction is added to the chain, the block is made immutable by using a cryptographic
algorithm.
[C] Working
Before deepening the process of a blockchain transaction, certain terms and concepts
need to be understood. Some of them are:
Hashing: The concept of blockchain depends heavily on hash function as these

make the chain immutable and the data is tamper-proof. These functions use the hash
value for comparison between the state of blocks and not the actual block data. Com-
paring data is time taking and computationally heavy process whereas comparing hash
values is simple, fast and secure.
Blocks: These store the details of a transaction made on the blockchain. The blocks
are added to the chain in chronological order. Every block has its data along with the
hash value of the previous block which makes the chain immutable. A single change in
the block will alter its matching with the hash of the next block and thus can be detected.
Mining: This is the activity that is performed to add a block to the blockchain. The
miners create their blocks of unconfirmed transactions and compete to solve the math-
ematical puzzle designed uniquely for each block [Blockchain: how mining works and
transactions are processed 2018].
The miner who solves the puzzle in the minimum time is awarded the blockchain
currency or tokens as a computation fee, which is for the time and computational efforts
put in solving the problem. This process is called mining where miners make computa-
tions to add their block of transactions to the chain and get rewarded in the form of a
cryptocurrency. Figure 2.2 describes the working of a blockchain system.
Figure 2.2: BlockChain working.
The technology works in a way that when any transaction is made, it is added to
a pool and miners pick the transactions from the pool to create their blocks having a
timestamp. The block data is sent as input to a hashing function to produce a hash value.
This hash value is mapped against the hash standard which is set differently for every
type of blockchain. The combination of the transactions in the block might not produce
the required hash value and thus, miners keep trying new combinations through setting
a different nonce.
Once a miner produces a hash value for a block that matches the conditions of
the hash standards of the blockchain system, he shares the block and the generated
signature with all other nodes. The nodes verify the work by generating the new hash
and matching it with the shared signature. And hence, blockchain is based on the
proof-of-work consensus. Once the proof of computational work done by a miner is
verified by all other nodes, the block is added to the chain.
The other nodes might as well be sharing their blocks and here comes the time
stamp into picture which enables sequential aligning of the blocks in a chain. This chain
is secured using a hash which makes the links between the blocks unbreakable. All the
nodes on the network have the same chain information at any given point.
The security of data on the network chain is achieved by adding the hash code of this
block in the next block ensuring a trace of the hash function is woven into the new hash.
This happens for all the blocks throughout the chain. Hence, any change in any of the
previous block would mean that the hash on the block will not match with the encoded
hash in the next block. This will continue through the chain depicting an alteration in
the chain. This mechanism of hash chaining provides the surety of tamper-proof data.
2.2.2 Types of Blockchain

Based on the network type, the blockchain can be categorized as: public, private, and
consortium or permission-less and permissioned [BlockchainHub n.d.]
Public: These can be accessed by anyone as these do not have any central authority
[Buterin 2015]. Anyone can make transactions and can also be a part of the consensus
needed to verify the transactions by other using some cryptographic mechanisms. The
best example of this is the Bitcoin currency.
Private: Here, a single authority or the company owns the right of writing and
verifying the correctness of any operation. These are fast and secured as compared to
public blockchain for the very simple reason of access being provided to limited group
of people.
Consortium: These are a combination of public and private blockchains. These

are public in a way that the access can be provided to anyone however, the read access
is provided by some specific nodes selected by consortium of the companies. Unlike
private blockchains where the power lies with single authority, the right to give read
access in consortium blockchain is associated with a group rather than a single entity.
Permissionless: These blockchain does not require authorisation from any existing
node in the network. The joining node is free to participate in the validation process.
Permissioned: These are composed of a group of trusted nodes that participate in

the verification process. Moreover, these group of nodes have the authority to permit
the verification rights to other nodes joining the network.
Table 2.1 below illustrates the major differences between the various types of
blockchains.
Factors Public Consortium Private

Multiple Single
Control Decentralized
Organisations Organisations
Participants Permissionless Permissioned Permissioned.
Voting or Voting or
Proof of Work,
Consensus multi-party multi-party
Proof of Stake,
Mechanism consensus consensus
etc..
algorithm algorithm
Transaction
Long Bitcoin: Short Short
Approval
10 min or more 100x msec 100x msec
Frequency
Disruptive in the Cost cutting to Cost cutting to

sense of reduce transaction reduce transaction
disintermediation. costs. Similar to costs. Similar to
USP
No middle men. SAP. Less data SAP. Less data
Unclear business redundancy. More redundancy. More
models. transparency. transparency.
Table 2.1: Types of Blockchain
2.2.3 Ethereum Blockchain

It is a public, open-source, blockchain-based platform that allows us to build and run
distributed applications with smart contracts [Ray 2014]. It uses a cryptocurrency
called "ether" to make transactions. The ethers can be transferred between ethereum
accounts, used to pay transaction fees and are given to miners as an award for their
computational efforts in adding a new block to the chain. The fundamental working is
depicted in Figure 2.3
Figure 2.3: Ethereum working.
[A] Main features of Ethereum Protocol

The main objective of the Ethereum protocol is the designing of decentralized appli-
cations with smart contracts. The protocol, however, is based on five main principles
[Chinchilla 2019]:
Simplicity: The Ethereum platform is kept as simple as possible to ensure that any
developer unschooled in Ethereum can use the platform to make Dapps using smart
contracts. As per the founders, simplicity is the key concept worthy enough to sacrifice
cost and time. The white paper states that any optimizations that add complexity should
not be added unless it provides some substantial benefits.
Universality: Ethereum’s design policy provides the programmers with a language

that can be used to generate their currency by deploying smart contracts or make trans-
actions that can be defined mathematically. The white paper mentions:
Want to invent your own financial derivative? With Ethereum, you can. Want to
make your own currency? Set it up as an Ethereum contract. Want to set up a full-scale
Daemon or Skynet? You may need to have a few thousand interlocking contracts and be
sure to feed them generously, to do that, but nothing is stopping you with Ethereum at
your fingertips.
Modularity: Ethereum has been designed as modular in a way that it is divided into
smaller separable modules. The intention behind is to enable making changes in one
part of the program without impacting the entire application. The white paper presents
a clear example as:
Over the course of development, our goal is to create a program where if one was to
make a small protocol modification in one place, the application stack would continue
to function without any further modification. Innovations(such as Ethash, modified
Patricia trees and RLP) should be, and are, implemented as separate, feature-complete
libraries. This is so that even though they are used in Ethereum, even if Ethereum does not
require certain features, such features are still usable in other protocols as well. Ethereum
development should be maximally done to benefit the entire cryptocurrency ecosystem,
not just itself.
Agility: The Ethereum protocol details are not stone set. They are agile and accept
modifications although the founders have made clear that:
Although we will be extremely judicious about making modifications to high-level

constructs, for instance with the sharding roadmap, abstracting execution, with only data
availability enshrined in consensus.
Non-discrimination and non-censorship: The Ethereum protocol allows every

kind of usage and there are no restrictions based on categories. As the white paper
illustrates:
All regulatory mechanisms in the protocol should be designed to directly regulate the
harm and not attempt to oppose specific undesirable applications. A programmer can
even run an infinite loop script on top of Ethereum for as long as they are willing to keep
paying the per-computational-step transaction fee.
[B] Ethereum Accounts

An account in a traditional ledger holds the balances and other details of the user. Simi-
larly, in Ethereum, the state is made up of objects called "accounts", with each account
having a 20-byte hexadecimal address and state transitions being direct transfers of
value and information between accounts. The Ethereum account comprises of following
data:
• The nonce, a counter used to make sure each transaction can only be processed
once
• The account’s current ether balance
• The account’s contract code, if present
• The account’s storage (empty by default)

[C] Transactions
The term "transaction" is used in Ethereum to refer to the signed data package that
stores a message to be sent from an externally owned account [Ray 2014]. Transactions
contain:
• The recipient of the message
• A signature identifying the sender
• The amount of ether to transfer from the sender to the recipient
• An optional data field
• A STARTGAS value, representing the maximum number of computational steps

the transaction execution is allowed to take
• A GASPRICE value, representing the fee the sender pays per computational step
The first three terms are the same for any transaction, as we saw in the blockchain
section above. The data field has no function by default, but the virtual machine has an
opcode which a contract can use to access the data.
The STARTGAS and GASPRICE are crucial to ensure the anti-denial of service in
ethereum blockchain. The fixing of the computational steps for a transaction is to
prevent any infinite loops that might occur. "Gas" is the basic unit for any computation
and is usually 1 gas per computation step. The fee system is implemented to ensure that
in case of any potential attacks, the attacker also pays for the computation and other
resources used. Hence, greater network consumption will roughly increase the gas fee
in the same proportion.
[D] Transaction Validation

Every user on the network has an account that does not contain any personal informa-
tion like name, address, etc.. but the wallet details. The wallet is itself a public address
which keeps a track of all the transactions of the user and therefore the balance. The
address is also called the public key. The user has a pair of public and private keys. The
address of the user is the hash of the public key but not the public key itself. The private
key is secret and must be preserved to check own details. Although, the two keys are
related but finding one from the other is impossible.
The public key is used as an address for the whole of the world, the private key is
used in transaction validation [Ray 2014]. The private key and the amount of currency is
put in the blockchain software. Other nodes can plug the public key(known to everyone)
into the blockchain program and check if the user holds at least the amount of tokens
he wants to send. And thus, the transaction is validated based on this.
[E] Ethereum Virtual Machine

The EVM is a single, global 256-bit "computer" in which all transactions are local on
each node of the network, and executed in relative synchrony. It’s a globally accessible
virtual machine, composed of lots of smaller computers. It can be seen as a worldwide
computer that is accessible to anyone for a small fee which is paid in ethers.
The EMV is a transaction singleton machine with a shared state. In computing, this
means it behaves like one giant data object, rather than what it is: a network of discrete
machines, themselves singletons, in constant communication. From the perspective of
a software developer, the EVM is also a runtime environment for small programs that
can be executed by the network.
EVM is like a state machine as it maintains the history of all the transactions ever
done. Each transaction in the memory bank can lead back to the very first transaction.
EVM is the most trustful and reliable machine that any global network has today.
For every instruction the EVM executes, there must be a cost associated, to discourage
useless contracts deployment (for that testnets exist). Every time an instruction exe-
cutes an internal counter keeps track of the fees incurred, which are charged to who is
performing them. Each time a sender initiates a transaction that’s user wallet reserves
always a small portion to pay fees. After a transaction has been broadcast to the network
from a given node, the network propagates the transaction around so that all the nodes
can include it in the latest block.
Implementations: The main network has a list of live EVMs [Feliam 2018]. Some of
those are:
• go-ethereum, a popular Ethereum client with its EVM implementation (core/vm

directory);
• Parity in Rust, another popular Ethereum client with its EVM implementation
(ethcore directory);
• cpp-ethereum, an Ethereum client that generates the consensus test suite (libevm/
VM.cpp);
• Pyethereum in Python, a mostly deprecated client (ethereum/vm.py);
• Py-EVM, a Python implementation designed to be highly configurable and mod-

ular and compliant with the Ethereum test suite, work is in progress on it to run a full
node and develop sharding;
• EthereumJ in Java, a client with its EVM implementation.
Programming languages: The EVM has more than one language that compile into
it. Some of those are:
• Solidity, the most popular programming language for Ethereum contracts;
• Vyper, a language strictly focused on security, with overflow-checking, numeric

units but without unlimited loops;
• Flint, a language with several security features: e.g. asset types with a restricted
set of atomic operations;
• HAseembly-evm, an EVM assembly implemented as a Haskell DSL;
• Bamboo (experimental), a language without loops but with explicit constructor

invocation at the end of every call.
[F] Distributed Applications (DApps)

These applications are like any traditional web application that would run in the browser
and store data in the database. DApps also run in the browser and data for the user
account is fetched from the blockchain and the transaction data is written back to the
blockchain. The business logic occurs in a smart contract deployed on the blockchain.
[G] Smart Contracts

In simple terms contracts are the agreements between two parties. For example, a
financial contract is an agreement between a buyer and a seller on a pre-decided price.
In the Ethereum context, smart contracts are agreements between accounts, to render a
transfer of ether when certain conditions are met. These contracts are called "smart"
because they are executed by a machine, and the assets (ether and other tokens) are
moved automatically.
Solidity: It is a new high-level programming language used to write smart contracts

on Ethereum blockchain. It is influenced by C++, Python, and javascript [Solidity
Documentation n.d.] It is designed to target EVM. Some of the features of the language
are it is statically typed, supports inheritance, libraries, and complex user-defined types.
2.3 LOYALTY POINTS: BLOCKCHAIN 18
2.3 Loyalty Points: Blockchain

When referring to loyalty programs there are a lot of reasons for migrating from tradi-
tional loyalty programs to a digital blockchain approach [Making blockchain real for
customer loyalty rewards programs n.d.] Some of them are:
• Reduced cost: The cost incurred in buying and renting physical infrastructure or
virtual machines is reduced by the use of smart contracts being deployed on the network
itself.
• Improved speed: Blockchain transactions are faster and provide a better cus-
tomer experience due to the improved performance.
• Secure: The blocks in the blockchain are time-stamped for every single transac-
tion and hence are immutable but traceable. On one hand, they make the system fraud
tolerant and abuse proof while on the other, the transactions become irreversible.
• Standardization: All the points a customer earns at different places can be made
available in a single wallet and then be used at the company based on the loyalty point
provider’s policies and conditions.
• New Opportunities: Building a loyalty program on a platform such as Ethereum

means creating smart contracts that provide all the main advantages of the public
blockchains. Currently, the power of using efficient and secure structures such as smart
contracts has not fully discovered yet, and these could be an added value for those
businesses that will be able to find new types of applications.
2.3.1 Existing Real-World Systems

Singapore Airline’s KrisFlyer, frequent-flyer program, launched on 24th July 2018 an-
nounced the migration of the reward system on the blockchain platform. It is the world’s
first blockchain-based airline loyalty digital wallet using Ethereum blockchain [Sin-
gapore Airlines Press Release 2018]. The airlines worked on the migration project in
partnership with KPMG and Microsoft. The system provides a digital wallet KrisPay.
The travellers earn miles on every flight which can be converted to KrisPay units using
app available on Apple and Google Play Store. The airlines collaborated with 18 partner
merchants in Singapore and the points can be redeemed at these stores either fully or
partially.
Appsolutely Inc. is a universal loyalty platform that has been launched in the Philip-
pine [Agrawal et al. 2018]. The loyalty coin earned from one retailer can be used on
other brand’s purchase.
2.3 LOYALTY POINTS: BLOCKCHAIN 19
Orioncoin uses blockchain in multi-tiered loyalty points systems. The cryptocur-

rency, ORC, is transferrable between airlines, hotel partners and even can be used as gift
cards. This can be compared to a traditional credit card system except that its scope is
not limited or centralized [Agrawal et al. 2018].
There are many more organizations that have moved to blockchain for reward-
ing. Eventually, all these corporations involve the use of digital currency. As per the
stackoverflow survey, only 12.7% of organizations use blockchain for non-currency
applications.
Chapter 3
Analysis
The analysis is a very crucial phase in any kind of development to understand the bigger
picture, the design and the requirements for the buildout. The right study of details is the
backbone of success for any project. Even in the software development life cycle(SDLC),
analysis is done before designing the application architecture and start working on its
implementation. As discussed in the introduction, this project deals with a research
question and tries to answer that by using state-of-art technology: blockchain. This
chapter emphasizes on various requirements of the project and its components to
achieve the set requirements.
If there is anything any project must have in order not to be doomed to failure, that
is a sensible and comprehensive collection of both the functional and non-functional
requirements. The major requirements that need to be fulfilled to solve the problem at
hand are discussed in the next section.
3.1 Functional Requirements

These requirements are related to the technical functionality of the system. These spec-
ify something that a system should do, typically an intended behavior or function. A
function is nothing but inputs, its behavior, and outputs. It can be a calculation, data
manipulation, business process, user interaction, or any other specific functionality
which defines what function a system is likely to perform. The project at hand aims to
encourage volunteering by the use of technology, so there have to be some technical
aspects to it.
The first and most important requirement is to create an alternate currency that
acts as the backbone of the system to motivate the people to volunteer. This is fulfilled
by creating an Ethereum smart contract and deploying it on the blockchain network.
The contract should generate tokens which can be used as an award for the volunteering.
3.2 NON-FUNCTIONAL REQUIREMENTS 21
The tokens are initially assigned to one account and a certain amount can be trans-
ferred to every new organization on its successful registration. These rewards held by
the volunteering firms can then be given as credit points to volunteers. Moreover, when
redeeming these rewards in the future, the volunteers can transfer a certain amount
back to the organization and avail the required services.
The next requirement is to provide a platform where all the upcoming volunteering
activities in the country can be listed together. This is achieved by designing a web
application that can be used by the state registered volunteering organizations as well
as by the people looking for contributions to society.
This application serves the purpose of providing one-stop for all volunteering op-
portunities. Also, it comes with the convenience of maintaining one single account for
any volunteering across Ireland. Additionally, the rewards for volunteering at different
organizations are stored in one user account.
3.2 Non-Functional Requirements

Unlike the functional requirements which describe what the system should do, these re-
quirements focus on how the system works. These are specifically the quality attributes
of the system. They represent a set of standards used to judge the specific operation of a
system. A non-functional requirement is essential to ensure the usability and effective-
ness of the entire software system.
The non-functional requirements of the current system can be classified as:
Performance: This can be measured on the statistics that the application takes few
seconds to load and the transaction of an ERC-20 token on the Ethereum platform is
confirmed within a minute on an average.
Security: The system is secure as it requires the login credentials of the user to
access their account. The user should never share the login details with others.
Moreover, the blockchain account of the user has a password that should neither
be shared nor be lost. If the password of the blockchain account is lost, it cannot be
recovered and all the credits earned are lost with it.
Usability: The application is very user-friendly as it just requires registration to kick

start with new volunteering experience. Additionally, the Ethereum account created
by the user to register to the application to earn and store tokens can also be used to
collect ethers or other tokens.
3.3 PROJECT COMPONENTS 22
3.3 Project Components

Dividing a large scale application into smaller components provides clarity of the tasks
and helps to keep a track of the work done so far. Subcomponents also provide an insight
into the dependencies of the modules on each other. The individual components are
easy to maintain and hence, the entire system is divided into three major components.
They are:
3.3.1 Web Application

The project aims at providing the people with a system that can motivate them to vol-
unteer. The web-app is the front-end of the system that provides a platform for the
volunteers to look for volunteering opportunities.
Registration: As discussed earlier, there are numerous registered volunteering orga-

nizations in the country. Therefore, it is a task for people to look for opportunities on
websites of multiple organizations. This application provides the firms with a system
wherein they all can register themselves.
This application would not only require the firms to register but also the volunteers
need to enroll themselves on the system. They need to provide their basic contact
details and create a user account. An account, on one hand, will help to build trust and
confidence in the person while on the other side will enable the person to keep track of
his volunteering.
Announcing New Opportunities: Once the organizations are registered, they can
add the activities that require volunteers to come and help. This way the participants
are provided with a single platform to look for any opportunity across Ireland. The
volunteer’s account can be used to search and select from the numerous volunteering
opportunities added by various organizations on the portal.
Volunteering Requests: Besides registering, the users also need to request the orga-
nization to allow them to volunteer for a particular activity. The organization can then
accept or reject the request based on the requirement and conditions of the task.
Successful Volunteering and Rewarding: The volunteers are required to inform

the organization through the system about the successful completion of the task. The
organization confirms from the elderly person about receiving the services and there-
after accepts and approves the volunteer’s work. Upon the acceptance of the efforts,
the volunteer is rewarded with the blockchain tokens that are stored on the blockchain
platform along with the Ethereum address of the user.
3.3 PROJECT COMPONENTS 23
3.3.2 Ethereum Blockchain Platform

This project is based on the idea of rewarding the volunteers for their effort. The idea is
not to use the government-issued currency due to legal involvement and implications
of the same but to introduce an alternative form, that is, blockchain tokens.
The Ethereum blockchain allows deploying custom token on the network through
the use of smart contracts. The approach in this project is to use a token deployed on
the blockchain. This token is issued to users for the efforts in terms of hours spent in
volunteering.
Since the project also focusses on the concept of payback, the Ethereum blockchain
is the perfect platform to utilize for this functionality. Ethereum keeps a record of every
single transaction that is ever done on the network, therefore, any transaction made
to the volunteers by the organization will be recorded forever. This ensures that the
participants of volunteering can access their token anytime in the future and redeem
them for their self-care services.
3.3.3 Database
The blockchain account is used just to hold the tokens associated with a user account.
However, we have more data, other than just the tokens, that needs to be stored. The
data that needs to be stored in the database includes:
• Volunteering Organisation details: This is the data of the organization including

basic information like owner, address, contact details and the Ethereum address.
• Volunteer data: These are the details about the volunteer including information
like name, address, contact details, and the associated Ethereum address.
• Volunteering activities: This includes the description, date and time, duration
and the address of the location where volunteering is required.
• Activities assigned to volunteers: When the task to be performed is assigned to a

volunteer, the details including the volunteer, organization and the activity are stored
here.
• Approval request by participants to the organization to let volunteer/ earn reward

tokens: Here is the data regarding the requests made by the participants for approval to
volunteer or accept the completion of the task.
Chapter 4
Design
Designing is a very crucial step to kick start any development, especially, software prod-
ucts. It provides a clear picture of the various aspects of the system: it’s users, how will
they interact with the system or with each other and what are the various use cases
that need to be covered as part of the system architecture. This phase also helps to
understand the sequence of activities that will be performed using the application and
how this sequence will lead to solving the problem.
The Figure 4.1 is a simple use-case diagram that represents the various functionali-
ties of the system and their use by the appropriate user.
There are three actors: Volunteer, Organisation, and Admin, who will use the system
in some ways or the other. The application provides several use-case options that can
be performed by one or more users. For example, login functionality is used by all the
users of the system, whereas, the Blockchain Token Creation feature is only accessible
to the Admin.
One more thing to notice here is that the Blockchain Token Transfer function can
be called directly by the volunteer and the admin, however, for the organization, it is
included and called directly when it confirms and approves the completion of volun-
teering activity by the volunteer.
These various user activities follow a sequence to determine the interaction between
multiple entities and how the actors interact with the system. The sequence of actions
can be explained in the diagrams that follow.
• The basic functionality is the registration of users on the system. The various
steps involved in registering the different type of users are shown in Figure 4.2:
The system involves six entities: Volunteer, GUI, Database, Organisation, Admin,
Ethereum Blockchain. For registration, the organization needs approval from the admin
25
Figure 4.1: Volunteering System Overview.
Figure 4.2: Registration Sequence.

26
and only then it receives certain initial tokens. The system can be used by the organiza-
tion only after the admin’s approval. However, the volunteers can directly register and
create an account on the web application.
• Another functionality is the approval of volunteering request.
The Figure 4.3 shows a complete sequence from adding an activity by the orga-
nization to the transfer of tokens on final approval of successful volunteering. The
organizations use the front end of the application to add an activity, approve the re-
quests send by the volunteers, confirming from the person receiving the service and
then finally completing the task performed by the individual.
Figure 4.3: Completion Request Approval.
• The organization can also reject the request made by the volunteers.
As can be noticed in the Figure 4.4, the initial steps remain the same but the outcome
is a rejection by the organization. On confirmation from the elderly person about the
volunteering service received, the person might not have received any help or the ser-
vice might not be as expected. In that case, the organization can reject the completion
request made by the volunteer and thus, there will be no transfer of tokens from the
organization to the volunteer.
27
Figure 4.4: Completion Request Rejection.
• The last scenario is where the initial request to volunteer is rejected by the or-
ganization. There can be any reason to it like the elderly person no more requires that
service on that day, the organization might have approved some other volunteer to
perform the task or anything similar. The sequence involved can be described as shown
in Figure 4.5
One important note here is that these diagrams represent the sequence of activities
for a single volunteering opportunity but these steps remain the same for every volun-
teering task that is added by the organization and needs efforts of the citizens in helping
the older generation to be connected to the society.
28
Figure 4.5: Volunteering Request Rejection.

Chapter 5
Implementation
This chapter discusses the project implementation as part of the thesis. The following
sections throw light on the components and technologies that were used to build the
system.
5.1 Entities
The reward system developed as part of this project is an Ethereum-based distributed
application where different users of the system interact with each other through a front-
end. The functions accessible to system entities vary from user to user.
The system is designed to identify the below three different types of users:
• Admin
• Volunteers
• Organizations
All three entities are expected to have a hexadecimal Ethereum blockchain address
before accessing the volunteering system. This address is used to send and receive the
application tokens. As mentioned earlier, ether is the fuel for any transaction on the
blockchain and, therefore, every account holder should have the right amount of ether
to enable successful function calls. The collection of ethers and tokens can only be
done through a wallet and the application designed to work with a chrome extension:
Metamask.
5.2 COMPONENTS OUTSIDE THE BLOCKCHAIN 30
5.1.1 Admin
The admin is the initial holder of all the generated tokens. When a smart contract is
deployed on the Ethereum network for token generation, the initial supply is done to
the admin’s Ethereum account. He is the token generator and distributes some fixed
amount to the organization on approval. Moreover, he can also transfer tokens to
anyone provided he has the blockchain address of the receiver. When it runs out of the
tokens, it can pay the smart contract with some ethers and get the equivalent tokens in
its account.
5.1.2 Volunteers
These are the ultimate receivers of volunteering tokens, which are stored on his/her
Ethereum wallet. The volunteers need to register themselves to use the application.
Once registered, they need to authenticate themselves every time they want to access
the system. The authentication is performed by the Firebase authenticator. Besides
this, they can transfer their earned tokens to their loved ones using the application’s
"Transfer Token" functionality.
5.1.3 Organizations
Organizations also need to enroll in the system to get the advantages. They require the
approval of admin to be a valid user of the application. Upon successful registration,
they receive certain tokens in their ethereum wallet corresponding to the blockchain
account linked to the application user account. These tokens are then transferred to the
volunteers in multiples of ten for the number of hours spent in contributing to society.
These are also responsible for announcing new volunteering opportunities. They
can also receive tokens from some users of the system and help them receive a service
by adding it to the website. This is where the basic concept of the project is achieved.
The volunteers can transfer their tokens back to the organization to receive services for
themselves.
5.2 Components outside the blockchain

Outside blockchain, there are three entities as discussed in the above section and further-
more, the volunteering token credit system provides has few infrastructural components.
These components are:
• Node.js server, the server to provide the blockchain-enabled web application to

everyone.
• The front-end, the react.js web application to enable entities to perform some
tasks using the graphical user interface as well as it facilitates interaction with the smart
contract.
• Firebase database, the database platform to store details other than the tokens
as well as to support application user authentication.
5.2.1 Node.js Server

It is a free, open-source server environment that allows running javascript on the server.
Unlike PHP and ASP which waits for the file system to open a file, Node.js uses asyn-
chronous programming which eliminates waiting and simply continues with the next
request. It can communicate efficiently with the file system, web form, webpages, and
database. Node.js is memory efficient as it runs single-threaded asynchronous program-
ming.
Node Package Manager(NPM) is installed along with node.js on the computer and
provides thousands of free packages to use.
5.2.2 Front-End Interface

The entities are provided with a user-friendly interface to interact with the blockchain.
Several tools can be used to develop the graphical user interface, but react.js was used
because it facilitates building responsive client-side applications fast. Moreover, it is
one of the most widely used modern javascript frameworks for front-end development.
React.js
It enables creating interactive UIs and design state-wise views in the application.
This means that there is no need of describing transactions on interfaces but describe
the interfaces in terms of final state so that it can efficiently update and render the right
component when the data changes on the web page. React is very similar to javascript
with one small API to be learned additionally [The React Project n.d.]
Some of the basic and most important screens developed as part of the "Volunteer-
ing System" are shown in the figures that follow.
Figure 5.1 shows the summary of the token deployed on blockchain as part of the
application. It provides the details of the Ethereum address which was used to deploy
the contract on the Ethereum network, the contract address which can be used to get
the details of the smart contract, the token symbol and name, the current amount of
tokens held by the creator and also the rate at which the ethers can be converted to
"VOG" tokens.
Figure 5.1: General Token Statistics.
The volunteers can look for opportunities from multiple organisations at one place
on the "Volunteer Options" tab. The screen looks as shown in Figure 5.2. The volunteers
can just click on the "Volunteer" button to make a request to the organisation that
posted the opportunity. There can be multiple requests made at once, however there is
no option of cancelling the request once send.
Figure 5.2: Volunteering Opportunities.
Figure 5.3 shows the registration screen for the organisation. The volunteer registra-
tion screen is also the same with a few lesser fields.
Figure 5.3: Organisation Registration.

The organisation can add an activity that require helping an older person through
volunteering. The screen that allows organisation to achieve this is shown in Figure 5.4.
Figure 5.4: Adding Volunteering Activity.
Web3.js
The web3.js library is a collection of modules to allow interaction with a local or
remote ethereum node [The Web3js library documentation n.d.] The web3-eth package
is used for blockchain and smart contracts. The web3 library is installed and injected
in every webpage on adding Metamask to the chrome extension. This injection helps
to get the current provider which is the basic step to fetch the ethereum address of the
"from" account. The web3.getAccounts() helps to get the hexadecimal address from
which the deduction of tokens is done while initiating a transaction.
5.2.3 Firebase Database

Firebase realtime database is a NoSQL cloud-hosted database. By realtime, it means
that instead of using HTTP requests, Firebase uses data synchronization- every time
there is any change in the data, all the connected devices receive an update within
milliseconds. Firebase database can be used to build cross-platform applications with
javascript, android, and iOS. Thus, if there arises a plan of developing a mobile appli-
cation for the volunteering web app then the same database can be used on all platforms.
The database is scalable as the data can be split across multiple database instances
in the same Firebase project. Though the database offers several services, the project
uses just the two of them: authentication and database. The Firebase database can
be added to any application by just writing a few lines of configuration code in the
application. This configuration code is provided when a firebase project is created in
the Firebase console.
Authentication
Firebase Auth is a service to authenticate users using the client-side code. This
project uses this service to authenticate the various entities when they provide their
login credentials: the email id and the password, which are stored on the Firebase [Get
Started with Firebase Authentication on Websites n.d.]
From the perspective of this project, when the user registers itself on the system, a
new entry is added to Firebase authentication. The authentication tab is present under
every Firebase project created on the console. It contains details like the email id of the
user, date of account creation, last signed date and the unique user identity generated
by Firebase. A sample of the Firebase authentication for this project can be seen in the
Figure 5.5.
Figure 5.5: Firebase Authentication.
Realtime Database
This project uses the library written in node.js to allow web application save and
retrieve realtime data from Firebase database [Firebase Realtime Database n.d.] The
database is realtime as all the clients using a single instance of database are automat-
5.3 BLOCKCHAIN COMPONENTS FOR SMART CONTRACT 36
ically updated when any changes are made in the data. It is used to store all sorts of
data that need not be stored on the blockchain, such as volunteer details, organization
details, admin data, volunteering opportunities, requests made by the volunteers.
The data for the project is stored in a project named as "VOGen". The various
records can be stored under respective collections as shown in Figure 5.6.
Figure 5.6: Realtime Database.
5.3 Blockchain components for smart contract

This section concerns the tools related to creation and interaction with the Ethereum
smart contract.
5.3.1 Ethereum Testnets

Testnet is not a real blockchain network but it resembles and emulates all the behav-
ior of the Ethereum main network for testing purposes. It is the network used by the
developers because it provides all the look and feels of the Ethereum except that the
transactions here are not paid. There are various test networks like Rinkeby, Ropsten,
and Kovan and this project uses Rinkeby Testnet; otherwise, all the transactions would
have been paid.
Rinkeby is a proof-of-authority network and therefore uses a different consensus

mechanism than the Ethereum main network, which uses the proof-of-work concept.
Since there is no mining in this testnet, it cannot be considered as fraud-proof. However,
security is not a concern in the testing phase.
Ropsten, on the other hand, is more similar to the main net as it uses proof-of-work
consensus. Though it is similar to the mainnet, the mining is weak which makes it
slower than the Rinkeby network. Additionally, mining on Ropsten is done just for the
developer community and there is no financial incentive given to the miners. The gas
fee paid for processing a transaction on any test net is very low compared to a real
blockchain transaction.
5.3.2 Metamask
It is a bridge that allows visiting the distributed web using the browser. It is a great
tool for developing Ethereum DApp without running a full Ethereum node. Metamask
has a secure identity vault that enables users to manage multiple identities on various
websites to sign blockchain transactions.
Metamask add-on can be installed on different browsers like Chrome, Firefox, Opera
and even Brave browser [Metamask Project n.d.] In November 2018, MetaMask’s Google
Chrome browser extension surpassed 1.3 million users [Rhodes 2019]. In this project,
the Metamask is installed as a chrome extension. The figures below show the Metamask
interface of the admin account. The various details displayed on the interface can be
described as:
• The network, that is, the Rinkeby Testnet on which transactions are done. How-
ever, the dropdown has the option to select any of the other available networks as can
been seen in the Figure 5.7.
• The account holder, admin in this case Figure 5.8.
• The most recent transaction done by the admin in Figure 5.8 is the creation of
volunteering tokens in exchange for 1Ether.
• The second last transaction was the transfer of tokens. The transaction was
successful.
• The Figure 5.7 also shows a transaction, that is, transaction number #32 which
was failed either because it was canceled by the sender(admin) or the gas fee was insuf-
ficient to pay for the transaction.
The Metamask browser extension enables browsing of Ethereum blockchain web-

Figure 5.7: Metamask Networks.
Figure 5.8: Metamask Interface.

sites. The extension automatically injects web3 API into every webpage’s javascript
context. In this project, this API injection helps the web application to read from and
write on the smart contract deployed on the Rinkeby network. It provides a personal
wallet to store the credits earned by each user.
Since Metamask allows creating multiple accounts, this project uses it to create vari-
ous personal wallets for admin, organizations, and volunteers. The main of Metamask
is to make Ethereum as easy to use for as many people as possible.
5.3.3 Etherscan
Etherscan is a web application used for in-depth inspection of every single transaction
done on the network. Not only does the Ethereum main net has its own Etherscan to
inspect the transactions but also the test networks: Rinkeby, Ropsten, and Kovan [Ether-
scan Project n.d.] The Figure 5.9 shows the list of all the transactions that are done with
the smart contract used in the volunteering system project.
Figure 5.9: Etherscan Platform.
The contract address "0x4b5C007Aa29C61B63dAd684c731bd8a5e62997F5" is the

address on which the volunteering system’s smart contract can be contacted. The image
also shows that the contract is on the Rinkeby network. The transaction details include
the from address, to address, fees paid for the transaction to happen, the value of ethers
5.4 TOKENS 40
paid, the block and the transaction hash.
The Figure 5.9 also has the "Token Tracker" which explains that the token is created
in the name "VOGen Coin" and uses the symbol "VOG" to represent itself. Besides this,
it also provides the "creator address" 0x80d6668DF50852... which is also the ethereum
blockchain address of the admin. This symbolizes that the admin is the creator of the
contract.
5.3.4 Remix IDE

The Remix IDE is an IDE for Solidity DApp developers, powered by Remix. It is a powerful
open-source tool that facilitates Solidity contract writing directly from the browser [The
Remix Documentation n.d.] It provides testing, debugging and deploying smart contracts
and much more in a browser-based ecosystem. In this project, this IDE was used to
test the smart contract deployment and calling its various functions without having
developed a front-end application to make smart contract’s method calls.
5.4 Tokens
A token is a currency used in the Ethereum volunteering system to reward volunteering
and motivate people to volunteer even more. Ethereum uses ethers as its cryptocurrency,
however, the points value in the system is extremely low concerning ethers(1 ETH = 1018
tokens). This concludes that Ethereum not only has a currency of its own but also have
tokens on top of it, which can act as a currency [Ethereum Blockchain n.d.]
Metaphorically, Ethereum can be seen as the internet and all the DApps as the
websites that run on it. DApps are decentralized and owned by people once the related
smart contract is deployed on the Ethereum platform. Therefore, people need to own a
certain number of tokens to take complete advantage of the system. It must be specified
here that tokens might not be the need of every DApp, it depends on the context of the
application. In this project, tokens are used as credits for volunteering.
Since Ethereum has ethers as its currency then why not use ethers directly for trans-
actions? What is the need for an alternative currency? The answer to these questions
lies in the real world where there is a ticket system considered over directly using money,
even though the tickets are bought using money.
Using tokens to perform certain functions in smart contracts is comparatively sim-

pler and quick. They are easy to send and make the entire process very seamless. Having
tokens that are used by the application only ensures that people have earned tokens
by volunteering and only then can they redeem those for themselves. This eventually
assures that the purpose of the project is achieved in the respect that people volunteer
5.4 TOKENS 41
today and enjoy being volunteered for in the future.
The most common and used standard for designing Ethereum tokens is ERC-20.
ERC-20 Standard
ERC-20 is a technical standard that defines a certain set of functions that the devel-
opers can use for smart contract deployment on Ethereum blockchain. The majority
of tokens on Ethereum are ERC-20 compliant. There is no enforced rule to implement
ERC-20 standards in the tokens but having them ensures that the tokens can undergo
interactions between various wallets, exchanges, and smart contracts without any issue.
According to Etherscan.io, there were 200,778 ERC-20 token contracts on the Ethereum
blockchain as on July 16, 2019. For a token to be ERC-20 compliant, it needs to declare
some variables and a set of six functions that can be recognized by other smart contracts.
The following activities are the basic ones that need to executed by every ERC-20 token:
• Get the total token supply
• Get the account balance
• Transfer tokens from sender to receiver
• Approve the use of tokens as a monetary asset
All the four functions mentioned are used in the token creation in this project. The
transfer token uses the receiver address and the value to be transferred.
5.4.1 Token Transactions

The only type of transaction that is possible in this project is the transfer of tokens.
The points transfer in the volunteering system stands for transferring tokens from a
sender to a receiver. There are following four use-cases which involve token transfer:
• Admin sending tokens to organizations on approving their successful registra-

tion.
• Organizations sending tokens to volunteers on successful completion of a vol-

unteering task.
• Volunteers redeeming their tokens by sending them back to organizations for

receiving services for themselves in their old age.
5.4 TOKENS 42
• Volunteers transferring tokens to their loved oldies so that they can use the
tokens to receive volunteering services.
In the first two cases, the transfer of tokens takes place internally when a request
approval is done by the user, that is when the admin approves an organization or the
organization approves the volunteering effort of a volunteer.
Figure 5.10 shows the "Completion Request" page of the organisation where the
organisation can approve or reject the request from the volunteer. The transfer of tokens
from organisation’s Ethereum account to volunteer’s account takes place on clicking
the "Approve" button. This also completes the request cycle by marking its status as
"Completed". The organisation can click on the "Reject" button and there is no transfer
of token.
Figure 5.10: Volunteering Completion Request.
In the last two cases, the transfer operation is performed by filling in a form, as
shown in Figure 5.11. This form has two fields which require the receiver address and
the token value to be transferred. On clicking the "Transfer" button, the transfer of to-
kens from the logged-in user’s account (Admin/Volunteer) to the account of the receiver
is initiated.
Before the transaction is added to a block to be mined, the Metamask extension

makes some basic checks like, whether the sender has sufficient tokens that he/she
wishes to transfer, if the transaction fee (in ether) can be paid by the sender and then
asks a confirmation from the user if he/she is sure to make the transaction. The Meta-
mask confirmation alert can be seen in Figure 5.12 which confirms the transfer of "20
VOG" coins from volunteer (Account3_Volunteer) to organisation (Account2_Org)
5.4 TOKENS 43
Figure 5.11: Tokens Transfer Screen.
Figure 5.12: Metamask Confirmation Interface.

5.4 TOKENS 44
Once all the checks by the Metamask are successful and the transaction also passes
all the validations mentioned in the smart contract, the logged in user can see the suc-
cess message on the screen as shown below in Figure 5.13.
Figure 5.13: Successful Transfer Message

Chapter 6
Testing and Evaluation
This chapter focusses on the testing of the volunteering system and evaluate the results
achieved on the completion of the project.
6.1 Testing
For any project, testing is required to ensure that the requirements are fulfilled by the
system and it behaves as expected. This system is build in modules and there are various
types of testing being performed. A few of those are explained below:
6.1.1 Unit Testing

The three main components of the system are designed as a single unit and tested to
ensure that they perform their individual tasks. The Firebase database was created
and the console was used to create new tables and add records. Besides this, the front-
end application was designed to ensure that all the screens fo various functionalities
are working in place for the volunteer and organisations. Finally, the smart contract
is deployed on the blockchain network and the Rinkeby network is used to test the
function calls to the Ethereum blockchain network.
6.1.2 Integration Testing

This is the phase of making different units co-ordinate with each other and behaving as
a system rather than single units. The Firebase realtime database is configured in the
system to store and retrieve data from the database using the graphical interface of the
application. The system is then tested for storing data and allowing communication
between volunteer and organisation through the volunteering web application.
Thereafter, the connection call to the Ethereum smart contract is done by calling the
Metamask and the web3 injected in the browser. The web application is verified to call
6.2 CHALLENGES 46
Metamask extension and make successful transfer of tokens to the receiver’s account.
6.1.3 System Testing

The entire system is tested by performing the sequence of activities as set in the design
phase. The volunteering application works exactly as the set requirements and performs
all the expected functionalities.
6.2 Challenges
While developing the prototype application there were certain challenges faced at the
technical front. The integration of various modules need to be synchronised to ensure
the system works as per the desired behaviour. Some issues are discussed as below:
• Proper addition of the Metamask plugin to chrome extension: If the plugin is not
installed properly, the application would not be able to fetch the ethereum address of
the user logged in to the application and gives the error as shown in Figure 6.1. This
ethereum address is the from address to make any transfer of tokens.
Figure 6.1: No "from" Address Fetched
• Database integration: The Firebase database needs to configured properly to en-

sure that the application writes records to the correct collection. A faulty configuration
would mean missing data.
• Web3 integration: The web3 integration is a must to make the web application
communicate with the Ethereum network. The inappropriate version or improper call-
ing of web3 library leads to issues such as transaction failure on blockchain.
6.3 EVALUATION 47
6.3 Evaluation
The evaluation of the work is done based on below-mentioned parameters:
• Performance of the payment method
• The cost involved in transferring tokens
• Reviews from society on the project, like will the people be willing to use the
application.
6.3.1 Performance
The time required to mine a transaction and add it to the Ethereum blockchain network
depends on the amount of gas paid as well as the network congestion. On an average day,
every transaction on the Ethereum network takes 15 seconds to 10 minutes for mining,
provided that, a standard gas price is paid. A decrease or increase in the standard gas
price for a transaction can slow down or speed up the transaction respectively. This
project has observed many variations in the time when provided a higher gas for faster
processing.
6.3.2 Cost
The only cost involved in the transfer of tokens is the gas fee that fuels the transaction.
Higher the gas price, the higher is the chance of the transaction to be picked by miners.
For this project, the gas price was set to a low value: 1gwei, which coincides with the
lowest safe value. The transaction fee for a different type of transaction varies, however,
it is the same for all similar transactions.
The gas price of the transaction to transfer tokens from sender to receiver is 39,514
gwei, which is equal to 0.0075USD; it must be noticed here that the amount of tokens
transferred does not affect the gas price paid. The gas price is affected when the sender
is willing to pay more for a faster transaction and increases the gas fee manually.
6.3.3 Society Reviews

This section emphasises on how well the application prototype developed as part of the
project will be accepted by the society.
Business Perspective
This project is done in collaboration with the Independent Living Ireland(ILI) or-
ganisation. The organisation’s representative, Patrick Mulvihill, not only helped in
understanding the requirements but also shared his insight on the work. According to
Patrick, the application could add value to the work that ILI have put into developing a
6.3 EVALUATION 48
prototype with community groups in Mitchelstown.
General Survey
As the project work is done with the motive of making a change in the society, it is
important to understand what the community feels about the application and how will-
ing are they to use it in future if the application is launched in complete sense. For this
purpose, there was survey done which included five people in the age group 20-35years.
The survey was kept short and quick as it also involved showing the application to the
people. The questions prepared for the survey are:
• Q1: How often do you volunteer?
• Q2: Would you volunteer more if being rewarded?
• Q3: How about earning blockchain tokens as reward points and use them in
your retirement to receive services?
• Q4: Would you register and use a system like the "Volunteering System" if it is
available in future?
• Q5: What according to you is the most interesting feature of the prototype appli-
cation?
The findings of the survey can be described as below:
Payal Naik(25years)
She does not volunteer as she’s always occupied with work or studies. However, she
feels that if volunteering can earn her something she would definitely start devoting
her time for some activity. Moreover, the idea of blockchain fascinates her as it is a new
buzzing technology. Payal on having a walkthrough of the prototype application feels
that she would surely use the application if it’s available. Lastly, she finds the use of
blockchain tokens as the most interesting feature as its long lasting.
David O’Shea(34years)
David works for construction department and has a family. He used to volunteer
in his teen age but ever since he started working and that he has a family now, he finds
difficult to get time to volunteer. He thinks having a reward system to help elder people
is a great idea and he too would like to volunteer and earn blockchain tokens. An experi-
ence of the prototype application helped him to understand various uses of the system
and he would wait for a system like this to be available. The concept of transferring
tokens to loved ones was most appreciated by David as he feels he can share his tokens
6.3 EVALUATION 49
with his parents who constantly need support.
Rachel (31years)
Rachel is a working women and answered the questions sequentially as below:
• Ans1: on an average, once a month
• Ans2: Ofcourse yes, and more than what I do now
• Ans3: I do not have much idea about blockchain but if I earn something that I
can use in my old age, I will definitely volunteer and earn.
• Ans4: Yes, I will surely do.
• Ans5: The payback system is well thought and something that encourages me to
use the application as today I’m capable to volunteer and secure my old age to receive
services.
Anmol Vaish(26years)
A student at University College Cork(UCC) who wants to volunteer but is confused

between a lot of registered volunteering organisations. He thinks constantly visiting
multiple websites to find an opportunity that might suit his timings is troublesome. He
was excited to hear the idea of the project and that he has a chance to earn blockchain
tokens by volunteering. He registered on the prototype application and walked through
a complete process of making request and getting approval. Anmol found it a great
concept and would surely use the application. A single platform for all registered or-
ganisation is the best thought for him as he found searching multiple websites as time
consuming and troublesome.
John McCarthy(28years)
John is already involved in a lot of volunteering but he still finds the idea of the
project as relevant to the need of society in current times. He believes that this con-
cept of using blockchain tokens will encourage him and other like-minded people to
contribute more to the elderly people. The application is a platform that combines
all volunteering opportunities across Ireland which will allow him to volunteer even
when he’s travelling to different part of the country. A single user account for all the
organisations is the best to keep track of all the good work done.
These results of the survey gives the confidence that the application will be helpful
to society for some or the other services that it provides.
Chapter 7
Final Conclusion
This research was aimed to solve the issues of the volunteering sector in Ireland by the
use of technology. The objective has been achieved by designing a prototype applica-
tion that uses the basic concept of loyalty points by storing those e arned points on a
blockchain platform ensuring the tokens last forever and cannot be tampered.
The blockchain technology, especially public platforms like Ethereum, is receiv-

ing more attention for not just investing in cryptocurrency but also for the multitude
of possibilities offered through smart contracts and decentralized web applications.
Subscribing to the "Medium Daily Digest" forum has helped me to be updated on the
latest news on the Ethereum blockchain. The latest "Ethereum 2.0 Phase 0 Testnet"
release aims to upgrade the existing Ethereum proof-of-work blockchain and provide
a significant increase in security, scalability, and decentralization [Loon n.d.] A core
concept of Ethereum 2.0 is the idea of using shards. Having shards allows for horizontal
scalability of the system, as transactions can be processed in parallel.
In my opinion, blockchain technology has a great reach and will improve security,
increase speed, and save money. The immutability of the transactions enables its adop-
tion in many sectors like government and medical records-keeping where the data once
stored is not changed. Though blockchain technology has found its way into many
organizations it still has a long way to penetrate the mindsets of people, just like the
internet technology.
My research and application development for an Ethereum-based reward system

founded the advantages of using the Ethereum token system over currencies. It is fast,
seamless and a secure process without involving any third party. The idea of using
Ethereum tokens as time-based currency has not yet been implemented in any field and
this new thought can be put into effect for societal benefits in various sectors other than
just volunteering.
Many other aspects could also be realized but remained out of scope due to the
51
time constraint of the project. There could have been discussions and workshops with
the volunteering organizations in Ireland to better understand the improvements that
might have been made on the existing prototype development.
As part of the future scope, the prototype can be transformed to a complete applica-
tion available to the society. Also, there can be mobile applications developed on the
same concept for the ease of the volunteers to look for opportunities and earn credits
after successful volunteering. Besides this, the geographical reach of the application
and concept can be expanded as the system does not rely on one currency which is
continental.
Appendix A
Developer’s Manual
This appendix details the most important part of the code written as part of the thesis.
It briefs about the smart contract, database configuration and web3.js configuration.
A.1 VOGen Smart Contract

This smart contract is deployed on the Ethereum Rinkeby network and can be searched
for either by the token name, token symbol(VOG) or the ethereum address of the token.
The address of the smart contract is:
0x4b5C007Aa29C61B63dAd684c731bd8a5e62997F5
The contract can also be contacted at "https://rinkeby.etherscan.io/address/0x4b5c007aa29c61b63dad684c7

The contract contains four main components as mentioned below:
• SafeMath Library
• IERC20 Standard
• Owner restrictions
• The VOGen Smart Contract
A.1.1 SafeMath
This is an OpenZeppelin library to ensure safe math operation by throwing errors. Cur-
rently this library is used in almost every smart contract as it provides protection against
underflows and overflows. The related code is shown in Figure A.1
A.1 VOGEN SMART CONTRACT 53
Figure A.1: SafeMath Interface
A.1.2 IERC20
This library is used to ensure that the token created by deploying the smart contract is
ERC20 compliant. The interface in Figure A.2 represents some of the functions to make
the token ERC20 compatible.
Figure A.2: ERC20 Interface
A.1.3 Owner Restrictions

The code in Figure A.3 is to restrict the call of some functions to the owner using
the "onlyOwner" modifier. The constructor Owned() ensures that the deployer of the
contract is the owner and only he can access certain methods written in the smart
contract.
A.1 VOGEN SMART CONTRACT 54
Figure A.3: Owner Restrictions
A.1.4 VOGen Smart Contract

The contract is defined as:
contract VOGenPoints is IERC20, Owned

using SafeMath for uint256
These two lines of code define the contract and also simultaneously declare the
contract imports token interface, safeMath library and owner restrictions.
The main modules managed by the contract are: token creation and transfer of
tokens.
Token Creation
Firstly, the below mentioned variables need to be defined to create a token:
uint public constant INITIAL_SUPPLY = 1000000000000;

uint public _totalSupply = 0;
string public constant symbol = "VOG";
string public constant name = "VOGen Coin";
uint8 public constant decimals = 18;
uint256 public constant RATE = 1000000000000000000;
After the parameters are declared and defined, the ERC20 functions needs to be
declared and implemented.The functions totalSupply() and balanceOf(address account)
just returns the value of the variables totalSupply and balances[account], like two stan-
A.2 WEB3 55
dard getters.
The most interesting and useful function from the point of this project is the trans-
fer() which is the key function to transfer tokens and takes the parameters as below:
transfer(address _to, uint256 _value) public returns (bool success).
This function can be implemented as in Figure A.4. The comments in the code
snippet explains the use and function of every line of code.
Figure A.4: Token Transfer Function
A.2 Web3
Web3.js is imported and linked to the Ethereum Rinkeby network using the code in the
Figure A.5. The code checks if the Metamask plugin is installed and web3 is injected to
the web pages running on the browser.
A.3 Firebase Database Configuration

The Firebase database is configured to allow the application to store and retrieve data
from it. This configuration is done using the code shown in Figure A.6
A.3 FIREBASE DATABASE CONFIGURATION 56
Figure A.5: Web3 Configuration
Figure A.6: Firebase Configuration

Bibliography
Agrawal, Dhwani et al. [2018]. “Loyalty Points on the Blockchain”. In: Available
at SSRN 3246395.
Blockchain: how mining works and transactions are processed [May 2, 2018]. URL:
https://blog.goodaudience.com/how-a-miner-adds-transactions-
to-the-blockchain-in-seven-steps-856053271476.
BlockchainHub [n.d.] Blockchains & Distributed Ledger Technologies. URL:
https://blockchainhub.net/blockchains-and-distributed-ledger-
technologies-in-general/.
Buterin, Vitalik [Aug. 6, 2015]. On Public and Private Blockchains. URL: https:
/ / blog . ethereum . org / 2015 / 08 / 07 / on - public - and - private -
blockchains/.
Chinchilla, Chris [June 17, 2019]. Ethereum white paper. Tech. rep. URL: https:
//github.com/ethereum/wiki/wiki/White-Paper.
Ethereum Blockchain [n.d.] URL: https://www.ethereum.org/.
Etherscan Project [n.d.] URL: https://etherscan.io/.
Feliam [Oct. 30, 2018]. The Ethereum EVM Implementations. URL: https :
//github.com/ethereum/wiki/wiki/Ethereum- Virtual- Machine-
(EVM)-Awesome-List#evm-implementations.
Firebase Realtime Database [n.d.] URL: https : / / firebase . google . com /
docs/database/.
Get Started with Firebase Authentication on Websites [n.d.] URL: https : / /
firebase.google.com/docs/auth/web/start.
Hayashi, Mayumi [2012]. “Japan Fureai Kippu time-banking in elderly care:
origins, development, challenges and impact”. In: International Journal of
Community Currency Research 16.A.
Loon, Preston Van [n.d.] Ethereum 2.0 Phase 0 Testnet Release. Ed. by Medium
Corporation. URL: https://medium.com/prysmatic-labs/ethereum-2-
0-phase-0-testnet-release-1e9e682db910.
Making blockchain real for customer loyalty rewards programs [n.d.] Deloitte.
URL : https://www2.deloitte.com/us/en/pages/financial-services/
BIBLIOGRAPHY 58
articles / making - blockchain - real - customer - loyalty - rewards -

programs.html.
Metamask Project [n.d.] URL: https://metamask.io/.
Ray, James [2014]. A Next-Generation Smart Contract and Decentralized Appli-
cation Platform. Tech. rep. DOI: 04/05/2014. URL: https://github.com/
ethereum/wiki/wiki/White-Paper.
Rhodes, Delton [July 29, 2019]. Moving from Web2 to Web3: Technical Improve-
ments. URL: https://medium.com/the-green-light/https-medium-
com-the-green-light-moving-from-web2-to-web3-cf3cd4ac1a62.
Ryan, Orla [July 25, 2018]. In: Irish charities annual income.
Singapore Airlines Press Release [2018]. URL: https://www.singaporeair.
com/en _ UK/sg/media- centre/press- release/article/?q=en _ UK/
2018/January-March/ne0518-180205.
Solidity Documentation [n.d.] URL: https://solidity.readthedocs.io/en/
v0.4.24/.
Spice Time Credits: Impact [June 2015]. Tech. rep. URL: http://www.apteligen.
co.uk/wp-content/uploads/2015/08/Impact-Report-2015-Spice-
Time-Credits.pdf.
The React Project [n.d.] URL: https://reactjs.org/.
The Remix Documentation [n.d.] URL: https://remix- ide.readthedocs.
io/en/latest/.
The Web3js library documentation [n.d.] URL: https://web3js.readthedocs.
io/en/v1.2.1/.

Hansika Shishodia

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hansika Shishodia

Uploaded by

Copyright:

Available Formats

RECORDING VOLUNTEERING EFFORTS ON

MSc in Computing Science

Volunteering is a way of contributing to the society. However, reports

List of Tables vii

List of Figures viii

6 Testing and Evaluation 45

2.1 Types of Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Time based currency working. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Volunteering System Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 General Token Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1 No "from" Address Fetched . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A.1 SafeMath Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

This statement describes the situation of volunteering in society. As already noted

1.1 Problem Statement

1.2 Research Question

The subsequent decomposition of this question will give a clear understanding of

1.3 Aims and Objectives

1.4 Personal Contribution

In addition to this timelessness, the system is also expected to be cashless in a way

1.5 Report Structure

Chapter 2: Literature Review

problem under investigation.

Chapter 4: Application Design

Chapter 6: Testing and Evaluation

A full bibliography and appendix completes the paper.

2.1 Community Currencies

2.1.1 Alternate Currencies

The "Spice Time Credits" is another example of a time-based alternative currency

Impact June 2015].

Figure 2.1: Time based currency working.

2.1.2 Loyalty Reward Points System

Challenges for Companies

Challenges for Customers

• The inconvenience of creating accounts and registering is a major issue faced by

2.2 Blockchain Technology

[A] Blockchain Environment

Peer-to-peer systems musst satisfy some requirements to work properly:

• the coordination between and among members;

The advantages of using a peer-to-peer network are:

[B] Blockchain feature Analysis

Distributed and Shared:

Hashing: The concept of blockchain depends heavily on hash function as these

Figure 2.2: BlockChain working.

verified by all other nodes, the block is added to the chain.

2.2.2 Types of Blockchain

Consortium: These are a combination of public and private blockchains. These

Permissioned: These are composed of a group of trusted nodes that participate in

Factors Public Consortium Private

Participants Permissionless Permissioned Permissioned.

Disruptive in the Cost cutting to Cost cutting to

Table 2.1: Types of Blockchain

2.2.3 Ethereum Blockchain

Figure 2.3: Ethereum working.

[A] Main features of Ethereum Protocol

Universality: Ethereum’s design policy provides the programmers with a language

a clear example as:

Although we will be extremely judicious about making modifications to high-level

Non-discrimination and non-censorship: The Ethereum protocol allows every

[B] Ethereum Accounts

• The account’s current ether balance

• The account’s contract code, if present

• The account’s storage (empty by default)

• The recipient of the message