The Potential ICO Contract That Might End All of the Nonsense

The two problems facing an Ethereum ICO:

• Network contstraints rendering the blockchain unusable for a period of time and/or unequal acceptance of bids.
• The potential for míners to inject themselves between users and token contracts during an ICO.

I'm going to layout an ICO contract design that will solve these two biggest issues Ethereum is facing reference ICO's.

The ICO issuer creates a contract with capped issuance. The cap should be stated in ether. This contract takes bids from EOA's over a period of 30 days. All bids are taken, for the entire 30 days. The bids are sent with value and the addresses and value sent are bound in an iterable array within the issuing contract. This contract includes a generateToken function. After the 30 days, the owner of the issuing contract executes the generateToken function (and yes pays for the execution of this function.)

The generateToken function creates the ERC20 token contract and then executes a random number generator. Each random number represents the index of the chosen bid in the iterable storage, puts that bid into the token contract, and keeps track of the total value pulled from the bid array. Once the cap is hit, it puts the remaining bids in a map and allows those not selected to withdraw their ether. After 30 days, if the ICO issuer does not execute the token generator, a map is automatically created to allow everyone to withdraw their ether.

The actual number of ERC20 tokens issued is arbitrary and should be automatically computed so as if the value sent in a selected bid = 10% of the cap then that address receives 10% of the tokens issued.

As an example, if the issuer wants to have 1M tokens and issue 100k tokens, then the generateToken function would produce the contract so that it has the 1M tokens and a bid for 10% of the cap would allocate 10% of the issuable tokens, so 100k * 10% = 10k tokens.

As an aside, to reduce costs of memory allocation during the ERC20 contract creation, then the function could deploy the token contract before the iterations and then the iteration function could execute and immediately populate the token contract.