ERC667 suffers from the same problem as ERC223: if the receiving contract does not define the receiver function, ERC667Receiver.onTokenTransfer, then the receiving contract's fallback function will be called instead, and there is no way for the caller to know that this has happened, if the fallback function does not revert. This means that the purpose for which ERC667 was even created (ensuring that tokens can only be sent to contracts that actually support receiving them) is thwarted.
Please see ERC777/ERC1363/ERC4524 for how this should properly be handled, via ERC1820 or ERC165 interface registration, and (for ERC1363/ERC4524) return of a magic value (the function selector) to signify that the correct function has been called.
Also, onTokenTransfer is supposed to return (bool success), but the reference implementation doesn't even check the return value:
https://github.com/smartcontractkit/LinkToken/blob/master/contracts/v0.4/ERC677Token.sol#L35
ERC667 suffers from the same problem as ERC223: if the receiving contract does not define the receiver function,
ERC667Receiver.onTokenTransfer, then the receiving contract's fallback function will be called instead, and there is no way for the caller to know that this has happened, if the fallback function does not revert. This means that the purpose for which ERC667 was even created (ensuring that tokens can only be sent to contracts that actually support receiving them) is thwarted.Please see ERC777/ERC1363/ERC4524 for how this should properly be handled, via ERC1820 or ERC165 interface registration, and (for ERC1363/ERC4524) return of a magic value (the function selector) to signify that the correct function has been called.
Also,
onTokenTransferis supposed to return(bool success), but the reference implementation doesn't even check the return value:https://github.com/smartcontractkit/LinkToken/blob/master/contracts/v0.4/ERC677Token.sol#L35