What is a DeFi Safety Audit

What is a DeFi Safety Audit?

DeFi asks us to trust smart contracts, rather than companies, governments or individuals. They ask you to trust the code. DeFi Safety checks the code, how it was developed, tested and score the results.

Very simply, the audit looks for the following declarations from the developer’s site. With these declarations, it is reasonable to trust the smart contracts.‌

  1. Here are my smart contracts on the blockchain.
  2. You can see it matches a software repository used to develop the code.
  3. Here is the documentation that explains what my smart contract does.
  4. Here are the tests I ran to verify my smart contract.
  5. Here are the audit(s) performed on my code by third party experts.

To check this we look at the public artifacts of deployed contracts, check them against straightforward questions and grade them on their response. A short summary of the process is below and the detailed process here (tl;dr).

The DeFi Safety audits check the smart contracts using a Process Quality Audit. This process is applicable to any smart contract, not just DeFi.

Advantages of PQ Audits

  • Single consistent standard for all audits (so direct comparison possible)
  • Can be refreshed regularly (say once a quarter)
  • Can be done without consent of the contract owners
  • Incentivizes improvement
  • Process and reports are public, making it clearer when disputing the results
  • The questions are clear, leaving little room for judgement and interpretation.

Dis-Advantages of PQ Audits

  • It only audits the process (documentation, tests and Github quality, audits done).
  • It does not audit code quality or financial models

Short Summary of the PQ Audit Process

We review the public documents, software repository, website and other documentation and ask the following questions. The answers are documented and a score determined using a set scoring matrix.

Questions

  1. Executed Code Verification
    • Is the executed code address(s) readily available? (Y/N)
    • Is the code actively being used? (%)
    • Are the Contract(s) Verified/Verifiable? (Y/N)
    • Does the code match a tagged version in the code hosting platform? (%)
    • Is the software repository healthy? (%)
  2. Documentation for the Executing Code
    • Is there a whitepaper? (Y/N)
    • Are the basic application requirements documented? (Y/N)
    • Do the requirements fully (100%) cover the deployed contracts?
    • Are there sufficiently detailed comments for all functions within the deployed contract code (%)
    • Is it possible to trace requirements to the implementation in code (%)
  3. Overall test strategy for the Code
    • Full test suite (Covers all the deployed code) (%)
    • Code coverage (Covers all the deployed lines of code, or explains misses) (%)
    • Scripts and instructions to run the tests (Y/N)
    • Packaged with the deployed code (Y/N)
    • Report of the results (%)
    • Formal Verification test done (%)
    • Stress Testing environment (%)
  4. Review of Software Security Audits