Agenda

1  Project Introduction ........................................................................................................................ 1 
1.1  Scope of this report ................................................................................................................. 1 
1.2  Idea and vision ......................................................................................................................... 1 
1.3  The three phases of the project .............................................................................................. 2 
2  Stakeholders and requirements ...................................................................................................... 3 
2.1  Phase I: .................................................................................................................................... 3 
2.2  Phase II .................................................................................................................................... 3 
2.3  Phase III: .................................................................................................................................. 4 
2.4  Non­functional requirements .................................................................................................. 4 
3  Interaction patterns of the three Phases ........................................................................................ 5 
3.1  Phase I ..................................................................................................................................... 5 
3.2  Phase II: ................................................................................................................................... 6 
3.3  Phase III: .................................................................................................................................. 6 
4  Development of the smart contract ................................................................................................ 7 
4.1  Phase I: .................................................................................................................................... 7 
4.1.1  Development of the ERC20 Token/Wrapped Ether ........................................................ 7 
4.1.2  Addition of a mintable function ...................................................................................... 7 
4.1.3  Add start­ups ................................................................................................................... 8 
4.2  Phase II .................................................................................................................................... 8 
4.2.1  Start an appeal ................................................................................................................ 9 
4.2.2  Contribute to appeal ....................................................................................................... 9 
4.2.3  Get the contributed amount ........................................................................................... 9 
4.2.4  Check if appeal is reached ............................................................................................... 9 
4.3  Phase III ................................................................................................................................... 9 
5  Concluding remarks .................................................................... Fehler! Textmarke nicht definiert. 
References ............................................................................................................................................... 9 

 
  

1 Project Introduction

The money invested or donated in the crowdfunding segment is rising fast. According to Statista
(Statista, 2019) in 2019, crowdfunding campaigns had a transaction volume of over six billion
€. This transaction volume is expected to rise to more than ten million € in 2023. Distributed
ledger technologies have many use cases in mainly the financial services industry and this
project report explains one approach to develop a fully decentralized way to create and support
crowdfunding campaigns. As so much money is involved in those campaigns it is of interest
for the stakeholders that no centralized crowdfunding platform can shut down their services and
leave with the currently not yet disbursed money. The project is developed as a smart contract
written in the programming language Solidity and is planned to be deployed on the Ethereum
virtual machine.

1.1 Scope of this report

In order to give an overview of the project, the idea and vision behind the final product is briefly
explained. Furthermore, the stakeholders are identified and analysed. The non-functional and
functional requirements of the respective stakeholders are described. This overview ends with
an explanation of the smart contract functions and interaction patterns. This project is structured
into three major milestones or phases. Each phase is separately explained. As the development
is at the time of this report at the end of phase II, the last phase is described as a brief outlook.

The contract of Phase II can be found on the Ropsten testnet:

0xAeBb1F8eFD9D27BB04A9FeC70F5c3dA49E8fc218

The contract of Phase I can be found on the Ropsten testnet:

0x5645Bc905e160625B93Cba5B7F75040Ead8b7095

The development can be tracked via GitHub: https://github.com/teleho/Crowdfunding

The contracts of this report can be found in the folders Phase I and Phase II

1.2 Idea and vision

A crowdfunding platform built on a distributed ledger has several advantages for the
stakeholders. Collecting money via a smart contract instead of a platform like Kickstarter
reduces the administration fees, as only the smart contract as a middleman is needed. Only the
Gas price for interactions has to be paid, but there are no additional administrative costs. As a

 
  

funder, an advantage is that in case of a failed campaign you can be certain to receiver the
funding back, while in case of success, the investor as well as the start-up know, that the start-
up will receive the funds.

Concepts like the one above already lead to the creation of companies like qpq.io. qpq.io hopes
that so called Security Token Offerings (STO) will replace traditional funding. Today, getting
funding, especially on a high scale, requires a lot of administrative work. Therefore, to reduce
costs, companies tend to keep the pool of potential investors small. This leads to inequality in
terms of investment opportunities, since high net worth individuals are preferred.

An STO can help making funding easier. From a technical point, a STO means you fund a
company via a smart contract/on a Blockchain and receive a token back. The main difference
to our concept is, that this token represents a share of the company and has to fulfil legal
requirements.

Selling the tokens via Blockchain reduces costs, because it is easy to keep track of every
Shareholder. This is similar to the proposed Ethereum-based crowdfunding platform, where
everyone who has the internal so-called Cheese tokens can exchange it for Ether. As a long-
term vision, with an STO, everyone who owns it can be entitled to receive e.g. a dividend.

1.3 The three phases of the project

The project is structured in three phases, going from proof of concept (POC) up to an enterprise
ready solution.

Phase I: In this phase, the most basic functions are created. This means, the contract allows to
buy the ERC20 token of the contract (called Cheese) and use it for funding and to exchange
back for Ether. Also, the contract allows to sign up as a start-up to ask for funding.

Phase II: For the second phase the project team worked/work on several additional
functionalities. Start-ups should be able to create a specific target for their funding which
includes a deadline as well as the amount needed. On day of the deadline, in case of success,
the start-up automatically receives the Cheese token and can use it to exchange it for Ether. If
a campaign failed, funds automatically get returned to the funders.

Phase III: Here the project gets to an enterprise level, where the project team also would need
legal advice, besides technical points. In addition to Phase II, now with every success of a
campaign, not only does the start-up receive its funds, but also the investors receive unique

 
  

tokens created for each campaign. These tokens either represent shares in the company funded,
or give other rights, like receiving a product when developed, in exchange for the tokens.

2 Stakeholders and requirements

The project team identified several important stakeholders. The list not completely exhaustive,
but main stakeholders of each phase are explained. Each phase contains the stakeholders of the
previous phase. This first list of the phases contains only functional requirements. Due to the
decentralized nature of the POC, non-functional requirements like stability or reliability, are
offered by the Ethereum Blockchain and not by the developers.

2.1 Phase I:

Investors:

­ can send Ether to the contract address

­ receive ten times the internal Cheese tokens of the Ether send to the contract

­ can send Cheese tokens to other investors or listed start-ups

­ can exchange Cheese tokens back to Ether

Further requirements include e.g. that investors can check if a start-up is listed as a
registered start-up or check the own balance of Cheese tokens. Only the most important
requirements are listed.

Funded entities:

­ can register their address for funding

­ can receive Cheese tokens from investors

­ can exchange Cheese tokens back to Ether

2.2 Phase II

Besides all requirements from Phase 1, now additional ones become important as well. Because
at the end of this stage the platform could be already used as a commercial crowdfunding
platform, the developer of the smart contract is now also an important stakeholder. Furthermore,
the Ethereum Network is getting more important, as it could be heavily used, and e.g. the Gas
fees could rise as a result.

Developers:

 
  

­ To ensure the smart contract is trustworthy for funding campaigns, it needs to be open
source. The developer has to make sure, that there is no possibility to access funds if
you are neither and investor, nor a funded entity.

The developers of this project do not aim to have a commercial advantage from this project.
However, the reputation of the developers could be affected. One restriction of the contract
functions would be that nobody should be able to mint the internal tokens without sending Ether
to the contract.

Ethereum Network:

­ The Ethereum network and mainly the validators are also stakeholders. However, no
specific functional requirements were identified.

2.3 Phase III:

The platform could be also set up as an IPO Platform. In this case, more stakeholders need to
be considered.

Investors:

­ Must receive a token according to their funding

Existing Investors:

­ Are affected, but don’t have specific functional requirements

Regulators:

­ Further research needs to be conducted. However, specific functional requirements

could be needed to enable audits or other analysis of the business behind the platform

2.4 Non-functional requirements

­ User Experience: The contract should be easy enough to use that users without a
technical background can use it. To conquer this problem, a web-app based on Python
Flask could be built, so that users have a nice Website interface to use the platform.

­ Scalability: The platform should be scalable. This cannot be changed by the developers
and is completely dependent on the Ethereum Network. It is proven to be scalable, but
only to a certain point. Prior smart contracts that created a hype already slowed down
the Ethereum quite heavily (BBC News, 2017).

 
  

­ Immutability: The transactions should be saved forever and should not be able to get
changed. This is also a underlying issue that is connected with the Ethereum Network.

Further non-functional requirements regarding the performance, security, speed, privacy or

availability were identified but are not described in more detail in this report.

3 Interaction patterns of the three Phases

The defined functional requirements were combined for each phase to create a visualised
interaction pattern. Not all functions that are implemented are shown, e.g. checking the balance
of an account or checking the total supply of the Cheese tokens are not included. For these
functions, please refer to the Code on GitHub or try the deployed contract on the ropsten
Testnet.

3.1 Phase I

 
Figure 1: Interaction pattern of Phase I functions 

This phase is fully developed. The functions that can be used in the first phase are all ERC20
token functions, wrapped Ether functionality to receive the token of the contract and exchange
it back to Ether, and a function to register as a start-up.

Exemplary interaction if a start-up wants to receive funds:

­ Contract: Start-up registers its Ethereum address on the smart contract
­ External: Start-up could advertise and share their address and wanted goal
­ Contract: User can check on the contract if the advertised address is registered
­ Contract: User sends Ether to the smart contract
­ Contract: Mints Cheese Tokens and sends them to the user
­ Contract: User can send Cheese tokens to the start-up

 
  

­ Contract: Start-up can exchange the received Cheese tokens back to Ether on the
contract

3.2 Phase II:

 
Figure 2: Interaction pattern of Phase II functions 

This phase is currently still under development. Additional to the functions of the first phase,
any user can now start an appeal for funding. Users then can contribute to the appeal. Also, the
users or the start-up can check how much was contributed to each appeal. Another function can
be used to check if the goal was reached. If it was reached, the appeal will be deleted, and the
funding is transferred to the start-up.

3.3 Phase III:

 
Figure 3: Interaction pattern of Phase III functions 

This last phase is not yet implemented. In theory, a token for each appeal is created and sent to 
investors.  

 
  

4 Development of the smart contract

The team has a GitHub repository and is working individually but mainly together on the code.
This way, the team can push up or fetch the current repository. The team uses visual studio code
to write the code in solidity for the smart contract. Then, the online platform remix is used to
compile and deploy the written smart contract. Each developer uses the browser plugin
Metamask as a wallet from which gas fees are paid and transactions can be made. Currently, all
testing and deploying is done on the robsten testnet. All relevant sources of used code are
shared, to make sure that standard procedures (like ERC20 requirements) are used from existing
trusted libraries and to help developing the appropriate functions. The final contract code on
GitHub contains licenses and links to the resources used.

4.1 Phase I:

4.1.1 Development of the ERC20 Token/Wrapped Ether

To enable easier interaction with the Smart Contract and to enable future STOs or similar, we
decided to include a wrapped Ether function with an ERC20 token (Cheese Token). The idea is
that users can buy an ERC20 token “Cheese” from the Smart contract (wrap Ether) for their
Ether, use the token for funding or send the token back to the contract to receive Ether (unwrap
Ether). As ERC20 is a standard, the project team used an existing library called OpenZeppelin
that is usually used with Ethereum development frameworks like Truffle (OpenZeppelin, 2019).
In this case, all libraries and smart contracts were used in a single contract file for this project.
Which parts of OpenZeppelin we used in our Contract can be seen in the attached code or on
GitHub. This is also true for other libraries/inspirations we used from different sources.

Figure 4: MIT license of OpenZeppelin explained 

4.1.2 Addition of a mintable function

This function enables the smart contract creator to mint the ERC20 Cheese tokens. But the
creator can also give the minter status to another user that now also can mint. Because of the
functional requirements in any of the Phases, this function was adjusted, and parts were taken
out of the smart contract. In the modified version, only the smart contract itself can mint new
tokens. This happens only if Ether is sent to the Contract and automatically leads to a transaction
 
  

of the minted tokens to the Sender. When the Token is sent back to the Smart Contract in
exchange for Ether, all tokens get burned as an additional security. This also helps keeping track
of the total amount of funds in the contract at any given time. Checking the total supply of
Tokens can be checked by anyone at any given time.

4.1.3 Add start-ups

This function uses the library “Role” that consists of a structure called “Role” from
OpenZeppelin. The way the contract that defines the “addStartup” function was inspired by the
“addMinter” that needed to be deleted in the step before. The start-up can be added by inputting
an address. This address will be included in a mapping of registered start-up addresses and a
Boolean true. This way, start-ups can be also deleted from this registered list or it can be
checked if an address can be found in this mapping.

4.2 Phase II

The functionality of this phase is still in development. The code structure is in place. However,
connecting the developed wrapped Ether functionality needs to be connected to the mapping
visualised in the Figure below. Currently, users can contribute, but it is not connected to the
internal token. The appeals can be checked and are deleted if the goal is reached. The start-up
that listed the appeal does not get any tokens or Ether at the current stage.

Figure 5: Structures and Mappings that are used in Phase II 

 
  

4.2.1 Start an appeal

Any user can start an Appeal. For this, an ERC20 address is needed and the desired goal of the
funding. A campaign is added with an address, a goal, and the contributed amount and number
of contributions is zero.

4.2.2 Contribute to appeal

The campaigns created receive an ID in the mapping. The first campaign created in the contract
receives the ID 0. To contribute to an appeal, a user needs to input the ID of the campaign and
an amount he wants to contribute. In the struct “Contributions” the user is saved in a mapping
containing the address of the contributor and the contributed amount.

Furthermore, the overall contributed amount of the respective appeal and the number of
contributions is increased.

Work in progress: The contributed amount is increasing, but it is currently not yet
connected with the wrapped Cheese tokens.

4.2.3 Get the contributed amount

This function does not cost any Gas. The contributed amount for each campaign can be checked.  

4.2.4 Check if appeal is reached

This function needs to be triggered to disburse the funding. The only input needed is the ID of the 
campaign. The function already checks if the goal is reached and triggers the deletion of the appeal.  

Work in progress: Even if the goal is reached, no wrapped Cheese tokens are sent to any party.  

4.3 Phase III

In this final phase, a start-up or corporate company can give tokens/codes in exchange.

This adds a lot of legal considerations, to define what the tokens represent. As explained, this
could be a share of the company and give voting rights or the ability to receive a dividend. The
tokens could also give the right to buy a product in the future. The smart contract on this stage
can be used as a central place for ICOs/STOs. It would reduce the amount of work companies
have at the moment when going public. Due to the nature of Blockchains and the tokens,
keeping track of ownership becomes easier. The company can simply say that everyone who
has a token has certain rights, without having to worry that tokens get created without having
paid for it or other types of fraud.