ICO smart-contract with automatic emission of tokens
We want to present you ICO smart-contract, which releases tokens at the time of its creation. Accrual of tokens occurs by moving them to the investor’s account. Briefly, the terms of an ICO are described as follows:
• Initially, a certain amount of tokens emitted. This amount is the maximum and final, the additional emission is not provided.
• All unrealized tokens will be burned.
• A certain percentage of tokens will be distributed to the team, advisers, to the reserve fund, and marketing campaigns.
• Acquired tokens will be frozen until the time when ICO will be finished.
There is nothing special about this smart-contract. But we think that someone will be interested in this information. Any comments and suggestions will be helpful to us.
Creating a token contract. ADAB token must meet standards, recognized by the community. Next is the implementation of the functionality of the burning process. Then we provide it with the “ability” to freeze tokens for a period of time. Afterward, we create a contract.
The first step is implementation of the token contract.
Foremost, in order to satisfy the standard, adopted in the Ethereum world, our token contract must be inherited from the contracts, presented in the repository: openzeppelin-solidity.
We use the following code:
• A simplified version of the ERC20 interface.
• ERC20 interface.
• SafeMath Library
• Implementation of standard contracts — BasicToken and StandartToken
Code of the implementation will look as follows:
Secondly, we need to realize the possibility of burning tokens. To do this, we will make our contract inheritable from the BurnableToken contract from the same repository. In this contract, there is only a single function that burns tokens from the balance of the user that caused the function and emits an event about it.
Thirdly, according to the rules, for the period until ICO will finish, tokens will be frozen. We implement this condition by that our token contract will be inherited from the FreezableToken contract (also from OpenZeppelin). We use a simplified version of this contract. To account for frozen tokens, we introduce a new balance variable, while the existing variable, entered to the standard contact will keep a balance of unfrozen tokens:
Tokens are defrosted after ICO will be finished, and we use only one defrosting date for all accounts. Let’s enter such date in the contract:
Let’s accept conditionally this date for 1.09.2018.
The balance of tokens at a specific address now consists of two components: the current balance of tokens and the balance of frozen tokens; therefore, we rewrite the balance functions taking this circumstance into account:
The first function returns the balance of the address sent as an argument, including frozen tokens, the second — without the last, the third — frozen balance.
We will write a function that will freeze tokens on the balance:
The function accepts the number and address where tokens have to be frozen, checks for a non-zero address and the existence of the required amount on the balance sheet. Also, the function emits an event of freezing on the recipient’s address.
Now we need a function that will give an opportunity to an investor to defreeze his/her tokens in the appropriate time. This is done by the fact that the investor calls the release function directly in the Ethereum network, which looks like this:
The function can be called after ICO’s ending only and then function transfers the frozen balance to the balance of conventional tokens, after which they will be ready for transfer.
Creating a token contract. It is inherited from FreezableToken and BurnableToken.
We gave the name to our token.
According to the conditions, we have assumed the initially limited emission. To do this, we have prescribed the expected number of tokens (line in the code uint256 public INITIAL_SUPPLY = 10000000 * 1 ether;), in the constructor, we initialized the balance of the contract owner with all emitted tokens: a string balances[msg.sender] = INITIAL_SUPPLY;
For simplicity, we assume that 10,000,000 tokens are emitted. Remember that the number of tokens is indicated, taking into account decimal places. For example, in our token 18 decimal places. Therefore, we multiply by 1 ether (1 ether = 1000000000000000000 wei).
We introduce the modifiers onlyOwner and allowTransfer, which validate the contract owner and the time of the operation, respectively.
We will restart the transfer and transferFrom functions of the standard contract by adding a check on the possibility of performing the operation over time and also adding the function of sending to the special addresses for bonuses accrual, which will be discussed below. The latter can be called only by the owner of the contract, which is ensured by adding the onlyOwner modifier to the function header.
We have completed the token contract. Let’s start writing a sale smart-contract.
First of all, our sale smart-contract will be inherited from the Ownable contract. This contract provides the ability to restrict access to functions to everyone, except the owner of the contract.
By condition, part of the emitted tokens should be distributed as follows:
1) 1% of tokens must be distributed across the bounty campaigns.
2) 15% of tokens are intended to create a reserve fund that stabilizes the cost of tokens.
3) 8% of tokens are distributed among team members. Tokens will be frozen and can be unlocked: 25% of tokens 12 months after the start of the project, and 75% — 24 months after the start.
4) 4% of tokens are intended for project advisers. Tokens are also frozen and can be unfrozen: 25% — immediately after the completion of the ICO and 75% — after the start of the project.
We implement the following contracts:
Contracts are intended for funding certain amounts on them and, therefore, do not accept airs to their addresses. The funding code will look like this:
Following variables will be in our contract:
1. startDate — the start date of the sale of tokens
2. token — our token’s contract
3. owner — the address of the owner of our contract. The proceeds will be sent to this address.
4. period — how many days the sale will last
5. rate — the rate of the broadcast to the dollar.
According to the conditions, we assume the distribution of tokens between different participants. Let’s implement it.
The distribution of tokens should occur between:
1. bounty program;
2. reserve fund;
4. pool of the advisors’ addresses
It will work like this:
• Creating contracts of funds, from which we will distribute tokens to recipients, namely, distribution to the bounty program, reserve fund, team, and advisors;
• We will list tokens of funds according to the terms of the ICO. These tokens will be frozen until the moment when under the terms when transfer becomes possible;
• Creating functions with help of which there will be a charge from the created funds on receivers.
The code that implements these conditions is presented below:
ADAB token’s rate is pegged to the U.S. dollar. Therefore, we introduce a variable reflecting the rate of the ether to the dollar and use it in calculating the charges when buying tokens.
uint rate = 50 ether
The rate sets every 15 minutes from the back-end function, presented below. In order to provide investors with confidence in the absence of the rate manipulation, we add a public function that returns the current rate and the event that is triggered every time a course change occurs.
When a user purchases tokens within the ICO framework, we transfer the emitted tokens to him/her, according to the rules of the ICO. Then we create a function that implements these rules and it’s fallback functions, that receives the ether.
It only remains to add functions that set the dates for the start of sales and launch of the exchange, as well as the burning function from the token contract:
#pre-sale #ico #ADAB #adabsolutions #cryptocurrency #blockchain #Adab #Muslims #investments #crypto-economy #Islamic #finance #cryptocurrency #exchange #FICE #Shariah#trading #cryptocurrencies #Muslim #community #market #digital #economy