Audit scope defines the boundaries of a security review—which smart contracts, external integrations, and specific concerns auditors will examine. A well-defined scope ensures auditors focus their efforts effectively and clients receive thorough coverage of their most critical code. Poorly defined scope leads to wasted effort, missed vulnerabilities, and disputes about audit completeness.

Components of Audit Scope

A comprehensive scope definition includes several elements:

Contracts in scope: The specific smart contract files that auditors will review. This typically includes main protocol contracts while excluding test files, deployment scripts, and mock contracts.

Lines of code: The total size of the codebase being reviewed, often measured in source lines of code (SLOC). This metric influences audit duration and pricing.

External dependencies: Whether integrations with other protocols (oracles, DEXs, lending platforms) are included in the review. Auditors may examine how your code interacts with external contracts without auditing those external contracts themselves.

Deployment configuration: Which networks the contracts will deploy to, what constructor arguments will be used, and what admin configurations are planned.

Known issues: Previously identified issues that auditors shouldn't spend time rediscovering. This includes findings from prior audits, internal reviews, or acknowledged limitations.

Specific concerns: Areas where the development team wants focused attention—complex calculations, novel mechanisms, or integration points they're uncertain about.

Why Scope Matters

Clear scope benefits both auditors and clients:

Focused effort: Auditors concentrate on code that will actually be deployed, not experimental features or deprecated modules.

Accurate pricing: Audit cost correlates with scope size. Undefined scope makes pricing impossible and leads to disputes.

Complete coverage: When scope is explicit, auditors can confirm they've reviewed everything. Vague scope leaves gaps.

Appropriate expectations: Clients understand exactly what they're getting. An audit of "the lending module" is different from "the entire protocol."

Scope Definition Best Practices

When defining scope for an audit:

Be specific about files: List contract paths explicitly rather than saying "all contracts in /src". This prevents confusion about which files matter.

1Contracts in scope:
2- src/core/Vault.sol
3- src/core/Strategy.sol
4- src/periphery/Router.sol
5
6Contracts out of scope:
7- src/mocks/*
8- src/test/*

Specify commit hash: Pin the audit to a specific git commit. Code changes during an audit create confusion about what was actually reviewed.

Document external dependencies: List all external contracts your code interacts with and clarify whether those interactions are in scope.

Include deployment context: Explain planned deployment parameters, admin configurations, and expected operating conditions. A contract might be secure under certain configurations but vulnerable under others.

Share known issues: Don't waste audit time on issues you're already aware of. Document known limitations, acknowledged risks, and issues from prior reviews.

Scope and Pricing

Audit pricing typically correlates with scope size and complexity:

• SLOC count: More code requires more review time
• Complexity factors: DeFi primitives, assembly code, novel mechanisms increase effort
• External integrations: Reviewing cross-protocol interactions adds complexity
• Documentation quality: Well-documented code audits faster than undocumented code

Reducing scope isn't always cost-effective. Excluding critical contracts to save money often results in finding those vulnerabilities in production—a far more expensive outcome.

Changing Scope During Audits

Scope changes during an audit create challenges:

Added code: New contracts added mid-audit may not receive thorough review. Auditors may need additional time and compensation.

Removed code: Excluding code after the audit starts wastes effort already invested in reviewing it.

Material changes: Significant modifications to in-scope code may require re-review of affected areas.

Best practice is to finalize code before the audit begins and resist changes until the audit completes. If changes are necessary, communicate immediately with auditors about implications.

Scope in Competitive Audits

Public audit contests define scope differently than private audits. Contest scope typically includes:

• Repository and commit hash
• Contracts eligible for findings
• Categories of findings accepted
• Known issues that won't be rewarded
• Severity criteria for categorizing findings

Contest participants focus only on in-scope contracts, and findings outside scope are typically rejected regardless of severity.

Scope Documentation

Include scope documentation in your audit preparation materials:

1. README with contract descriptions and relationships
2. Scope table listing files, SLOC, and complexity notes
3. Architecture diagram showing contract interactions
4. Known issues list from internal reviews
5. Deployment specification with configuration details
6. Areas of concern where you want focused review

This documentation helps auditors start productively immediately rather than spending initial time determining what to review.