This post is about best practices on how to handle the missing return value bug, a well-known vulnerability that exists in hundreds of ERC20 tokens that don’t return a value in their
transferFrom functions. The knock-on effect of this bug is that users may end up with their tokens locked up in some contracts, just like it happened with the BNB liquidity pool in Uniswap.
After reading the OpenZeppelin Erc20 README, I understand the following things:
- ERC20.sol is the core implementation, which correctly adheres to the Erc20 standard
- SafeERC20.sol is an extension to the core implementation that fends off against other non-compliant tokens like BNB or OMG
It is this “fends off” that I want to shed some light on with this post. Are the following statement correct?
- A contract that extends only from ERC20.sol puts its users’ funds at risk, should they ever deposit vulnerable tokens.
- A contract that extends from both the core ERC20.sol and uses the SafeERC20.sol library makes it possible to both deposit and withdraw vulnerable tokens.