FAQ

What is audit drift?

"Audit drift" refers to situations where a protocol deploys new unaudited code, after having been previously audited. This results in a drop in overall audit coverage—how much of the project has been audited by security professionals.

Why does it matter?

The new unaudited code may have vulnerabilities an audit would have caught, or introduce vulnerabilities to the previously secure audited code through side effects. This has resulted in many real world hacks, most famously the Nomad bridge exploit of $190M USD in August 2022.

Many more can be found on the Rekt leaderboard using the tag 'unaudited'.

Why do projects push unaudited code?

Achieving full audit coverage is difficult. There is a severe shortage of qualified security professionals with the skills necessary to audit complex smart contract protocols and financial applications. A project may feel compelled to deploy new features to retain users or attract more funding or talent. The odds of a vulnerability slipping through with skilled developers are fairly low, but the chance still exists and increases with code complexity.

This website exists not to cast blame on projects for deploying unaudited code, but to enable users to do their own due diligence. Unaudited code is much more likely to contain latent bugs. By drawing attention to these parts of the code, responsible members of the community can report them through bug bounty programs before they are exploited by malicious actors. In the past, many serious vulnerabilities have existed undetected on-chain for months before they were exploited.

Better tooling, transparency, and processes are necessary to improve the security of the Web3 ecosystem. Web3 was founded on the premises of transparency and observability. Let's make that vision a reality!

What percentage of unaudited code is unsafe?

This varies by project and complexity. Many of the largest DeFi hacks have been exploits affecting unaudited code. Thus, unaudited code should generally be considered unsafe. We recommend 100% audit coverage by at least two qualified firms, 100% unit and integration test coverage, and a bug bounty program with appropriate incentives.

Although most unaudited code in high quality projects is usually safe, as a result of human error, it is inevitable that some code will not be. It's difficult to distinguish whether a project is safe or not without exhaustively considering all changes. A single erraneous line of code can introduce a serious vulnerability, even when hundreds of other lines are safe.

I'm from an audit firm. How do I list all my audits?

Send us an email!

Why does my project have a "Git hash" warning?

Many projects squash their Git commit history when doing a public release, but this means their pre-release audit covered a commit that no longer exists. In this case, we pick the Git commit hash that seems closest to the audit report date, but will add a warning disclaimer to the top of the project that makes it clear the results may not be fully accurate.

To fix this, please get in touch with us to provide a copy of the Git repository that has the audit commit hash present.