DEV Community

Cover image for Smart contract bugs & best ways to protect smart contracts
Diana Maltseva
Diana Maltseva

Posted on • Updated on

Smart contract bugs & best ways to protect smart contracts

When starting smart contract development, many programmers strongly believe that learning Solidity takes less than two weeks, especially if they know JavaScript and have experience in working with it.

Though Solidity is rather simple, companies that specialize in ensuring the security of smart contracts, ask for huge money for smart contract audit.

Also, sometimes even large corporations and experienced developers make mistakes resulting in losses of millions of dollars. You’ve probably heard of the DAO when the attacker took away $50 million. So, why does it happen?

Unfortunately, smart contracts have some vulnerabilities, which makes the use of protection tools and smart contract audit very important. In this post, I'll consider the main types of bugs and technologies you can apply to provide smart contract security.

Smart contract vulnerabilities

Transaction Ordering Dependence (TOD)

Miners control the order of transactions, meaning that your transaction can be outrun by paying more gas in the other one (the higher the amount of gas, the higher the priority of your transaction for a miner is).

Only the miner who closes the block decides the transaction order, and this is the vulnerability, called transaction ordering dependence. In TOD, you may face unexpected malicious behavior from miners.

Timestamp Dependency

Unfortunately, the timestamp can be manipulated by the miner who isn’t always a user’s friend. The miner can adjust the timestamp provided by a few seconds, thus changing the output of the contract to his own benefit.

It can work as follows: when a smart contract uses the timestamp in order to generate random numbers, the miner can post a timestamp within 30 seconds of the block being validated, enabling to predict a more preferred option to his chances in this lottery.

So, be aware that the timestamp of the block can be manipulated by the miner, and all direct and indirect uses of the timestamp should be considered. Block numbers and average block time can be used to estimate time, but this is not future proof as block times may change (such as the changes expected during Casper).


The first version of reentrancy vulnerability involved functions which could be repeatedly called before the first function call was ended. For this reason, different function calls could interact in destructive ways. Take a look at the code below:

mapping (address => uint) private userBalances;

function withdrawBalance() public {
uint amountToWithdraw = userBalances[msg.sender];
if (!( { throw; } // At this point, the caller’s code is executed, and can call withdrawBalance again
userBalances[msg.sender] = 0;

Find out more about other smart contract bugs and ways to provide smart contract security and protection.

Also, check out smart contract audit best tools and practices that help deliver the code of the highest quality.

Top comments (3)

erebos-manannan profile image
Erebos Manannán

It baffles me why in the smart contract world people have had to reinvent the wheel with the terms.

E.g. reentrancy looks like race condition to me.

thorstenhirsch profile image
Thorsten Hirsch

While a race condition is linked to unlucky timing, a reentrancy bug works completely deterministic.

gurulhc profile image
Lucky Henry

A closer look at smart contracts written with RIDE shows it solves loads of common sc issues by default