How Daox Works — Part 1
Creating a DAO and Raising Funds
This article is to help developers and people who are interested in the Daox project understand how this platform works, what the main stages of lifecycle for each created DAO are, and how different components of the platform connect with each other. The first part explains and describes lifecycle stages starting from the creation of a DAO and to the end of the crowdsale. By DAO we mean Daox-based organization (a DAO created using Daox smart contracts on the Ethereum blockchain).
All code presented in this article is provided with .js extension only for correct highlight. The real extension is .sol
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.
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.
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 initStatefunction of the State module is being called, or by transferring funds directly to the address of the DAO’s 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 fallbackfunction 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.
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.
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 initBonusesfunction 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.
Conclusion
This part of the article explains that in case of an unsuccessful crowdsale the DAO’s lifecycle ends. Another case (when the crowdsale succeeds) will be considered in the next part of this article and will describe voting processes in a DAO which include withdrawal, refund, etc.
Full code of smart contracts that are used by Daox can be found in our github repository: https://github.com/daox/daox-contracts
