What’s in a Token?

Evolution of ICOs: Part I

Yap Stone Money by stevenson_john

During the last year, we have seen an avalanche of successful ICOs raising more than six billion USD in 2017 alone. 2018 does not seem to fall behind that number, actually so far there were already more than three billion USD raised in the first three months of the year. With the first ICOs happening already 2014 — even before they were called ICOs — there has been an evolution of ICOs from a technical perspective. I will show some of the developments that have taken place and give a glimpse at what might happen in the future. This piece looks at the essence of an ICO itself, the token.

The mini-series is divided into three parts:

1. The Token (this piece): What is it that I am actually buying?
2. The Price: How much am I going to pay for it?
3. The Release: Once I have bought a token, how (and when) can I sell it again?

The Token: What Do I Buy?

When participating in an ICO the most important thing to consider is the token that is being sold in the ICO. Apart from the actual functionality there is a technical part to the token that influences its adaptability and usefulness in the greater ecosystem.

The Past: Self-Implemented Tokens

The first ICOs were not really called ICOs yet. They were mostly done to raise money for the implementation of new blockchains that had some different use-cases than the grandmother of all blockchains, Bitcoin. Examples for these early ICOs were Ethereum 2014, Storj 2014 or Augur 2015. Ethereum sold ether for its own blockchain that was still in development at the time of the ICO. Thus, buyers could not directly use the tokens that they bought, but had to wait until the ethereum blockchain was fully functional. Ethereum set out to extend the scripting functionality in Bitcoin on its own blockchain with a full-blown programming language to introduce smart contracts. It raised a bit more than 15 million USD. Storj also used its own implementation of a blockchain for its first ICO and raised approximately 460'000 USD.

The common theme for these early ICOs is the self-implemented token with its own blockchain: To do anything with the token, investors had to download the blockchain client, install it and let it synchronize the blockchain. Only then could they interact with the token. Furthermore, any exchange or wallet that wanted to support the token had to implement the full client for the particular blockchain. This early approach makes its proliferation complicated as it requires a lot of work from a lot of different parties.

The Present: ERC20

On Novemer, 19th, 2015 a new request for comments was posted on the Ethereum git to standardize a token interface on the Ethereum blockchain. This ERC20 interface set a rather small standard for tokens that any token should implement so that it could be transfered and queried in a standardized way. The actual interface is pretty small and consists of just six functions and two events:

The beauty of this interface is that it is a tiny interface with just three parts:

• Getters: There are three getter functions totalSupply(), balanceOf() and allowance() that are used to query the state of the token contract. Theses functions do not change the contract, but just return either the total amount of tokens, the amount of individually owned tokesn or the tokens that one is allowed to withdraw from somone else’s address.
• Functions: There are three functions transfer(), approve() and transferFrom() that actually do something and change the state of the token contract. One can either transfer tokens from one’s own address to another, one can approve another address to withdraw a certain amount of tokens from one’s own address or one can withdraw tokens from an address to one’s own address.
• Events: There are two supporting events that are used as a logging mechanism to indicate that a transfer or an approval has happened.

Soon, very many projects working on top of the Ethereum blockchain adopted the ERC20 standard and build their ICO tokens as a ERC20 token. This achieved two main goals:

1. A new project can adopt the standard and does not have to implements its own blockchain or its own token. The project can focus on the actual value proposition of the token instead of focussing on the token development.
2. Existing wallets and exchanges can implement the standard and support all tokens that use the standard immediately.

These two effects lead to a proliferation of the ERC20 standard and the usage of the Ethereum blockchain for the vast number of ICOs during the last two years. It paved the way for an easy to setup ICO infrastructure that is used by most ICOs up to today (June 2018).

The Future: Extensions of ERC20

ERC20 And Its Extensions

However, ERC20 defines basically just a token, but nothing else. In particular, it does not cater for a varying supply of tokens. Furthermore, it established a method of transfering tokens that differs from the method of transfering the base currency (ether) on the underlying blockchain.

Currently, most ICOs are still using the ERC20 standard and most wallets and exchanges support it. However, since its inceptions many extensions have been proposed. In no particular order, some of them are:

• ERC621: While the default standard has a fixed supply of tokens that must be specified in advance, ERC621 extends it with the possibility to increase or decrease the supply later on.
• ERC661: Similar to ERC621’s possiblity of decreasing the token supply, ERC661 introduces a provable burn functionality for tokens. This is useful for projects that want to have a deflationary token with a decreasing supply over time.
• ERC223: One shortcoming of the original standard is the fact that a contract cannot reject a transfer of tokens, even if it does not support the tokens. This means that a transfer of ERC20 tokens to a contract that does not implement the standard results in tokens locked forever in contract with no ability to recover these tokens from the contract. That is almost never intended. Thus, ERC223 introduces the possibility for smart contracts to reject a token transfer if it does not support the token.
• ERC827: The original standard established a method of transfering token via function call to the token contract. One calls the function transfer(address _receiver, uint _amount) to send tokens from one’s own address to the receiver. However, there is no possiblity for the token transfer to execute another function call on the receiving contract in an atomic way. That differs from the way ether itself is transfered: An ether transfer can include a function call on the receiving contract. Solidity provides the payable modifier to explicitly state that a function can receive ether when being called. With ERC20 tokens, such a workflow would result in two transactions. Firstly one would call the function on a contract and then send the tokens in a second transaction to the contract. ERC827 allows to call a function within token transfer and combines the two transactions into one again.
• ERC721: ERC20 tokens are fungible. One token can be interchanged for another and the resulting state of the contract is the same. This mirrors typical fiat currency: A coin can be exchanged for another coin of the same type, a bank note can be exchanged for another bank note of the same type while retaining the same value. ERC721 introduces non-fungible tokens that are unique and can each have a different value. These tokens are not necessarily useful for an ICO, but do have other use cases. The best know ERC721 token are the Cryptokitties. They implement a kind of trading card game on the blockchain that has been wildly successful.
• ERC777/ERC820: One of the disadvantages of ERC20 is that different semantics for value transfers as compared to a ususal ether transfer. ERC777 wants to consolidate the semantics to the common call of send(address to, uint amount, bytes32 data) so that one can send arbirtrary data along with a value transfer. Furthermore, ERC777 tokens must register with the token registry in ERC820. This allows for contracts or accounts to advertise the tokens that they either accept or reject beforehand.

Probably, in the future, we will see more tokens in ICOs that implement one of the extensions above, because they implement more of the underlying use case in a standardized way. That will simplify support for third parties (ie. wallets or exchanges) and reduce the risk of implementation bugs.

So, if you are interested in launching an ICO on Ethereum, do look at the various extensions of ERC20. They might provide a good standard for a token and relief you of the hassle to implement it on your own.

In part II of this mini series, I will look at the pricing mechanisms that are used to determine the price of a token during an ICO. In part III, I will talk about the release of the funds after an ICO has ended.

If you liked this part or you have a suggestion and/or remark, feel free to comment on the piece. As the author, I really appreciate any feedback. Also, if you liked it, please clap for it. It shows your appreciation and helps others find it.