In the world of blockchain technology, smart contracts have emerged as a revolutionary tool, automating transactions and agreements without the need for intermediaries.

As a leading team of smart contract security auditors, Audita has witnessed firsthand some common mistakes made by our clients in the deployment of smart contracts. These oversights can lead to significant vulnerabilities, putting the integrity of the protocol and the security of the assets at risk. 

This article aims to shed light on some common mistakes, offering insight into how they can be preemptively addressed and mitigated.

Join Audita’s team, as we delve into these challenges: 

…

Front-running Vulnerabilities

Front-running upon price calculations is one of the most common reasons for smart contract exploits. It is straightforward and easy to execute given the right conditions. 

Example 1: Calculating user rewards. If rewards are based on the protocol token’s current price, but paid off in another token, there is a risk that a transaction is preempted by others, changing the token price and resulting in the user receiving less than the expected rewards.

Fix? Implement a feature which lets users set a minimum reward threshold when they stake, unstake, or harvest rewards. This would protect them from the effects of price volatility and transaction front-running, ensuring a more predictable and secure reward system.

Example 2: Front-running NFTs. Anyone can list an NFT, but the item first needs to be approved. An attacker can monitor for approval transactions. When he notices one, he can front-run the listItem by executing the same transaction with a price of 1 wei. Because the NFT has already been approved, it will get transferred to the attacker’s address. Read more on this in our Medium article.

Fix? Replace seller with msg.sender and don’t use seller at all. Alternatively, in case the business logic requires the usage of a seller argument, implement signature verification within the smart contract - The owner of the NFT should sign the nftAddress, tokenId, and the price beforehand, and then the executor should provide that signature to verify the owner has indeed allowed these values.

…

Denial Of Service Vulnerabilities (DoS)

DoS attacks are very common. 

What we’ve encountered is the failure to prevent infinite loops, a.k.a. unbounded balanceArrays. In this scenario, as the array size grows with more transactions, the function's gas requirement may exceed the transaction limit, causing it to fail due to excessive gas consumption. This is an unnecessary headache for both parties. 

Fix? Carefully redesign your smart contract implementation to prevent this from happening and to save on gas!

…

Rounding Issues

Computing token amounts based on time elapsed. Here there is a hidden vulnerability in the scenarios where not much time has passed before this calculation occurs. If the amount is very small and insignificant, it can get messed up due to Solidity’s integer division.

Example: Vesting calculations. If a rounding issue appears upon calculating vested amount, the result might be that some tokens get locked until the end of the vesting period.

Fix? Implement safeguards in your smart contracts to handle scenarios of minimal time elapse. One effective strategy is to introduce a threshold for time or token amounts, ensuring calculations remain accurate despite the limitations of Solidity's integer division.

While those were just glimpses into the myriad of vulnerabilities out there, addressing these issues is a significant step toward ensuring the security and reliability of your smart contracts. As Audita’s team prepares for Part 2 of this series, it's important to emphasize that the security journey is ongoing and requires continuous efforts and improvements. 

Discover more from Audita in our blog.

Need help auditing your smart contracts? Audita is here to help. Request an audit with us today and receive vulnerabilities and mitigation advice in a detailed audit report.

Stay SAFU!
Audita's Team