Cross-posting some arguments I made in another thread regarding EIP-5298 to consider supporting EIP-1363 or not:
ERC721 and ERC1155 has established
safeTransferFromas a naming convention that EIP-1363 is ignoring and create a new name
transferAndCall, if the
transferAndCallfunction is being used to only verify the recipient account being a contract account
On the other hand, if the
transferAndCallfunction 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.
transfer(to, value, data)assume it can call the
tobut doesn’t support specifying
ether Valuewhich 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