How Smart Contract Audit Scoping Works

By the Guardian team Updated November 2026 5 min read

Quick answer. Auditors scope from your repository at a frozen commit: the files in scope, their size in nSLOC, how complex and integrated the code is, and what is excluded. That sets auditors and review days, which set the price.

Watch: How Smart Contract Audit Scoping Works 1:43

Video transcript

Every audit quote rests on its scope: the code auditors will read, at which commit, and what they will not. The report covers that scope alone.

Before anyone quotes, scoping settles four questions: what code, how hard it is, who reviews it for how long, and what is left out.

Scripts and config count too. In Guardian's Citrea Stablecoin Bridge report, 907 of 1,098 lines in scope were deployment and configuration scripts, and one finding sat there.

After Cetus lost 223 million dollars in May 2025, Zellic said the bug sat in a library outside the scope of its audit. So list every dependency your code trusts.

Size, in non-comment source lines, sets the baseline. Complexity adjusts it: oracles, external calls, novel math, multi-chain code. That sets auditors and review days, which set the price.

Exclusions matter. In a study of 68 audited incidents from the first half of 2026, 67.6 percent had attack paths outside every identified public audit scope. Those carried 94.4 percent of reported losses.

At Guardian, audits are scoped by repository and commit, OpSec audits by funds at stake, and pentests by accounts, endpoints or code. Vanguard reviews audited-scope changes for six months after production.

Read the full guide for what a scope document should say, or talk to Guardian at guardian.security to get your audit scoped.

Scope is the agreement behind an audit quote. It names the code the auditors will read, at which commit, and what they will not.

It also decides what the final report can claim. An audit covers the scope it was given, and nothing else.

This guide covers how scope is set. For prices, see our audit cost estimator. For getting the code ready, see how to prepare for a smart contract audit.

What Scoping Answers

Before anyone quotes, scoping settles four questions:

What code: the repositories, the files and the commit.
How hard: size, complexity and integrations.
Who and how long: the auditor count and review days.
What is out: excluded code, and what auditors may assume about it.

The answers become the scope document. The quote is built from it.

Files, Commits and Dependencies

The commit

Scope is pinned to a commit hash, so everyone reviews the same code. Sherlock's contest guide asks for "the frozen commit hash and branch" and the final list of contracts in scope about 72 hours before the start.

Fixes are reviewed later, at their own commit. Guardian's Citrea Stablecoin Bridge report lists one commit for its main review and another for its remediation review.

The files

The file list is where scope is really decided. Deployment scripts and configuration count too.

In that Citrea report, 907 of the 1,098 nSLOC in scope were deployment and configuration scripts.

One finding sat in them. The scripts enabled bridge peers before the destination bridge was allowed to mint, so early messages would revert (L-02, resolved).

Dependencies

Imported libraries are the classic gap. After Cetus lost $223M in May 2025, Zellic said the bug sat in the integer-mate library, which "was not included in the scope of our audit."

List every library, oracle, bridge and protocol the code trusts. Mark each one as in scope, or as an assumption the auditors may rely on.

Sizing in Auditor-Days

Scope becomes a team and a calendar: how many auditors, for how many days. Our cost estimator turns that into a price range.

Size sets the baseline

The usual size measure is nSLOC: non-comment source lines of code. Sherlock calculates it with the Solidity Metrics tool.

Days rise with nSLOC, but not in a straight line. For very large codebases, Sherlock notes, "duration is not purely linear."

Complexity adjusts it

Code4rena's scoping questions show what auditors weigh. Its 2023 PoolTogether audit asked, among others:

How many external calls and imports?
Does it use an oracle, a timelock, an AMM or rollups?
Is there novel curve logic or a mathematical model?
Is it a fork of a popular project?
Is it multi-chain?
What is the test coverage?
Do auditors need context from code outside the scope?

For non-Solidity code, Sherlock sets review length by "program structure, attack surface, and integration complexity rather than nSLOC."

Scope Creep and Change Requests

Scope creep usually arrives as new commits. The code keeps moving after the quote, and the auditors are asked to include it.

Agree the rules before the start:

Changes after the frozen commit are out, unless both sides agree in writing.
Additions are priced in the same unit as the quote.
Fixes are reviewed at a named commit, in a fix-review round.
Work too large for one window is split or sequenced.

Sherlock may recommend that split for broad scopes. If the frozen commit falls short of its readiness checklist, it works with the team to reschedule, extend the audit or proceed on a best-efforts basis.

Code changed after the final review needs its own review. See when you need a re-audit.

What Is Out of Scope

Exclusions are normal. The risk is that readers of the report miss them.

A study of H1 2026 incidents by ack3 and Czech Technical University looked at 68 with an identified audit history.

In 46 of them (67.6%), the attack path was outside every identified public pre-incident audit scope. Those 46 accounted for 94.4% of the group's reported losses.

So write each exclusion down, with its reason. PoolTogether's Code4rena scope excluded two unfinished components and told auditors what to assume about each.

Guardian's contest terms are explicit in the same way. Post-audit changes, frontend, backend and infrastructure bugs are out of scope unless explicitly included.

For where losses came from, read audited vs unaudited exploits.

What a Scope Document Includes

A good scope document fits on a page or two. It states:

The repository URL and the frozen commit hash.
In-scope files with nSLOC each, including scripts and config.
Out-of-scope files, with reasons and assumptions.
Dependencies and trust assumptions: libraries, oracles, bridges, admin roles.
Target chains and how the code will be deployed.
Known issues and past audit reports.
Documentation, the test suite and its coverage.
Auditor count, review days, start date and fix-review rounds.
Deliverables: the report, the severity scale and whether it is published.

Trail of Bits also asks teams to include past security reviews and known bugs. Any private dependency needed to build the code should ship with it.

How Guardian Scopes an Audit

Each Guardian engagement has its own scoping unit:

Engagement	Scoped by
Smart contract audit	Your repository and commit
OpSec audit	The funds at stake and who can move them
Infrastructure pentest	The cloud accounts and platforms in play
API pentest	Endpoint count and the roles behind them
Offchain automation pentest	What has to be read, like a code review

On its institutional page, Guardian scopes pre-production reviews "by what the code can move rather than by line count alone."

Scope also carries past launch. Vanguard reviews changes to the audited scope for six months after production, up to 2,500 onchain or 10,000 offchain SLOC.

Frequently Asked Questions

What is the scope of a smart contract audit?

It is the named files in a repository, at a specific commit, that the auditors agree to review. A scope document also lists exclusions, dependencies and assumptions, team size and review dates.

What is nSLOC?

Non-comment source lines of code, the usual measure of an audit's size. Sherlock calculates it with the Solidity Metrics tool. Complexity and integrations then adjust the estimate.

What happens if code changes during an audit?

Changes after the frozen commit are out of scope unless both sides agree to add them, usually with more time. Fixes for findings are reviewed later, at a named commit, in a fix-review round.

Why do audits leave code out of scope?

Code may be unfinished, already audited or owned by a third party. Exclusions are normal, but write each one down with what the auditors may assume about it: the report covers only what was in scope.

Sources

Get your audit scoped

Share your repository and frozen commit, and Guardian will set the scope before it quotes.

Talk to Guardian Get a Vanguard quote