I had a discussion with 1363’s author, and I think this whole thing is worth a discussion.
I identified two sub-problems, and sometimes depending on your point of view, the resulting code might be different:
- Being able to prevent transfers to address that can’t recover the funds (contracts that are not token aware)
- Being able to notify the recipient that tokens have been sent.
I’ll call that the
safeTransfer problem vs the
ERC-721 solves both with a single mechanism, the
onERC721Received combo. Its important to notice that for smart contract recipients, the two problem are very similar:
- you do the transfer
- notify the receiver through a public hook
- the receiver can check the msg.sender, accept or deny the transfer, and take any subsequent action (with user data passed through)
- the token will revert if the receiver did not accept the transfer
plain and simple.
ERC1363 does that on top of ERC20.
But there is a difference when the receiver is not a contract. If the receiver is an EOA (or more generally an address without code), then the callback will successed, but return no data … (when you expect some byte4 to be returned for security against fallbacks)
ERC721 says that, you should be able to safe transfer to an EOA and not care about data being returned.
IN OZ, this is currently implemented doing this
ERC1363 isn’t specific about EOA, leaving (IMO) room for interpretation. However, the author’s intensions (from its implementation and our discussion) it that he expected
transferAndCall to revert if the target is not a contract. This would make 1363 a acceptable solution for the
transferAndCall problem but not for the
IMO, it would be enough for 1363 to not revert when targeting an EOA to address both problems, just like 721 does. Still, there is an ambiguity about 1363, and the author is meaning toward an interpretation that is not suitable for some usecases.
I fear that the
safeTransfer problem will justify the existence of another ERC, which would not revert on EOA (but otherwise be identical). If such a competing ERC is to exist, then I believe that it should reuse 1363’s hook … because the hook is only used for contracts, and contracts don’t care if they are called by a function that revert/doesn’t revert with EOAs … as long as the intension of the caller is clear.