Arranging an ICO takes around 3-4 months. The actual sales is open 15-60 days. Afterwards it takes 1-2 months to distribute tokens to participants and to convert raised funds. Below is an exemplary ICO project steps:

CROWDSALE CONTRACT

Select a strategy for crowdsale contract. Smart contracts must be written according to the modern best practices of Ethereum community. Modern crowdsale strategy recommendations include Cap, multiple tiers, whitelisiting, limits, built-in refund and minimum funding goal for every crowdsale.  There can also be migration and emergency stop and other matters such as: capped or uncapped, how price changes during the crowdsale from tier to tier and finalizing strategy: what happens after a successful crowdsale: allow tokens to be transferable, give out extra-tokens, etc.

The good practice is writing the smart contracts with separation of concerns:  e.a. – crowdsale,  token and other logic lies in separate contracts that can be assembled together like lego bricks. Also building upon a foundation: instead of building everything from scratch, we use OpenZeppelin contracts as much as possible as they are the gold standard of Solidity development

TOKEN SETUP

Setup token and rules of future distribution. Will configure the properties of your token. Will create token contract that  will be ERC-20 compatible.  (https://github.com/TokenMarketNet/ico).  The token itself is just a representation of Ether in a smart contract. Properties include:

TOKEN: NAME – The name of your token. (Will be used by Etherscan and other token browsers. Be afraid of trademarks). TICKER – The three letter ticker for your token. There are 17,576 combinations for 26 English letters. DECIMALS – refers to how divisible a token can be, from 0 (not at all divisible) to 18 (pretty much continuous).

RESERVED TOKENS: ADDRESS - Address where to send reserved tokens. DIMENTION -. Fixed amount or % of crowdsaled tokens. Will be deposited to the account after finalization of the crowdsale. VALUE – Value in tokens or percents.
___________
Ex:

{
“compilerVersion”: “0.4.11″,
“contractName”: “MintedTokenCappedCrowdsaleExt”,
“contractType”: “white-list-with-cap”,
“contracts”: {
“token”: {
“src”: “”,
“bin”: “”,
“abi”: [],
“addr”: “”,
“abiConstructor”: “”
},
“crowdsale”: {
“src”: “”,
“bin”: “”,
“abi”: [],
“addr”: [],
“abiConstructor”: []
},
“pricingStrategy”: {
“src”: “”,
“bin”: “”,
“abi”: [],
“addr”: [],
“abiConstructor”: []
},
“multisig”: {},
“nullFinalizeAgent”: {
“src”: “”,
“bin”: “”,
“abi”: [],
“addr”: “”,
“abiConstructor”: “”
},
“finalizeAgent”: {
“src”: “”,
“bin”: “”,
“addr”: [],
“abiConstructor”: []
},
“tokenTransferProxy”: {},
“safeMathLib”: {
“src”: “”
“bin”: “”
“addr”: “”,
“abiConstructor”: “”
}
},
“optimized”: true,
“token”: {
“name”: “MyToken”,
“ticker”: “MTK”,
“supply”: 0,
“decimals”: “18″
}
“reservedTokens”: [{
“addr”: “0x005364854d51A0A12cb3cb9A402ef8b30702a565″,
“dim”: “tokens”,
“val”: “10″
}],
“reservedTokensElements”: [{
“key”: “0″,
“ref”: null,
“props”: {
“num”: 0,
“addr”: “0x005364854d51A0A12cb3cb9A402ef8b30702a565″,
“dim”: “tokens”,
“val”: “10″
},
“_owner”: null,
“_store”: {}
}],
“reservedTokensInput”: {
“dim”: “tokens”,
“addr”: “”,
“val”: “”
},
“stepTwoValidations”: {
“tier”: “VALIDATED”,
“startTime”: “VALIDATED”,
“endTime”: “VALIDATED”,
“walletAddress”: “EMPTY”,
“supply”: “VALIDATED”,
“rate”: “VALIDATED”,
“updatable”: “INVALID”
},
“stepThreeValidations”: {
“tier”: “VALIDATED”,
“startTime”: “VALIDATED”,
“endTime”: “VALIDATED”,
“supply”: “VALIDATED”,
“rate”: “VALIDATED”,
“updatable”: “INVALID”
},
“pricingStrategy”: [{
“rate”: “10000″
},
{
“rate”: “1000″
}
],
“crowdsale”: {
“startTime”: “2017-09-28T17:05″,
“endTime”: “2017-10-03T00:05:00″,
“walletAddress”: “0x005364854d51a0a12cb3cb9a402ef8b30702a565″,
“supply”: “1000″
}
“whitelist”: {
“addr”: “0x005364854d51A0A12cb3cb9A402ef8b30702a565″,
“min”: “1″,
“max”: “10″
},
“whiteListElements”: {
“key”: “0″,
“ref”: null,
“props”: {
“crowdsaleNum”: 0,
“whiteListNum”: 0,
“addr”: “0x005364854d51A0A12cb3cb9A402ef8b30702a565″,
“min”: “1″,
“max”: “10″
},
“_owner”: null,
“_store”: {}
},
“whiteListInput”: {
“addr”: “”,
“min”: “”,
“max”: “”
},
tiers: [
{
“tier”: “Tier 1″,
“updatable”: “on”,
“whitelistdisabled”: “no”
},
{
“tier”: “Tier 2″,
“supply”: “1000″,
“updatable”: “on”,
“whitelist”: [],
“whiteListElements”: [],
“whiteListInput”: {},
“startTime”: “2017-10-03T00:05:00″,
“endTime”: “2017-10-07T00:05:00″
}
],
}

CROWDSALE SETUP

 Setup tiers and crowdsale parameters. This is the most important and exciting part of the crowdsale process.  You need to define parameters of your crowdsale campaign.

REISSUANCE – There can be multiple crowdsales for the same token (pre-ICO, ICO, etc.)

CROWDSALE SETUP NAME - Name of a tier, e.g.: PrePreIco, PreICO, ICO with bonus A, ICO with bonus B, etc. We advice to simplify that and will increment a number after each tier.

WALLET  ADDRESS – where the money (FIAT or BTC) goes after investors transactions. Immediately after each transaction. (We recommend to setup a multisignature (“multisig”) wallet with hardware based signers).

START -END TIME – Date and time when the tier starts and ends. (Start time can’t be in the past from the current moment. End time can be only in the future).
RATE – Exchange rate Ethereum to Tokens. (If it’s 100, then for 1 Ether you can buy 100 tokens).
SUPPLY – How many tokens will be sold on this Tier. (Cap of crowdsale equals to sum of supply of all tiers).

TIER CAMPAIGN MODIFICATION – Allowing modifying or not. Pandora box feature. If it’s enabled, a creator of the crowdsale can modify Start time, End time, Rate, and Limit even after contract publishing.

WHITELISTING – For instance – disabling whitelisting means that anyone can buy on the tier.

INVESTOR MIN CAP – This is a requirement from the global limits. Minimum amount tokens to buy. Not a minimal size of a transaction. (If min Cap is 1 and user bought 1 token in a previous transaction and buying 0.1 token it will allow him to buy).

CODE TESTING AND AUDIT

 Publish generated code and artifacts for verification in Etherscan for security audit of token system. The goal is 100% branch code coverage with both semi-automated process and formal source code testing as usual practice in software development. There is a semi-automated process to verify deployed contracts on EtherScan verification service.  Using formal verification, it is possible to perform an automated mathematical proof that your source code fulfills a certain formal specification. The specification is still formal (just as the source code), but usually much simpler.

CROWDSALE PAGE

Integrate this page with the campaign real-time statistics

HOSTING AND ESCROW

Hosting and Escrow to raise funds and distribute tokens.

  • Accepting fiat currencies (EUR, GBP, others)
  • Know Your Customer (KYC)
  • Security Market Trading