Security Audits

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.

Here 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.

Audit goals

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.

Security checklist

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:

ID Title Relationships
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

Checking correctness

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.



Preparing for audit

If you decide to audit your contract with Extropy, we recommend some steps to ensure the audit goes smoothly.

  • Write clean code with a consistent code style
  • Use standard libraries where possible
  • Include a test suite (ideally 100% code coverage)
  • Document the functions of your public API (at least)
  • Document your protocol and release process
  • For token issuance document the procedure
  • Include end-user documentation where relevant
  • To arrange an audit of your code or to discuss your requirements, please contact us, our details are given below.