Audit quality is determined substantially before any code is read, in decisions about scope, timing and access.
Scope definition
Which contracts, at which commit, including or excluding tests, scripts and dependencies.
Which is agreed in advance and stated in the report.
Excluding deployment scripts is common and has been the source of real incidents.
Duration and staffing
Engagement length relative to code size and complexity.
Which determines depth more than any other factor.
Reports state reviewer count and duration, and comparing that to lines of code is informative.
Code freeze
Whether the code changes during the review.
Which invalidates work already done and is a common source of friction.
Reviews of a moving target produce findings against code that no longer exists.
Documentation provided
Specifications, architecture documents and threat models.
Which allow reviewers to check whether the code does what it should rather than only whether it is internally consistent.
Projects providing no specification receive a narrower review by necessity.
Access to the team
Availability to answer questions during the engagement.
Which materially affects how much time reviewers spend reconstructing intent.
Responsive teams get better reviews for the same fee.
Findings and remediation
Reviewers report, the team fixes, reviewers verify.
Which requires the verification step to be included in scope.
Reports listing findings without stating whether fixes were verified provide less assurance than they appear to.
Publication
Whether the report is published in full, in summary, or not at all.
Which is the project's decision.
Selective publication of favourable summaries has occurred and is detectable by asking for the full report.
Multiple reviews
Different firms find different issues, with limited overlap in practice.
Which supports commissioning more than one for substantial protocols.
What to look for as a user
Full report, recent commit, adequate duration, verified fixes and the section describing administrative privileges.
Cost structures
Priced by reviewer time, which means larger and more complex codebases cost more.
Which creates pressure to reduce scope on constrained budgets.
Reducing scope to fit a budget is a decision worth documenting rather than obscuring.
Specialist reviews
Cryptographic implementations, economic mechanism design and infrastructure security are distinct specialisms.
Which a general smart contract review does not cover.
Protocols with novel mechanisms need mechanism review as well as code review.
Continuous engagement
Ongoing relationships rather than one-off reviews.
Which suits protocols shipping changes regularly.
This is increasingly common for larger protocols.
Formal methods
Proving properties mathematically for critical components.
Which is expensive and provides stronger assurance for the properties actually specified.
Interpreting reports as a user
Scope, date, duration, unresolved findings, privilege description and whether fixes were verified.
Pre-audit preparation
Clean code, complete tests, written specifications and an internal review first.
Which substantially improves what a review can find in the time available.
Reviewers spending days understanding undocumented code are not finding bugs.
Findings the team disputes
Disagreements about severity or validity are recorded in reports.
Which is legitimate and is worth reading, since the reasoning is stated on both sides.
Post-deployment changes
Code changed after review is unreviewed regardless of what the report says.
Which is checkable by comparing the deployed bytecode against the audited commit.
Bounty programmes alongside
Continuous incentive complements point-in-time review.
Which is the arrangement most mature protocols use.
The summary for users
An audit is evidence of diligence rather than a guarantee, and reading the report tells you far more than the existence of one.
The realistic expectation
Good reviews catch a substantial proportion of issues and never all of them.
Which is why layered assurance — review, bounties, monitoring, staged deployment — is what mature protocols actually do.
Reading a report properly
Skip the summary and read the scope statement, the unresolved findings and the section on administrative privileges.
Which is where the information that actually affects your risk position sits.
Those three sections take about twenty minutes and tell you more than any marketing page will.
The economics behind quality
Firms compete on price and on reputation simultaneously, and the two pull in opposite directions when a project wants a fast, cheap review before a launch date.
Which is why the better firms decline engagements where the scope and timeline do not permit meaningful work.
A firm that accepts any timeline is telling you something about how it operates.
Where the field is heading
Continuous review, automated analysis integrated into development, and formal verification of critical components.
Which shifts assurance earlier rather than treating it as a gate before deployment.
A last note
The scope statement at the front of a report is the single most important paragraph in it, and it is the one nobody reads. Everything the review did not cover is listed there, in plain language, before any findings appear.
It costs nothing to read and reframes everything that follows it.
Everything else in the document is downstream of what the scope permitted.