Critical problems of ERC20 token standard

Dexaran
2 min readJun 16, 2017

Source: https://www.reddit.com/r/ethereum/comments/6h17aw/critical_problem_of_erc20_tokens/

This is a description of issues of ERC20 token standard, which is widely used for Ethereum ICOs. ERC20 tokens have two critical issues that are causing money losses for token users.

1. Lack of transaction handling.

There are two ways of performing a transaction in ERC20 tokens:

1. `transfer` function.

2. `approve` + `transferFrom` mechanism.

Event handling is a standard practice in programming (Ethereum transaction should be considered an event): https://en.wikipedia.org/wiki/Event_(computing)

Unfortunately, ERC20 token standard lacks event (transaction) handling/emitting mechanism.

The `transfer` function will not notify the recipient that the transaction happened. The recipient will not be able to recognize the incoming transaction! I wrote this illustration of the process that is leading to unhandled transactions and, as a result, stuck tokens and lost funds for users.

Token balance is just a variable inside token contract.

Transaction of a token is a change of the internal variables of the contract (the `balance` of the sender is decreased and the `balance` of the recipient is increased).

As a result, if the recipient is a contract, users must transfer their tokens using the approve +transferFrom mechanism. If the recipient is an externally owned account address then users must transfer their tokens via the transfer function. If a user will make a mistake and choose a wrong function then the tokens will get stuck inside contract (contract will not recognize a transaction). There will be no way to extract stuck tokens and the user will just lose his funds represented by this token.

Reliance on an assumption that no one will ever make a mistake was a mistake on its own. Some users are constantly using a wrong function to deposit tokens into contract and it is leading to huge financial losses for Ethereum users.

2. approve + transferFrom mechanism is potentially insecure. Re-approval attack.

`approve` + `transferFrom` mechanism allows double spents.

A possible attack is described here.

My previous articles regarding the problem.

article #1

article #2

article #3

article #4

article #5

article #6

article #7

--

--