Standards for
Smart Contract
Security Audits

The Smart Contract Security Alliance consists of blockchain security companies, research institutions, and other organizations dedicated to securing blockchain technology.

We believe the future of blockchain applications depends on security - the foundation of trust. Member organizations help the ecosystem by building standards for smart contract security and smart contract audits.

Our standards, published on this website, help end-users understand blockchain security better, developers build safer products and businesses comply with evolving regulations.

Alliance Members

Quantstamp logo
MythX logo
National University of Singapore logo
NRI Secure logo
LayerX logo
Blockgeeks logo
Fujitsu logo


Select an option below to learn more about securing Smart Contracts:

Client Smart Contract Audit Readiness Guidelines

  1. Articulate in your words clearly what exactly your smart contract is intended to do and what features it has (e.g., vesting/linear vesting, whitelist/blacklist). Include appropriate references, files (e.g., truffle project, unit tests, spec, white paper), specifications, and documents.

  2. Identify your target date of your audit completion and any reasons for such timing (e.g., when will you begin your sale). As code complexity may increase the time associated with a complete audit, be cognizant of the pressure deadlines may hold.

  3. Provide the location of your source code, preferably GitHub with the commit hash to be audited, and access to auditors, including any associated credentials, requirements, or terms. Make sure that the source code and smart contracts are available in an accessible form for the auditors.

  4. Provide the location of your white paper and how it can be accessed, including any associated credentials, requirements, or terms.

  5. Provide any additional documentation and information about the code being audited.

  6. Is the system intended to be completely trustless? If not, who are the trusted actors and what should they be trusted with? What is the scheme for read/write permissions, and what consensus mechanism enforces this?

  7. Who are the main users or stakeholders of the contract? What kind of applications and users will be interacting with the contract?

  8. If the source code is unavailable at this time, please specify why, and indicate the size of your smart contract (e.g., number of lines of code).

  9. List all outside libraries or resources that your smart contract contains, references, accesses, or to which your smart contract must link.

  10. Specify whether your smart contract is currently compiled and has been deployed to a testnet. If it has been deployed to a testnet, determine the time it has been up, and what aspects (if any) are traceable back to you.

  11. Specify special requirements within your contract, such as compiler information, custom code used, and non-standard language practices (such as writing your own “Event” functionality).

  12. Do you need the finalized audit report for your smart contract to be released under your company name, subject to confidentiality terms, or any other special requirements?

  13. Is this code currently deemed production-ready by the company? Have all previous reviews been considered and fixes implemented?

Client Smart Contract Audit Readiness Checklist Token/Crowdsale Smart Contracts Checklist 1

  1. For the token contract, provide the following parameter information: name, symbol, decimals, and supply.

  2. Will these tokens have an open mint? When is your target sale date? The smart contract audit for a token/crowdsale should be done at least 2 weeks prior to sale.

  3. Will these be burnable tokens? If so, under what circumstances do you anticipate tokens being burned? For example: “During/After crowdsale, or users will burn because ____.” or “The Dapp will burn tokens because ___.” Exact start/end times and in which time zone, or block numbers if using blocks.

  4. Token price. Does the price change during the sale? If so, how and when?

  5. Are there any caps for both the overall sale and participating addresses?

  6. Is there any address management system? For example, addresses being whitelisted via registration, or blacklisted.

  7. How should token distribution be handled before, during, and after the sale?

  8. What control should the owner have regarding the sale before, during, and after?

  9. Is this code currently deemed production ready by the company? Have all previous reviews been considered and fixes implemented?

  10. Consider Tokens/Crowdsale Team General Readiness Checklist 2.

  11. Adhere to best practices. For example, ConsenSys Diligence actively maintains a guide to Smart Contract Best Practices.

  12. Provide a plain English specification. Your specification should describe, in plain English, how each function of a contract should work and how those functions should work together. Functions may be treated as “black boxes”; the specification should describe what goes in, what comes out, what should happen, and what should not. After this, outline the design decisions behind the intended behavior of your code, rather than alternative approaches you might have chosen. This will help clarify for yourself the alternatives, as well as how people may misinterpret or misuse your code. Diagrams are tremendously helpful and show a well thought-out design process. Both WeiFund and Golem have excellent examples of specification diagrams.

  13. Think start to finish. A documented deployment process is essential in order to avoid introducing security problems. Such a guide would include: which compiler version to use for which contracts, the order in which contracts will be deployed, and constructor parameters for initialization of each contract.

  14. Write a good README. Your project should have a good file which clearly describes how to install the system locally and run the test suite. It should also clearly link to other references which are useful for understanding the project. If you will run a bug bounty after the audit (which we recommend), provide instructions for participation.

  15. Clean up the project repository. Reducing clutter in your code makes an auditor’s job much easier. You should remove any unused or unnecessary contracts, files, or code. You should also indicate: (a) which contracts are only used for testing purposes, and are not part of the final system and (b) which contracts are reused from audited code, or inherit heavily from audited code.

  16. Lint your code. Use solium, or solcheck, and follow the official Solidity style guide. Also, use a linter on your test suite.

  17. Comment complex sections of code. Gratuitous comments are not necessary, but comments clarifying your intention can be helpful, especially in highly complex sections of code.

  18. Measure your test coverage. Measuring test coverage is helpful for identifying sections of code that are not tested, or need more testing. Solidity-coverage is a great tool for this. Even 100% test coverage is not a panacea, so auditors should also evaluate the quality and thoroughness of the test code. Writing tests in Python, or using the async/await syntax of NodeJS makes them much more readable and easier to follow.

  19. Freeze the codebase. The purpose of a code audit is not to clean up your code or check for simple mistakes. Your contract system must be considered ready prior to the commencement of an audit. A commit hash from your Github repo is required to specify the state of the code to be audited.

Client Smart Contract Audit Readiness Checklist Tokens/Crowdsale Team General Readiness Checklist 2

  1. Secure list of people with access to company multisig wallet.

  2. Ethereum addresses assigned ownership to multisig wallet.

  3. List of mnemonic passwords (if any) stored, in a highly secure, offline location.

  4. Secure list of people with access to company website hosting server.

  5. Secure list of admin accounts for social networks such as Slack, Facebook, Twitter, etc.

  6. Two Factor Authentication (2FA) enabled on website hosting server.

  7. Two Factor Authentication (2FA) enabled on all social network admin accounts.

  8. Two Factor Authentication (2FA) enabled on all emails with access to admin accounts, suggest use of protonmail.

  9. Advise the public through all communication channels that no direct messages will be sent from the company regarding Ethereum activity. Never use DM’s to communicate, as this is a primary phishing method where impersonators send DM’s as your company.

  10. Advise your community of the exact date/time of your crowdsale as well as methods used to participate, and stress that any messages contrary to this data is fake. Users should be able to verify accurate information over multiple channels, such as Twitter, Medium, Facebook, Github, and the company website.


Since Ethereum is deterministic, pseudo-random number generation can be exploited if not implemented well. Below we present some recommended options for generating pseudo-random numbers on Ethereum. For each solution, we discuss its advantages and disadvantages. Regardless of the chosen methods, a block miner can decide whether to publish or withhold the block that makes use of the pseudo-random number.


A contract that implements a Decentralized Autonomous Organization (DAO) whose goal is to generate pseudo-random numbers via commit-reveal scheme.
  • Safe
  • Relatively slow
  • Can be DoS-ed: if it fails to collect enough sha3(s) within the time period, then RNG at this block height will fail


A predefined function that returns hash of a given block number. It is available only for the last 256 blocks (excluding the current one). As a general rule, blockhash() can only be safely used for a random number if the total amount of value resting on the quality of that randomness is lower than what a miner earns by mining a single block.
  • Readily available language construct
  • Future blockhashes can be combined with commit-reveal to create a safe pseudo-random number generator (but must be called within the next 256 blocks so that blockhash() is non-zero)
  • Available only for the last 256 blocks (excluding the current one). Returns 0 otherwise.
  • blockhash(block.number - 1) would be shared within the same block


A blockchain oracle is a service that finds, verifies, and submits external data into the blockchain. Oracles can be used to relay random numbers from external sources to the Ethereum blockchain.
  • Oracles are able to provide real-world data, and, if trusted, they may be a good source of entropy.
  • Until decentralized oracles are used, centralized oracles must be trusted third parties. We need to trust not just that they provide truly random numbers, but that they will keep providing data into the future.

Not Recommended

Ethereum Block Attributes

Ethereum offers a bunch of attributes, such as block.timestamp, block.coinbase, block.difficulty, block.number, block.gasLimit, that projects may want to use as a source of entropy.
  • Data is readily available
  • Can be manipulated by miners
  • All block attributes are shared within the same block (a miner could find out the value via an internal call)

Smart Contracts Audit Categories and Severity Levels


The issue puts a large number of users’ sensitive information at risk, or is reasonably likely to lead to catastrophic impact for client’s reputation or serious financial implications for client and users.


The issue puts a subset of users’ sensitive information at risk, would be detrimental for the client’s reputation if exploited, or is reasonably likely to lead to moderate financial impact.


The risk is relatively small and could not be exploited on a recurring basis, or is a risk that the client has indicated is low-impact in view of the client’s business circumstances.


The issue does not pose an immediate threat to continued operation or usage, but is relevant for security best practices, software engineering best practices, or defensive redundancy.


The impact of the issue is uncertain.