Is there a tool, checklist of methodology to help reviewing smart contract security?

E.g. for each of function you review

  • Is there re-entry possibility and how it behaves on re-entry

  • How it behaves if loops run out of gas

  • How it behaves if stack limit is reaches

... and so on.

If no such tool is available is there a good source or list for all known failure modes of Ethereum smart contract security?


2 Answers 2


This is the community wiki (no reputation) answer for possible attacks and how to protect against them. Feel free to update the list. If your contract functions have characteristics matching prerequisites carefully evaluate your function against the given advice.

This is the list of potential attacks or mispractices enabling those attacks only. For additional resources for smart contract programming best practices see the Resources link at the end of the answer.

Study potential attack vectors and history of past exploits

Those who do not learn history are doomed to repeat it. Here is a nice summary of known smart contract attacks.

Have more than one developer

One developer writes the code and the other reviews it. Having more than one set of eyeballs is important during development. Issues should be caught during the development time through public discussion, not in the audit.

Use well-known libraries

Do not try to develop smart contracts like ERC-20 yourself. Instead, use open source libraries that provide ready-made and battle-tested smart contracts. It is likely that when you develop something from the scratch you are going to make a mistake.

Gold standard libraries include, but are not limited to

Have a test suite

Try to ensure that your Solidity code has 100% code coverage with an automated test suite. This ensures your code is testable. The automatic test suite covers and runs every line and branch of the smart contract code at least once.

Solidity unit tests are usually written in Python (Brownie, web3.py) or JavaScript (Hardhat, Truffle).

Tests will do transactions against the smart contract and check that the state of the transaction is as indented post-transaction. (Pendatically, the state is always as the letter of the contract, however in this case the letter and the indent would not match.)

Test for positive cases and negative cases - i.e. things that should not happen even though you know that it does not happen. Sometimes, when the code lives and is updated, some new issues slip through and they would be caught by the past tests - this is called regression testing.

Doing audits without tests is not very productive, as the tests should be always the first line of defence what comes to write robust code.

Set up Github continuous integration that executes all the tests for everyone commit. Reports are automatically stored for the future. This also helps other people to replicate the test environment and run it later, as often due to package upgrades the test runner tools themselves start to fail.


Correct use of function visibility modifiers

Internal functions are marked as such and only the proper author can call the function.

Please see The Parity Wallet Hack Explained.

Call stack attack

Synonyms: Shallow stack attack, stack attack

Prerequisites: Functions uses send() or call()

Invoking: The attacker manipulates cross-contract call stack to call() to fail by calling contract with stack of 1023.

Protection: Always check return value of a send() and call(). Prefer someAddress.send() over someAddress.call.value()

More info

Re-entrancy attack

Synonyms: Race condition

Prerequisites: Functions uses send() or call() for ethers, or transferFrom() for ERC-20 tokens or send() for ERC-777 tokens.

Invoking: The untrusted called contract calls the same function back, having it in unexpected state. This is how TheDAO was hacked.The attack can be chained over several of functions (cross function race condition).

Protection: Protect your functions with re-entrancy guards. Use Check-Effect-Interact order of actions in your functions that call anything that could be reflected back to the smartcontract.


Use this pattern to minimize the damage of potential re-entry attack.

  1. First Check, run things like require()

  2. Then Effect, update counters, like balance[address] -= 10

  3. Last, do anything that is Interact and will run code in other contracts through send(), call(), transferFrom() and others.

More info

Read-only re-entrancy attack

A Read-only re-entrancy attack is a variation of a re-entrancy attack. Both attacks are based on the same principle of the vulnerable code not following the CEI pattern.

In a read-only re-entrancy attack, the attacker does not re-enter the vulnerable function directly on a call (like receiving ETH), but manipulates some value outside the vulnerable function. Then the vulnerable function reads this value between CEI the cycle: effects are not yet updated, but the interaction has caused the attacked to change some value outside the vulnerable contract.

As this attack needs complicated preconditions, protocols are less likely to be vulnerable for complex manipulation schemes. The attack is not theoretical though.

Balancer read-only re-entrancy vulnerability explained

DoS with unexpectEd throw

Prerequisites: Functions uses send() or call() with throw following on fail

Invoking: The attacker manipulates the contract state so that send() always fails (e.g. refund)

Protection: Prefer to pull payment system over send()

More info

Economic attacks

Prerequisites: Your smart contract reads price data and trades based on it

Invoking: Arbitration opportunities and unsafe price feeds may not be exploits per se, but they still expose the users to the loss of funds that could have been otherwise avoided. In an economic attack, the attacker exploits the opportunity to trade for profit against someone, usually based on disparities in the price of a token.

Protection: Do not rely on the spot price given by the exchanges or automated market-making smart contracts. All prices, including stablecoin prices, are subject to manipulation.

Popular automated market makers and smart contracts provide safe functions to calculate the price in different situations.

More info

Malicious libraries

Prerequisites: Using an external contract as a library and obtaining it through the registry.

Invoking: Call another contract function through a contract registry (see library keyword in Solidity).

Protection: Ensure no dynamic parts which can be swapped out in future versions.

Integer overflow

Prerequisites: Function accepts an uint argument that is used in math

Invoking: Sending very big or very negative integer causing the sum calculation to overflow

Protection: Always check the order of values when doing math operations. E.g. https://github.com/Firstbloodio/token/blob/master/smart_contract/FirstBloodToken.sol

More info

Integer division round down

Prerequisites: Payment logic requires division operator /

Invoking: Programmer's error

Protection: Be aware that divisions are always rounded down

Loop length and gas manipulation

Others: Allocating too small int for arrays

Prerequisites: Any loop, copy arrays or strings inside the storage. A for loop where contract users can increase the length of the loop. Consider voting scenario loops.

Invoking: The attacker increases the array length or manipulates block gas limit

Protection: Use pull style payment systems. Spread send() over multiple transactions and check msg.gas limit.

Fallback function consuming more than the limit of 2300 gas

Prerequisites: A Solidity contract with catch-all function() { } to receive generic sends

Invoking: Programmer's error

Protection: 100% test coverage. Make sure your fallback function stays below 2300 gas. Check for all branches of the function using the test suite. Don't store anything in the fallback function. Don't call contracts or send ethers in the fallback function.

More info:

Donation attack / forced balance update

Prerequisites: The function reads token/ERC-20 balance of a contract balance and has some logic depending on it.


  • selfdestruct(contractaddress) can forcibly upgrade its balance

  • ERC20.tranfer() tokens on a smart contract. This is because ERc-29 has a design flaw that smart contracts cannot reject any received ERC-20 transfers ("donations").

A smart contract may use the balances of its tokens to calculate the value of LP tokens, shares tokens or similar. Any unexpected balance update may be able to manipulate the value of such calculations, especially when entering to the domain of fractional integers and rounding errors.

Because ERC-20 transfers cannot be blocked, there are complex workarounds like adding virtual shares or virtual LP tokens to the calculations.

enter image description here


Miner frontrunning and MEV

Synonym: Transaction-Ordering Dependence (TOD)

Prerequisites: A bid styles market, like DAI liquidation and auctions

Invoking: The attacker sees transactions in a mempool before they are finalized in the blockchain. The attacker has a privileged connection, like a mining pool, to broadcast his transaction first and override the original benefactor.

Protection: Pre-commit schemes


Static analysis tools

Static analysis tools that check the code for commonly known errors, like integer overflows. They cannot check the intent of the code, but they run to try to analyse the code against well-known common problems.



Devcon2: Smart Contract Security Speakers: Christoph Jentzsch

After a quick overview of smart contract failures in the past, a list of important takeaways will be covered. Some coding techniques to prevent unexpected behaviour in smart contracts will be covered as well as some remarks about governance in decentralized systems.

Youtube Link

Another one;

Researchers from National University of Singapore will soon release a tool that will help ethereum users determine whether the smart contracts they've coded are valid or not.

This is the whitepaper link

Source Coindesk.

  • Devcon 2 came and go. Did anything good come out of this? Commented Sep 26, 2016 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.