Learn more about reusing OpenZeppelin smart contracts to create customised ERC20 token and ICO that match your business model
Ethereum is the largest smart contract platform that enables developers to create quasi-Turing complete applications running on the blockchain. Ethereum community understands the critical role of standards and collaboration in growing the ecosystem. Many startups find creating their cryptocurrency a lucrative way to collect funds for further growth.
In this article, I would like to focus solely on technical aspects of issuing and distributing ERC20 tokens.
You can find the up-to-date code in the repository on GitHub: https://github.com/tooploox/ethereum-ico-examples
ERC20
Ethereum Improvement Proposals (EIPs) are standards for Ethereum platform. Anyone can fork the repository on GitHub and share his idea with the community. One of the standards is the ERC20 token specification which defines a common interface for smart contracts storing users’ balance of fungible tokens, sometimes, referred to as a cryptocurrency.
Other standards (e.g. ERC223) improve upon ERC20 to mitigate certain issues like freezing tokens on smart contracts that are not designed to support token transactions. Nonetheless, ERC20 is the most often used type of token that facilitates the exchange in implementing support for new crypto assets thus allowing for broader adoption and high liquidity (less volatility).
This is a standard interface for the ERC20 token.
Some implementations also feature three additional properties that can provide us with some details about the token. 18 is the most common number of decimal places, the same as in the case of ether that is 10^18 wei.
Head to EIPs repository for an in-depth explanation: https://github.com/ethereum/EIPs/issues/20
OpenZeppelin is a library that consists of multiple, reusable contracts including puzzles to build ERC20 tokens. You might be a bit lost in the dependency trees at the beginning as I was. The following diagram presents all token-related contracts to guide you through the implementation of your ERC20 token.
StandardToken is a typical implementation of your ERC20 token. StandardToken additionally implements `increaseApproval` and `decreaseApproval` methods, which are safer to use than the standard `approval` method due to frontrunning vulnerability. You can read more about this and other common vulnerabilities here: https://blog.sigmaprime.io/solidity-security.html#race-conditions
MintableToken extends StandardToken adding the `mint` method. Minting is the process of creating new tokens out of thin air, and only the owner of the token contract can mint new tokens. CappedToken is the extension of the MintableToken and introduces cap, which is a maximal amount of tokens that can be minted. RBACMintableToken allows for managing creators of new tokens.
PausableToken changes StandardToken in the way that transferring tokens is impossible when the token is paused. Only the owner can pause and unpause the smart contract.
There is a little code to add when using OpenZeppelin to create a new ERC20 token. I am going to use Truffle, development framework which makes using external packages, migrations, and testing possible.
The goal of this exercise is to create the SimpleToken, ERC20 token, which assigns the entire supply to its creator making it responsible for further token distribution.
Token expects four parameters, which we have to specify in the migration script – name, symbol, number of decimal places, and the total number of tokens without decimal.
Let’s deploy our contract and see how you can interact with it.
The beauty of standardization is compatibility. We can now add our token to MetaMask wallet. Open MetaMask and switch from the default “SENT” tab to “TOKENS”. Click “Add Token” button and paste token contract address. MetaMask will fetch token symbol and decimals of precision from the contract.
Make sure you connect to the right network. In case of messed up balances, try to reset accounts in the MetaMask settings.
Crowdsale
The idea of a crowdsale, ICO, or a token sale is simple. You can automate exchanging your tokens for the base cryptocurrency, ETH in our example, and you do it with a smart contract.
In general, crowdsale smart contract owns tokens (or is allowed to mint them) and sends them to the user that transfers it some ether. The number of tokens the user gets for his ether is determined by the rate, which is usually a parameter for the crowdsale smart contract and may change with time.
This simplified crowdsale example shows how you could implement a token sale. You probably want to use OpenZeppelin anyway.
Let’s assume that you have to start your ICO with a presale. What is a presale? Usually, presale is the round 0. Presale has the best rate, maybe also a fixed bonus and is available only to registered users that are early believers in the project. They also take the highest risk investing in the unproven project.
The other type of the crowdsale we need in our project is a time-bounded token round. You might want to have the possibility to spin up a few rounds and let the market decide on the future crowdsale rate.
Let’s start with deploying only the presale crowdsale. Since this crowdsale is the allowance crowdsale, it uses allowance balance for distribution instead of its own balance, which makes a lot of sense when you plan to run more than one token sale round.
After deployment, you can spin up Truffle console and play with it.
Do not forget to whitelist the second business. The rate we pass to the constructor determines the number of tokens you get in exchange for your ether. Thus, sending 1 ETH buys you 1000 TPX tokens.
Front-end
It might be a good idea to make it easier for investors or early adopters to participate in the crowdsale through your website. You just have to integrate with the crowdsale smart contract and fetch some additional information about the token, exchange rate etc.
Vesting
It is a common practice for authors of a project to declare that they keep a part of distributed tokens for themselves. This is reasonable because it is a reward for their big efforts when developing. Unfortunately, there are more and more scams in this business, since it is an easy way of drawing money from investors and disappearing with millions of dollars in a pocket.
One of the ways of preventing the fraud and keeping developers motivated is releasing tokens progressively, not all at once, at the very beginning of the project. This practice is called token vesting.
OpenZeppelin provides a simple implementation of the contract that we can use in order to lock tokens for the given period of time. The beneficiary will be able to release the first part of tokens when the time cliff passes. Then, the tokens are distributed in the defined period of time progressively. We can deploy the token vesting contract for each beneficiary and transfer some percentage of tokens to each and the rest to the crowdsale contract.
The disadvantage of this idea is the lack of possibility of managing beneficiaries in time. Maybe another developer is joining the team and we want to give him some shares when the vesting already started. We prepared a simple example of how the multi-beneficiary token vesting contract could look like. The source code is available here. This vesting strategy assumes that the total number of tokens allocated in the vesting contract is distributed between beneficiaries according to their shares ratio.
To illustrate it, let’s imagine we have two developers at the very beginning of the vesting. Each of them has 100 shares. The total number of tokens is 900k. The duration of the vesting is 3 years. In this case, after the first year, developers would be able to release 300k tokens (900k / 3 years). This number would be distributed among two developers, each of whom has 50% shares (100 / 200, where 200 is the sum of all shares), so each developer would receive 150k tokens at that time. But now they decide to give 50 shares to another beneficiary, so the division is 100/100/50. When the next year passes, two developers having 100 shares would receive 120k (300k * 100 / 250) tokens and the one having 50 shares – 60k tokens.
Take a look at the source code of the contract and tests. Also, check the sample of a migration that illustrates how to deploy a token, a crowdsale, and a multi-beneficiary token vesting together using truffle framework.
Authors:
Michał Załęcki
Mariusz Żak
