1. Creating a 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:

This function uses the DAODeployer library for uploading an organization with defined parameters to the Ethereum network.

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:

The Voting Factory address is needed to create proposals in case the crowdsale is successful. 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.

Figure 1: creation of a DAO

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:

State — initialization of technical parameters, creation of a commission contract. Crowdsale — initialization of parameters, incoming payments processing, completion of the token generation event. Payment — outgoing payments processing, for instance a refund in case of an unsuccessful crowdsale. 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 2: initialization of technical parameters of a DAO

2.1 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.

The source code of the function is given below:

For each organization, the token is created separately, that is why it is necessary to save its address in the contract’s storage. 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 platform, the initialization of the parameters is called from the service account.

2.2 Crowdsale variables

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

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 platform.

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.

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

The canSetWhiteList flag provides a one-time function invocation. If a DAO is being created via the Daox platform 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.

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.

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.

3.1 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 function of the State module is being called, or by transferring funds directly to the address of the DAO’s contract.

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

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:

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.

The handlePayment function looks as follows:

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 fund raising is still in progress and that the amount of the collected funds does not exceed the hardCap respectively.

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

3.2 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:

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.

Figure 5: investing in a DAO by means of DXC token

3.3 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.

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:

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

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.