Audit Anomalies Archive — Issue#1
Developers commonly build smart contracts that interact with ERC20 tokens, the most prevalent type of token on the Ethereum blockchain. These tokens have become an essential part of the decentralized finance (DeFi) ecosystem. A crucial aspect of ERC20 tokens is their decimal representation, which dictates the precision of token amounts in transactions.
Most widely used ERC20 tokens adhere to a standard of 18 decimal places. This implies that a token can be divided into 10¹⁸ (1 followed by 18 zeros) subunits, allowing for high precision in value representation. This 18-decimal convention has become a norm in the industry and simplifies token calculations and user interactions.
However, there are exceptions to this standard decimal representation. Notably, tokens like USDT (Tether) and USDC (USD Coin) utilize 6 decimals, and WBTC (Wrapped Bitcoin) employs 8 decimals. These tokens were designed with different decimal precision to align better with their underlying assets and use cases.
Consider a scenario where a developer builds a smart contract with the assumption that all ERC20 tokens have 18 decimals. This contract might inadvertently fail to handle tokens with different decimal representations. For example, if a user deposits USDC, which has 6 decimals, into the contract, they might encounter difficulties when attempting to withdraw the funds.
To address this potential vulnerability, developers should refrain from making assumptions about the decimal representation of ERC20 tokens. Instead, they can adopt a more dynamic approach by fetching the actual decimal value of a particular ERC20 token programmatically.
While a standard of 18 decimal places has emerged as the norm, exceptions like USDT, USDC, and WBTC remind us of the need for adaptable and dynamic smart contract development practices. By avoiding rigid assumptions and embracing flexibility, developers can create robust and secure contracts that cater to a diverse range of tokens and their respective decimal representations.
To test the potential vulnerability described above, you can find a demonstration by following this link: [https://github.com/zzzuhaibmohd/AuditAnomaliesArchive/blob/main/README.md#issue-1---denial-of-servicedos-due-to-hardcoding-of-decimals].
Thank For Reading.
Stay Tuned for more such Issues.
