ERC20 Edge Cases Every Smart Contract Engineer Should Know

ERC20 tokens present various edge cases that smart contract engineers must be aware of when integrating with these tokens. The ERC20 standard is an interface that defines function signatures but does not dictate the internal execution logic, leading to potential issues when dealing with arbitrary tokens. Engineers often make flawed assumptions about token behavior, leading to systemic insolvency and user funds being trapped.

The first common edge case involves fee-on-transfer and rebasing tokens. These tokens can deduct fees or dynamically alter user balances algorithmically. For example, if a user deposits 100 fee-on-transfer tokens and the token takes a 5% fee, the vault will receive only 95 tokens. However, the vault may internally mint 100 shares based on the requested amount, resulting in a discrepancy. This leads to users withdrawing more tokens than they actually possess, causing systemic insolvency.

Secondly, tokens with callbacks or transfer hooks can introduce reentrancy attacks. When a token calls back into the user's contract before updating the internal state, it can cause the protocol to mistakenly update the user's debt balance multiple times. This reentrancy can be mitigated by following the Checks-Effects-Interactions (CEI) pattern, updating internal state before interacting with external tokens, and using OpenZeppelin's ReentrancyGuard modifier to prevent unintended execution paths.

Thirdly, some tokens may return false instead of reverting when a transfer fails. For instance, the ZRX token returns a boolean indicating the success or failure of a transfer. If a protocol does not check this return value, it might mark a user's debt as paid even if no tokens were transferred. To handle this, always use OpenZeppelin's SafeERC20 library, which normalizes behavior by forcing a revert on silent failures.

Lastly, transfers of zero amount or to the zero address might not always revert. Different token implementations handle zeros differently, with some reverting while others do not. In a scenario where a protocol distributes yields to users and one user earned zero yield in a batch, the transfer of zero tokens could be silently ignored if not handled properly.

This could lead to incorrect accounting and balance discrepancies. To avoid this, always validate the transferred amount and target address before executing any token transfers.

In conclusion, engineers must be cautious when integrating with ERC20 tokens and understand the various edge cases that can arise. By accounting for actual balance deltas, using SafeERC20, implementing reentrancy guards, and validating transfer amounts and targets, engineers can build more robust and secure smart contracts.