Callisto Network

<a href="https://ethereum.org/en/developers/docs/standards/tokens/erc-20/" rel="noopener noreferrer nofollow">ERC-20 token standard</a> contains a major logical flaw — a lack of communication model (lack of transaction handling model).This problem is well-known. I wrote tens of articles on Ethereum Reddit, Gitter, and GitHub during the past 6 years. Starting from <a href="https://www.reddit.com/r/ethereum/comments/60ql37/attention_be_careful_using_ethereum_tokens/" rel="noopener noreferrer nofollow">this post</a>. Also, <a href="https://dexaran820.medium.com/response-to-vitaliks-speech-about-erc-23-ad240a27490f" rel="noopener noreferrer nofollow">here is Vitalik Buterin’s comment</a> on this.The solution exists. In 2017 I proposed the <a href="https://github.com/ethereum/eips/issues/223" rel="noopener noreferrer nofollow">ERC-223 token standard</a>. ERC-223 implements a transaction handling model for tokens. (Note that ERC23 and ERC-223 is the same thing, ERC23 is just the old deprecated name)<h2 id="header-0">Lost ERC-20 tokens</h2>Let’s take a look at the <a href="https://etherscan.io/address/0x6b175474e89094c44da98b954eedeac495271d0f#code" rel="noopener noreferrer nofollow">DAI contract address</a>. This address has $647,211 worth of ERC-20 tokens on its balance.<img src="https://coinmarketcal-share.s3.eu-west-1.amazonaws.com/News/photo_2023-03-16&#43;23.53.09.jpeg" />But it’s a token contract — the token contract is not intended to receive and hold any tokens. The token contract is intended to only be the token.<img src="https://coinmarketcal-share.s3.eu-west-1.amazonaws.com/News/photo_2023-03-16&#43;23.53.08.jpeg" />There are not only DAI tokens in the contract; there are some USDC and USDT as well.<h2 id="header-1">How does this happen?</h2>Here is <a href="https://dexaran820.medium.com/erc20-token-standard-critical-problems-3c10fd48657b" rel="noopener noreferrer nofollow">the description of ERC-20 problems</a> that was posted on Ethereum Reddit.Users accidentally sent tokens to a DAI contract address by mistake, and the contract successfully received tokens when it mustn’t receive them.It is known for sure that the DAI contract (and any other token contract) is not intended to receive any assets.- This contract WILL NOT receive Ether if it is sent to the contract address — in this case, an error will occur, and the transaction will fail. ETH will be returned to the address of the sender.- The contract WILL NOT receive ERC-223 tokens — an error will occur similar to that of an Ether transaction.- The contract WILL NOT receive ERC-721 NFTs if it is not intended to, and the transaction will fail; no NFTs will be lost.- The contract WILL receive ERC-20 tokens without any errors (despite it being known that the transaction can only be a mistake), and the tokens will become stuck in the contract address without any possibility of recovering them. The user will just lose his funds.This constantly happens because it is not possible to handle ERC-20 transactions at all. Ether transfer notifies the recipient of an incoming transaction, ERC-223 notifies the recipient, ERC-721 notifies the recipient, and ERC-20 does not.<h2 id="header-2">Technical description of the ERC-20 problem</h2><a href="https://gist.github.com/Dexaran/ddb3e89fe64bf2e06ed15fbd5679bd20" rel="noopener noreferrer nofollow">Read more about ERC-20 problem classification here</a>.In programming, <a href="https://en.wikipedia.org/wiki/Event_%28computing%29" rel="noopener noreferrer nofollow">event handling</a> is standard practice. When one program (such as a token contract) is performing some action that involves another program, it must notify that program. A transaction is an event, and the recipient of the transaction must be able to get a notification on the incoming transaction and handle it.The “final” ERC-20 documentation can be found here: <a href="https://eips.ethereum.org/EIPS/eip-20" rel="noopener noreferrer nofollow">https://eips.ethereum.org/EIPS/eip-20</a>According to ERC-20 EIP, it defines two methods of transferring tokens:- <a href="https://github.com/OpenZeppelin/openzeppelin-contracts/blob/3214f6c2567f0e7938f481b0a6b5cd2fe3b13cdb/contracts/token/ERC20/IERC20.sol#L41" rel="noopener noreferrer nofollow">transfer()</a> function, assumed to be used to transfer tokens between addresses owned by humans.- <a href="https://github.com/OpenZeppelin/openzeppelin-contracts/blob/3214f6c2567f0e7938f481b0a6b5cd2fe3b13cdb/contracts/token/ERC20/IERC20.sol#L77" rel="noopener noreferrer nofollow">transferFrom()</a> function that requires that an approval between sender and spender is issued first. Assumed to be used when a user needs to deposit tokens to contract.None of these functions notifies the recipient about the incoming ERC-20 transfer. ERC-20 standard does not declare the logic of sending tokens directly to contracts at all.In order to avoid the situation where a user sends tokens and these get lost in a contract that can’t operate with them, the following conditions must be met:- If the token is sent to a contract directly and ERC-20 does not support this type of depositing tokens — then an error must occur.- If the ERC-20 token is sent to a contract that is not intended to receive tokens — then an error must occur.In order to reject an incoming ERC-20 or throw an error, the recipient must recognize the incoming transaction. And this is exactly the problem of the ERC-20 standard — it does not let the receiver recognize an incoming transaction.<h2 id="header-3">How many tokens are lost due to this flaw?</h2><h3 id="tens-of-millions-of-dollars-worth-of-erc-20-tokens">Tens of millions of dollars worth of ERC-20 tokens.</h3>On 27 Dec 2017, there were about $3,000,000 worth of ERC-20 tokens stuck in the contracts (you can find the number on <a href="https://github.com/ethereum/eips/issues/223" rel="noopener noreferrer nofollow">this thread</a>).There is a public record — a Twitter<a href="https://twitter.com/Dexaran/status/1303630642052321280" rel="noopener noreferrer nofollow"> thread where one person described how $1,000,000 worth of USDT</a> was lost in the contract exactly because of this ERC-20 flaw.As of today (3/9/2023), only in the next contracts there are more than $11 million tokens that were lost by users due to ERC-20&#39;s lack of transaction handling:- $6,800,000 are lost in BNB contract <a href="https://etherscan.io/address/0xB8c77482e45F1F44dE1745F52C74426C631bDD52" rel="noopener noreferrer nofollow">https://etherscan.io/address/0xB8c77482e45F1F44dE1745F52C74426C631bDD52</a>- $2,600,000 are lost in SHIB contract <a href="https://etherscan.io/address/0x95ad61b0a150d79219dcf64e1e6cc01f0b64c4ce" rel="noopener noreferrer nofollow">https://etherscan.io/address/0x95ad61b0a150d79219dcf64e1e6cc01f0b64c4ce</a>- $1,700,000 are lost in HEX contract <a href="https://etherscan.io/address/0x2b591e99afe9f32eaa6214f7b7629768c40eeb39" rel="noopener noreferrer nofollow">https://etherscan.io/address/0x2b591e99afe9f32eaa6214f7b7629768c40eeb39</a>- $80,000 are lost in USDT contract <a href="https://etherscan.io/address/0xdac17f958d2ee523a2206206994597c13d831ec7" rel="noopener noreferrer nofollow">https://etherscan.io/address/0xdac17f958d2ee523a2206206994597c13d831ec7</a>- $549,000 are lost in MATIC contract <a href="https://etherscan.io/address/0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0" rel="noopener noreferrer nofollow">https://etherscan.io/address/0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0</a>- $526,000 are lost in UNI token contract <a href="https://etherscan.io/address/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984" rel="noopener noreferrer nofollow">https://etherscan.io/address/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984</a>- $238,000 are lost in BUSD contract <a href="https://etherscan.io/address/0x4Fabb145d64652a948d72533023f6E7A623C7C53" rel="noopener noreferrer nofollow">https://etherscan.io/address/0x4Fabb145d64652a948d72533023f6E7A623C7C53</a>You can open any contract on Etherscan and watch the amount of tokens that it holds. If the contract is not intended to receive tokens (it is not a DEX contract and not a multi-sig) — then the tokens are lost due to an ERC-20 transaction that must be rejected, but it wasn’t.<h2 id="header-4">How this issue can be solved?</h2>This is the issue of the adoption of the ERC-20 standard as it is. Unfortunately, recovering already lost tokens is not possible, but we can prevent this issue in the future.<a href="https://eips.ethereum.org/EIPS/eip-223" rel="noopener noreferrer nofollow">ERC-223 is now on the list of EIPs.</a>It is important to spread the word about the issue to convince the token developers of new tokens to pay attention.Here is a good example of what can be the root of the problem:1. <a href="https://www.reddit.com/r/storj/comments/6ajjo3/attention_issues_of_the_upcoming_storj_migration/" rel="noopener noreferrer nofollow">I warned STORJ developers</a> that using the ERC-20 standard can be dangerous and will surely lead to the losses of funds for their users.2. STORJ developers <a href="https://www.reddit.com/r/storj/comments/6ajjo3/comment/dhf95qz/?utm_source&#61;reddit&amp;utm_medium&#61;web2x&amp;context&#61;3" rel="noopener noreferrer nofollow">replied</a>, “we know, but everyone is using ERC-20, so we will use it too despite knowing of its problems and losses of funds”.3. Users&#39; funds <a href="https://www.reddit.com/r/storj/comments/6t2czj/5000_are_lost_storj_erc20_tokens_are_vulnerable/" rel="noopener noreferrer nofollow">got lost on the STORJ contract</a>, as it was expected.So far, ERC-223 is still the most suitable solution, in my opinion, but any other token that supports the communication model could work. NFTs are safe, and ERC-721 implements a communication model derived from ERC-223.Right now, I am building the ecosystem for ERC-223 tokens:- Token Wrapper ERC20&#61;&gt;ERC223 — a contract that will allow to create “wrapped tokens” for each ERC-20 contract. Wrapped ERC-223 tokens will be backed 1:1 by the original ERC-20 tokens and can be switched back to ERC-20 at any moment. This would open up the opportunity to utilize the advantages of ERC-223 without having to delete and reconstruct the whole token ecosystem. <a href="https://github.com/Dexaran/ERC223_to_ERC20_wrapper" rel="noopener noreferrer nofollow">https://github.com/Dexaran/ERC223_to_ERC20_wrapper</a>- DEX that supports ERC-223 standard (already deployed on Ethereum main net): <a href="https://github.com/SoyFinance/smart-contracts" rel="noopener noreferrer nofollow">https://github.com/SoyFinance/smart-contracts</a>- ERC-223 extensions, examples, and documentation updates on Ethereum<h2 id="header-5">Frequent arguments</h2>This is not a problem of the token standard; stupid users just send their tokens to the wrong address. User mistake, not a flaw of ERC-20.1. When a user sends tokens to the wrong address — it is the user’s fault. When a contract accepts tokens that it shouldn’t accept— that’s the contract’s fault.2. This is a serious problem anyways; tens of millions of dollars are lost already, and the amount is growing with each year and each day. It is solvable. So why just leave it as it is while it can be solved?3. ETH can’t be transferred to a contract that is not intended to receive it. ERC-223 can’t be transferred to a contract that is not intended to receive it. NFT can’t be transferred to a contract that is not intended to receive it. Only ERC-20 can be transferred to a contract and get stuck there.It can be solved on the side of a UI.--&gt; The issue exists for 6 years already; the amount of lost tokens only grows with time, so it doesn’t work this way.This problem can be solved with ERC-20, just need to prevent deposits of tokens to the same contract address.--&gt; No. Every contract that is not intended to work with ERC-20 tokens can receive them, and there is no way to recognize and subsequently reject the improper transaction for the recipient. That’s a bigger problem. Not just stuck tokens in token contracts.ERC-677 TransferAndCall solves this issue.--&gt; No, it doesn’t. If a token standard does not declare the logic of transferring tokens and only declares the API, then it does not solve the issue.<h2 id="header-6">Contacts</h2>Have you lost your tokens, need any other assistance, or have a question? Feel free to contact me:- Emails: dexaran820&#64;gmail.com (preferred) / dexaran&#64;callisto.network / dexaran&#64;ethereumclassic.org (only highest priority)- Github: <a href="https://github.com/Dexaran" rel="noopener noreferrer nofollow">https://github.com/Dexaran</a>- Twitter: <a href="https://twitter.com/Dexaran" rel="noopener noreferrer nofollow">https://twitter.com/Dexaran</a>- Telegram <a href="https://t.me/Dexaran" rel="noopener noreferrer nofollow">t.me/Dexaran</a>

Uncovering the Major Flaw in ERC-20 Token Standard & the Promising Solution

Spis treści

Callisto Network

Inne artykuły opublikowane 18 mar 2023

Why Shibarium Beta Testnet Does Not Have a Unique Blockchain ID? 5 Million+ Bone Unstaked

HNT Price Prediction: Will Helium Token Recover Amid Market’s Turmoil?

Alpha Mainnet Update

It’s DAO or Never

Binance Replaces BUSD Stablecoin in ‘SAFU’ Fund With TUSD and USDT

SBF set to agree on fresh bail conditions

Zapisz się na bezpłatny newsletter i otrzymuj codzień aktualności ze świata kryptowalut!