Cross-posting some arguments I made in another thread regarding EIP-5298 to consider supporting EIP-1363 or not:
-
ERC721 and ERC1155 has established
safeTransferFrom
as a naming convention that EIP-1363 is ignoring and create a new nametransferAndCall
, if thetransferAndCall
function is being used to only verify the recipient account being a contract account -
On the other hand, if the
transferAndCall
function is being used anything other than verifying the recipient account being a contract account, e.g. to conduct a general function call, I think there is a lot of limitations of EIP-1363 for example, the parameter choice and implied technical direction of EIP-1363 has significant restrictions, e.g.
- the
value
oftransfer(to, value, data)
assume it can call theto
but doesn’t support specifyingether Value
which makes it not able to support general case of a remote function call that includes ethers required. - It also doesn’t support extra data so it couldn’t make a more flexible call
- It doesn’t support a transfer call to specific which method inside of that recipient function to call, and restricting it to only
onTransferReceived
, renders it much less useful other than just verifying the recipient being an account, and instead introduced a lot of risk of re-entry attack.
With such consideration, and also explained by original author of EIP-1363 @vittominacori , I agree see there is a legitimate distinction between EIP-1363 and EIP4524 and a valid need for a safeTransfer/safeTransferFrom for ERC20s.
I also see that EIP-4524 also has some place of improvements, e.g.
- explain how the magic word is computed,
- it should mandate the caller to restrict any state change on calling
onERC20Received
e.g…