fundraising dao protocol and ecosystem · fundraising dao protocol and ecosystem ... withdrawal...

The Daox Protocol and Ecosystem

Created: October 5, 2017

Last updated: Aug 16, 2018 www.daox.org

ABSTRACT Blockchain technology and the new crypto economy offered tremendous opportunities for investing and raising funds. As an outcome, we saw a skyrocketing growth of Initial Coin Offerings (ICOs) as the first widespread form of blockchain based investing. However, its current implementation (as crowdfunding, ICOs, or in other forms) has a number of problems which resulted in the uncertainty among the community, regulatory issues, uprising number of scams, speculative nature of “utility” tokens, and as a matter of fact, the majority of ICOs are simply created to raise funds. The reason for that is that the general public, with little or no previous experience in investing, got access to thousands of investment offers. Most people are simply not aware of how to evaluate startups and often become victims of ambitious promises or even scams. Many experts expect at least 97% of all ICO startups to fail within the next couple of years.

1


These and other problems are constraining factors for the vast amount of projects and investors that could participate in a new cryptoeconomy and significantly boost it. While regulatory work is definitely needed here, we believe that we should solve the problems with blockchain technology itself, while also keeping blockchain based investing transparent and completely open for everyone in the world, as it meant to be. This is why Daox is proposing an advanced open-source technological solution and a unified protocol that aims to fix all these problems, preserving the benefits of crypto, raising the efficiency of capital and establishing the basis for the future investment industry. The Daox Protocol allows for deploying Decentralized Autonomous Fundraising Organizations or Fundraising DAOs on the Ethereum blockchain network.

Comparison of Fundraising DAOs vs other forms of investing Fundraising DAO is an Ethereum based modular application that combines all the best practices of VCs, crowdfunding, and ICOs. It is aimed at becoming a gold standard for all kinds of token sales. While the core of the Daox

2


Protocol was ultimately developed by the Daox core team, the further control over this protocol will be passed to the community.

Basic Terms

(a) Ethereum smart contracts: a contract in the sense of Solidity is a

collection of code (its functions) and data (its state) that reside at a specific address on the Ethereum blockchain.

(b) Decentralized Autonomous Organization (DAO): an organization

that is run through rules encoded as computer programs called smart contracts.

(c) Daox-based organization, Fundraising DAO: a DAO on the

Ethereum blockchain, created using The Daox Protocol.

(d) Daox Network: a service available at daox.network that is an interface for interaction with the Daox-based organizations.

(e) Investor: a person who has transferred funds to a Daox-based

organization. An investor is identified by his address on the Ethereum blockchain.

(f) Tokens of Fundraising DAO: tokens distributed and transferred to

the Ethereum address that has transferred funds to a Daox-based organization.

(g) The executive team: project initiators who have created a Daox-based

organization. Project initiators are identified by their address or multiple addresses on the Ethereum blockchain.

3


Table of Contents Basic Terms 3

1. The Protocol 6 1.1 Vision 6 1.2 How it Works 8

1.2.1 Token sale using the Daox Protocol 9 1.2.2 Withdrawing Funds 10 1.2.3 Refund to Investors 11

1.3 Daox Ecosystem 12 1.4 What Problems are Solved by Daox 14

2. Motivation 17 2.1 Why Blockchain 17 2.2 Why Ethereum 18 2.3 Why DAO 18

2.3.1 Advantages for Investors 19 2.3.2 Advantages for Startups 20

3. Brief Market Overview 22

4. Daox Network 24 4.1. Additional Features 31

4.1.1 Daox Integrated Affiliate Network 31 4.1.2 Know Your Customer Service 34 4.1.3 Automated Legal Service 35

5. The Wallet App 37 5.1 Purpose of The Wallet App Introduction 37 5.2 Key Features 37

6. Daox Roadmap 39

7. The DXC Token 42 7.1 Uses of the DXC Token 42 7.2 DXC Token Technical Features 43 7.3 Legal Aspect of the DXC Token 44

4


7.4 DXC Decentralized Token Generation Event (or DAICO) 44 7.5 DXC Token Metrics 46

8. The Founding Team and Advisors 47

9. Software Overview 57 9.1 Components 57 9.2 Smart Contracts Overview 57

9.2.2 Initialization of DAO’s special parameters 60 DAO modules 60 Technical Parameters 61 Crowdsale variables 63

9.2.3 Crowdsale 65 Participating with Ether 65 Participating by means of DXCs 69 Crowdsale completion 71

9.2.4 Votings 73 Voting 77 Regular 80 Withdrawal 82 Refund 85 Module 88

10. The Bottomline 92

Legal Disclaimer 93

5


1. The Protocol The Daox Protocol is the new standard for all kinds of token sales that allows investors and startups deploy and interact via independent decentralized autonomous organizations (DAOs), enabling safety, efficiency, and decentralized decision making.

1.1 Vision

Daox is proposing an advanced open-source technological solution and a unified protocol that is aimed at fixing the major problems related to token sales and crowdfunding. The Protocol allows for the deploying of decentralized autonomous fundraising organizations (Fundraising DAOs) on the Ethereum blockchain. These DAOs play the role of advanced intermediaries between startups and their investors, protecting interests of both sides and increasing the efficiency of the capital. They are like real world companies but instead of a legal body they have smart-contracts, instead of bank accounts they use cryptocurrencies, instead of shares there are tokens, and instead of the jurisdiction — a borderless blockchain network. The features of each DAO could differ, but the major goal is to motivate all parties to do its best for the project success. One of the main principles of the protocol is that all the raised funds are stored in a DAO, instead of being at the disposal of a single individual (or group of individuals). The funds are released based on withdrawal proposals submitted by the startup team. If investors (token holders) of the startup find such proposals reasonable, they approve such requests.

6


However, if the majority of investors do not see that the startup stick to its declared roadmap and obligations, they can simply vote for the refund. This functionality alone solves some of the major problems of token sales and crowdfunding. Not only we can get rid of scams because it is simply becoming unprofitable, but we also increase the success ratio due to the fact that the startup’s team is way more motivated. The Daox Protocol is basically replicating the way joint-stock companies work, while also preserving all the benefits of crypto. Each Fundraising DAO created using the Daox Protocol is modular. Which means that its governance structure and functionality might be adjusted to the specific needs of different projects. For example, authors could set up a simple DAICO issuing utility tokens, or create an organization that will pay dividends, or even offer equity-based tokens. Imagine, building a DAO of blocks that are representing different features and functionality. All DAOs are entirely independent, including from Daox developers. All procedures related to the deployment of DAOs, token release, transfers, and the return of funds are based on the Ethereum smart-contracts and therefore could not be changed or removed. Neither the team of Daox developers nor any third parties have access to the collected funds that are stored in DAOs. In the same respect, no one can affect the predefined operating rules of any Daox-based organization except for its token holders. The source code of the Daox protocol is open and available for review and code contributions.

7


1.2 How it Works

This section describes the concept of the Daox Protocol. Technical description, including detailed review of the source code can be found in the section 9.2 of this document. Each project in the Daox ecosystem is launched in the following steps:

A. ICOs and crowdfunding campaigns are easily launched using the Daox Protocol.

B. Each campaign then forms an Ethereum-based Fundraising DAO featuring its own ERC20 token.

C. Each DAO holds the raised funds and is managed by the transparent voting of its token holders.

Figure 1: Fundraising DAO concept

Each startup and its investors establish their own Fundraising DAO and receive its tokens. Right after the DAO is formed, the governance procedures are accessible via any Ethereum client or the Daox Network.

8


1.2.1 Token sale using the Daox Protocol Each genuine Fundraising DAO could only be deployed using the Crowdsale DAO Factory smart-contract on the Ethereum blockchain. In this way it is guaranteed that the operating rules of the DAO remained unchanged. The deployment could be done either via the Daox Network in a user-friendly interface, or independently via any Ethereum client. Right after the DAO is created, its author receives its address on the Ethereum Blockchain. From that point on, the newly created DAO is completely independent and governed according to its rules. If the project was created using the Daox Network, the user also receives a unique webpage address on daox.org. In return for funds transferred to the Ethereum address, the DAO transfers its tokens to the sender. Those tokens meet the ERC20 standard and can be immediately transferred to other addresses or be listed on cryptocurrency exchanges.

Figure 2: Creating a DAO

9


Project initiators can assign a percentage of the total amount of tokens to the team members, advisors, bounty pool, etc. It is also possible to set up a lock-up or vesting period for the tokens issued during the establishment of a DAO. The crowdsale continues until the end date of campaign or the hard cap is reached. If the predefined minimum (soft cap) is not reached to the crowdsale end date, the DAO automatically returns all the funds back to its contributors.

1.2.2 Withdrawing Funds The executive team requests withdrawals, and investors decide whether to approve or decline them. Each such request consists of the amount of funds to be transferred, the voting time frame, the receiving Ethereum address, and a hash code of the inquiry text. In case the request is approved by more than 50% of all tokens participated in a voting, the funds will be automatically transferred to the specified Ethereum address.

Figure 3: Withdrawing funds from DAO

To avoid the reuse of tokens in a single inquiry, the tokens are frozen until the end of the voting. The frozen tokens do not lose their properties, except for the ability to be transferred to other Ethereum addresses.

10


1.2.3 Refund to Investors Every token holder can submit a proposal for activating the refund mode. Such a proposal should be approved by 90% of all the tokens, excluding the number of tokens distributed when the DAO was established.

Figure 4: Refund to Investors If the voting is successful, the DAO is switched to the refund mode. The exchange is carried out proportionally to the number of tokens or the amount of contributions. The DAO also automatically switches to the refund mode if no withdrawals were approved within the period of 3 months.

11


1.3 Daox Ecosystem

Right after the Daox and DXC token smart-contracts are deployed on the Ethereum blockchain, a completely independent and autonomous ecosystem is formed. Each DAO created using the Daox Protocol becomes a part of this ecosystem, that consists of investors, startups, developers, and third-party services integrated via the Daox Open API. The services and tools represented on the Daox Network (e.g. Integrated Affiliate Network) are third-party services, that participants of the ecosystem could optionally resort to. There is a marketplace for such services on the Daox.Network. Imagine hundreds of services for startups and investors that are easily accessible in a few clicks and also transparently rated by the community. For instance, a project can apply for rating report, or media publishing, or bounty campaign, or start banner advertising, right from the Daox Platform interface. An example of such service is bounty.daox.org So, on the one side there are investors and startups and on the other there are service providers, while DXC Token is powering interaction between them.

12


Figure 5: Daox Ecosystem Overview

13


1.4 What Problems are Solved by Daox

The Daox Protocol and Daox Ecosystem is solving most of the major problems related to token sales and crowdfunding for both sides: investors and startup teams. Scams Problem: The easiness of launching an ICO and high level of anonymity in crypto is making a lot of space for scams. Solution: Token holders of the project can vote for the return of the remaining funds if the project turns out to be a scam. Low motivated founders Problem: When the startup team receives the total amount of funding at once, their motivation decreases dramatically. Solution: The startup team is highly motivated to succeed to keep getting financing for their project. Value of tokens Problem: Tokens of early-stage startups are not backed by any assets other than the team’s obligations. Solution: Tokens are backed by the raised funds that reside in a DAO, as token holders can get a refund. Misuse of funds Problem: Investors can’t see the purposes of expenditures. This opens a lot of space for misuse of funds.

14


Solution: The startup team has to submit proposals indicating the purposes of withdrawal. Frequent failures Problem: Experts expect that 97% of all ICO startups will fail within the next few years. In 2018, only 1 out of 5 projects makes it to exchanges. Solution: Due to many improvements in the way token sales are conducted, it is expected that the success ratio will be at least 4x higher. Lack of transparency Problem: Because of the lack of a unified standard for token sales, investors cannot verify how tokens are distributed. Solution: With a unified standard token sale contributors can easily see how many tokens are distributed in exchange for crypto and what discounts are given. Highly competitive environment Problem: There are thousands of ICOs and founders has to have big marketing budget to stand out. Solution: Since the risks for investors are lower, it is easier to attract sufficient attention even without marketing spendings. Complexity of technology Problem: Each startup has to either resort to expensive third-party token sale solutions, or spend time and resources to make their own. Solution: Daox Protocol is an open source and zero commission framework that doesn’t even require any special knowledge to run an ICO.

15


Hacker attacks Problem: Every noticeable token sale attracts a lot of attention of hackers looking to steal the raised crypto. Solution: All the raised funds reside in a DAO that is being managed by the transparent voting of token holders. Inefficient ICO marketing Problem: Each startup has to resort to hundreds of different services, not being able to assess the effectiveness of each of them. Solution: Each startup becomes part of the ecosystem which allows access to solutions and services using the DXC token. Excessive time input Problem: Instead of working on the product, the whole startup team spends about 6 months to conduct the token sale. Solution: With the ready-made solution and the whole ecosystem of services and tools, token sales are made easy.

16


2. Motivation This section briefly describes the grounds for decision-making, while developing and planning Daox.

2.1 Why Blockchain

Blockchain technology completes a variety of tasks that would either be done with a significant loss of efficiency or would not be able to be implemented at all. Shown below is a list of the main Daox features that could not function without the use of blockchain:

(a) Use of cryptocurrencies: one of the principal goals for Daox is to simplify the process of attracting and distributing the funds in crowdfunding, when neither borders nor jurisdictions matter. This would be impossible to implement through traditional financial institutions.

(b) Absolute independence: in order to reach the required level of

credibility towards the new ecosystem, the complete elimination of an intermediary between investors and project authors is required. This became possible only with the use of blockchain, which in this case serves as an unconditional warranty that the rules described in the source code will be complied with and will not be modified.

(c) Transparent voting: when it comes to centrally-controlled systems,

there is always a possibility of administrative interventions. Due to all the services and data of Daox being in a decentralized blockchain network, the potential influence of administrative resources is

17


eliminated, which means total credibility can be reached for the process of voting.

(d) Unstoppable app: when placing funds in any kind of a system, users

expect this system to be highly reliable. Since Daox is entirely on the blockchain, there is no threat that its work will be stopped. This kind of an application is also called the “Unstoppable app”.

(e) Hard-and-fast rules: in order to implement the ideas of crowdfunding

that are being proposed by Daox, it is essential to follow the predetermined rules closely. That is why the source code for Daox smart contracts is open and described in details, and since the code is placed in the blockchain network, it guarantees its invariability.

These are the 5 main objectives that the Daox team accomplishes by means of the blockchain technology. In addition, the use of the blockchain allows for the improvement in efficiency of the other features related to the performance of the ecosystem (for instance, Integrated Affiliate Network).

2.2 Why Ethereum

Currently, that platform is the most widespread for raising funds and running dApps. Additionally, the blockchain-space of that network has a high degree of credibility.

2.3 Why DAO

The DAO approach to fundraising appears to be the most transparent and fair method of using the collected funds. This approach had never been possible before the blockchain and cryptocurrencies became widespread, due to the lack of technical opportunity to establish transparent voting and the secure storage of funds.

18


The DAO concept serves as an absolute and unbiased guarantee, promising that the interests of both parties will be respected, as well as serving as the intermediary. It is important to notice that when designing rules for Daox organizations, the interests of both parties were taken into account in equal measure, investors and project authors alike. Some of the main positive aspects of applying that approach are given below.

2.3.1 Advantages for Investors

(a) Safety: all the proceeds raised and stored following the principles of Daox are protected from misuse and unauthorized withdrawal. The finances are securely stored in Ethereum smart contracts and could only be used on project development. Therefore, scams and any other fraudulent activity are almost completely eliminated.

(b) Value of Tokens: the funds raised via Daox principles are kept at

investors’ disposition; the way they are managed further on is determined by voting. Therefore, even upon transferring funds to the project, the investor owns an asset as the digital share of a DAO (a token).

(c) Project team is motivated: when the startup team does not receive all

the funds at once, but rather gets tranches as work proceeds, the level of motivation rises significantly. This in turn increases the chances of success of the startup. This is one of the reasons why the funds are being transferred as tranches when it comes to traditional forms of investment, and it is indeed needed to be implemented in crowdfunding and ICOs.

19


(d) Transparency: project initiators may get funds gradually by publishing proposals, whereby this procedure can only take place when approved by the majority of investors.

(e) Lowering the risks: according to Daox principles, each Daox-based

organization has a functionality to return investments, if the investors decide that the founding members fail to achieve the assigned goals.

2.3.2 Advantages for Startups

(a) Ready-made solution: by using a simple step-by-step interface a startup is able to launch its crowdfunding campaign and tokens. No programming or other skills are required.

(b) Investors’ heightened interest: attracting funds according to Daox

principles confirms the team’s intentions to achieve success rather than collect funds. This has a positive impact on fundraising process, since the team gets more credibility.

(c) Engagement in the daox.org community: investors follow updates

on new projects, which appear on the daox.org platform. Project initiators may get a prompt reaction from the community, right after their campaign is launched.

(d) Independence: each project can use Daox smart contracts regardless of

daox.org platform or any other service, and it is possible to attract funds through any source.

(e) Safety: all the funds are securely stored in an independent organization

on the Ethereum blockchain. That is why it is impossible to steal them or get them in any other illegal way.

20


(f) Transparency for team members: the DAO concept solves the problem of trust among the team members. This is due to the following factors. First, all members get the amount of tokens (their share of a startup) known beforehand, and second, for each member the proceeds are being applied in a transparent way and do not belong to a single person.

21


3. Brief Market Overview In the year 2017, the volume of venture capital investment in Europe, Canada, China, India, Israel, Japan and the USA amounted approximately to 161 billion US dollars. The crowdfunding market is estimated at $50 billion (excluding p2p lending). Around $6.7 billion was raised by means of ICOs.

Figure 6: venture capital investment market according to Dow Jones, from 2015 to 2018 Figure 7: crowdfunding market according to TechNavio (excluding p2p lending), from 2015 to 2018

22


ICOs are notable for the biggest rate of growth: in comparison with the year 2016, the amount of funds raised by means of this tool has increased twenty-fold. What is more, 2018 is expected to see almost three-fold growth.

Figure 8: forecast for the ICO market in 2018

23


4. Daox Network Daox Network is a group of software that allows for the interaction with the Daox Protocol and Daox ecosystem through a simple and user-friendly interface. The whole process of deploying DAOs and interacting with them is done in a user-friendly application called Daox Network (https://daox.network/). Startups can build their DAOs, with their own ERC20 tokens and start ICOs in a matter of minutes. Besides that, there is a marketplace of services and tools that are integrated via the Daox Open API. Imagine hundreds of different services for startups and investors that are easily accessible in a few clicks. For instance, a project can apply for rating report, or media publishing, or bounty campaign, or start banner advertising, right from the Daox Network interface. In addition, Daox Network is a tool for the interaction between project authors, investors, developers and service providers. The Daox Network is compatible with any up-to-date mobile or desktop browser. Shown below are the main features implemented on the Network that are already available:

- Registration and user profile - Creation of a DAO - Settings and launch of a fundraising campaign - Creation and distribution of tokens - Review of a fundraising campaign and a DAO - Purchasing DAO tokens with Ether (ETH) - Purchasing DAO tokens with DXC tokens - Negotiation of requests and consideration of projects

24

https://platform.daox.org/


- Proposals (withdrawal requests, other types of proposals) - Review, discussion, and participation in a proposal - Integration of services and widgets via the Daox Open API - Interaction with features of the DXC token - Generation of Ethereum addresses for users - Storage of tokens and ether

25


Figure 9: screenshot of the first step in

creating a DAO

26


Figure 10: screenshot of the project’s

overview

27


Figure 11: screenshot of the process of

creation of a proposal

28


Figure 12: screenshot of the funds

withdrawal request

29


Figure 13: Screenshot of the

proposal/voting discussion

30


4.1. Additional Features

This section describes implementation of the main tools that are already released or being prepared to be released by the community and developers of Daox. The Daox ecosystem is entirely open, which is why any developer or service provider can integrate their services to the Daox Network (c. 4). Additional features are introduced in order to simplify the process of holding the campaign, as well as to improve overall efficiency for the users of the ecosystem.

4.1.1 Daox Integrated Affiliate Network Any project launched on the Daox Network can participate in the Daox Integrated Affiliate Network. How it Works When a crowdfunding campaign is launched on the platform, project initiators can activate their participation in the Integrated Affiliate Network. This network operates according to the Cost Per Sale (CPS) principle. The core of that principle is that a party advertising a product (a publisher), gets a reward from an advertiser (a crowdfunding campaign in this case) in case the advertisement leads to a purchase. Sales are being tracked owing to the fact that publishers are given a unique link containing their tracking number. After a visitor follows the link, the system will bind this visitor to a specific publisher. In case the visitor supports the campaign (purchases tokens of the project), the publisher gets a fixed percentage as remuneration.

31


Operating Peculiarities It is obvious that it might take more than one session for the visitor to decide whether to purchase tokens or not, as it might take a considerable amount of time to get acquainted with the project data. That is why the Post Click period is provided, which amounts to 90 days for all campaigns. This way, information about the visitor is stored in the system, and even if the sale takes place in a month, the publisher still gets rewarded. However, when it comes to affiliate networks, there is a common issue, when the same user is led through different sources by two or more publishers at different times. As a result of this, the Integrated Affiliate Network has a Last Click Wins rule, according to which compensation goes to the publisher who owns the link that the user followed for the last time. Campaign Launch It only takes 2 steps to launch an advertising campaign in the Integrated Affiliate Network:

1. Authors of the campaign set a payout for each sale.

2. Authors of the campaign are transferring DXC tokens on a special Ethereum contract, which will make payments to the publishers. Payments between publishers and advertisers could only be made by means of the DXC token.

After funds are transferred to the deposit contract, the advertising campaign is enlisted in a catalogue and becomes available for all the users of the platform. From then onward, any registered user can get his own unique tracking link and start earning referral rewards, providing advertisement and sales for a crowdfunding campaign.

32


In case all the funds on the deposit of the campaign are spent, project participation in the Integrated Affiliate Network will be suspended and publishers will get corresponding notifications. Publishers Each member of the Daox ecosystem can become a publisher in the IAN. Each IAN publisher gets access to a catalogue of currently available offers, detailed statistics, and information on payments. Payments are made upon request and transferred to the Ethereum address that is specified in the profile. For the projects to participate in the Integrated Affiliate Network, a commission fee of 5% of a publisher’s reward is charged. Let us consider how it works by the following example:

1. Project authors set remuneration at 10% from the token sale.

2. The investor following the tracking link purchased tokens for a total amount of 1 ETH.

3. A publisher gets a reward in DXC tokens. The amount of the reward is equivalent to 0.1 ETH in this case.

4. DXC tokens equivalent to 0.105 ETH are taken off the project's deposit.

Commission is necessary to maintain the support desk and quality assurance service. Neither of these services is able to change the way the affiliate network operates or influence its terms, but their main goal is to ultimately improve the experience for both parties.

33


The Bottomline Owing to the Integrated Affiliate Network, marketing objectives are addressed in a simple and accessible way. Now, project founders can focus entirely on a product quality and feel confident about the marketing of their crowdfunding campaign. At the same time, enthusiasts and experts from across the globe can easily start making profits by promoting projects they like.

4.1.2 Know Your Customer Service The Know Your Client (KYC) functionality is being implemented on the Daox Network. Each project can activate this mode and select the degree of verification. This procedure is required for the identification of investors who participate in the crowdfunding campaigns. If a team of a project launched on the daox.org platform would prefer to have KYC procedures activated, they can either resort to an in-built KYC service or use any other service available, as they wish. How it Works In case the KYC service is activated in the settings of the crowdfunding campaign, the Ethereum contract will only apply funds from the confirmed addresses. When transferring the funds right before the address is displayed, the potential investor will be notified about the prerequisite of undergoing the KYC procedure. The system will require the necessary data, and soon the investor’s account will be verified. All the data collected during the verification process is available in the personal account of the project authors in encrypted form. Thus, a one-time decipher key is given when the KYC mode is activated. This key is never stored on Daox servers. Therefore, data leakage is entirely excluded.

34


Provided that the funds are transferred to an Ethereum address of the crowdfunding campaign from an unverified address, they will be automatically returned to the sender (in case the KYC is activated). Price of the Service For the service to operate, the project initiators are adding to the deposit by transferring DXC tokens to the Ethereum contract. Each verification charges a fee; the charge rate is set when the KYC mode is being activated for each crowdfunding campaign individually. The KYC service fees can only be paid using DXC tokens.

4.1.3 Automated Legal Service The project team will need the standard set of documents while running the crowdfunding campaign, for example Terms and Conditions. Although it is advised to reach out to a competent person to draft such papers, the Daox ecosystem will have an automated service for that. How it Works Authors of the crowdfunding campaign will be offered to select a list of the required documents in a special section of their personal accounts, upon which they will fill out a form in a user-friendly interface. After that, the Legal Service will automatically generate the required documents, which will be available for downloading. The list of available documents and their quality are subject to a process of continual improvement and modification.

35


Price of the Service This service is offered to all DXC token holders and members of the Daox ecosystem at no additional costs; however, it does not provide any guarantees.

36


5. The Wallet App The Daox Wallet is an app, that allows users to interact with the Daox-based organizations, trade tokens, and buy DXCs by means of a simplified interface. The main goal of this tool is to make crowdfunding via cryptocurrencies widely available, simple, and popular among general public.

5.1 Purpose of The Wallet App Introduction

Despite obvious advantages of the crypto economy, there is an issue of low usership of cryptocurrencies in the society. As was mentioned earlier, one of the principle goals for Daox is to encourage non-blockchain projects to raise funds using cryptocurrencies. However, it becomes obvious that if a project is not related either to a crypto economy or the blockchain technology, then cryptocurrencies are uncommon among the target audience of its backers. A user-friendly app The Daox Wallet is created in order to address that issue. The goal for the app is to create a seamless tool for all users, including those who had no previous experience with cryptocurrencies.

5.2 Key Features

The key features of The Wallet include a possibility to interact with Daox-based organizations and purchase DXC tokens that are used to participate in crowdfunding campaigns.

37


Authors of the crowdfunding campaign see no difference as to whether it should be transferred through the Ethereum wallet, daox.org or The Wallet app. In either case, the project receives cryptocurrency from a user of an Ethereum address. At the same time, the user of The Wallet app sees the whole procedure in a much simpler way. Firstly, it is as easy to register in the app as it is in any messenger. Secondly, the user will have a possibility to purchase DXCs through the app; consequently, it will become possible to participate in the crowdfunding campaign by means of fiat money. This way, a crowdfunding campaign gets all the benefits of the new crypto economy while maintaining the simplicity of participation for its backers, which is as easy as on traditional crowdfunding platforms, such as Kickstarter. Considering all this, The Daox Wallet will become a seamless portal to crypto economy and crowdfunding for the average user. This is a tool that enables anyone to invest, for example, $1 dollar in a project, from any part of the world and get a tokenized share. And the whole procedure is as simple as sending a message. In turn, project initiators will get an opportunity to attract backers and investors, while being sure that the interaction with their crowdfunding campaign is made to be as simple as possible for users; therefore, they would have a high conversion ratio.

38


6. Daox Roadmap

39


40


41


7. The DXC Token The DXC token (Daox coin) will be released right after the public launch of the Daox Network, and it will be for sale during the Decentralized Token Generation Event (cf. 7.4).

7.1 Uses of the DXC Token

DXC is the native token of the Fundraising DAO Protocol, Daox Ecosystem and Platform. It is an ERC20 utility token that is aimed to fuel the economy around the protocol and ideas of fair and open blockchain based investing of the future.

(a) Functional Part of Fundraising DAO Protocol Each Fundraising DAO could only be deployed by using some amount of DXCs that will form the initial account of a DAO. This account is used to set variables and to connect functional modules or services that are being introduced by third-party developers. This is how the growing community of developers is incentivised to contribute code to the Fundraising DAO protocol in a completely decentralized way.

(b) Daox Marketplace for ICOs and Investors There is a marketplace of services and tools that are integrated via the Daox Open API. Imagine hundreds of services for startups and investors that are easily accessible in a few clicks and also transparently rated by the community. For instance, a project can apply for rating report, or media publishing, or bounty campaign, or start banner advertising, right from the Daox Network interface. An example of such service is bounty.daox.org.

42

https://bounty.daox.org/


(c) Daox Network and Wallet App The DXC token is used to get access to the services provided on the Daox Network. Although the Daox Network does not charge any commission from the projects or investors, it offers different promotional services, such as, featuring projects, targeted ads, email lists, support, etc. Besides that, DXC token is the main token of the Daox Wallet app that is aimed to take crypto funding mainstream.

(d) Early Participation in ICOs 2.0 The DXC token is the only token that is used to participate in the limited Initial Tokensale Stage of Fundraising DAOs. The funds raised during this stage are held on a separate account and are accessible for the project team immediately and without withdrawal requests. However, this funds could only be transferred to the integrated service providers. Thus, the majority of Fundraising DAOs will run DXC-presale stage to fund their ICO campaigns. Consequently, DXC token holders will get the priority access to the ICOs based on Fundraising DAO protocol.

7.2 DXC Token Technical Features

The token is ERC20 compatible and has a number of additional features:

(a) Features that enables for the interaction between users, third-party services and service providers (Daox Open API). For this, the code of the DXC implements functions that allow to automate the exchange of the DXC tokens for access to services.

(b) Features that enables for the use of DXCs as a tool to participate in

DAOs that are created within Daox smart-contracts.

43


7.3 Legal Aspect of the DXC Token

DXC tokens are neither currency, valuable security nor currency swap, security swap or any other financial instrument. DXC does not grant any rights to manage the Daox developer company or any subsidiary Daox companies. DXC tokens do not entitle investors to derive profits or receive dividends from the business of the Daox company. The DXC token is used solely for the interaction with the elements of the Daox ecosystem and as a means of access to the platform services; consequently, it is a Utility token. This being the case, DXC tokens are not and cannot be deemed as securities, and they are not registered in any government enterprise as securities and should not be regarded as such.

7.4 DXC Decentralized Token Generation Event (or DAICO)

In accordance with the concept and ideas of fair crowdfunding that is being proposed by the Daox project itself, the total amount of cryptocurrency raised during the Decentralized TGE will be placed in a decentralized autonomous organization, established on the daox.org platform. Consequently, DXC token holders will be able to control expenditures, hence the risks will be almost entirely eliminated. If the majority of DXC token holders are not happy with the way the project unfolds, they can vote for a full refund of the remaining proceeds.

44


All the tokens that will not be distributed during the Token Generation Event will be burnt.

SOFT CAP 3000 ETH

HARD CAP 20 000 ETH

TOTAL SUPPLY 150M DXC

DELIVERY DATE Immediately after purchase

Tokens will be transferred without delays or a lock-up period. The DXC Token generation event would be conducted starting from September 5th, 2018. During this time period, DXC tokens would be transferred in exchange for fiat money to the bank account and Ether to the Ethereum address of the DAO created on the Daox Network. The sale is not limited by a minimum threshold and is accessible for anyone in accordance with the laws of country of residence.

45


7.5 DXC Token Metrics

46


8. The Founding Team and Advisors

Alex Kuvaytsev Project Lead Startup entrepreneur with more than 10-years experience. Background in IT business, management and consulting different projects. Keen on innovation, blockchain and fintech. Master’s degree in financial management. MBA from Hult International Business School, San-Francisco, CA. https://www.linkedin.com/in/alexkuv/ Jordan Pool Media Director Jordan brings a lengthy background in live television, digital media production and creative marketing to the team. He understands the importance of digital media marketing and is excited to creatively communicate the value and vision of Daox to the world. https://www.linkedin.com/in/jordan-pool-8475738/

47

https://www.linkedin.com/in/alexkuv/

https://www.linkedin.com/in/jordan-pool-8475738/

https://www.linkedin.com/in/jordan-pool-8475738/


Alex Shevlyakov Product Lead More than 12 years of experience in developing tech products. Formerly a product lead for dozens of products, each with excellent quality. Passionate about perfect design and usability. Master’s degree in computer science. http://www.linkedin.com/in/ashevlyakov https://t.me/sanchosrancho Enju Lu (呂恩汝) Asian Markets PR More than 7 years of experience in sales at an international marketing and trading company. Master’s degree in journalism. Specialist in Public Relation, Linguistics, International Marketing. https://www.linkedin.com/in/enju-lu-76a001b6/

48

http://www.linkedin.com/in/ashevlyakov

https://t.me/sanchosrancho

https://www.linkedin.com/in/enju-lu-76a001b6/


Anton Vityazev Tech Lead More than 5 years in web development. High-load and complex systems architect. Blockchain expert. Master's degree in cybersecurity. https://www.linkedin.com/in/anton-vityazev/ https://t.me/giddeon

Kirill Bulgakov Smart Contracts Developer Backend and smart contracts developer, inspired by dApps and blockchain technology. Natural language processing researcher and ML developer in the past. https://www.linkedin.com/in/bulgakovk/ https://t.me/bulgakovk Oleg Adamov Mobile Developer Experienced mobile engineer with more than 10 years in programming. Participated in the development of a product with a multi-million user base. Master’s degree in Mathematics. https://www.linkedin.com/in/oleg-adamov

49

https://www.linkedin.com/in/anton-vityazev/

https://t.me/giddeon

https://www.linkedin.com/in/bulgakovk/

https://t.me/bulgakovk

https://www.linkedin.com/in/oleg-adamov


Kevin Kimick Marketing Strategist Serial entrepreneur, growth marketer and digital strategist. CEO and co-founder of SOHO Digital — a company that builds custom software (including blockchain development), designs & builds premium websites, strategizes growth marketing plans, and provides marketing analytics and automation services. Bachelor’s degree in business administration and management from Baruch College, City University of New York (CUNY). https://www.linkedin.com/in/kevinkimick/ Artyom Molchanov Data Scientist / AI Researcher Artyom's background is Data Science and AI research. He has developed various AI-based solutions for Russia's largest bank, Sberbank. Artyom will be a tech lead for data related technologies in Daox. He has a Bachelor's degree in Computer Software Engineering. https://www.linkedin.com/in/artyom-molchanov-220310123/

50

https://www.linkedin.com/in/kevinkimick/

https://www.linkedin.com/in/artyom-molchanov-220310123/

https://www.linkedin.com/in/artyom-molchanov-220310123/


Gleb Plotnikov UI/UX Designer Founder of Yutani (a Belarus-based design firm). More than 10 years’ experience in design and UX. Have developed UI/UX for hundreds of amazing projects, including well-known brands. https://www.linkedin.com/in/platva1/ https://www.facebook.com/platva1 Nina Mikhailenko Community Manager Work experience as a project coordinator, community manager and translator at different conferences and workshops. Master’s degree in Linguistics, study program in the University of Tromsø, Fulbright program in the USA. https://www.linkedin.com/in/nina-mikhailenko-66528284/

51

https://www.linkedin.com/in/platva1/

https://www.facebook.com/platva1

https://www.linkedin.com/in/nina-mikhailenko-66528284/

https://www.linkedin.com/in/nina-mikhailenko-66528284/


Natalie Dudkina Key Partnership Manager Over 10 years experience in development of the work streams with KEY customers and clients in various economic domains. Negotiation of cooperation and contract terms with compliance of the company’s policy, ethics and interests. Three degrees: Management, Economist, Philologist. https://www.linkedin.com/in/natalie-dudkina-72452755/ https://t.me/tuskapuska

Elena Novozhilova Key Partnership Manager During the last 8 years, Elena held executive positions in e-commerce and advertising companies worldwide. Elena is responsible for partnership development and business event management at Daox. Master's degree in management. https://www.linkedin.com/in/lena-novojilova

52

https://www.linkedin.com/in/natalie-dudkina-72452755/

https://www.linkedin.com/in/natalie-dudkina-72452755/

https://t.me/tuskapuska

https://www.linkedin.com/in/lena-novojilova


Oleg Gaidul Founder Serial entrepreneur and investor. Founder of Spacemind Capital, EnventVR, AD1, and other successful startups with a yearly turnover of more than $50M. Tech visionary and a fan of decentralization. Besides of more than 12 years of managing experience, he is also a tech guy and a former software developer. Master’s degree in management. https://www.linkedin.com/in/oleg-gaidul/ https://facebook.com/oleg.gaidul https://t.me/gaidul Keith Teare Adviser Executive Chair at Accelerated Digital Ventures. A leading figure past and present in many important companies, including Archimedes Labs, Minds and Machines Inc, MedCo, EasyNet and RealNames to name just a small few. Keith is also one of the co-founders of Techcrunch. https://www.linkedin.com/in/kteare

53

https://www.linkedin.com/in/oleg-gaidul/

https://facebook.com/oleg.gaidul

https://t.me/gaidul

https://www.linkedin.com/in/kteare


George Kimionis Adviser Serial entrepreneur and investor with multiple founded companies and multiple exits. More than 15 years of working experience in Fintech and Banking. CEO of Coinomi, the industry's leading multi-asset wallet with native support for more than 500 assets and millions of users. CEO of Cryptean. Crypto-currencies enthusiast. Special Forces Veteran. Strong technical background. Early adopter and contributor in Bitcoin and other open-source projects. https://www.linkedin.com/in/kimionis/ https://twitter.com/kimionis Andrea Brignone Adviser Andrea has vast experience in financial markets and cybersecurity. He is an author of almost 200 articles on finance and computer science. During his career, Andrea co-founded noticeable companies and cometees: European Financial Marketing Association (EFMA), Milipol, Protexarms Group. He is also a former chairman of Special Interest Group for Information Security of the European Community.

54

https://www.linkedin.com/in/kimionis/

https://twitter.com/kimionis


Mihai Milea Adviser Over 10 years of experience in global Forex & CFD brokerages, holding various strategic positions in Technology and Digital Marketing. Directly involved in the delivery of innovative projects within the brokerage space and achieving a positive ROI. Expert in mining cryptocurrencies and an avid crypto investor. Msc in Cybersecurity. https://www.linkedin.com/in/mihai-milea-1ab17793/ Kyle Asman Adviser Kyle has extensive experience helping clients raise capital in the finance, banking, regulatory consulting space, and most recently, developed complex international tax structures in the tax advisory space. Kyle has held investment banking regulatory consulting and transfer pricing roles at Liquidity Energy, Duff and Phelps, and Ryan LLC, a global tax firm. He is also a VC investor in multiple startups and co-founder of Bx3 Consulting. https://www.linkedin.com/in/kyleasman/

55

https://www.linkedin.com/in/mihai-milea-1ab17793/

https://www.linkedin.com/in/mihai-milea-1ab17793/

https://www.linkedin.com/in/kyleasman/


Dr. Walter Tonetto Adviser Technopreneur and ASEAN expert. Visiting Professor for the Univ of Tokyo & Waseda. Co-Founder of Indoblockchain.id. Network of Captains of Industry in Indonesia and SE Asia. President SE Asia of Finteix Pte. Singapore. Chief Strategist for Indigen. Advisor to the CCEG, The University of Northampton. Co-Founder of Snapfood. https://www.linkedin.com/in/waltertonetto/

DISCLAIMER: This section is to be updated in the next versions of the document. We have a great advisory team and new amazing team members coming.

56

https://www.linkedin.com/in/waltertonetto/


9. Software Overview This section describes the Daox Network and the Ethereum smart-contracts software and source code that form the basis of the ecosystem. This part does not describe any software or code that is used to carry out the DXC Token generation event (cf. 7.4).

9.1 Components

(a) Daox Ethereum smart contracts: this is a set of contracts that enables the performance of all the services for Daox-based organizations, such as receiving and withdrawing funds, generating tokens, and voting on proposals etc.

(b) Daox Network backend: this is a software stored on the centralized servers that enables the interaction with Daox Ethereum smart contracts in a convenient way.

9.2 Smart Contracts Overview

All smart contracts linked to Daox are open-source and available in the repository under the following link: https://github.com/daox. We know that when using a fundraising platform, it is vitally important to have a complete level of confidence that all the features work properly and comply with the announced concept, and funds are always safe. That is why we not only publish the source code but also offer its detailed description. This part includes a list of major functions and code highlights in order to make the navigation in the code easier when being analysed by tech experts.

57

https://github.com/daox


Everyone can make sure that the code in smart-contracts complies with all the announced features, which are as follows:

(a) Fair and transparent voting (b) Safety of the collected proceeds and lack of access to them by third

parties (c) Refunds functionality (d) Complete independence from the Daox Network or third parties

In this section, by DAO we mean Daox-based organization (a DAO created using Daox smart contracts on the Ethereum blockchain). 9.2.1 Creation of DAO All DAOs are created with a special factory contract that is called CrowdsaleDAOFactory. The factory keeps settings that are constant for all DAOs, which in turn are transferred to each organization when they are being established. For the establishment of new DAOs createCrowdsaleDAO function is used. The source code of this function is given below:

function createCrowdsaleDAO(string _name, string _description) public { address dao = DAODeployer.deployCrowdsaleDAO(_name,

_description, serviceContractAddress, votingFactoryContractAddress);

require(dao.call(bytes4(keccak256("setStateModule(address)")), modules[0]));

require(dao.call(bytes4(keccak256("setPaymentModule(address)")), modules[1]));

require(dao.call(bytes4(keccak256("setVotingDecisionModule(address)")), modules[2]));

require(dao.call(bytes4(keccak256("setCrowdsaleModule(address)")), modules[3]));

58


DAODeployer.transferOwnership(dao, msg.sender);

DAOs[dao] = _name;

CrowdsaleDAOCreated(dao, _name);

}

This function uses the DAODeployer library for uploading an organization with defined parameters to the Ethereum network. The name, description as well as two addresses and transferred as parameters:

1. The Voting Factory address is needed to create proposals in case the crowdsale is successful.

2. The address of the service contract is used to send commissions to the

the platform. An important note: the commission is charged only from payments transferred via the daox.org interface and when using Ether (ETH). No commission is charged from investments made by means of the DXC token.

After that, the addresses of different modules are added to the newly created organization; they will be closely described further on. For different parameters to be assigned correctly in the contract’s storage, a

change of ownership to an address initiating this code is required (most often

this is a special account owned by Daox). As a result of an execution of the

function an individual contract CrowdsaleDAO is created.

59


Figure 14: creation of a DAO

9.2.2 Initialization of DAO’s special parameters

DAO modules Implementation of the DAO’s contract is split up into 4 separate contracts (so called modules), each encapsulating a code that is in charge of certain functionality. Currently modules are divided according to the task in the following way:

1. State — initialization of technical parameters, creation of a commission contract.

2. Crowdsale — initialization of parameters, incoming payments processing, completion of the token generation event.

60


3. Payment — outgoing payments processing, for instance a refund in case of an unsuccessful crowdsale.

4. VotingDecisions — finalizing various proposals by putting into operation the relevant voting decisions.

Most functions in the CrowdsaleDAO in fact are just a proxy “cover”, in other words by means of a delegatecall the module function is called, that changes the storage of the called contract. This architecture is necessary so that a contract fits in the block gas limit, as well as that there is a possibility to “update” the source code if required.

Figure 15: initialization of technical parameters of a DAO

Technical Parameters After the creation of a DAO it is necessary to initialize several internal parameters, as well as to create a commission contract. This is executed by the initState function, that is located in the State module.

61


The source code of the function is given below:

function initState(address _tokenAddress, address _DXC) external onlyOwner(msg.sender) canInit crowdsaleNotStarted {

require(_tokenAddress != 0x0 && _DXC != 0x0);

token = TokenInterface(_tokenAddress);

DXC = TokenInterface(_DXC);

created_at = block.timestamp;

commissionContract = new Commission(this);

canInitStateParameters = false;

State(commissionContract);

}

1. For each organization, the token is created separately, that is why it is

necessary to save its address in the contract’s storage.

2. The DXC address is required for the correct payment processing by this token.

At the end of the function the canInitStateParameters flag sets to false, which in turn guarantees that the variables will be initialized only once. In case the DAO is created via the Daox Network, the initialization of the parameters is called from the service account.

62


Crowdsale variables The initCrowdsaleParameters function of the Crowdsale module is in charge of the crowdsale variables:

function initCrowdsaleParameters(uint _softCap, uint _hardCap, uint _etherRate, uint _DXCRate, uint _startTime, uint _endTime, bool _dxcPayments)

external

onlyOwner(msg.sender) canInit

{

require(_softCap != 0 && _hardCap != 0 && _etherRate != 0 && _DXCRate != 0 && _startTime != 0 && _endTime != 0);

require(_softCap < _hardCap && _startTime >

block.timestamp);

softCap = _softCap * 1 ether; hardCap = _hardCap * 1 ether;

(startTime, endTime) = (_startTime, _endTime);

(dxcPayments, etherRate, DXCRate) = (_dxcPayments,

_etherRate, _DXCRate);

canInitCrowdsaleParameters = false; }

This initialization of parameters takes place only once. Just as it is the case with the previous function, this one is being called from the service account as well if the DAO is created via the Daox Network.

In addition, such functions as initBonuses and setWhiteList could be used for customizing the process of crowdsale. Due to technical reasons, they can not be moved to the module that is in charge of setting up the crowdsale, that is why they are implemented directly in the CrowdsaleDAO contract.

63


The setWhiteList function allows for listing the addresses that the funds could be withdrawn to:

function setWhiteList(address[] _addresses) public onlyOwner(msg.sender) { require(canSetWhiteList);

whiteListArr = _addresses;

for(uint i = 0; i < _addresses.length; i++) { whiteList[_addresses[i]] = true;

}

canSetWhiteList = false;

}

The canSetWhiteList flag provides a one-time function invocation. If a DAO is being created via the Daox Network the invocation will be performed by the service account.

The initBonuses function is meant to determine team members of a DAO, their bonuses (amount of tokens that they will get), time period that the bonus (team) tokens will be locked-up for. It is also used to specify the identificator that indicates whether the withdrawal address is a person or it is an address for service-related objectives (for instance, a fund for the bounty program). Moreover, the function allows for defining token sale periods and the amount of bonuses in each period.

function initBonuses(address[] _team, uint[] tokenPercents, uint[] _bonusPeriods, uint[] _bonusEtherRates, uint[] _bonusDXCRates,

uint[] _teamHold, bool[] service) public onlyOwner(msg.sender) {

require(_team.length == tokenPercents.length && _team.length == _teamHold.length && _team.length == service.length && _bonusPeriods.length == _bonusEtherRates.length &&

(_bonusDXCRates.length == 0 || _bonusPeriods.length == _bonusDXCRates.length) &&

canInitBonuses && (block.timestamp < startTime ||

сanInitCrowdsaleParameters)

64


);

team = _team;

teamHold = _teamHold;

teamBonusesArr = tokenPercents;

teamServiceMember = service;

for(uint i = 0; i < _team.length; i++) { teamMap[_team[i]] = true;

teamBonuses[_team[i]] = tokenPercents[i];

}

bonusPeriods = _bonusPeriods;

bonusEtherRates = _bonusEtherRates;

bonusDXCRates = _bonusDXCRates;

canInitBonuses = false;

}

The function checks whether the params for crowdsale are not set yet or set, but the time of the crowdsale launch has not yet come. This check does not allow to change bonuses at a time when the crowdsale is already in progress. As in the examples above, the canInitBonuses variable does not allow to set the bonuses multiple times.

9.2.3 Crowdsale At a time when the current timestamp becomes greater than the timestamp in the startTime variable, the crowdsale is considered to have begun and it becomes possible to transfer funds to the DAO. It is possible to participate in a crowdsale both with Ether and with the DXC tokens.

Participating with Ether There are two ways one can participate in a crowdsale of a DAO with Ether: by means of a commission contract, which is created when the initState

65


function of the State module is being called, or by transferring funds directly to the address of the DAO’s contract.

Figure 16: transferring funds to a DAO through the commision contract

66


If the funds are transferred via the daox.org service, then the transaction is automatically made by means of a commission contract. The code for such a contract is as follows:

interface IDAOPayable { function handleCommissionPayment(address _sender) payable; }

contract Commission {

IDAOPayable dao;

function Commission(address _dao) { dao = IDAOPayable(_dao);

}

function() payable {

dao.handleCommissionPayment.value(msg.value)(msg.sender);

}

}

When receiving Ether, this contract does not call DAO’s standard payable fallback function, but it calls its specific function for processing the payment transferred via the daox.org service. Both, a standard payable fallback function and a special handleCommissionPayment function call the handlePayment function of the Crowdsale module. The difference is in the value of the commission parameter, that is being passed to the function.

67


The handlePayment function looks as follows:

function handlePayment(address _sender, bool commission) external payable CrowdsaleIsOngoing

validEtherPurchase(msg.value) { require(_sender != 0x0);

uint weiAmount = msg.value; if (commission) {

commissionRaised = commissionRaised +

weiAmount;

}

weiRaised += weiAmount;

depositedWei[_sender] += weiAmount;

uint tokensAmount = DAOLib.countTokens(weiAmount, bonusPeriods, bonusEtherRates, etherRate);

tokensMintedByEther =

SafeMath.add(tokensMintedByEther, tokensAmount);

token.mint(_sender, tokensAmount);

}

The code shows that in case the value of the commission parameter is equal to “true”, the commissionRaised variable increases by the amount of the received funds. The function is implemented in a way that the user gets tokens right after the funds are transferred, not upon the completion of the crowdsale. Modifiers CrowdsaleIsOngoing and validEtherPurchase are required to check that the

68


fund raising is still in progress and that the amount of the collected funds does not exceed the hardCap respectively.

Figure 17: transferring funds directly to the address of the DAO contract

Participating by means of DXCs To participate in a DAO by means of the DXC tokens, it is necessary to call the contributeTo function from the DXC contract. This can be done by sending the address of the DAO where the funds should be transferred to, as well as the amount of transfer to the function:

function contributeTo(address _to, uint256 _amount) public { super.transfer(_to, _amount);

require(_to.call(bytes4(keccak256("handleDXCPayment(address,uint256)")), msg.sender, _amount)); }

69


The function will transfer the funds to the indicated address, then it will notify the DAO about a transfer of a certain amount from a certain address, by calling the DAO’s handleDXCPayment function. The implementation of this function is given below:

function handleDXCPayment(address _from, uint _dxcAmount) external CrowdsaleIsOngoing validDXCPurchase(_dxcAmount) onlyDXC {

DXCRaised += _dxcAmount;

depositedDXC[_from] += _dxcAmount;

uint tokensAmount =

DAOLib.countTokens(_dxcAmount, bonusPeriods, bonusDXCRates,

DXCRate);

tokensMintedByDXC =

SafeMath.add(tokensMintedByDXC, tokensAmount);

token.mint(_from, tokensAmount);

}

The validDXCPurchase modifier functions the same way as validEtherPurchase, except the token. The onlyDXC modifier checks that the function was called from the DXC token contract, not from some random address.

70


Figure 18: investing in a DAO by means of DXC tokens

Crowdsale completion At a time when the current timestamp becomes greater than the timestamp in the endTime variable, the crowdsale is considered to have been completed, payments are not accepted anymore and it becomes possible to call the finish function that sums up the results.

function finish() external { fundsRaised = DXCRate != 0

? weiRaised + (DXC.balanceOf(this)) / (etherRate / DXCRate) : weiRaised;

require((block.timestamp >= endTime || fundsRaised == hardCap) &&

!crowdsaleFinished);

crowdsaleFinished = true;

if (fundsRaised >= softCap) { teamTokensAmount =

DAOLib.handleFinishedCrowdsale(token, commissionRaised,

71


serviceContract, teamBonusesArr, team, teamHold);

} else { refundableSoftCap = true;

}

token.finishMinting();

}

The finish function calculates the amount of the funds collected in Ether and in DXC tokens and decides whether the crowdsale was conducted successfully.

If the softCap requested by the team was not reached, the DAO switches into the refundableSoftCap phase, when all the participants can get their transferred funds back, and the tokens that they received are burnt. For refunds it is needed to call the refundSoftCap function, the implementation of which is stored in the Payment module: function refundSoftCap() whenRefundableSoftCap { require(depositedWei[msg.sender] != 0 || depositedDXC[msg.sender] != 0);

token.burn(msg.sender);

uint weiAmount = depositedWei[msg.sender];

uint tokensAmount = depositedDXC[msg.sender];

delete depositedWei[msg.sender]; delete depositedDXC[msg.sender];

DXC.transfer(msg.sender, tokensAmount);

msg.sender.transfer(weiAmount);

}

If the softCap is reached, the handleFinishedCrowdsale function is called automatically from the DAOLib library.

function handleFinishedCrowdsale(TokenInterface token, uint commissionRaised, address serviceContract, uint[] teamBonuses, address[] team, uint[] teamHold) returns (uint) { uint commission = (commissionRaised / 100) * 4;

72


serviceContract.call.gas(200000).value(commission)(); uint totalSupply = token.totalSupply() / 100; uint teamTokensAmount = 0; for (uint i = 0; i < team.length; i++) { uint teamMemberTokensAmount = SafeMath.mul(totalSupply, teamBonuses[i]);

teamTokensAmount += teamMemberTokensAmount;

token.mint(team[i], teamMemberTokensAmount);

token.hold(team[i], teamHold[i]);

}

return teamTokensAmount; }

This function calculates the number of generated tokens and transfers a certain amount of tokens indicated for each individual when the initBonuses function was called to each member of the team. After that, the function freezes the transferred tokens for a period that was specified when the initBonuses function was called. Additionally, this function transfers commission from the collected funds to the address of the Daox service contract. If the crowdsale is finished successfully, various voting functions become accessible.

9.2.4 Votings If the funds collected during the crowdsale equal or exceed the softCap, then voting functions become accessible to the participants of a DAO. A separate contract called VotingFactory is in charge of creating various votings. The address of the above-mentioned contract is set when the CrowdsaleDAO

contract is created. When attempting to create a particular voting with a function from a DAO, it delegates a call with all the transferred parameters to the VotingFactory contract, which in turn creates a voting contract and returns its address back to the DAO.

73


contract VotingFactory is VotingFactoryInterface {

address baseVoting;

DAOFactoryInterface daoFactory;

function VotingFactory(address _baseVoting) { baseVoting = _baseVoting;

}

function createRegular(address _creator, string _name, string _description, uint _duration, bytes32[] _options)

external onlyDAO onlyParticipant(_creator) returns (address) {

return new Regular(baseVoting, msg.sender, _name, _description,

_duration, _options);

}

function createWithdrawal(address _creator, string _name, string _description, uint _duration, uint _sum, address withdrawalWallet,

bool _dxc)

external onlyTeamMember(_creator) onlyDAO onlyWhiteList(withdrawalWallet) returns (address) {

return new Withdrawal(baseVoting, msg.sender, _name, _description,

_duration, _sum, withdrawalWallet, _dxc);

}

function createRefund(address _creator, string _name, string _description, uint _duration) external onlyDAO onlyParticipant(_creator)returns (address) { return new Refund(baseVoting, msg.sender, _name, _description,

_duration);

}

function createModule(address _creator, string _name, string _description, uint _duration, uint _module, address _newAddress)

external

74


onlyDAO onlyParticipant(_creator) returns (address) {

return new Module(baseVoting, msg.sender, _name, _description, _duration,

_module, _newAddress);

}

function setDaoFactory(address _dao) external { require(address(daoFactory) == 0x0 && _dao != 0x0); daoFactory = DAOFactoryInterface(_dao);

}

modifier onlyDAO() {

require(daoFactory.exists(msg.sender)); _;

}

modifier onlyParticipant(address creator) {

require(IDAO(msg.sender).isParticipant(creator)); _;

}

modifier onlyTeamMember(address creator) {

require(IDAO(msg.sender).teamMap(creator)); _;

}

modifier onlyWhiteList(address creator) {

require(IDAO(msg.sender).whiteList(creator)); _;

}

}

All in all there are 4 types of voting in a DAO:

1. Regular — voting that does not change the DAO’s current state in any way, whatever the result is, and serves only to let the participants of the DAO to decentrally voice their opinions on a question that is being discussed in voting.

75


2. Withdrawal — voting primarily required by the team members, which allows for receiving funds from the deposit established in a DAO during the crowdsale.

3. Refund — voting that allows members of a DAO to declare a project as

failed for one reason or another, and to reimburse the funds from the DAO’s remaining amount, which will be distributed proportionally to the DAO token-holders.

4. Module — service voting, which allows for changing the address of one

module for the address of another module where the mistake has been eliminated, in case an error or a bug is found in one of the functional modules linked to a DAO. This voting also allows for changing the address of the Voting factory contract, in case there are problems related to the votings that need to be fixed.

Before any voting is created the VotingFactory checks that the voting was generated by the member of a DAO or member of a project team, namely by the holder of tokens that have been distributed in this particular DAO during the crowdsale. The VotingFactory also checks that the function itself was called by the contract of the DAO, not by a random address. There are individual checks as well, but they will be described further on. Each of 4 types of voting has its own contract with specific functionality, but common features are combined into a separate contract with basic voting functionality, that is called Voting. Thus, when the functionality overlaps, all votings delegate the execution request to the Voting contract.

76


Figure 19: voting creation

Let us consider the basic Voting contract, and then take a good look at each type of voting.

Voting

contract Voting is VotingFields {

function create(address _dao, bytes32 _name, bytes32 _description, uint _duration, uint _quorum)

succeededCrowdsale(ICrowdsaleDAO(_dao)) correctDuration(_duration) external {

dao = ICrowdsaleDAO(_dao);

name = Common.toString(_name);

description = Common.toString(_description);

duration = _duration;

77


quorum = _quorum;

}

function addVote(uint optionID) external notFinished canVote

correctOption(optionID) { require(block.timestamp - duration < created_at); uint tokensAmount = dao.token().balanceOf(msg.sender);

options[optionID].votes += tokensAmount;

voted[msg.sender] = optionID;

votesCount += tokensAmount;

dao.holdTokens(msg.sender, (duration + created_at) - now);

}

function finish() external notFinished { require(block.timestamp - duration >= created_at); finished = true; if (keccak256(votingType) == keccak256("Withdrawal")) return finishNotProposal();

if (keccak256(votingType) == keccak256("Proposal")) return finishProposal();

//Other two cases of votings (`Module` and `Refund`) requires quorum

if (Common.percent(options[1].votes, dao.token().totalSupply() - dao.teamTokensAmount(), 2) >= quorum) { result = options[1]; return; }

result = options[2]; }

function finishProposal() private { VotingLib.Option memory _result = options[1]; bool equal = false; for (uint i = 2; i < options.length; i++) { if (_result.votes == options[i].votes) equal = true; else if (_result.votes < options[i].votes) { _result = options[i];

equal = false; }

}

if (!equal) result = _result; }

78


1. create — this function receives all the common parameters from the voting contracts and sets their value to storage variables. It checks that the duration of voting is indicated correctly and will allow participants to have enough time to get acquainted with voting procedures and take part in the voting itself.

2. addVote — this function gets information about an option that the

participant wants to vote for from the voting contracts, and it also receives token balance of the participant, considers the participant as having voted and assigns value that is equal to the number of tokens hold by the participant to the selected option. After that, the tokens of the participant will be frozen until the end of voting. This is done so that after the voting the participant would not be able to transfer his tokens to another address, that could use these tokens one more time during the same voting. Before the function is performed, it checks that the voting is still in progress, that a person who is voting is not a team member, but a member of a DAO, that he has not voted yet and that he votes for the selected option.

3. finish — this function completes the voting and sums it up, having

checked in advance that the completion time has come and the voting has not yet been completed. Then, votes for each option, as well as the total number of votes in reference to all possible options are being counted, upon which the results are calculated.

Regular This is the simplest type of voting used to handle practical issues that do not result in affecting the DAO in anyway. It has from 2 to 10 user-defined options, and each person taking part in voting should choose one from those. In order to be created, this voting should have indicated name, description, duration in seconds, and array of options.

80


The code used to create this voting is given below:

function Regular(address _baseVoting, address _dao, string _name, string _description, uint _duration, bytes32[] _options){ require(_options.length >= 2 && _options.length <= 10); baseVoting = _baseVoting;

votingType = "Regular"; VotingLib.delegatecallCreate(baseVoting, _dao, _name,

_description,

_duration, 0); createOptions(_options);

}

function createOptions(bytes32[] _options) private { for (uint i = 0; i < _options.length; i++) { options[i + 1] = VotingLib.Option(0, _options[i]); }

}

When creating this type of voting, the number of transmitted options is checked, and if it is either less or more than the number of predefined options, then the creation process is being halted. The ‘addVote’ function and ‘finish’ function do not have any additional code for this type of voting, and are entirely described in the Voting contract. An option that got the most votes in tokens is regarded as an accepted one.

81


Figure 20: voting completion

Withdrawal This type of voting is designed to make requests for partial withdrawals of the raised proceeds from a DAO. When creating this kind of voting, it is necessary to indicate name, description, duration, withdrawal amount, address that the funds would be transferred to and currency, that is, if the team members would like to get the funds in Ether or in DXCs. If the currency for funds withdrawal is Ether, then the sum should be indicated in wei. Before the voting contract is created, the VotingFactory checks whether the address given for funds withdrawal is on a list of accepted addresses, that was specified in the setWhiteList function before the start of the crowdsale. Options for this type of voting are generated automatically, and they are only: “yes” and “no”.

82


The code for this type of voting looks as follows: function Withdrawal(address _baseVoting, address _dao, string _name, string _description, uint _duration, uint _sum, address _withdrawalWallet, bool _dxc) { require(_sum > 0 && VotingLib.isValidWithdrawal(_dao, _sum, _dxc));

baseVoting = _baseVoting;

votingType = "Withdrawal"; VotingLib.delegatecallCreate(baseVoting, _dao, _name,

_description,

_duration, 0); withdrawalSum = _sum;

withdrawalWallet = _withdrawalWallet;

dxc = _dxc;

createOptions();

}

Before the voting is created, it is checked that the withdrawal amount is more than zero and that there is sufficient amount of funds in the DAO. The voting function addVote of the Withdrawal voting is entirely executed in the basic Voting contract, while the function of voting completion has an additional code:

function finish() public { VotingLib.delegatecallFinish(baseVoting);

if(result.description == "yes") dao.withdrawal(withdrawalWallet, withdrawalSum, dxc);

}

An option that has gained 50% + 1 token from all the tokens taking part in the voting will be regarded as an accepted one. In case if upon the completion of the voting, the “Yes” option got the most votes, the DAO, for which the voting was created, calls the withdrawal method, the implementation of which is in the VotingDecisions module. Such parameters as the sum, currency of the withdrawal and the address which the funds should be transferred to, are passed to that function.

83


The implementation of the withdrawal method looks as follows:

function withdrawal(address _address, uint _withdrawalSum, bool _dxc) notInRefundableState onlyVoting external { lastWithdrawalTimestamp = block.timestamp;

_dxc ? DXC.transfer(_address, _withdrawalSum)

: _address.transfer(_withdrawalSum);

}

Before the execution it is verified that the DAO is not in the refund phase at the moment, and that the call originated exactly from the voting contract. If the verification is successful, the date of the last withdrawal is set and the transfer takes place.

Figure 21: voting completion of the

‘Withdrawal’ type

84


The date of the last withdrawal is used to prevent lock-up of the funds in a DAO. If the last withdrawal date was more than two months ago, a call to the function, that transfers a DAO to the state of refund to investors mode, becomes available. More details on that state is given below: function makeRefundableByUser() external { require(lastWithdrawalTimestamp == 0 && block.timestamp >= created_at + withdrawalPeriod

|| lastWithdrawalTimestamp != 0 && block.timestamp >= lastWithdrawalTimestamp +

withdrawalPeriod);

makeRefundable();

}

Refund This voting makes it possible to activate the refund state for a DAO. Only a name, description and duration are needed to create this type of voting. The code for creating this method is provided below: function Refund(address _baseVoting, address _dao, string _name, string _description, uint _duration) { baseVoting = _baseVoting;

votingType = "Refund"; VotingLib.delegatecallCreate(baseVoting, _dao, _name,

_description,

_duration, 90); createOptions();

}

The voting options are created in the same way as in the Withdrawal. The addVote function does not contain any additional code.

85


There is additional code in the ‘finish’ function: function finish() public { VotingLib.delegatecallFinish(baseVoting);

if(result.description == "yes") dao.makeRefundableByVotingDecision();

}

Voting will be considered successful if the “Yes” option gets more than 90% of all the issued tokens (excluding team-members tokens). That way, upon the completion of the DAO voting, the makeRefundableByVotingDecision function is called form the voting creator, implementation of which is in the VotingDecisions module. The code of the function looks as follows:

function makeRefundableByVotingDecision() external onlyVoting { makeRefundable();

}

The function checks that the call had been made from the voting contract, and then calls the makeRefundable function. The function is implemented as follows:

function makeRefundable() notInRefundableState private { refundable = true; newEtherRate = SafeMath.mul(this.balance * etherRate, multiplier) / tokensMintedByEther;

newDXCRate = tokensMintedByDXC != 0 ? SafeMath.mul(DXC.balanceOf(this) * DXCRate, multiplier) / tokensMintedByDXC : 0; }

A verification that the DAO has not been previously transferred to the refund stateis made, then, if the verification is passed, the transition to the

86


corresponding state occurs and the rate for both currencies is recalculated in accordance with the remaining funds in the DAO. When calculating the new rate, the multiplier variable is multiplied by 100,000. This is done in order to avoid having a fractional division result, which is interpreted as 0 in solidity. In subsequent functions, the result is divided by the same multiplier to bring the data to the correct values.


Refund type

87


After transition to the refund phase, it becomes possible to call the refund function implemented in the Payment module.

function refund() whenRefundable notTeamMember { uint tokensMintedSum = SafeMath.add(tokensMintedByEther, tokensMintedByDXC);

uint etherPerDXCRate = SafeMath.mul(tokensMintedByEther, percentMultiplier) / tokensMintedSum;

uint dxcPerEtherRate = SafeMath.mul(tokensMintedByDXC, percentMultiplier) / tokensMintedSum;

uint tokensAmount = token.balanceOf(msg.sender); token.burn(msg.sender);

if (etherPerDXCRate != 0)

msg.sender.transfer(DAOLib.countRefundSum(etherPerDXCRate *

tokensAmount, etherRate, newEtherRate, multiplier));

if (dxcPerEtherRate != 0) DXC.transfer(msg.sender,

DAOLib.countRefundSum(dxcPerEtherRate * tokensAmount, DXCRate,

newDXCRate, multiplier));

}

The function verifies that the DAO is in a refund state and that the refund request is not made by a team member. After that, the participant is refunded in accordance with Ethereum and DXC tokens, remaining on the balance of a DAO. The amount of the refund is calculated based on the amount of the participant's tokens and a new rate.

Module This is a special type of voting designed to upgrade the code of a DAO. This type of voting allows to change the address of one of four functional modules or the VotingFactory.

88


To create this type of vote, one should pass such parameters as name, description, duration, sequence number of the module that is to be replaced and the address it will be replaced to. The voting is created using the following code:

function Module(address _baseVoting, address _dao, string _name, string _description, uint _duration, uint _module, address _newAddress) {

require(_module >= 0 && _module <= 4); baseVoting = _baseVoting;

votingType = "Module"; module = Modules(_module); newModuleAddress = _newAddress;

VotingLib.delegatecallCreate(baseVoting, _dao, _name,

_description,

_duration, 80);

createOptions();

}

Before the voting creation, the verification is made that the passed sequence number of the module falls within valid values. The acceptance of the vote and voting termination rules coincide with the refund type, except that 80% of the votes instead of 90% are required for this type of vote to be accepted. The completion has the following code: function finish() public { VotingLib.delegatecallFinish(baseVoting);

if(result.description == "no") return;

//Sorry but solidity doesn't support `switch` keyword if (uint(module) == uint(Modules.State)) dao.setStateModule(newModuleAddress);

if (uint(module) == uint(Modules.Payment)) dao.setPaymentModule(newModuleAddress);

89


if (uint(module) == uint(Modules.VotingDecisions)) dao.setVotingDecisionModule(newModuleAddress);

if (uint(module) == uint(Modules.Crowdsale))

dao.setCrowdsaleModule(newModuleAddress);

if (uint(module) == uint(Modules.VotingFactory)) dao.setVotingFactoryAddress(newModuleAddress);

}

Thus, if the vote is successful, a call to one of the five functions of a DAO is performed to set the address of the module based on the supplied sequence number.

function setStateModule(address _stateModule) external canSetAddress(stateModule) { stateModule = _stateModule;

}

function setPaymentModule(address _paymentModule) external canSetAddress(paymentModule) { paymentModule = _paymentModule;

}

function setVotingDecisionModule(address _votingDecisionModule) external canSetAddress(votingDecisionModule) { votingDecisionModule = _votingDecisionModule;

}

function setCrowdsaleModule(address _crowdsaleModule) external canSetAddress(crowdsaleModule) { crowdsaleModule = _crowdsaleModule;

}

function setVotingFactoryAddress(address _votingFactory) external canSetAddress(votingFactory) { votingFactory = VotingFactoryInterface(_votingFactory);

}

90


Each function is verified using the canSetAddress modifier, which allows to change the address of the module only if the function call was made by the voting contract or the address has not yet been set at all and is being set by the contract’s owner. Therefore, module addresses can be changed only by means of this vote.


Module type

91


10. The Bottomline We believe that in the future anyone will be able to participate in a crowdfunding campaign (be it the construction of a skyscraper or implementation of an invention) with any amount of money, get a tokenized share of that project, and the right to influence on the way it is developing, while all the procedure would be as easy and common as posting on a social network. We want cryptofunding to become mainstream, yet fair and safe.

92


Legal Disclaimer This document is for informational purposes only and does not constitute an offer or solicitation to sell shares or securities in any jurisdiction. User acknowledges, understands, and agrees that DXC tokens are not securities and are not registered with any government entity as a security, and shall not be considered as such. None of the information or analyses presented are intended to form the basis for any investment decision, and no specific recommendations are intended. No person is entitled to rely on the contents of this paper or any inferences drawn from it, including in relation to any interactions with Daox, the TGE or the technologies mentioned in this paper. Investors and potential DXC Token holders should seek appropriate independent professional advice prior to relying on, or entering into any commitment or transaction based on material published in this paper, which material is solely published for information purposes alone. Daox expressly disclaims any and all responsibility for any direct or consequential loss or damage of any kind whatsoever arising directly or indirectly from: (i) reliance on any information contained in this document, (ii) any error, omission or inaccuracy in any such information or (iii) any action resulting therefrom. Daox also reserves the right to change, modify, deviate from, add to, or scale down any plans, projections, or forecasts which have been expressed in this paper at any time whether during or after the TGE at its sole and absolute discretion. Further, we may be required to amend the intended functionality of DXC Tokens in order to ensure compliance with any legal or regulatory obligations that apply to us now or in future.

93


The English language white paper is the primary official source of information about the project. The information contained in English language white paper may from time to time be translated into other languages. In the course of such translation some of the information contained in the English language white paper may be lost, corrupted or misrepresented. The accuracy of such alternative communications cannot be guaranteed. In the event of any conflicts or inconsistencies between such translations and the official English language white paper, the provisions of the English language original document shall prevail.

94

fundraising dao protocol and ecosystem · fundraising dao protocol and ecosystem ... withdrawal...

Documents