(This gist is created to render a post at ethereum research forum, no clue whose genius idea it was to restrict publications on a RESEARCH FORUM to 2 links per post but it is definitely not that smart)
ERC-20 standard is designed in a way that violates secure software design practices which resulted in (1) impossibility of handling transactions and (2) the implementation of pull transacting method which is not suitable for decentralized trustless assets and must be avoided.
The impossibility of handling transactions in turn resulted in impossibility of handling errors.
The impossibility of handling errors resulted in the fact that “it’s possible to send erc20 tokens to token contract address” as @p_m said but this is just the top of the iceberg. The root of the problem is a bit more complicated.
It must be noted that:
-
It is not possible to send plain ether to any contract address that is not designed to receive it, the tx will get reverted because ether implements transaction handling
-
It is not possible to send ERC-223 token to any contract address that is not designed to receive it because ERC-223 implements transaction handling
-
It is not possible to send ERC-721 NFT to any contract address that is not designed to receive it because the transferring logic of ERC-721 is based on ERC-223 and it implements transaction handling
-
It is only possible to send ERC-20 token and lose it to a software architecture flaw that does not implement a widely used mechanism Lack of error handling is a cruel violation of secure software designing principles and it resulted in a loss of $130M worth of ERC-20 tokens already.
I would like to invite researchers to investigate the problem of Ethereum token standards and most notably ERC-20. I am the author of ERC-223 token standard and a security expert.
- I've created a security auditing organization that audited more than 300 smart-contracts and not even a single one was hacked afterwards
- I was doing security audits myself.
- I have launched a successful consensus-level attack on one of the top5 chains of its time
So, I kinda know what I'm talking about.
I'm stating that ERC-20 is an insecure standard. It has two major architecture flaws:
-
Lack of transaction handling: https://dexaran820.medium.com/known-problems-of-erc20-token-standard-e98887b9532c
-
approve & transferFrom is a pull transacting pattern and pull transacting is not designed for trustless decentralized systems so it poses a threat to users' funds safety there: https://dexaran820.medium.com/erc-20-approve-transferfrom-asset-transfer-method-poses-a-threat-to-users-funds-safety-ff7195127018
Today users lost at least $130M worth of ERC-20 tokens because of the above mentioned design flaw of the standard.
First, I described this issue in 2017. This can be a precedent of a vulnerability discovery in a "final" EIP. The EIP process does not allow changes even upon vulnerability disclosure.
-
It caused people to lose $13K when I first reported it.
-
Then it became $16K when I reported it and had a discussion with Ethereum Foundation members.
-
Then it became $1,000,0000 in 2018.
-
Then the author of ERC-20 standard stated he doesn't want to use it in his new project (probably because he knows about the problem of lost funds...).
-
And today there are $130,000,000 lost
Ethereum Foundation didn't make any statement about this so far. This issue fits in "critical severity security vulnerability" according to OpenZeppelin bug bounty criteria OpenZeppelin/openzeppelin-contracts#4474
You can find the full timeline of events here https://dexaran.github.io/erc223/