Prep guide: 7 essential tips to prepare for a blockchain audit

Veridise

Published in

Veridise

5 min readApr 18, 2024

Security audits have become an industry standard in blockchain projects.

So far, over $10 billion USD have been drained through various vulnerabilities within the last five years.

It’s one of the most crucial considerations for dapp founders to avoid ending up in these statistics.

How to prepare for an audit

Proper preparation ensures a smoother audit process, leading to more accurate results and actionable insights.

All projects come with different resources, timelines, and team sizes. We understand that preparing everything mentioned in this article may not be realistic for most projects.

So, take this as a guideline, and aim to complete the mandatory items, and consider the other items within the boundaries of your resources.

Let’s get started!

A summary info graph

Find the full article below.

1. Booking an audit slot: Understand the timeline

Industry-leading blockchain auditing skills are a scarce resource. The most experienced auditors are always booked at least weeks, and often a couple of months, in advance.

Immediate start dates might sometimes hint at varying levels of expertise.

It’s a good idea to start conversations and get a quote early on.

2. Defining the scope of your audit

Defining the scope of your audit is critical to ensure targeting areas of highest risk and significance.

This involves pinpointing specific parts of your blockchain project, such as smart contracts, connected back-end services, or advanced constructs like ZK circuits, that will be examined during the audit.

Aiming for comprehensive security, the scoping decision requires careful thought.

On one hand, a well-defined scope (exact files/folders) allows auditors to focus on the most critical security aspects.

On the other hand, too narrow scoping can also be detrimental. The auditor needs to understand how each piece of the system works, so any code out of scope needs to be at least extremely well-documented. Otherwise, it will prolong the project’s duration even though it’s not scoped in.

That’s why we generally encourage well-balanced scoping.

3. Commit selection & feature freeze

It’s vital to earmark a specific commit of your codebase for the audit.

This establishes a stable reference point, and ensures clarity and consistency throughout the process. This can be done up to the day before the audit start date.

We’ve noticed that developers occasionally continue to work on new features during the audit. It’s completely understandable, as audits can take a while, and the projects need to move quickly. However, these extra features that are deployed after the audit often lead to hacks and cause problems.

It’s worth ensuring to have a proper security plan in place to accompany the development. This leads to higher-quality protocols.

4. Provide relevant documentation

To ensure that auditors can use their time most effectively, it’s worth the effort to ensure that the documentation covers system architecture, data flow, and other critical components.

Relevant documentation depends on your dapp and might include:

Architecture overviews
Design documents (logic behind smart contracts)
Detailed function specifications, state variables, and control flow
Data flow diagrams illustrating:
— How data is input, processed, stored
— Output: insights into data handling and storage mechanisms
External integrations (third-party services or APIs)

5. Code testing and reproducible builds

Before audit, we encourage you to make sure the following steps are prepared, to ensure auditor’s work can start smoothly:

Clean build: Start from a clean environment to ensure that the build and test processes are not dependent on any local configurations or cached data.
Build scripts: Provide any necessary build scripts and instructions to ensure that our team can reproduce your development environment and the steps to get from the source code to the running application.

6. Test for every “Happy Path”

The “happy path” is the typical, expected sequence of events in a feature or function, mimicking the standard user behavior within standard operating conditions.

Make sure you have tests that cover each of these paths to validate that the system behaves as expected under normal conditions:

Ensure functions with valid inputs execute correctly
Ensure integration points between smart contracts and front-ends (correct data flow)

Optimally, these tests are automated and included in the continuous integration/deployment pipeline. This ensures the “happy path” scenarios remain functional through future updates.

7. More testing & code coverage

While testing the “happy path” is the starting point, it’s essential to go further. Ideally, every core component of your software should be tested. Untested components create blind spots in security.

Studies have shown that a rigorous auditing process AND high test coverage lead to stronger and more resilient projects. Not just audits or testing alone.

In projects with low test coverage, we tend to find more significant bugs, many of which are simple bugs where the behavior deviates from what the developers have documented.

Thus, the more thoroughly you can test your own code, the better.

That said, we understand that all projects come with their unique resources and timelines, and we can accommodate the situation at hand.

Further testing and other methods:

Testing the “Bad Paths”: Not every interaction with your system will follow the expected route. It’s crucial to test for unexpected or erroneous inputs and actions to see how your system responds.
Programmatic coverage checks: Use tools to programmatically check test coverage. These tools can highlight areas of your code that haven’t been tested, providing a roadmap for improving test coverage.
Access control tests: Ensure that every access control mechanism fails when it should. This verifies that unauthorized users cannot access protected resources or perform actions beyond their permissions.
Checking invariants: For systems, especially financial ones like pools, check for expected invariants. For example, swapping one currency for another, then back, shouldn’t lead to the pool losing money.
Utilize static analyzers: These tools examine your code without executing it. They can identify common vulnerabilities and issues that might be missed during runtime testing. Many static analyzers are open-source and can help catch errors as early as possible.
Write consistent code: For example, you can use linters for your specific programming language. Linters ensure the code is consistent, clean, and follows best practices. Well-formatted code aids in the audit process by improving readability and reducing potential pitfalls.
Avoid code duplication: Needless to say, avoid duplication when writing code. That is, avoid copy-and-pasting! This will reduce the time needed to audit your code and make the codebase more maintainable.

We’re looking forward to working with you to enhance the security of your software