As probably all of you, we have followed the recent ICOs with interest. We are truly on the bleeding edge of a new era here, so it is only understandable that a perfect structure for ICOs does not exist yet.

Our goals when designing the ICO were:

  • to allow a broad participant base;
  • to ensure fair distribution;
  • to be safe;
  • to be a good participant in the community and not overload the network.

We have structured the ICO very closely to that of BAT’s, but with a higher funding cap. We do not expect to run into the fund cap, and hope to have the ICO open considerably longer than BAT’s 24 seconds.

To ensure fair distribution, we have chosen not to implement early bird discounts. We don’t want the vanity headlines, where the whole funding allocation happens in pre-sales and behind the scenes. We want as many people as possible to have access to invest.

Time or token amount limited discounts typically also lead to high gas prices and network congestion.

To be safe, we have used the BAT code base with as few modifications as possible. This code base has already been audited and used in a real life case.

We did implement a few changes in the code though.

1. Using Block Times.

The BAT Sale contract uses block start and end numbers instead of block times due to a belief held by Consensys that timestamps can be manipulated by miners.

https://github.com/ConsenSys/smart-contract-best-practices#timestamp-dependence

Our conversations with Ethereum core developers leaves us with the opinion that such manipulations are likely to lead to inaccuracies of no more than a couple of seconds. Comparatively, it is almost impossible to estimate when a block will occur more than a few block into the future which makes a block based ICO a real pain to manage.

This causes changes to the constructor which now calculates the end time by adding <duration> days to the start times.

2. Transfer of Tokens Updates the Splitter Contract.

The splitter contract (more info below) needs to know every time that an account’s balance changes. This is coded into a derivative of the transfer function.

3. Last Token Distribution

The BAT contract would reject any deposit that crossed the funding cap. If you were monitoring closely you could get a smaller bid in when an earlier, larger, one had failed. We felt this to be unfair.

Our one modification to the funding part of the contract is, when a deposit is made that crosses the funding cap, to accept the required amount and return the rest.

e.g. if 0.78 ETH are required to finish the sale, on receiving 2 ETH we will allocate 0.78 worth of tokens and return 1.28 ETH.

We have one major addition in our smart contract.

The splitter is a core contract specifically designed to facilitate post-event extraction of token allocation data as of a specific location in time while still permitting data movements during the extraction process.