Back to Blog 
You've finished building. You ping three audit firms for quotes. The first comes back at 90,000 over six weeks. The third asks for a kickoff call before they'll even quote.
The spread isn't because two of them are overcharging. It's because all three are guessing — and one is guessing more carefully than the others.
The price and timeline of an audit are not set when you sign the engagement letter. They're set in the first hour an auditor spends in your repo. If they spend that hour reverse-engineering your intent, you're paying senior security researcher rates for them to read your mind. If they spend it attacking your trust boundaries, you're getting what you paid for.
This is a guide to making sure it's the second one.
What scoping actually decides
Scoping is the process an audit firm uses to answer three questions before they quote you:
- Which contracts do we review, at which exact version of the code?
- How many auditor-days does that surface area need?
- What does the team already know that we don't have to rediscover?
The output is a scope document, a quote, and a timeline. The inputs are everything you hand over before the first call. Sherlock's published guidance puts a number on this: when teams arrive with a clean scope, their reviewers recover one to two full days of attention on deeper issues instead of basic orientation. Across the industry, clean preparation reduces final cost by 15–30%.
That's not a marketing claim. It's the difference between an auditor finding the economic exploit in your liquidation logic and an auditor still figuring out which contract holds the liquidation logic.
The seven things every auditor needs from you
These are the deliverables that consistently appear across the readiness checklists published by Hacken, ConsenSys Diligence, OpenZeppelin, Quantstamp, Trail of Bits, and Nascent. When all seven are present, audit firms quote faster, charge less, and write better reports.
1. A frozen commit hash and explicit scope boundaries
Every major firm requires this. There is no exception.
Quantstamp states it plainly: smart contract audits are always done on a frozen codebase, which is a snapshot in time at a specific commit hash. Any changes made during or after the review may introduce attack vectors the audit never examined. ConsenSys Diligence won't allow scope changes once an audit starts. Sherlock calls commit-pinning "non-negotiable."
The reason is mechanical. If your code changes mid-review, the auditor loses the ability to reason about the system as a whole, and the timeline expands as they re-trace the impact of every modification. Findings written against
main last Tuesday may not apply to main next Tuesday.What to hand over:
- Full repository URL
- Branch name
- Exact commit hash
- File paths in scope (every
.solfile, every library, every interface) - File paths explicitly out of scope (frontends, off-chain indexers, third-party dependencies you're not modifying)
- Deploy scripts and upgrade scripts inside the scoped commit — Nascent's checklist is explicit that deployments and upgrades are as important as runtime code and require the same security attention
If certain modules must keep developing in parallel, push them to a separate branch and exclude them from the scoped commit. Don't ask the auditor to audit
main and "just ignore the new stuff." Our pre-audit checklist walks through the exact tag-and-freeze commands we recommend.2. A reproducible build that runs in one command
The Hacken methodology frames the goal directly: hand over a repository that a new engineer can clone, set up, and run without manual guesswork or local workarounds.
Cyfrin's audit walkthrough confirms the same — the first thing an auditor does is build the project locally and run the test suite. If that takes two days because of undocumented private dependencies, an unspecified Node version, or a missing
.env template, those are two days of senior research time billed to you for DevOps work.Concrete deliverables:
- A
READMEwith one-command install and build steps - Documented Solidity / Rust / framework versions
- Foundry, Hardhat, or Anchor configuration committed
.env.examplefor any required keys (RPC endpoints, fork URLs, API keys)- Notes on testnets, mainnet forks, and any RPC requirements
- Any private dependency setup steps documented explicitly
If
forge build doesn't succeed on a fresh clone, you're not ready to audit.3. A test suite with visible coverage
Quantstamp's published target is 100% line coverage. That's aspirational for most teams, but the principle isn't: well-written tests decrease the time and cost of audits because reviewers can see what the developers consider critical and where the gaps are.
The Cyfrin framing is more useful in practice: tests are the protocol's heartbeat. They reveal what the developers value, and examining test coverage exposes the more vulnerable segments of the codebase by showing which corners are unwalked.
What auditors expect to see:
- Unit tests covering happy paths and revert paths. All tests passing.
- Coverage report generated and visible. Don't hide gaps — auditors will find them anyway, and a visible gap is faster to triage than a hidden one.
- Fuzz tests. Foundry invariant testing or Echidna stateful fuzzing. Nascent's checklist treats this as baseline, not bonus.
- Integration / fork tests against mainnet state where the protocol depends on live external contracts.
- Deploy script tested end-to-end against a local node or testnet.
A protocol that hands over a test suite already exercising its invariants under fuzzing is asking the auditor for higher-level review than one that hands over five unit tests and a
TODO file. If you're newer to fuzzing, our guide to how fuzz testing strengthens Web3 security covers what "baseline fuzzing" actually looks like.4. Three layers of documentation
Documentation isn't one deliverable. It's three, and auditors expect all three.
Layer 1 — High-level specification. What is the protocol supposed to do? Hacken's methodology splits this into functional requirements (the baseline used to evaluate correctness, written in clear testable form) and a technical description (how the system works internally and provides context for security analysis). Dedaub's stated position to clients is that auditors will not know your specification — your mathematical formulas, your desired behavior — if you don't clearly communicate it. Auditing will likely miss violations of functional correctness when the definition of correct calculations is not given.
Layer 2 — Architecture diagrams. Inheritance hierarchy. Contract interconnections. State transitions. The flow of value through the system. Where external calls cross trust boundaries. OpenZeppelin's readiness guide expects these. So does every checklist that takes architecture review seriously, because the highest-impact bugs in production DeFi systems are rarely isolated Solidity gotchas — they're failures of assumptions about how the pieces fit together.
Layer 3 — Code-level documentation. NatSpec on every public and external function. The Solidity compiler only parses NatSpec tags on
public and external interfaces, but Nascent and OpenZeppelin both recommend documenting internal functions that implement sensitive logic anyway. Inline comments at points of concentrated risk — untrusted external calls, sensitive calculations, anywhere unchecked or assembly appears.ConsenSys Diligence puts the cost of skipping this in plain terms: failing to clarify intent in code comments forces auditors to spend more time trying to understand. That increases scope and drives up cost.
5. A roles and permissions table
This is one of the highest-leverage pre-audit deliverables and one of the most consistently missing.
The first question on the Rekt Test is whether you have all actors, roles, and privileges documented. Trail of Bits' guidance is direct: by answering this question and crafting the documentation, teams find low-hanging fruit in misaligned assumptions, gaps in who is actually responsible for which functions, and who is and is not supposed to have access to what.
A roles table is a single page. The columns are:
- Role name (Owner, Admin, Pauser, Treasurer, Keeper, User)
- Address type (multisig threshold, EOA, contract)
- Functions callable by this role
- Trust assumption (e.g. "assumed not malicious," "assumed to act within timelock")
- Blast radius if compromised (e.g. "can mint unlimited supply," "can pause withdrawals for 24 hours")
Trail of Bits' own published research on access control maturity makes the case that audits conducted by blockchain-native firms rarely flag architectural access control issues as formal findings — meaning if you don't surface privileged functions yourself, the auditor may not write them up even if they spot them. The roles table forces the conversation onto the table.
6. A list of invariants
Invariants are the statements that must always be true about your system, regardless of which functions are called or in what order. Total deposits should equal total shares times the share price. No user should withdraw more than they deposited plus their accrued yield. The protocol should never enter a state where it owes more than it holds.
ConsenSys Diligence's framing: identifying these invariants helps auditors brainstorm user operations that could violate security properties and result in exploits. Sherlock's recommendation is identical — give auditors a clear spec, include invariant statements ("this must always be true"), and document trusted roles and upgrade paths.
The Rekt Test's question 9 is whether you define key invariants for your system and test them on every commit. If the answer is yes, hand over the invariant suite. If the answer is no, write the invariants down even if you haven't tested them yet — the list itself is valuable.
Nascent recommends the FREI-PI pattern (Function Requirements–Effects–Interactions–Protocol Invariants) for this: treat all token and ETH transfers as interactions, then verify your system-level invariants still hold at the end of each one. Whether or not you've adopted the pattern, the invariant list is what the auditor uses to design adversarial test cases. For a deeper walkthrough of how invariants and formal methods interact, see our post on fuzzing and formal verification in blockchain security.
7. A "known acceptable issues" list
This is the deliverable that prevents wasted findings.
Nascent's checklist gives the model: write down extraneous security assumptions. Their example covers everything from oracle behavior to chain reorg depth: we assume the owner is not malicious, that Chainlink oracles won't lie about price, that Chainlink oracles will report at least once every 24 hours, that all tokens the owner approves are ERC20-compliant with no transfer hooks, and that there will never be a chain reorg of more than 30 blocks.
Sherlock's position: listing open concerns gives auditors a clearer target and often leads to stronger findings. Hiding them slows everything down and forces reviewers to rediscover what you already suspected.
Without this list, the audit report will contain Medium-severity findings the team had already evaluated and accepted three months ago. Each one consumes auditor time to write up, team time to respond to, and report space that could have gone to a real exploit path. With the list, the auditor knows your trust boundary on day one and spends review time stress-testing whether the assumptions actually hold.
What drives the price
Once the scope is defined, the quote is largely a function of five variables.
1. Codebase size, measured in nSLOC. Non-comment source lines of code is the primary pricing driver across every major firm. Sherlock's published timeline guidance maps this directly:
| nSLOC | Contest duration |
|---|---|
| ~500 | 3 days |
| ~3,000 | 18 days |
| ~6,000 | 38 days |
Above 6,000 nSLOC, duration stops scaling linearly — the complexity becomes exponential, and Sherlock will recommend splitting scope or sequencing reviews. Sherlock uses the Solidity Metrics tool to calculate nSLOC; if you want to predict your own quote, run it before requesting one.
2. Logic density. A 500-line ERC-20 is not the same as a 500-line cross-chain bridge. Boilerplate token logic is a solved problem priced at 15K. The same line count handling state synchronization across chains, ZK proof verification, or custom AMM math can triple. Auditors price the difficulty of the code, not just its length.
3. Language and chain. Solidity has the deepest auditor pool, which keeps prices anchored. Rust on Solana commands a 25–40% premium because qualified reviewers are scarcer. Cairo and Move sit 30–45% above EVM equivalents. ZK circuits — circom, Halo2, Plonky2 — run 80–120% above the Solidity baseline because the cryptographic expertise is rare.
4. External integrations. Each oracle, bridge, or external protocol your contracts touch expands the threat model the auditor has to internalize. A 600-nSLOC Uniswap v4 hook is not a 600-nSLOC scope if the hook's behavior depends on PoolManager internals. Sherlock's framing: scope that looks small on the surface often expands once integration dependencies are counted.
5. Timeline urgency. Requesting a two-week turnaround for a six-week scope means pulling senior engineers off other engagements. Sherlock prices this at 20–40% on top of base fees. Other firms quote 10–30%. If you've planned the security budget but not the security calendar, the calendar slip is what costs you.
A reference table of 2026 markets, cross-referenced from Sherlock, Zealynx's own pricing data, and public quotes from Hacken and Hashlock:
| Scope type | nSLOC range | Typical cost | Typical duration |
|---|---|---|---|
| Simple ERC-20 / NFT | <500 | 15K | 2–5 days |
| Mid-complexity DeFi | 1,000–3,000 | 100K | 2–4 weeks |
| Complex DeFi / multi-contract / cross-chain | 3,000–6,000 | 250K | 4–8 weeks |
| Bridge / L1 / ZK rollup | 6,000+ | 500K+ | 2–6 months |
| Re-audit (per pass, post-remediation) | n/a | 20K | 1–2 weeks |
The re-audit line is the most commonly forgotten budget item. Plan for at least one remediation pass; complex protocols often need two. Our article on what smart contract audits actually cost breaks down the re-audit line item in more detail.
Run the Rekt Test before you request a quote
Before you fill in any scope document, run the Rekt Test internally.
The Rekt Test is twelve yes/no questions published by Trail of Bits, Fireblocks, Immunefi, Anchorage Digital, Solana Foundation, and Euler Labs. It's the de facto industry gate for whether a project is actually ready for an external review. Several firms — Cyfrin and Nascent both publicly — recommend that teams unable to answer "yes" to most of these questions delay their audit until they can.
The twelve questions:
- Do you have all actors, roles, and privileges documented?
- Do you keep documentation of all the external services, contracts, and oracles you rely on?
- Do you have a written and tested incident response plan?
- Do you document the best ways to attack your system?
- Do you perform identity verification and background checks on all employees?
- Do you have a team member with security defined in their role?
- Do you require hardware security keys for production systems?
- Does your key management system require multiple humans and physical steps?
- Do you define key invariants for your system and test them on every commit?
- Do you use the best automated tools to discover security issues in your code?
- Do you undergo external audits and maintain a vulnerability disclosure or bug bounty program?
- Have you considered and mitigated avenues for abusing users of your system?
Are you audit-ready?
Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.
No spam. Unsubscribe anytime.
Questions 1, 2, 4, 9, and 10 map directly to the scoping deliverables in this guide. The others are operational maturity that auditors increasingly factor into how they assess whether a team will respond competently to remediation.
A "no" to any of these isn't a reason not to audit. It's a reason to know what you're walking in with.
The scope document auditors actually want
The closest thing the industry has to a standardized scope document is the form Code4rena uses for its competitive audit prep, which Nascent published as the second half of its audit-readiness checklist. Filling this out before the first sales call does roughly 60% of the work an audit firm would otherwise need to do during scoping.
The fields:
- Public code repo URL
- Number of contracts in scope
- Total SLoC for these contracts
- Number of external imports
- Number of separate interfaces and struct definitions
- Composition vs. inheritance (which dominates)
- Number of external calls
- Overall line coverage % from your tests
- Whether a separate part of the codebase needs to be understood for context, and if so what
- Oracle usage (which provider, fallback behavior, staleness handling)
- ERC20 standard conformance (yes / no / which deviations)
- Interaction with non-standard ERCs (ERC721, ERC777, fee-on-transfer, rebasing)
- Novel curve logic or mathematical models
- Timelock usage
- NFT (yes/no)
- AMM (yes/no)
- Fork of a popular project (yes/no, which one)
- Rollup usage
- Multi-chain (yes/no)
- Side-chain
- Specific areas you want stress-tested ("please try to break X")
The last field is underused and high-value. If you suspect the liquidation math is the weakest link, say so. The auditor will spend disproportionate time there, and the report will be sharper for it.
What clean preparation actually buys you
If you hand over the seven deliverables above plus the Code4rena scope document, three things happen.
The quote drops. Cross-source data from PixelPlex, Hacken, and Sherlock puts the savings at 15–30% on the final price, depending on starting condition. For a 15K–$30K — more than the cost of a re-audit pass.
The reviewer attention shifts upward. Sherlock's data point is one to two days of senior reviewer time recovered from orientation and re-scoping, redirected at adversarial review. On a three-week engagement, that's roughly 10% of the entire audit window moved from setup to attack surface analysis.
The report quality improves. Reviewers who already understand intent can write findings in terms of "this violates the protocol invariant that total debt cannot exceed total collateral" instead of "this looks suspicious, please confirm intended behavior." Specific findings remediate faster.
The inverse is also true. The five most common preparation failures, drawn from cross-referencing the Hacken, Sherlock, and BlockchainAppFactory readiness guides:
- No frozen commit. The team sends a repo link and says "audit
main." The auditor re-scopes every push. - Unwritten invariants. The team knows what must hold but never wrote it down. The auditor either derives invariants from tests or guesses.
- Hidden privileged roles. Admin functions exist but aren't enumerated. Trail of Bits flags this as the #1 cause of architectural findings being missed.
- No known-acceptable-issues list. The auditor reports a Medium finding the team had already evaluated and accepted. Wasted finding, wasted response cycle.
- Stale or missing diagrams. The only architecture artifact is the original whitepaper diagram from before three major refactors.
Each of these adds days to the engagement. Together, they explain most of the variance between a 90K quote on similarly sized codebases.
What to send the auditor
A working pre-audit packet contains:
- Repository URL, branch, commit hash
- In-scope file list, out-of-scope file list
- README with one-command setup
- Test suite passing, coverage report attached
- Fuzz / invariant test files
- Whitepaper or technical specification
- Architecture diagrams (current, not stale)
- NatSpec on every public and external function
- Roles and permissions table
- Invariants list
- Known acceptable issues list
- Deploy and upgrade scripts
- Filled-out Code4rena-style scope document
- Specific areas you want stress-tested
If all of this exists when you request a quote, you've removed the auditor's day-one friction. The quote you get back reflects the actual difficulty of attacking your code, not the difficulty of understanding it.
That's the version of audit pricing that scales with the security risk, instead of the documentation debt.
Partner with Zealynx
At Zealynx, every quote we issue is grounded in scoped data — the seven deliverables in this guide are exactly what we ask for during intake. Teams that arrive prepared get faster turnarounds, lower quotes, and reports that focus on real attack paths instead of orientation gaps. We also help teams prepare for a productive audit before they commit to a quote.
Before you request quotes, choose the right next step
Option 1, self-serve readiness check with Krait
Use Krait first if you want to surface missing tests, thin documentation, or unclear scope drivers before talking to any audit firm. It runs the same readiness checks our intake team uses.
- Best for teams still tightening scope, test coverage, or launch timing
- Reduces auditor ramp time before the first sales conversation
- Concrete next step before committing to a quote request
Option 2, request a scoped audit quote
If your contracts, chain, and launch window are defined, request a scoped audit quote and we'll map the review to your architecture and timeline.
- Best for teams ready to book an audit window
- Direct path for buyers who already know they need expert review
FAQ: Smart contract audit scoping
1. What is smart contract audit scoping, and why does it set your price before the audit even starts?
Audit scoping is the process an audit firm uses to define what code will be reviewed, at which exact commit, for how long, and at what price. The output is a scope document, a quote, and a timeline. The inputs are the materials the project hands over: repository details, frozen commit hash, test suite, documentation, roles map, and invariants list. Better inputs produce faster quotes and lower prices — the pre-audit checklist covers how to prepare them.
2. What is a frozen commit hash and why do auditors require one before quoting?
A frozen commit hash is the exact, immutable Git reference (e.g.
a3f4c1d...) the audit will be performed against. Every major firm — Quantstamp, ConsenSys Diligence, Sherlock, Hacken — requires it because findings only make sense against a fixed version of the code. If the code changes during the audit, the auditor loses the ability to reason about the system as a whole and the timeline expands. A branch name like main is not a frozen commit hash — main moves; the SHA doesn't.3. What is nSLOC and how does it affect audit pricing?
nSLOC is non-comment source lines of code — the number of executable Solidity (or Rust, Cairo, etc.) lines, excluding comments and blank lines. Sherlock and most contest platforms use nSLOC as the primary pricing driver. Sherlock's published mapping: ~500 nSLOC = 3-day window, ~3,000 nSLOC ≈ 18 days, ~6,000 nSLOC ≈ 38 days. Above 6,000, complexity becomes exponential and scope often gets split. Run Solidity Metrics against your scope before requesting quotes so you can sanity-check the numbers firms come back with.
4. What documentation do auditors actually need, and what happens if I skip a layer?
Three layers: (1) high-level specification or whitepaper describing what the protocol is supposed to do, (2) architecture diagrams showing inheritance, contract interactions, and value flow, and (3) NatSpec comments on every public and external function plus inline comments at points of concentrated risk. Missing any layer forces auditors to reconstruct intent, which inflates cost. ConsenSys Diligence specifically flags missing layer-3 code comments as one of the top causes of audit scope creep.
5. What are smart contract invariants, and why do auditors ask for an invariants list during scoping?
Invariants are statements that must always hold for your system to remain secure — for example, "total deposits always equal total shares times share price" or "no user can withdraw more than they deposited plus accrued yield." Documented invariants help auditors design adversarial test cases that probe exactly the boundaries you care about. They also let fuzzing tools (Foundry, Echidna, Medusa) attack system properties directly. Nascent's FREI-PI pattern takes this further by enforcing invariants at runtime, not just in tests.
6. What is a "known acceptable issues" list, and why does leaving it out cost you findings?
It's a written list of risks your team has already evaluated and chosen to accept — for example, "we assume the owner multisig is not malicious" or "we accept that Chainlink may not report price more frequently than once per 24 hours." Without this list, audit reports include findings the team had already evaluated, wasting both auditor and team cycles. Nascent's audit readiness checklist makes this an explicit deliverable. It also clarifies the protocol's stated trust boundary — which is where auditors then focus stress-testing effort.
7. How can I reduce my audit quote without sacrificing depth of review?
Run the Rekt Test internally, freeze your commit hash, hand over a one-command-setup repo, document invariants, build a roles table, and fill out the Code4rena-style scope document. Cross-source data puts preparation savings at 15–30% on final price. For a 15K–$30K — more than a re-audit pass costs. Our guide to how to efficiently prepare for a productive smart contract audit walks through the prep in order.
8. What is the Rekt Test, and how does it relate to audit readiness?
The Rekt Test is a 12-question self-assessment published by Trail of Bits, Fireblocks, Immunefi, Anchorage Digital, Ribbit Capital, Solana Foundation, and Euler Labs. It covers documentation, key management, invariants, monitoring, and incident response. Industry guidance is that teams unable to answer "yes" to most questions are not yet audit-ready and should resolve the gaps before requesting quotes. It's cheaper to close a Rekt Test gap yourself than to pay an auditor to discover it.
Glossary
| Term | Definition |
|---|---|
| nSLOC | Non-comment source lines of code. The standard metric for sizing smart contract audit scope. |
| Rekt Test | The 12-question pre-audit readiness self-assessment published by Trail of Bits and partners. |
| Frozen Commit Hash | The specific, immutable Git reference a smart contract audit is performed against. |
| FREI-PI Pattern | Function Requirements–Effects–Interactions–Protocol Invariants. Nascent's invariant-aware contract design pattern. |
| Audit Readiness | The state of a protocol's codebase and documentation being prepared for a formal security audit. |
| Audit Scope | Defined boundaries of what code and functionality will be reviewed. |
| Trust Boundary | Interface where data enters the protocol or assets move between components — highest-risk analysis area. |
Are you audit-ready?
Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.
No spam. Unsubscribe anytime.
