What is a DeFi Safety Audit

DeFi Safety

What is a DeFi Safety Review?

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 scores the results.

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

  • Here are my smart contracts on the blockchain

  • Here is the documentation that explains what my smart contracts do

  • Here are the tests I ran to verify my smart contract

  • 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 reviews check the smart contracts using a Process Quality Review. This process is applicable to any smart contract, not just DeFi.

Advantages of PQ Reviews

  • Single consistent standard for all reviews (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 Reviews

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

Short Summary of the PQ Review 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.


  1. Code and Team
    • Are the executing code address(s) readily available? (Y/N)
    • Is the code actively being used? (%)

    • Is there a public software repository? (Y/N)

    • Is there a development history visible? (%)

    • Is the team public (not anonymous)? (Y/N)

  2. Documentation 
    • Is there a whitepaper? (Y/N)
    • Are the basic software functions documented? (Y/N)

    • Does the software function documentation fully (100%) cover the deployed contracts? (%)

    • Are there sufficiently detailed comments for all functions within the deployed contract code (%)

    • Is it possible to trace from software documentation to the implementation in code (%)

  3. Testing
    • 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
Back to top