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.
Select an option below to learn more about securing Smart Contracts:
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.
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.
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.
Provide the location of your white paper and how it can be accessed, including any associated credentials, requirements, or terms.
Provide any additional documentation and information about the code being audited.
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?
Who are the main users or stakeholders of the contract? What kind of applications and users will be interacting with the contract?
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).
List all outside libraries or resources that your smart contract contains, references, accesses, or to which your smart contract must link.
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.
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).
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?
Is this code currently deemed production-ready by the company? Have all previous reviews been considered and fixes implemented?
For the token contract, provide the following parameter information: name, symbol, decimals, and supply.
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.
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.
Token price. Does the price change during the sale? If so, how and when?
Are there any caps for both the overall sale and participating addresses?
Is there any address management system? For example, addresses being whitelisted via registration, or blacklisted.
How should token distribution be handled before, during, and after the sale?
What control should the owner have regarding the sale before, during, and after?
Is this code currently deemed production ready by the company? Have all previous reviews been considered and fixes implemented?
Consider Tokens/Crowdsale Team General Readiness Checklist 2.
Adhere to best practices. For example, ConsenSys Diligence actively maintains a guide to Smart Contract Best Practices.
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.
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.
Write a good README. Your project should have a good README.md 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.
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.
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.
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.
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.
Secure list of people with access to company multisig wallet.
Ethereum addresses assigned ownership to multisig wallet.
List of mnemonic passwords (if any) stored, in a highly secure, offline location.
Secure list of people with access to company website hosting server.
Secure list of admin accounts for social networks such as Slack, Facebook, Twitter, etc.
Two Factor Authentication (2FA) enabled on website hosting server.
Two Factor Authentication (2FA) enabled on all social network admin accounts.
Two Factor Authentication (2FA) enabled on all emails with access to admin accounts, suggest use of protonmail.
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.
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.
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.