Erc223 token - potential issue


I found this comment on ERC223 token on Reddit and would appreciate your view on this potential issue (error?) on Dexaran’s EERC223 coding:

"Quickly looking at the ERC223 github, I think it has a design shortcoming too:

assembly {

codeLength := extcodesize(_to)


The above code looks like it’s trying to see if _to is a contract rather than an external account (because codeLength would be > 0 if it’s a contract). However, this is the wrong assumption, because there’s an edge case where codeLength is 0 for when the contract is being deployed, i.e. called from a constructor."

Do the above allegation have any merit? and is it a real problem for the ERC223 token?


NOTE: An important point is that contract developers must implement tokenFallback if they want their contracts to work with the specified tokens.

If the receiver does not implement the tokenFallback function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement function() payable .


Practically speaking it is not a problem. Here is the attack vector that they are describing (hypothetically, I don’t think it actually works):

  1. the dev creates a specially crafted smart contract with 0 length (and I am not even sure that it is possible, if somebody wants to test this and reply to this thread I’d greatly appreciate). The blockchain returns the address of the deployed smart contract
  2. Then the dev needs to convince people to send ERC223 tokens to this address. Since the smart contract of 0 length is pretty much guaranteed to not do anything useful, these tokens shall be burned forever.

The owner of the token has to manually send the tokens to that address, there is no way a “hacker” can steal the tokens from you unless you give them away. Compare this to ERC20 where you may lose tokens by accidentally sending them to ANY smart contract address, not just the specially crafted one. Furthermore, the “hacker” would not extract any benefit from this attack, and thus it is unlikely they will spend $$$ marketing their specially made contract address. The “hacker” would simply lose money without any gain.

Sounds like creating an ICO contract and asking people to send ETH to that address is a much more dangerous attack on the blockchain, and yet Ethereum is consistently in top-3 coinmarketcap with market cap of over 10 billion USD. And in the ICO case the money goes to a single person, instead of being burned and improving the token’s scarcity. What an attack vector! :scream:

Hope this explanation makes sense. It is hard to explain nitty-gritty details of how EVM works to an audience not familiar with coding, but definitely not impossible! We are doing our best, please keep asking those questions and provide us feedback on our answers :heavy_heart_exclamation:


Sounds like I was right, creating such a smart contract (with length 0) is impossible. The edge case that they are describing is when you, as a dev, are deploying a smart contract, you can potentially burn some of your own tokens while doing so.

  1. It is physically impossible, because when you are deploying a new smart contract its balance is 0, so you can’t burn anything.
  2. Even if it were possible, you would only be able to burn tokens from your own balance. WHY? no idea :smile:


seems i understood something wrong here X)