STEPS

The steps include publishing contracts into the Ethereum network (address), verifying them in Etherscan, creating a crowdsale web-page for ICO stages after WL with actual sale statistics. For participants, we can create a page from where they can invest into the actual campaign stage, including WL. Smart contracts are based on Ethereum Solidity smart contracts.

CROWDSALE CONTRACT

Selected strategy for crowdsale contract. Modern crowdsale strategy recommendations include cap, multiple tiers, whitelisiting, limits, built-in refunds and minimum funding goal for every crowdsale stage as well as migration and emergency stops and other matters such as: capped or uncapped, how price changes during the crowdsale from tier to tier and for finalizing sale: 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 and a token (and other logic) lies in separate contracts that can be assembled together. Also we are building upon a foundation: instead of wrting everything from scratch, we use OpenZeppelin contracts as much as possible as they are the gold standard of Solidity development

A TOKEN CONTRACT

Setup token, contract address and rules of future distribution. The setup token contract configures the properties of <UNI> token. A token contract is an ERC-20 compatible. (https://github.com/TokenMarketNet/ico). The token itself is just a representation of Ether in a smart contract with the specific properties. The properties include:

  1. NAME: – The name of a token – V. (Will be used by Etherscan and other token browsers. (Adv. Note: need to trademark).
  2. TICKER: - The three or four letter ticker for your token – V.
  3. DECIMALS: - refers to how divisible a token can be, from 0 (not at all divisible) to 18 (pretty much continuous). Will be recalculated depending on how much a purchaser pays: ex. :
  4. MINTABLE: minted as needed upon purchase.
(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