When doing Solidity audits at 4soft we oftentimes find the same bugs and issues. Here’s a short list of the most common mistakes we encounter. We hope you can learn from them and take advantage when writing your own smart contract.
Use safe math
Arithmetic operations on integers may overflow, silently causing bugs. You need to double check the math in your smart contract and consider all the possible scenarios.
To avoid these issues, we recommend using SafeMath library for Solidity integers.
Use ready and well-tested libraries
There’s a variety of open-source libraries available for creating tokens, crowdfunding processes and many others. They’re tested, verified by the companies and audited by the community.
Instead of reinventing the wheel, you can reuse them in your own project. For simple projects, consider reusing a standard ERC20 token implementation as a base for your project.
Separate code for the crowdfunding phase
When you create your Initial Coin Offering and publish your code, you need to make sure it is clean and easy to understand.
Consider separating the code that is executed only during the funding phase from the rest of the smart contract. This will help your investors to better understand how your token works.
Use up-to-date Solidity version
Every time we review a Solidity contract it uses an outdated version of Solidity.
Always try to use the most up to date version – those updates are important due to its performance and security.
Use Transfer event for minted tokens
In the ERC20 spec, it is recommended to emit a Transfer event with the source (_from) set to 0x0 when minting new tokens.
This enhances user experience by allowing applications such as Etherscan to find the new token holders. In this case, this is only relevant for the constructor where the initial balance is assigned to the distribution contract.
Nonetheless, consider emitting the corresponding event:
Transfer(0x0, msg.sender, _initialAmount)
