I agree with most of the ideas behind ERC223 and it fits closer with what I think a token should do. However, the ERC20 backwards compatibility story is not flawless.

I've searched around for examples and I've found contracts that emit both the ERC20 Transfer event and an ERC223 Transfer event for every transfer. This sounds bad. Transfers appear fine (once per transfer) in Etherscan, but there are still 2 events emitted behind the scenes, so anyone viewing raw events would see 2.

Example: https://etherscan.io/address/0x40395044Ac3c0C57051906dA938B54BD6557F212#code (see lines 158 and 159).

What are some options for developers of new tokens?

  1. Stick with ERC20 and its flaws.
  2. Support only ERC223.
  3. Support both, emitting the two Transfer events for each transfer.

Some questions:

  1. How bad is it to have 2 Transfer events?
  2. If I only had 1 Transfer event, the token would not be fully compliant with either ERC20 or ERC223. How bad is that? I am considering supporting only the ERC20 Transfer event, and leaving an enum in the contract that toggles this decision between 1, 2, or both.

What do you guys think?

It is not that bad to have two events. The event names are similar but their signature is very different. A wallet should only use the signature to refer an event.

  • Transfer(address,address,uint256) has signature 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
  • Transfer(address,address,uint256,bytes) 0xe19260aff97b920c7df27010903aeb9c8d2be5d310a2c67824cf3f15396e4c16

An ERC20 only wallet will ignore completely the second event.

An ERC223 aware wallet can check for both and ignore the first if both are present in the same transaction.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.