first in a series of articles about public token sale models
Whoever thought that it would be so easy to raise tens of millions of dollars in an hour? Has anyone coin-ed a term for this ICO disbelief I’m feeling?
The ICO craze has certainly taken the world by storm recently and everyone is jumping in to raise money for their new idea. There are over 25 sales happening at this moment and lots more to start in the coming weeks, and on the surface this seems great, but are our models of offering tokens to the public as robust and well documented as they should be? Or are we just throwing our sales out there without thinking very much about the implications of how we design them?
wrote a great post about token sale models a few months ago, but the topic needs more discussion. Lets talk about ICO models.
An ICO, or Initial Coin Offering, is an event, sometimes referred to as ‘crowdsale’, when a company sells its own utility token with a purpose of funding their projet. It usually releases a certain number of tokens and then sells those tokens to its intended audience, most commonly in exchange for Ether.
Companies have many goals in an ICO, most importantly to raise the capital to fund their project’s development. If the organization means business, they also care about distributing the tokens so that there is already a large network of users who own their tokens, ready to use them on the platform once it is released. Companies can choose either reason, but striving for both is the best. It is beyond the scope of this article to discuss how organizations use their tokens as a utility on their platform, but, over the course of a few posts, I would like explore a few different models that companies choose to distribute tokens to the general public for their ICOs and the pros and cons of each. Through these explanations we can discern the reasons for using different models, how each model effects the Ethereum network, the intended distribution of tokens, and how much money is raised. We can then find similarities and differences between the models and group them into different classes depending on what each company needs for their sale. This article and future articles in the series will not focus on how companies allocate their tokens between the company, pre-sale, investors, and public, or how tokens are valued, but on how the public token sales operate and how they are implemented.
Before I go into any details about specific models, I should point out something that most of us have probably realized in our research. While there are different models that function in unique ways, each crowdsale also has many similarities. Let’s lay out a set of traits and functions that all token sales will share in their specifications, starting with simple traits, or from a coding standpoint, variables, that all ICOs will share.
For the common variables, we can assume all sales will have an owner specified, a start time, an end time, and a unique token contract that it is using for the sale. Next, there will be an ETH-token exchange rate, or token price, which most of the time will be calculated using the most up to date fiat-ETH exchange rate and whatever model the sale uses to price tokens. There should also be a record of the total amount contributed in the sale, how much each address has contributed to the sale in wei (smallest denomination of Ether), a record of how many tokens an address has purchased, and a record of any unused wei that the buyer might have contributed that didn’t add up to a whole number of tokens. Hopefully they don’t feel like they wei-sted them.
Now that we’ve figured out a set of variables that each token sale would share, lets go through the functionality common across most crowd sale models.
Firstly, we need functionality to set/change the token price, as token prices tend to change throughout most sales.
Then we need a function for buyers to withdraw their purchased tokens and, similarly, a function for buyers to withdraw their excess Wei. In every sale, these will be called after users have submitted purchases and tokens have been allocated to their accounts for them to withdraw. Lastly, we need a function for the owner to withdraw their raised Wei at the end of the sale.
You probably noticed that I didn’t mention a function for buyers to purchase tokens. I left that out because, while all token sales will have some mechanism to purchase or bid on tokens, each token purchase will have very different functionality depending on the model.
Firstly, lets talk about the Fixed Exchange Rate, or Direct Crowdsale Model. This is the most common model that has been used for crowdsales. The high level overview is as simple as Ether in, tokens out. A buyer exchanges Ether for tokens at a fixed ratio. In some instances, the token price will increase or decrease over time. This is a simple and somewhat viable model for a token sale but it has some drawbacks.
First, we’ll cover the advantages:
Examples: ALMOST EVERY ICO
Next, let us explore the disadvantages to running a Direct Crowdsale Model:
As you can see, it is possible to run a token sale like this, but companies only should under certain circumstances. If the sale is going to be relatively small with not very much demand, a sale of this type might be good because of the simplicity in design and ease of use, but if it is a large, well-known project with high demand for tokens, then a different, more sophisticated model is the far better choice.
The functionality for a direct crowdsale is very basic. After checking that the sender and purchase are valid, the function checks for one of the intermittent changes in price and changes the price if needed, then calculates the number of tokens purchased, by multiplying the Wei contribution by the token price, moves the decimal point to reflect the tokens granularity, records the purchase and token amount, and credits the user with any Wei that was leftover from the exchange. Users can withdraw their tokens or leftover Wei at any time. In addition to this specification, other intricacies to this model could be added, but that is left up to the reader to imagine and design. :)
At Modular, we are working on creating open source, deployed libraries for Ethereum, and we plan to include crowdsales in our libraries. In accordance with the rules I laid out earlier in this article, we have created a base crowdsale library that includes all the common variables and functions mentioned above. Contracts can use this as a basis for any crowdsale. In addition, we have created a direct crowdsale library for fixed-rate sales which utilizes the base library to give developers a tested resource in creating their own crowd sale contracts.
You can see our libraries on our Github here. We already have libraries for a large variety of applications and are actively working on building out libraries for different ICO models. We plan to have libraries available for each major model.
We are all constantly learning and love to get feedback from the community, so if you see anything in this post or on our Github that needs clarification or improvement, we would love to hear from you in the comments or if you contact us directly at our website. We are always open to contributions from the community! Some organizations try to dig a river around their castle, but we want to Nakamoto-ut of the way (I am so sorry, I can’t help it) and help open up Ethereum to everyone.
[1] Analyzing Token Sale Models,
