ZUESS PRIVATE DIGITAL CURRENCY SERVICE

Capstone Project Final Report

California State University, Monterey Bay

Class of 2021

Robert Meis

Jesse Krepelka

Antonio Villagomez

Dr. Eric Tao (Faculty Advisor)

 Executive Summary

Digital currencies such as Bitcoin and Ethereum have grown substantially in both

monetary value and user adoption. In 2019, the digital currency market was worth approximately

$700 million and is expected to exceed $5 billion by 2026 (Globe Newswire, 2021).

Nation-states have also expressed interest in creating their own digital currencies, such as

China’s newly developed “cyber yuan” (Areddy, 2021).

Currently, however, an organization wishing to utilize the security, flexibility, and

transparency of a digital ledger service will typically need to purchase one of the publicly

available currencies such as Bitcoin through a public exchange. The purpose of this project is to

build a prototype private digital currency service, for the software startup Zuess, Inc.

Our application is a combination Digital Currency Service backend/frontend (where an

organization can deploy and administer a private cryptocurrency service), Ethereum Digital

Wallet (where a user can view and transfer funds), Digital Currency Store (where a user can buy

items with Ethereum funds), an educational platform, where users can view the actual Ethereum

Blockchain and gain insight into how it functions from our Help page.

Our web application is built on the Spring Java framework that interfaces with a modified

version of the Ethereum blockchain API built with the Web3J library.

This will potentially benefit California State University Monterey Bay, a university of

more than 7,000 students. The project outcome is to create a working system that allows digital

currency exchange between students and the university. The project will also serve an

educational purpose for the project builders, testers, and users, by potentially helping to foster

the adoption of a modern, paperless currency that is distributed, secure, and transparent (Crypto

Casey, 2020).
 Table of Contents

Introduction and Feasibility 1

Problem in Technology 1
A Solution to the Problem 3
Goals and Objectives 5
Community and Stakeholders 6
Feasibility Discussion 8
Functional Decomposition 9
Selection of Design Criteria 12
Final Deliverables 14
Approach and Methodology 15
Development Timeline 16
Ethical Considerations 17
Legal Considerations 20
Timeline/Budget 23
Usability Testing & Evaluation 27
Final Implementation 28
Ethereum, Smart Contracts, and the Blockchain 29
BlockchainService 31
MySQL Database 34
Spring Security and Role-Based Permissions 34
Spring HTTP Controller 37
Zuess Digital Store 39
Discussion 41

References 43

Appendix A: Test Plan 45

Appendix B: Division of Labor 46
Appendix C: Example Contract 48
 1

Introduction and Feasibility

Zuess Digital Currency Service is an Ethereum-based SaaS web application designed for

the company Zuess. The application is intended for organizations who want to set up a private

digital currency service that essentially functions like a private Ethereum (or BitCoin) network.

The private digital currency network allows an organization to create a proprietary

cryptocurrency token whose exchange rules are governed by a programmable ERC-20 compliant

Ethereum Smart Contract. Essentially, this allows an organization to create a private Ethereum

network, deploy a custom amount of tokens to that network, and allow the transfer of those

tokens to take place between users (or between a customer and a store, or a school and a student)

according to rules defined in the Smart Contract.

The intended clients for the application are private or educational institutions wanting to

deploy a personalized token and take advantage of Smart Contract functionality. The initial test

version of the application is built for a CSU Monterey Bay peer-to-peer financial system. The

private peer-to-peer currency network utilizes the security, immutability, transparency, and

distributed nature of an Ethereum blockchain ledger system.

Problem in Technology

Traditional or legacy currencies such as the dollar have several drawbacks relative to

digital currencies. First, it is impossible to digitally exchange dollars without involving a banking

institution, which frequently takes a portion of any transaction, or charges other related fees.

Secondly, transactions in dollars are subject to taxation. Traditional cash can also be lost, stolen,

or spent in ways other than was intended by the issuing party.

 2

Digital currencies go a long way toward solving these problems. Digital currency

transactions can occur outside of the traditional banking system, and because the Ethereum

blockchain is distributed, secure, and immutable, tokens will not be lost and cannot be stolen

unless an individual’s accounts are compromised. However, digital currencies are also currently

arcane and hard to use, and there are few apparent software options for an organization that

wants to utilize a private digital currency network.

Our application prototype for Zuess Digital Currency Service solves these accessibility

and ease-of-use problems by providing a clean, easy to use web application interface that allows

a user or organization to deploy a Smart Contract to the Ethereum blockchain, transfer funds to

other users on the blockchain, allow users to transfer funds on a peer-to-peer basis (or to a store),

and several other functions. Perhaps our most interesting feature from the standpoint of a

university is what we’re calling the Digital Scholarship(™).

Currently, a university that wishes to issue a scholarship to students is generally limited

to having to issue a cash scholarship. This has several drawbacks from the standpoint of the

institution. First, upon issuance to a student, scholarship funds are immediately deducted from

the bank account of the university.

Second, once the scholarship funds transfer occurs, the university no longer has control

or oversight on how the student spends those scholarship funds. The student may spend the funds

on books and tuition, or they may decide to spend them on clothing, a bar tab, or other

non-education-related purchases.

Third, if the student becomes ineligible for the scholarship, or does not spend all their

scholarship, the university may not be able to recover the funds.

 3

Fourth, cash transactions are subject to bank transaction fees and taxation, all of which

funnel a portion of a student’s scholarship funds to banks and governments.

A Solution to the Problem

Our Ethereum application and easy-to-use web UI will solve all four problems with the

introduction of the Digital Scholarship(™). When a university issues an Ethereum Digital

Scholarship to a student, an Ethereum allowance is defined on the university account on behalf

of the student account. This means that the student is authorized to spend up to the scholarship

amount directly from the university account. No funds are transferred directly to the student or

immediately debited from the university account; instead, only as the student spends their

allotted scholarship funds will the funds be debited from the university account. Additionally,

because we can control what items are eligible for scholarship funds, only when a student

attempts a legitimate, educationally-related transaction (such as buying a textbook or paying

tuition) will university-approved scholarship funds be transferred out of the university account.

The security and immutability of the Ethereum blockchain also ensure these transactions are just

as secure as any Ethereum blockchain transaction.

Issuing a Zuess Digital Scholarship means that if a student does not spend all of their

scholarship funds, only the portion of the scholarship (or allowance) spent by the student will

ultimately be deducted from the university account. Additionally, because the university is the

account holder, they can revoke the allowance/scholarship at any point if the student for some

reason was no longer eligible for the scholarship or did not use those funds in the allotted time.

And as mentioned above, because the scholarship funds are digital and transactions are

based on the rules defined in a Smart Contract stored on the blockchain (and rules definable
 4

within the Zuess application itself), it is possible to define, on a per-item basis, whether or not a

student is allowed to spend scholarship funds on that item. For example, with a prototype

CSUMB Bookstore currently active on the Zuess service, we have designed each inventory item

to have a “scholarship_eligible” attribute. Only items that are scholarship eligible can be

purchased with scholarship funds.

A university using the Zuess Digital Currency Service can attain a far greater level of

transparency and control over scholarship funding while reducing wasteful and

non-education-related spending in a way that would be impossible via traditional cash

scholarships.

It should be noted, however, that there are a few drawbacks to a Digital Scholarship or

digital funds in general. The main challenge is that only participating stores and individuals can

exchange funds. Also, the school would need to reimburse participating stores in dollars after

transactions are completed.

A service such as Zuess that allows organizations to create and manage their own

cryptocurrency would, therefore, appear to be a useful and potentially in-demand application. At

CSUMB we envision the creation of a bespoke digital token, “OtterCoin” which could be used

for both Digital Scholarships, and non-scholarship peer-to-peer transactions. For each Zuess

student/user account, our application supports both a scholarship balance, issued by the school,

and a non-scholarship balance controlled entirely by the student.

Private digital currency provides a secure and optionally anonymous method for

individuals to exchange capital. Because the currency is entirely digital, it can also be exchanged

more easily between individuals without needing to link to traditional bank accounts. In addition,

digital currencies offer a level of security that may not be offered by traditional currency. Digital
 5

currencies do not require physical representations such as paper money or credit cards, nor do

they require keeping personal data on file with a bank.

Finally, the behavior of a digital currency such as OtterCoin is completely customizable

based on the Smart Contract, which is an immutable program stored securely on the Ethereum

blockchain that defines what types of transactions can occur and in what circumstances. This

provides a level of security, transparency, and redundancy that is only possible with blockchain

technology such as Ethereum, without involving banks or governments. Ethereum and other

blockchain technologies like BitCoin have also proven themselves to be robustly secure such that

individuals and institutions have invested tens of billions of dollars in Ethereum and BitCoin

tokens to date.

Goals and Objectives

Goals:

● Provide a functional, “proof-of-concept” prototype for a private blockchain network

platform, based on the Ethereum technology

● Create a user-friendly web application as the interactive interface for the private

blockchain network.

● Customize an installation of the Ethereum blockchain, including Smart Contracts.

● Promote the use of a secure, transparent, and distributed digital ledger (currency) that is

not controlled by banks or nation-states.

● Allow users to securely exchange a private cryptocurrency.

● Test the feasibility of “OtterCoin,” a digital currency for CSUMB students.

● Test the feasibility of customized Ethereum Smart Contracts.

 6

● Utilize software engineering principles and tools including Agile, User Stories, Pivotal

Tracker, and Github to develop the project.

Objectives:

● Research and understand Ethereum technology by downloading the Ethereum engine,

and creating a working private Ethereum blockchain network.

● Build a web application using Spring Boot that will serve as the user interface for the

private network.

● Set up a private Ethereum blockchain running in a Linux environment.

● Create and customize a Smart Contract.

● Create an interface between the user-facing web application and the Ethereum blockchain

network APIs that will allow a user to conduct transactions and other actions on the

blockchain network.

● Present the project to users for testing and feedback, to develop a sense of the feasibility

of the service as a revenue-producing business.

Community and Stakeholders

The internal stakeholders of the project are Zuess, Inc., the student developers of the

project, and their advisor, Dr. Tao. Test users, the CSUMB students who may eventually use the

product, and potential future customers are the external stakeholders.

The student developers involved in this project are pursuing a Bachelor of Science in

Computer Science which requires completion of a Capstone project of sufficient software

engineering scope, complexity, and quality. Thus, the student developers of the project will
 7

benefit in terms of meeting academic requirements and growing their software engineering

knowledge and skillset.

The development of the project was guided by Dr. Eric Tao who provided technical

guidance and the overall vision for the project (developed in conjunction with the student

developers), which is to create a decentralized and secure digital currency service for

peer-to-peer use. Dr. Tao is also involved with the startup company Zuess, for whom the project

was being developed. The company Zeuss will benefit from this project by obtaining a working

prototype of the system it is interested in potentially marketing, in co-ownership with the

students who developed it.

Additionally, the knowledge gained from this project may benefit students of California

State University Monterey Bay in several ways. First, the project, if distributed among the

student body, will likely introduce many students to the concept and use of a digital currency for

the first time. Because digital currencies and distributed, decentralized ledgers are likely to

become more prevalent in the future, introducing students to an “OtterCoin” has educational

value in addition to the direct benefits of a digital currency service.

The completion of this project could also impact various programs other than just the

CSUMB Computer Science Department. For example, the implementation of a blockchain could

help those learning finance better understand this new technology. Students learning art could

create non-fungible tokens of their work and add unique value to their assignments. The goal of

this project is that it be developed beyond a prototype into a real digital currency service with

both commercial and educational value that is utilized by CSUMB, and potentially, additional

organizations.
 8

Feasibility Discussion

Most digital currency platforms that exist currently are public exchanges allowing you to

buy and sell existing public cryptocurrencies such as Bitcoin, Ethereum, and LiteCoin.

Examples of these public currency exchanges include Coinbase and Binance. There do not

appear to be a significant number of digital currency services available that allow an organization

to create and customize their own existing digital currency (such as Ethereum) while providing

the appropriate APIs and user interface to support transactions, Smart Contracts, and other

available functions of a digital ledger.

Blockchain technology is being used to solve increasingly complex problems. For

example, recent research has been conducted into how blockchain technology can be used to

help streamline the agricultural buying and selling process using distributed ledger and smart

contract technology to provide a fully transparent supply chain history, to improve trust along the

farm-to-table pipeline (Pranto, 2021). In essence, a blockchain’s transparent, distributed nature

allows individuals within a supply chain to know that no one along the sales path from farmer to

distributor to the grocer is being unduly greedy by providing a fully transparent and secure

record that is held by all parties.

A “Blockchain-Based Music Wallet for Copyright Protection in Audio Files'' is another

potential application of blockchain technology (Gurfidan, 2021) found in the literature. The

proposed approach is to use blockchain technology to securely allow users to exchange digital

music files while staying within copyright parameters.

Digital currencies are also drawing the attention of nation-states. China has recently

announced the creation of its own private digital currency, the “cyber yuan,” which will be

managed by China’s central bank. However, the cyber yuan won’t provide the same anonymity
 9

as public currencies such as Bitcoin or Monero (Areddy, 2021). It’s reasonable to speculate that

the United States and other nations will also look to follow suit at some point in the future with

their own digital currencies.

There are a few services that will help users to develop and deploy blockchain

applications such as Xooa (Xooa.com) a commercial blockchain application development

agency, as well as private developers such as on sites like Upwork (Upwork.com). Xooa aims to

provide “traditional developers” with a service that allows them to take advantage of blockchain

technology without worrying about the complex nature of the technology. To this end, they

essentially provide the backend alongside tools to interact with the “Xooa Blockchain.” While

individuals on sites like Upwork offer individual development services on a smaller scale.

These services show that there is some real-world demand for applications based on

blockchain technology, but they come with limitations. Xooa revolves around its own

blockchain, the “Xooa Blockchain,” which could be constricting in its uses. And does nothing

for the less tech literate. While the idea of hiring a private developer to set up your blockchain

application would likely be off-putting to private enterprises. Compared to our service, which

offers a simple method for a private organization, potentially lacking in technological expertise,

to implement and benefit from blockchain currency-based technology, these services are less

palatable.
 10

Functional Decomposition

Our application includes the following core elements:

Ethereum ERC-20 A Smart Contract that implements all of the ERC-20 standard
Compliant Smart Contract functions. This was written in Solidity, compiled into binary, and
imported as an object into Java.

Spring Boot/MVC A Spring MVC front-end application serving as the User

Application Interface for the application. The App uses the following key
technologies:
● Web3j - a library for interfacing with the Ethereum
blockchain
● Spring Security
● Jpa Repository
● JUnit/Mockito
● MySQL

Ethereum Blockchain A test Ethereum Blockchain Network using the Ganache

Network program.

The Zuess Spring MVC Web Application contains the following functionality enumerated by

page:

Admin Portal Page

Registration and Login Validates user input for correctness, ensures no duplicate emails
with Spring Security are used to register. Redirects upon login.

Deploy a Smart Contract Deploy a Smart Contract to the Ethereum blockchain with an
Ethereum private key and a simple click interface.

Transfer Funds Transfer funds to one or more users using a checkbox list of all
available accounts.

Grant a Grant an Ethereum allowance, AKA “Digital Scholarship” that

Digital Scholarship grants a student account the right to up to a certain amount from
the admin account funds.

View Scholarships View a list of granted scholarships.

 11

View Account Balance Return the account balance of a specific account on the Ethereum
Blockchain.

User Account Page

View Personal View personal information such as email, name, and assigned
Information Ethereum account ID.

View Ethereum Funds View Ethereum Funds (pulled from Blockchain)

View Scholarships View scholarships granted to that user.

Transfer Funds Transfer funds from one user account to another using Ethereum
IDs.

Bookstore Home, Checkout, Order Confirmation Pages

Display a List of Retrieve a list of items from the database and display them
Bookstore Items dynamically on the page.

Add items to cart Add items to a cart stored in the HTTP session variable.

Remove items from the Updates item count and total

cart

Each item has a Only scholarship-eligible items can be purchased with scholarship
“scholarship eligible” funds. In other words, a student cannot spend their scholarship
field. funds on a t-shirt or other non-academic item, but they can spend
them on a textbook.

View current Ethereum Displays logged-in user’s account balances (updated

funds and Ethereum dynamically).
Scholarship funds

View Order History Displays order history of user

Checkout Page This displays item list and total

Remove Items Allows a user to remove items from the list and the balance is
then updated

Use Scholarship Funds Tells users how much of their order total are eligible for
 12

scholarship funds use. Allows users to enter a number of

scholarship funds they wish to apply to the order total.

Order Confirmation The user gets an order confirmation page detailing the order total,
items, and how much scholarship funding was used.

Blockchain Visualization Page

Displays a real-time representation of the Ethereum Blockchain. Prints data for each block
and displays information such as the time created, block number, type of transaction stored
on the block (in progress), etc.

Each time a transaction is completed on the site, a new block is added to the page. The data
is pulled directly from the Ethereum blockchain

Miscellaneous/Cross Page Items

Ethereum Transaction Funds transfer, Contract Deployment, Scholarship Grant, etc. all
Receipts print data from the actual Ethereum transaction receipt associated
with that transaction.

Help Modals Several help modals are available with a video demonstration of
how to perform certain functions such as funds transfers.

Help Page

A help page was added with the intention of showing users how
to use the application.
 13

Selection of Design Criteria

The goal of our project was to build a prototype of a private digital currency service using

the Ethereum Blockchain technology. For that purpose, we decided to create a web application

that would interface with the Ethereum network to provide a variety of standard Ethereum digital

currency functions such as fund transfers, Smart Contract deployment, and allowance granting.

Simultaneously we intended to show that it is feasible for an uninformed user to interact

with and perform transactions on a blockchain and that it would be viable for an organization to

replace its intra-agency transactions with our private service. To this end, it was important that a

deep understanding of cryptocurrency is NOT needed to make use of our product. However, we

do want to popularize and validate the usefulness of, blockchain technology in the eyes of the

basic user so it shouldn't necessarily be hidden either. And finally, this application is dealing with

financial transactions and should therefore be robust and secure.

No expenses are planned for our demo, the necessary technologies to test our

functionality are all freely available. Development of this stage only requires our current

workstations. In the event, expenses occur, such as testing many transactions on a server, and

free service is not available, the client has offered to cover any costs.

In the pursuit of usability, we prioritized a responsive, easy-to-use user interface with

extensive validation of user input and helpful tips to guide the user in both what and why certain

actions are required. Extensive help literature is made available but ideally would not be

necessary. Simple tooltips located alongside each function should be adequate to allow users to

determine basic functionality.

Validation on the server-side to prevent invalid or fraudulent transactions was prioritized.

Front-end input validation to provide users with understandable error feedback is important as
 14

well. User details are stored on a database following standard security procedures, passwords are

hashed, and never stored in plain text. Spring Security is used as a basic industry-standard

security layer. In real-world implementation due to the nature of the application further security

layers would need to be put in place but as this is a demo the current solution was deemed

appropriate. Were this to be sold as a product professionals with security-specific backgrounds

should be sought out.

The application should be simple to manage and grant funds/scholarships to prevent an

increase in expenditure in the form of staff work hours as one of our goals is to reduce costs

associated with financial transactions.

And finally, we will need to examine the expense of validating transactions to determine

that it is not overall higher than it would be if they were performed by a third party. It makes no

sense to get rid of transaction fees if the increased cost of energy used to validate the transactions

or staff expenses to manage the service is greater than the fees themselves. Theoretically, the

application will lead to a net reduction of expenditure from both the organization and user sides

but a more in-depth study would need to be performed to validate this claim.

Final Deliverables

Our final deliverable is a Spring MVC web application service that enables users to

interact with a private Ethereum blockchain, serving as a prototype (Version 1.0) of the Zuess

Digital Currency Service. Users can deploy a Smart Contract, transfer funds on a peer-to-peer

basis, or between a user and a store, grant and utilize scholarship funds with specific spending

rules, and see an up-to-date visualization of the Ethereum Blockchain, watching as additional
 15

blocks are added as a result of new transactions. We have then provided a summary of our

experience throughout the project in the form of this final report.

Approach and Methodology

Our project consists of two distinct technical components: the first component is a web

application that will serve as a UI and that also provides interface logic for the second

component, a private Ethereum blockchain network.

We utilized an Agile and user story-oriented development process (tracked in Pivotal

Tracker and Github) of one-week sprints, with individual weekly coding assignments determined

at our Wednesday group meetings. Code commits from each group member were due on Github

Tuesday evenings the following week.

The project involved three fundamental development phases and a fourth user testing

phase described under the milestones heading further in the document.

Robert programmed the ERC-20 Smart Contract in Solidity and compiled it into a Java

object, and wrote each of the Web3J functions necessary for the Spring MVC application to

deploy the Smart Contract to the Ethereum Blockchain and interact with it on the blockchain to

perform actions like fund transfers. There is scant documentation on Web3j and creating a Java

application that interacts with Ethereum, but key resources were the DappUniversity Youtube

channel, www.web3labs.com (makers of Web3j), and Ethereum.org.

To test our services we will be working with local versions of an Ethereum blockchain

which we will create and interact with via Ganache. The front-end of the website uses the

Bootstrap framework.
 16

Development Timeline

Phase 1: Development of the Web Application and ERC-20 Smart Contract

Completed on 6/19

● Scaffold a web application with both a user portal and an administrator portal.

The technology stack used was MySQL, Java, SpingBoot, Web3j, Bootstrap.

● We maintained a common master branch of the web application in Github.

● Completed ERC-20 Compliant Smart Contract deployed on a local Ethereum test

network (running on localhost).

Phase 2: Integrate Web Application and Ethereum Network

Completed 6/20 - 6/29

● Accomplished initial integration Integrate the Spring web application with the

Ethereum Blockchain, and the Smart Contract deployed on the blockchain.

● Make sure all ERC-20 functions are accessible to a user via the web application

user interface.

Phase 3: Integration of the Web Application and Private Ethereum Blockchain Network

Completed 6/30-7/20
● Completed integration of the web application and Ethereum network so that a user

or administrator may interact with a user-friendly web application to carry out all

ERC-20 standard Smart Contract functions (transfer, set allowance/scholarship,

etc.).

● Completed administrator portal and functionality

 17

● Completed user portal and functionality

● Completed Spring Security implementation

● Add Unit Tests

Phase 4: User Testing and Re-Design/Refactoring

7/21 to 8/07

● Tested with a focus group of CSUMB students, friends/family, including industry

professionals.

● Refactor and improve functionality based on user feedback

● Resolved any outstanding bugs.

● Complete additional functionality if time permits

● Add any outstanding Unit Test

Ethical Considerations

The advent of digital currency, like any new technology (software or otherwise), poses

both benefits and challenges to society, including some legal and ethical challenges. Blockchain

technology is decentralized in nature, and therefore is not currently subject to control by a

banking institution or government, at least in the western world. This distributed nature gives

digital currency an unusually egalitarian and transparent quality -- anyone with the proper

knowledge and equipment can host a node on a blockchain network, and all users of the network

can see a transparent record of transactions.

 18

Additionally, blockchain transactions can be done essentially anonymously. There is no

requirement for identification, a social security number, or a credit card with an associated name

and address if one wants to purchase or spend digital currency.

Despite these apparent advantages, these same attributes of decentralization, anonymity,

and transparency also pose ethical questions. Some may argue that these ethical questions must

be resolved societally before digital currencies should be authorized for public use. Others might

argue that the very nature of digital currency rejects centralized, governmental, and institutional

control, and this is a good thing.

The decentralized nature of blockchain technology creates questions of standards and

accountability. Rhys Lindmark, Head of Community and Long-Term Societal Impact at MIT’s

Digital Currency Initiative, points out that “Blockchains make it possible to create leaderless,

‘decentralized’ organizations. Does that mean no one is responsible if something goes wrong

(Orcutt, 2020, Page 1)?”

The anonymity of a blockchain currency also poses both benefits and challenges.

Dissidents and other individuals living under repressive regimes may be able to use the digital

currency without having to fear reprisal from their governments. At the same time, this

anonymity could make it harder for government agencies to track the financial activity of bad

actors such as violent extremists.

The creation of a private, organizationally-specific blockchain like our project aims to

accomplish also means creating a currency system that can be controlled by the administering

organization. This could pose thorny ethical issues in terms of things like user privacy.

According to their website, Cal State Monterey Bay utilizes government-funded law enforcement

(CSUMB, 2020). If CSUMB’s administrators can access a record of all student transactions on
 19

the blockchain, this could potentially pose privacy concerns due to the transaction history

implicating students to activity the school might deem unacceptable. Additionally, users with

such access could potentially use it to simply spy on user transactions. The Edward Snowden

revelations show us that NSA employees with access to the private electronic histories of

individuals may use that access to gather unauthorized information such as “LoveINT”

(intelligence) on their romantic interests (Ferran, 2013). Would these same issues arise if a

student and/or school administrators of a private blockchain had full access to every user’s

transaction history?

Additionally, blockchain’s digital nature poses ethical challenges around accessibility for

disadvantaged communities. Certain groups may be left behind if their technological literacy is

poor, or if they lack access to reliable networks.

Additionally, the fact that digital currency is not universally accepted also poses

concerns. Students with limited financial resources would have to weigh whether it makes sense

to spend their money on a digital, school-specific currency that e.g., their landlords will not

accept as rent payment. Therefore, the use of this technology just might not be feasible for

everyone. At the same time, students with fewer financial and technological limitations might

become frequent users of “OtterCoin.” This could create more division between socioeconomic

classes at the university.

Our current vision of the service provides for both token ownership and, ideally, low or

no-cost transaction fees within our school’s community. This “free-trade” system could also pose

concerns if students made ill-advised purchases on the blockchain.

We also believe that because the school would control many aspects of the currency,

including potentially the allotting of scholarship funds and unilateral revoking of such funds in
 20

certain circumstances (such as a student not spending the funds within a sufficient time frame),

that an independent oversight commission within, but not necessarily limited to the university

would need to be established. This organization would need to set fair use standards for the

service, restrain institutional overreach, and mediate any disputes. Their role could be somewhat

analogous, though hopefully more effective than, the Securities and Exchange Commission

(SEC) or the Federal Communications Commission (FCC). It may also be wise to have both

students, faculty, and neutral third parties represented on such a committee.

Legal Considerations

Digital currency is a relatively novel concept on the global stage. As such the legal

framework dictating the use of cryptocurrency is in various stages of development around the

world. In China, for example, the first major legal documents pertaining to cryptocurrencies

appeared in 2009, when the Peoples Bank of China issued documents defining cryptocurrencies

and how its branches could work with them (Reuters, 2021). Yet, according to A Toss of a

(Bit)Coin: The Uncertain Nature of the Legal Status of Cryptocurrencies:

By January of 2018, the use of cryptocurrency in the country was effectively banned,

individual users were allowed to store various crypto tokens, but banks were prohibited

from performing any financial transactions with them. (p.177)

This is not to say that the country is not bullish on the concept of the use of digital assets:

“It is predicted that China will be the first major country to launch a central bank digital

currency… China will also implement real-name verification and other measures to

counter money laundering and tax evasion.” (Cassidy, 2020)

 21

This highlights the delicate situation that digital currencies currently exist in as well as

potential privacy concerns around their use. Across the globe, new laws are being introduced,

abolished, and reintroduced with wide-ranging implications for all types of digital currencies, not

just the mainstream coins such as Bitcoin and Ethereum.

There is no guarantee that some far-reaching law won’t challenge the legality of the

distributed ledger method of providing what has historically been a private banking service. If

the government decides that having a currency that can be used to attain physical goods or

services constitutes a store of physical property, then perhaps current banking laws start to look

more relevant.

Currently, governments issue their own currencies which their citizens use for the

exchange of goods and services. The issuing organization of a digital currency might be liable

for fraudulent transactions or breaches in user security, as financial institutions are today with

traditional “legacy” currencies.

Additionally, if it is possible to convert a digital currency to dollars the currency suddenly

has real-world value and the IRS may require records to be disclosed (Lopez, 2015). When

filling out tax forms or sending information to an accountant, your users may need to declare

how many OtterCoins they currently hold, their value at purchase, and what the school buys

them back for. This would erode the anonymity benefits (and challenges) a digital currency

provides.

Under our initial plan for the Zuess Cryptocurrency Service, the issuing agency may have

inherently greater power than its users. There would exist a ledger, which is standard for a

blockchain, but more importantly, addresses would be linked to users. This opens up a world of

liability and potential privacy violations.

 22

Student privacy issues have become particularly concerning for a digital currency service

controlled by the state of California. For example, if a student at a university that offered this

service was shown to have used the service for illicit activities not pertaining to the school in any

way, then what would prevent the school police from acquiring the entire transaction history of

the accounts involved and turning them over to state law enforcement agencies?

The solution to these issues may be to severely restrict how the metadata (such as

transaction history) about the currency could be used, perhaps in a Terms of Service agreement.

Finally, there may be legal implications involved in replacing or augmenting the banking

system within an organization. The development of such a system may or may not be a

significant hindrance to the effectiveness and/or cost-effectiveness of our service. The level of

hindrance is as of yet unknowable due to the shifting nature of the laws surrounding digital

currencies and marketplaces. There would be potential for a significant breach of privacy

depending on how users decide to use this service which the organization could be liable for. The

level of tax liability is, to the extent of the knowledge of the creators of this service, unknown.

Finally, to what extent are the creators of the service (the student developers) and Zuess

liable for how it is used? If a school uses our service, and there arises a dispute with a student

(perhaps who has their digital scholarship funds, or funds purchased with real currency revoked

by the school), who might be liable for that? Similarly, what if a security breach of the service

allows a clever hacker to allot themselves thousands of dollars worth of OtterCoins that they then

spend at participating school venues? Could the student developers of the service be successfully

sued for such an event? What about a data breach of sensitive student data?
 23

Before making this service available for purchase (or use beyond a limited test) legal

expertise should be sought in the areas of tax law, privacy law, education law, and, to the extent it

is accessible, digital currency law.

Timeline/Budget

The goal of our project was to create a prototype private Digital Currency Service based

on Ethereum technology. We believe we have met this goal. We were able to research and

understand Ethereum, and to implement an ERC-20 (a standard for functionality) Ethereum

Smart Contract, first in the Solidity language and then later compiled into Java.

We implemented a test Ethereum Blockchain network using Ganache that simulates the

Blockchain running on 10+ individual computer nodes.

Using the Ganache test Blockchain and our Smart Contract, we built a Spring MVC web

application in Java that provided the user interface, business/application logic, Ethereum

interfacing, and database functionality.

With our application, we have implemented the following functionality (and more):

● Deploy a custom-written Smart Contract (or a standard ERC-20 Contract)

to the Blockchain with a single click.

● Register and create an account securely using Spring Security, where it is

possible to delegate access using a role-based permissions structure

(USER, ADMIN, etc.).

● Create user/admin accounts that are automatically assigned a unique

Ethereum ID (from the Blockchain).

 24

● Transfer funds from the admin account to one or more users at the same

time using a convenient checkbox/click modal.

● Grant a Digital Scholarship, which is an Ethereum Allowance that allows

a user to spend funds from the Admin account in Bookstore, only on

approved academic items (like textbooks).

● View the account balance of any valid-user

● Transfer standard funds and Scholarship funds from a non-admin account

to any other active account using custom-written (non-Smart Contract)

calls to Ethereum.

● Purchase items from a Bookstore that are retrieved from the database and

dynamically displayed on the page. The user is shown how much of their

order is eligible for purchase with Scholarship funds.

● Input Validation (using regular expressions) is done entirely on the

server-side for security as client-side input validation is much more

hackable -- using a custom-written class and methods and Spring Security.

● View an up-to-date visual representation of the actual Ethereum

Blockchain used by Zuess Digital Currency Service.

We believe the implementation of all of the above functionality meets our goal of

developing a prototype Digital Currency Service. Future iterations of the project will want to

explore how an actual organization would set up the Ethereum Nodes (usually these exist on

many individual computers) necessary to store and process/mine data on the Blockchain.
 25

Additionally, it would be important to explore how scaling the application, including the

setup of Ethereum Nodes and individual Zuess organization accounts would be managed. A

question that would need to be answered is whether Zuess would maintain the multi-node

distributed computers (virtual/real) that are required to run the blockchain, or would it be the

responsibility of the organizations using the service?

Important Dates Project Goals

6/19 1. Scaffold initial Spring MVC project with controllers, services,

database design. - Completed

2. Build a user registration page. - Completed

6/29 1. Complete Initial User Stories in Pivotal Tracker - Completed

2. Continue building Spring app functionality for user account

interaction (e.g., homepage, login page, view accounts, update

personal information, etc.) - Completed excepting updating

personal information, which is not yet built in the user account

page.

3. Continue building the functionality of the Spring app ensuring it

can call all basic ERC-20 functions. - Completed

4. Add Spring Security - Completed

 26

7/12 1. Continue building Spring app functionality for user account

interaction. - Completed

2. Continue building the functionality of the Spring app ensuring it

can call all basic ERC-20 functions. - Completed:

BlockchainService has functions to call all Smart Contract

methods, and custom functions to pass in a specified “from”

address where needed.

3. Add additional custom Spring and Smart Contract functionality as

time permits. - Not Completed. We did not modify the Smart

Contract from its initial ERC-20 standard functionality. A clear

reason to modify did not present itself.

7/24 1. Complete user testing - Completed

2. Add additional custom Spring and Smart Contract functionality as

time permits. - Not Completed (see above)

7/31 1. Improve application Based on feedback - Not completed. Users

identified several issues but our focus this week has been the video

and report.

2. Add additional custom Spring and Smart Contract functionality as

time permits. Partial completion. Blockchain Visualization was

added which was not in the initial plan.

8/7 1. Capstone Festival Presentation

 27

Usability Testing & Evaluation

To test our software’s usability, we asked a set of test users to access our service, create

an account, perform a few predetermined tasks within the app, and then answer a short survey

about their experience. Because the potential user base for this application is anyone who is a

member of a private organization we do not have to be extremely specific in our test user

selection process. This should allow us to find a reasonable number of testers without too much

difficulty.

A total of six users were tested for this project. The users all come from different

backgrounds and it was very beneficial to get this information from such a diverse group. Their

technological knowledge and literacy were at different levels so that helped our team see how

various groups (not just CS college students but working professionals) would utilize such a

service. A common question that came up in our survey pertained to the knowledge of Smart

Contracts. This was important because our service was also meant to teach users about

blockchain technology so having them ask that question gave us the insight we needed to help

educate future users.

Most of our users ran through our service with relatively no help. Info modals and

specific features were labeled for minimal explanations needed. This may be possible and will be

attempted pending exploration of the difficulty of finding a group of people that are both willing

to test for us and regularly have a need to transfer funds among themselves.

In all cases of our testing, all members of this project were present to help guide and

explain functions when a user needed them. All tasks were completed and no user left any

remarks that made us overhaul our design.

 28

Testing forms were provided via Google Forms to ensure ease of use. Users were

instructed to give individual feedback on each task as they attempted to complete it. Then upon

completion of their task list, they were asked to fill out a short survey. An example of the format

of user feedback can be found in Appendix A.

Throughout this development process, we sought out to create an app that was technical

but made easy to use. There were designs we had in mind many that did not come into the final

product. Ultimately we felt that a minimalist look was the best for our user interface. These ideas

were modeled after mobile banking apps such as Coinbase or Chase mobile banking. We kept

our pages clean and responsive with bootstrap.

As you read through the final deliverables you will see the ways in which

simplified information makes the user experience easier.

Final Implementation

Our application is a combination Digital Currency Service backend/frontend (where an

organization can deploy and administer a private cryptocurrency service), Ethereum Digital

Wallet (where a user can view and transfer funds), Digital Currency Store (where a user can

purchase items with Ethereum funds), and an educational platform, where users can view the

actual Ethereum Blockchain and gain insight into how it functions from our Help page.
 29

Ethereum, Smart Contracts, and the Blockchain

The core of our application is an Ethereum Smart Contract. This program controls all of

the cryptocurrency functions in our application, such as transfers, account balance retrieval, and

allowances (Digital Scholarships).

Our Smart Contract is ERC-20 compliant, which means it meets the Ethereum

functionality standards required for deployment on the real public Ethereum Blockchain.

Initially, our Contract was written in Solidity, an Ethereum-specific programming language. Here

is a partial sample of the Solidity Contract Code. The full Contract is viewable in the Appendix.
 30

Once the Smart Contract was written in Solidity, it had to be compiled using the Truffle

framework into binary form and then exported as a Java object using the Java Ethereum Web3J
 31

library. In our Spring web application, the above Solidity contract exists in the binary form inside

a Java wrapper. The following screenshot is the above Solidity OtterCoin now as a Java object:

The “BINARY” String variable shown contains the original Solidity contract in binary form,

now in a Java wrapper:

Now that the Smart Contract (“OtterCoin”) exists as a Java object, an instantiated object

of the Smart Contract class can be deployed to a Blockchain network from our Spring/Java

application using an Ethereum private key of an existing Ethereum account holder. Once

deployed to the network, it is possible to call each of the ERC-20 functions on the application,

and more. All of this Blockchain interfacing functionality exists in our custom-written

BlockchainService.

BlockchainService

The BlockchainService class is the core of our application, and contains all methods that

interface with the Ethereum Blockchain. The class is divided into four sections, as follows:
 32

1. ERC-20 Methods: contains methods written to deploy OtterCoin to the Ethereum

Blockchain, and make calls to the Contract methods once deployed:

2. Custom Contract Calls: contains more complex methods necessary to pass to the Smart

Contract additional parameters beyond what are ordinarily passed using the default

functions. Specifically, it is necessary to pass a custom “from” or caller address any time

we want to create a funds transfer from an account that did not originally deploy the
 33

Contract. Without these functions, it is not possible for anyone other than the

administrator to transfer or spend funds.

This is the single method used for non-admin (standard user) peer-peer transfers and

Bookstore purchases:

3-4. These sections contain direct method calls to the Blockchain to gather user accounts and

return data from each individual block for the purpose of our Blockchain Visualization page:
 34

The BlockchainService is the foundation of our application in terms of interfacing with the

Blockchain. Following is the Zuess Administrator Page which relies heavily on the

BlockchainService class:
 35

MySQL Database

The application makes substantial use of a MySQL relational database. The database

includes tables that hold user information (Users table), user roles for our Spring Security

implementation, Bookstore inventory items, and more. In Spring, the JPA Repository Interface is

used for data storage and retrieval.

 36
Spring Security and Role-Based Permissions

We use Spring Security and a role-based permission system as well as custom javax

validation annotations to validate user activity on the site. Spring Security is a robust,

enterprise-grade web application security framework.

Upon new user submission, we use javax validation libraries along with custom

annotations to test the input for errors on the server-side before storing it in our database.

Example of @Valid annotation and error checking:

When an object is passed along with a valid annotation every piece of data on that object

is passed through the annotations assigned to it and the errors are applied to the binding result

object.

The custom constraints are defined in separate files. First, the constraint is defined and

linked to the class that will perform the validation.

Then in the validation file, you can write your custom methods.

This method is ideal as you can tailor validation code snippets to pertain to specific data

very clearly. For example, our password validator iterates through many if statements and
 37
evaluates the provided string against several regular expressions to provide specific error

feedback.

While our unique email annotation simply checks whether an email address shows up in the

database.

Once a user is validated we encrypt their password, assign a role (currently all

registrations default to a USER role), and save the user object to our database.
 38
In the current iteration of the application for testing purposes, it was easiest to simply

allow all validated users to access all pages of the application so currently most functionality is

only locked behind a basic authentication and permission level.

But because we have assigned roles we can lock pages to be accessible based on roles assigned

then hiding the paths to suit, like so:

Spring HTTP Controller

A web application needs a way to return HTML pages based on user requests. In our

Spring application, we use a standard HTTP Controller which handles all user GET and POST

requests.
 39

The Controller also contains a custom InputValidation class using parameterized

(generic) functions that provide input validation of two primary types. The notEmpty() method

can take in any number and any mix of parameter (int, String, int or String, String, String, etc.)

types to validate using regular expressions that none are empty or contain only whitespace. The

validateSingleField() and validateFieldList() classes can take in different variable types to

validate they conform to several important field type specifications such as for an Ethereum

Private Key.
 40

Zuess Digital Store

The Zuess Digital Store is a place where Zuess users can spend their Ethereum funds. For

our application prototype, using the “OtterCoin'' Smart Contract and the theme of the use of the

Zuess Service by a university, we chose to build a replica of the CSUMB Bookstore to

demonstrate the use of Digital Currency and Digital Scholarships. The Bookstore is pictured

here:
 41

The Bookstore makes use of three Service classes: InventoryService,

StoreTransactionService, and ScholarshipService. StoreTransactionService is pictured here:

 42

Zuess Help Page

The Help Page is a resource for both learning how to use Zuess Digital Currency Service, and

learning about Blockchain Technology and Ethereum more generally. It contains Help Videos

demonstrating the use of the application, information on the Zuess student developers and

educational information on Blockchain technology.

Discussion
The following timeline depicts the development of Zuess Digital Currency Service:
 43

Ganache and Truffle test suite allowed us to deploy a fully-functional Ethereum

Blockchain network on our local machines. A standard Blockchain network would require the

use of many individual computers all acting as nodes. Ganache provides an easy-to-use interface.

The use of an Ethereum private key was needed to deploy our contract in the application. The

private key-holder who deploys the contract is also the contract administrator in Zuess.

The Ganache test suite is really the only stable one of its kind. This service works on the

desktop (using Windows) and we are not aware of a local version usable on mobile at this time.

Early on we knew that working with relatively new technologies would pose this problem;

however, this drawback was not enough to prevent creation of a fully-functional ERC-20 Smart

Contract..
 44
This project was successful in many ways. However, we also have some ethical concerns

around how it could potentially be used commercially. The Zuess application is capable of giving

a great deal of centralized control to the school or organization that uses it -- more so than in the

case of cash exchange. In many ways, this is the antithesis of the fundamental spirit of

Blockchain technology, which is the decentralization of power from institutions to individuals.

In a commercial implementation of this application, we would need to strike a balance between

the sometimes competing ideals of user privacy and control, and providing a service that offers

something unique (greater oversight -- e.g., with our application’s ability to restrict Scholarship

purchases) relative to legacy currencies -- such that organizations will see a reason to use a

digital currency service instead of traditional currencies.

However, user actions on our Etherum Blockchain however are still immutable events

with the full level of security and transparency that the real Ethereum blockchain provides. What

defines the balance of control between the user and the organization is the functionality written

into the Smart Contract and the Zuess web application.

Reflecting back on the amazing work done to create Zuess, we believe and aim to show

that digital currency services may represent the future of capital exchange. Digital Currency is a

technology that few understand, but we believe we have already shown ways in which it can

improve the currency transaction services with which we are already familiar.
 References

Areddy, J. T. (2021, April 5). China Creates Its Own Digital Currency, a First for Major

Economy. The Wall Street Journal.

https://www.wsj.com/articles/china-creates-its-own-digital-currency-a-first-for-major-eco

nomy-11617634118.

California State University Monterey Bay. (2020). University Police | California State University

Monterey Bay. Csumb.Com. https://csumb.edu/police/

Cassidy, J., Cheng, M. H. A., Le, T., & Huang, E. (2020). A toss of a (bit)coin: The uncertain

nature of the legal status of cryptocurrencies. EJournal of Tax Research, 17(2), 168-192.

Retrieved from

https://www-proquest-com.csumb.idm.oclc.org/docview/2397708839?pq-origsite=primo

&accountid=10355

Crypto Casey. (2020, February 29). Ethereum 2021 Explained: What is Ethereum & How it

Works (Ultimate Beginner's Guide) [Video]. Youtube.

https://www.youtube.com/watch?v=DhoRtGCp4JI

Ferran, L. (2013, September 27). 'LoveINT': Given Immense Powers, NSA Employees Super

Cyber-Stalked Their Crushes. ABCNews.com.

https://abcnews.go.com/blogs/headlines/2013/09/loveint-given-immense-powers-nsa-em

ployees-super-cyber-stalked-their-crushes

Gurfidan, R., & Ersoy, M. (2021). Blockchain-Based Music Wallet for Copyright Protection in

Audio Files/Billetera De Musica Basada En Blockchain Para Proteccion De Derechos De

Autor En Archivos De Audio. Journal of Computer Science & Technology, 21(1), 11+.
 https://link.gale.com/apps/doc/A660012407/CDB?u=csumb_main&sid=CDB&xid=fba8a

b57

Lopez, Katherine J. Virtual Currency-Property or Foreign Currency? an Exploration of the Tax

and Ethical Implications. Southern Journal of Business and Ethics, vol. 7, 2015, pp.

119–128. Retrieved from

https://www-proquest-com.csumb.idm.oclc.org/scholarly-journals/virtual-currency-prope

rty-foreign-exploration-tax/docview/1767088198/se-2?accountid=10355

Orcutt, M. (2020, April 02). Why it's time to start talking about blockchain ethics.

Technologyreview.com

https://www.technologyreview.com/2019/10/10/132652/why-its-time-to-start-talking-abo

ut-blockchain-ethics/

Pranto, T. H., Noman, A. A., Mahmud, A., & Haque, A. B. (2021). Blockchain and smart

contract for IoT enabled smart agriculture. PeerJ Computer Science, 7, e407.

https://link.gale.com/apps/doc/A656846920/CDB?u=csumb_main&sid=CDB&xid=ae84

227b

Thomson Reuters. (2021, May 18). China bans financial, payment institutions from

cryptocurrency business. Reuters.

https://www.reuters.com/technology/chinese-financial-payment-bodies-barred-cryptocurr

ency-business-2021-05-18/.

(2021, February 23). Current and Upcoming Trends in CryptoCurrency. Globe Newswire.

https://www.globenewswire.com/news-release/2021/02/23/2180372/0/en/Current-and-Upcoming

-Trends-in-CryptoCurrency-Market-Cap-to-Hit-5-190-62-Million-by-2026-Soars-at-30-C

AGR-Facts-Factors.html
Appendix A: Test Plan
 Appendix B: Division of Labor

● Robert:

○ All Ethereum Blockchain and Smart Contract-related programming

including programming initial Smart Contract in Solidity, importing Smart

Contract into Java. Implementing all Ethereum/Smart Contract calls in

BlockchainService. Significant research time.

○ All backend Service functionality (wrote BlockchainService,

InventoryService, ScholarshipService, StoreTransactionService) outside of

Spring Security/Registration.

○ Most HTTP Controller and JPA Repository code

○ Initial front-end styling for all pages except help page, all UX styling for

Blockchain Visualization page, several revisions of UX styling for each

page.

○ InputValidation class for server-side input validation

○ Initial database design and table implementation

○ Substantial contributions to Capstone Reports.

● Antonio:
○ Unit testing for the CustomUserDetailsService

○ Front end work:

■ Custom login page to work with Spring Security

■ Dynamic printing and on the store page

 ■ Researched various forms of UX for financial service apps

■ Bootstrap for responsive designs

■ Various modals for displaying important information and help modals

■ Help Page Design

○ Substantial contributions to Capstone Reports

● Jesse:

○ Researched and Implemented Spring Security

■ User object

● Validation

○ Applied standard Java validation annotations

○ Created Custom Java validation annotations

■ EmailUniqueConstraint

■ PasswordValidConstraint

● Role assignment

○ Framework for access control based on assigned role in

place but not implemented due to nature of our testing

○ Currently all users assigned to “USER” role

■ Password hashing

■ WebSecurityConfiguration

○ Assisted front end development

○ Substantial work on database design and implementation

○ Substantial contributions to Capstone Reports

○ Capstone video editing

 Appendix C: Additional Project Code and Diagrams
Full ERC-20 Compliant Ethereum Smart Contract “OtterCoin” written in Solidity which controls all
transactions on our service:
Portion of Zuess Web Controller handling all user HTTP requests:
The Ganache test Ethereum Blockchain:

Zuess Database Entity-Relationship Diagram: