What is a Process Quality Audit

From good process comes quality, security and trust

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 here and the detailed process here.

The basic premise of these audits is that developers following and documenting a good software development process should have secure code and maintain trust. Well documented packages are easier to support and understand, making them safer places to trust with your money.

Good Process == Good Code

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.


  1. Deployed Code
    • Is the deployed 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. Requirements and other documentation for the Deployed Code
    • Is there a whitepaper? (Y/N)
    • Are the basic application requirements documented? (Y/N)
    • Are the requirements available publicly? (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 software requirements to the implementation in code (%)
  3. Overall test strategy for Deployed 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