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?
- Stick with ERC20 and its flaws.
- Support only ERC223.
- Support both, emitting the two Transfer events for each transfer.
- How bad is it to have 2 Transfer events?
- 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?