10 things every smart contract auditor should check when auditing an ERC20 Token contract.
Introduction
As the global significance of blockchains in facilitating value exchange continues to grow, the importance of thorough auditing for smart contracts supporting cryptocurrencies and tokens on platforms like Ethereum becomes increasingly evident.
Auditors play a pivotal role in strengthening codebases against vulnerabilities that could impact the secure management of user funds on a large scale, especially when assessing ERC-20, ERC-721, and cross-chain token implementations.
Prominent auditing firms emphasize the need for a comprehensive checklist covering security best practices, designing token issuance models, implementing access controls, and establishing robust arbitration logic.
This proactive approach helps prevent potential exploits such as reentrancy, race conditions, and denial-of-service attacks during the execution of critical functions.
Here are 10 things every smart contract auditor should check when auditing a token.
- Are safe transfer functions used in the contract?
Not all ERC20 tokens are compliant with the EIP20 standard, some of the tokens do not return a boolean flag and some do not revert on failure, it is advised that OpenZeppelin's safeERC20 should be used, these functions handle the necessary check that could allow an attacker to take advantage of the system
- Is there a potential for race condition in the approval?
Race condition for approvals can cause an unexpected loss of funds to the signer.
How does a race condition for ERC20 token happen?
Assume that Alice has approved Eve to spend n of her tokens, then Alice decides to change Eve's approval to m tokens. Alice submits a function call to approve with the value n for Eve. Eve runs an Ethereum node, so she knows that Alice is going to change her approval to m. Eve then submits a transferFrom request, sending n of Alice's tokens to herself, but gives it a much higher gas price than Alice's transaction. The transferFrom executes first so gives Eve n tokens and sets Eve's approval to zero. Then Alice's transaction executes and sets Eve's approval to m. Eve then sends those m tokens to herself as well. Thus, Eve gets n + m tokens, even though she should have gotten at most max(n,m).
It is advised that OpenZeppelin's safeIncreaseAllowance and safeDecreaseAllowance functions should be used.
- What is the number of decimals for the token?
Using a wrong decimal for a token can lead to incorrect calculations or interpretations, it is advised that the decimals should be checked and confirmed before using the token to avoid potential issues.
- Implementation of address whitelisting, blacklisting, or checks?
Some tokens implement whitelisting, blacklisting, and other checks, it is important to consider all these when using these tokens because it can lead to unexpected behaviors and problems. It is advised that extensive testing should be done to make sure the listed actions do not affect the token integration to other protocols.
- Does the token have fee on transfer?
Some tokens charge a fee during the transfer of a token, this can be a buy tax or sell tax, or both. The accounting for the token system should be adequately tested to make sure that the logic is correct.
- Is the token ERC777?
ERC777 tokens have hooks that execute code before and after transfers, which might lead to reentrancy. it is advised that developers should be cautious when integrating with ERC777 and be aware of the hook implications
- Is there a flash mint functionality?
Flash mints can cause the token supply to increase by a large margin and this can lead to potential abuse, it is advised that strict measures and control are around the flash mint functionality.
- What happens on zero amount transfers?
Some tokens revert on transfer of zero amount and it can cause issues when the token is integrated into other protocols. it is advised that checks should be in place to make sure only positive tokens are transferred.
- Is there a max approval used?
Some tokens implement the approval of type(uint256).max, although this may be good for UX to avoid continuous approval when using a contract or Decentralized App, it is a huge security risk. it is advised that the implementation of approval of type(uint256).max should be avoided.
- Can the token be paused?
Some ERC20 token can be paused by the owner of the contract, it is advised that extensive testing should be done to make sure that pausing the token does not affect the protocol in which the token is integrated.
Conclusion.
This is not an exhaustive list, as other things need to be considered like access control, code logic, centralization issues, capping minting, and burning and others.
This checklist is more like a starting point for anyone who wants to audit a token smart contract.
References.
.