Why isn't there an ERC for `safeTransfer` for ERC-20?

ERCs
, ,
21

Cross-posting some arguments I made in another thread regarding EIP-5298 to consider supporting EIP-1363 or not:

  1. ERC721 and ERC1155 has established safeTransferFrom as a naming convention that EIP-1363 is ignoring and create a new name transferAndCall, if the transferAndCall function is being used to only verify the recipient account being a contract account

  2. 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 of transfer(to, value, data) assume it can call the to but doesn’t support specifying ether 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.

  1. explain how the magic word is computed,
  2. it should mandate the caller to restrict any state change on calling onERC20Received e.g…
22

Would split this ERC. And put ERC165 on top of ERC20 into separate EIP to make it clear.

1 Like
23

Reviving this thread as I think this is an interesting EIP.

Regarding the reentrancy issue that was brought up by @frangio, wouldn’t proper design patterns and/or a reentrancy guard solve this issue? Restricting the hook to a STATICCALL would make it impossible for the recipient contract to perform any kind of accounting, for example.