Basic Guide for Smart Contract Auditing on Ethereum, EOS and Hyperledger

QuillAudits offer Smart Contract Audits based on Ethereum, EOS and Hyperledger Fabric to validate and secure your core business logic

Basic checks to undertake with any Smart Contract

To ensure your code is easily followable by auditors, team members, automated tools , and the wider community, you should follow style guide based on Solium’s standards. Having a set and automatically enforced style guide will additionally make it easier to spot erroneous code.

1. Correct Functions Visibility:-

Correct Functions Visibility

Functions in solidity can have four visibility specifiers: public, external, internal or private, with public being the default . State variables can be public, internal or private, with internal being the default. Explicitly specifying the visibility of functions and state variables is a security best practice.

Absent specifiers can be dangerous especially in the case of functions where the default is public accessibility. If such a function has critical logic then it can be triggered from any external address to potentially misuse the contract. The first hack on the Parity multisign wallet exploited such missing function visibility specifiers leading to the attacker stealing $31M worth of Ether.

2. Data Storage:-

In solidity data can be stored in memory which is non-persistent and less expensive or in storage which is persistent and very expensive.While writing smart contracts one should properly analyze that where the data should be stored.By default state variables and local variables are stored in storage and function parameters are stored in memory.

Data Storage

3. Prevent overflow and underflow:-

Prevent overflow and underflow

An overflow is when a number gets incremented above its maximum value. Solidity can handle up to 256 bit numbers (up to ²²⁵⁶-1), so incrementing by 1 would result into 0.

Likewise, in the inverse case, when the number is unsigned, decrementing will underflow the number, resulting in the maximum possible value.

Underflow and overflow can be prevented by using SafeMath library to perform math operations in smart contracts.

4. External Calls — Every external contract call is a risk:-

External calls to untrusted contracts can bring certain risks and errors. External calls may execute malicious code in that contract or any other contract that it depends upon. As such, every external call should be treated as a potential security risk. When it is not possible, or undesirable to remove external calls, use the recommendations.

External Calls

5. Check for re-enterancy and ensure state committed before external call:-

Reentrancy attack

The Reentrancy attack, probably the most famous Ethereum vulnerability, surprised everyone when discovered for the first time. It was first unveiled during a multi-million dollar heist which led to a hard fork of Ethereum. Reentrancy occurs when external contract calls are allowed to make new calls to the calling contract before the initial execution is complete. For a function, this means that the contract state may change in the middle of its execution as a result of a call to an untrusted contract or the use of a low level function with an external address.

Loss: estimated at 3.5M ETH (~50M USD at the time)

6. Don’t delegatecall to untrusted code:-

The delegatecall function is used to call functions from other contracts as if they belong to the caller contract. Thus the caller may change the state of the calling address. This may be insecure.

delegatecall function

7. Save Gas on smart contracts:-

Save Gas on smart contracts

Saving gas is necessary to build an efficient smart contract. It is one of the main issues that the developers face because not all of them know how to do it correctly. Auditors at QuillAudits understands well which instructions consume more gas and how we can avoid or minimize them.

8. Timestamp Dependence:-

If the contract function can tolerate a 15-second drift in time, it is safe to use block.timestamp

Timestamp Dependence

9. Compiler warnings:-

Compiler warnings

All the compiler warnings are serious issue sometimes developer ignore warnings and deploy contract without considering them as a big threat to their smart contract, we recommend necessary action to be taken to remove all the warnings.

10. Ownership of the deployed contract:-

It is very important to provide ownership to a contract at the time of deployment or a restriction to function calls else attacker may call those function or transfer ownership function before you or if you are required to give ownership of a contract later, most famous bug of this kind is oyster-pearl because ownership of smart contract was open attacker transfer ownership to himself and able to mint tokens of worth ~$300,000.


11. Oracle calls:-

Oracle calls

Blockchains cannot access data outside their network. An oracle is a data feed provided by third party service designed for use in smart contracts on the blockchain.

Oracles are third party services which are not part of the blockchain consensus mechanism. The main challenge with oracles is that people need to trust these sources of information.

12. Lock pragmas to specific compiler version:-

pragma solidity ^0.4.4; this is bad

pragma solidity 0.4.4; this is good

Lock pragmas

13. Security Tools:-

Security Tools

After manual and unit testing , your smart contract undergoes automation testing that is done using many open source security tools.


Surya , Solgraph, Evm-Labs, Ethereum-graph-debuger

Static and Dynamic Analysis:

Mythril, Oyente, Securify, Smartcheck

Test Coverage:



Linters improve the code quality

Solcheck, Solhint, Solium

Smart Contracts weakness classification and Test Cases

SWC-registry - The Smart Contract Weakness Classification Registry is an implementation of the weakness classification scheme proposed in EIP-1470

SWC Pages - The SWC-registry repo published on Github Pages


We choose One Project each month for a Free Detailed Audit

  • - The selected project has to embed our QuillAudits Widget & mention us their partners on their website and social media platforms.

  • - Applications are accepted between the first 2 weeks of every month.

  • - In the 3rd week of the month, projects will be reviewed on the bases of the different selection processes and on the 21st we will announce a project for the Community Audit.

  • - Detailed Audit Report is made live on 30th of the following month.