It is vital that projects have their smart contracts and blockchain protocols thoroughly audited before they are released.
At Extropy we have been auditing smart contracts for 3 years and advising clients on the best security practices.
We will take your smart contract application code and conduct a full security audit to check for security vulnerabilities.
In this post we will describe the process that we go through in our audits, including a checklist of some of the vulnerabilities that we look for. We’ll also offer some recommended advice for preparing your codebase for an audit.
We audit your code according to the following criteria.
- Sound Architecture. That is, assessments of the overall architecture and design choices, based on our understanding of your code.
- Best Practices. We evaluate whether the codebase follows the current established best practices for smart contract development.
- Code Correctness. The audit includes an evaluation of whether the code does what it is intended to do according to the documentation supplied.
- Code Quality. We evaluate whether the code has been written in a way that optimises readability and maintainability.
- Security. We look for any exploitable security vulnerabilities, or other potential threats to the stakeholders of the application.
- Testing and Testability. We examine both how easily testable the code is, and how thoroughly tested it actually is.
Of the above goals, one of the most important will likely be security. The SWC (Smart Contract Weakness Classification) registry is a very handy resource of known vulnerabilities
The Smart Contract Weakness Classification Registry is an implementation of the weakness classification scheme proposed in EIP-1470. It is loosely aligned to the terminologies and structure used in the Common Weakness Enumeration (CWE) while overlaying a wide range of weakness variants that are specific to smart contracts.
The Smart Contract Weakness Classification Registry
The following is a checklist of contract weaknesses / vulnerabilities that we look for in audits:
|SWC-132||Unexpected Ether balance||CWE-667 Improper Locking|
|SWC-131||Presence of unused variables||CWE-1164 Irrelevant Code|
|SWC-128||DoS With Block Gas Limit||CWE-400 Uncontrolled Resource Consumption|
|SWC-122||Lack of Proper Signature Verification||CWE-345 Insufficient Verification of Data Authenticity|
|SWC-120||Weak Sources of Randomness from Chain Attributes||CWE-330 Use of Insufficiently Random Values|
|SWC-119||Shadowing State Variables||CWE-710 Improper Adherence to Coding Standards|
|SWC-118||Incorrect Constructor Name||CWE-665 Improper Initialization|
|SWC-116||Timestamp Dependence||CWE-829 Inclusion of Functionality from Untrusted Control Sphere|
|SWC-115||Authorization through tx.origin||CWE-477 Use of Obsolete Function|
|SWC-114||Transaction Order Dependence||CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)|
|SWC-113||DoS with Failed Call||CWE-703 Improper Check or Handling of Exceptional Conditions|
|SWC-112||Delegatecall to Untrusted Callee||CWE-829 Inclusion of Functionality from Untrusted Control Sphere|
|SWC-111||Use of Deprecated Solidity Functions||CWE-477 Use of Obsolete Function|
|SWC-108||State Variable Default Visibility||CWE-710 Improper Adherence to Coding Standards|
|SWC-107||Reentrancy||CWE-841 Improper Enforcement of Behavioral Workflow|
|SWC-106||Unprotected SELFDESTRUCT Instruction||CWE-284 Improper Access Control|
|SWC-104||Unchecked Call Return Value||CWE-252 Unchecked Return Value|
|SWC-103||Floating Pragma||CWE-664 Improper Control of a Resource Through its Lifetime|
|SWC-102||Outdated Compiler Version||CWE-937 Using Components with Known Vulnerabilities|
|SWC-101||Integer Overflow and Underflow||CWE-682 Incorrect Calculation|
Another vital goal of an audit is to determine correctness of the code i.e. does it do what it’s intended to do? Clearly this has a lot to do with another of our audit goals above: testing Indeed, we encourage the inclusion of a test suite as part of the application code to be audited! It gives us a good sense of (at least) the following:
- The correctness of the code
- The testability of the code
- The developer’s intent
Recently we started using formal verification tools to help with our audits.With these tools, we can construct proofs of formal program specifications - a level of assurance that goes well beyond conventional means of testing. One particular formal verification tool we have been using is KLab. This provides very useful tooling for verifying correctness and debugging of contracts.
For auditing ERC20 tokens, we have developed a specification ERC20-act for formally verifying contracts against the ERC20 standard (see the box above). This allows us to check the most basic properties of a standard token contract.
Of course, to properly verify a contract in its entirety (whether a token or not) will depend on the particular nuances of the contract. As such, this will vary on a case by case basis. If you are interested in adding formal verification to your codebase, we can assist with that as an additional service to the audit.