Why is it necessary to read the returned bool value when interacting with ERC20 contracts using transferFrom() and transfer()? What security vulnerabilities might arise if it's not done?
The ERC-20 spec defines the functions with a bool success return value. Reverting when an operation like transfer fails is specified as a "SHOULD" behavior, i.e. it's a recommendation and not strictly required by the spec. A compliant implementation could return false if the operation failed, and you want to catch that.
That would (and in fact did) lead to erroneous implementation of various ERC20 contracts.
The EIP20 actually states MUST rather than SHOULD:
Unfortunately, some contracts - especially in the early days of DeFi - chose to ignore this requirement, forcing the entire ecosystem to implement the SafeERC20 (protection mechanism) wrapping layer.
I think you misunderstood my post.
I meant that it's optional for a compliant implementation of transfer to revert if the transfer fails. This is clearly listed as SHOULD (link).
Thanks for sharing that other part though, I had not seen that. It's very clear that one must handle a possible false return value. This is a consequence of the SHOULD for implementations that I mentioned.
Oh, sorry, I get what you mean now.
I suppose that this is exactly the reason behind the "non-compliance turmoil" which has followed, since those who chose to revert rather than returning false, must have figured that they didn't need to declare the function as a function which returns (bool).
I guess that perhaps this is what you meant by "This is a consequence of the SHOULD"...
1 Like
Exactly, but that was completely wrong.