Fake Audit Reports and What a Real One Contains

Projects advertise that their contracts have been audited. The claim is frequently true, occasionally fabricated, and almost always more limited than it sounds.

The fabrications

A report that does not exist. A logo on a website with no linked document.

A report from a firm that does not exist. A professional-looking document from an auditor with no history.

A report for a different contract. Genuine, for an earlier version or a different project, presented as covering the deployed code.

A report with the findings removed. A real audit, edited to delete the issues section.

The checks

Find the report on the auditor’s own site. Reputable firms publish their reports. A report existing only on the project’s site is unverified.

Check the date and the commit hash. A real audit names the exact version of the code reviewed. If the deployed contract differs, the audit does not cover what is running.

This is the most important check and almost nobody does it.

Check the scope. Audits cover specific contracts, not everything a project operates. A report covering the token contract says nothing about the staking contract.

Read the findings. Real audits find issues. A report with no findings is either a trivial contract or a document that is not an audit.

Check what was fixed. Reports list findings and their resolution status. Issues marked acknowledged rather than fixed are issues that still exist.

What an audit does not establish

That the contract is safe. It establishes that a firm reviewed specific code at a specific time and reported what it found. Audited contracts have been exploited.

That the team is honest. An audit reviews code, not intent. A contract can be audited and contain an owner function permitting the team to drain it, correctly reported as a centralisation risk and ignored by everyone reading.

That the deployed code matches. Only a commit hash comparison establishes that.

That the economics work. Audits review implementation, not whether the design is sustainable.

The centralisation findings

Real audits routinely note that an owner address can mint, pause, upgrade or otherwise control the contract. These appear as findings and are frequently marked acknowledged.

That is the auditor telling you the team can do whatever they want, in a document the project cites as evidence of safety.

Reading the centralisation section of any audit is the highest-value ten minutes available in token due diligence.

The practical hierarchy

An unverified contract is worse than an unaudited one, because nobody can inspect it at all.

An audited contract with unresolved centralisation findings is a contract whose safety depends on the team’s intentions.

A contract audited by a known firm, at the deployed commit, with findings resolved, is meaningfully safer and is not safe.

For anything you intend to hold rather than experiment with, the question of whether it is listed on a venue with its own review process, such as a licensed exchange with a published address, is a second filter applied by people whose money depends on getting it right.