Trusted by 100s of Web3 teams
What a smart contract audit costs in 2026, and how scope is decided
A manual smart contract audit at Fidesium starts at $5,000. Continuous automated scanning starts at $399 a month. Quotes across this category vary enormously, and the spread is not mostly about which firm you pick. It is about how much code you put in scope, how dense the logic is, and how fast you need the report.
That is the part almost nobody publishes, so this page does: what the market publishes, what moves a quote, how scope is decided, how lines of code are counted, and what happens when the code changes.
What a smart contract audit costs in 2026
Fidesium publishes its prices. Here they are in full.
| What you are buying | Price | What is included |
|---|---|---|
| Five free scans, Fid Pro | $0/ month | GitHub integration / file upload / onchain scan, 1 project, 3 members, API access |
| Continuous scanning, Fid Pro | $50/ month | GitHub integration / file upload / onchain scan, 3 project, 10 members, API access |
| Manual audit, standard contracts | from $5,000 | Our scanner, advance AI techniques, line-by-line review, logic and economic risk analysis, 2 rounds of fix verification, public report plus badge plus on-chain NFT, 1 month of scanning, 1 to 3 week turnaround |
| Enterprise security | Custom | Protocol-level review, bug bounty management, ongoing advisory, priority scheduling, custom SLA |
Manual audit plus six months of scanning is bundled at 30% off, and quotes come back within 24 hours.
What the rest of the category publishes
Three different things get called audit pricing, and confusing them is how a security budget ends up wrong by a factor of ten. A firm’s own published price is what that firm will charge. A published market reference is one firm’s estimate of what the market charges, useful for budgeting but not a quote from anyone. Quote on request is the default.
Every figure below was read on the named page on 25 August 2026. Nothing here is estimated.
| Source | What it publishes | The figure, as published | Where |
|---|---|---|---|
| Fidesium | Its own prices, in full | Manual audits from $5,000. Continuous scanning $50 per month. Enterprise custom | /pricing, /manual-smart-contract-audits |
| Hexens | Its own engagement range | “Engagements range from $30K for focused smart contract reviews to $1M+ for comprehensive platform-wide assessments” | hexens.io/services/blockchain-security |
| SolidityScan | Its own prices, for automated scanning rather than a manual audit | Trial $0, On Demand $50 per month, Enterprise custom, all USD | solidityscan.com/pricing |
| Sherlock | A market reference, not its own price list | “The audit market spans roughly $5,000 to $250,000 per engagement, with most DeFi protocol audits landing between $25,000 and $100,000“, plus remediation rounds that “typically add $5,000 to $20,000 per pass” | sherlock.xyz, Feb 2026 |
| Ulam | A market reference, attributed to third parties | Basic token contract $10,000 to $20,000, DeFi protocol or dApp $20,000 to $50,000, advanced ecosystem $75,000 to $150,000+ | ulam.io/blog/smart-contract-audit |
| **CertiK**, **Quantstamp**, **Cyfrin**, **Oak Security** | No price | Quote on request, after a scoping conversation | Their own audit service pages |
Set against those references, $5,000 is an entry point, not an average. It buys a standard-contract scope, not a multi-chain protocol review, and the honest way to compare it with a $40,000 quote is to compare the file lists rather than the invoices.
Quoting on request is not a failing either. Oak Security’s own answer to “how much does an audit cost” is “It depends. We price each audit individually”, which is a fair description of bespoke review. It does mean a founder budgeting ahead of a raise runs a procurement process just to learn the shape of the market.
What actually drives the price
Six inputs decide a quote, and line count is only the first.
| Input | Why it moves the number |
|---|---|
| Code in scope | Measured in nSLOC (non-comment source lines of code), not raw file length |
| Logic density | A 300-line AMM with custom curve maths is a harder review than 3,000 lines of standard token plumbing. Risk per line, not lines |
| External integrations | Every oracle, bridge, lending market or router you compose with is another system whose failure modes must be reasoned about |
| Language and chain | Solidity on EVM has the deepest tooling. Rust on Solana scopes off program structure and attack surface rather than line count |
| Upgradeability and privilege | Proxies, admin keys and timelocks widen the review from “is the code correct” to “what can the owner do to holders” |
| Timeline | A compressed window does not remove work, it adds reviewers in parallel |
For a sense of how size maps to time, Sherlock’s documentation puts roughly 500 nSLOC at about 3 days and 6,000 nSLOC at about 38 days on its contest model (docs.sherlock.xyz). Different model, different price, but the shape holds: review time scales with in-scope code, and cost scales with review time. That is why two quotes for “an audit of our protocol” can differ by an order of magnitude while both being honest. They are not quoting the same scope.
How scope is actually decided
Scope is agreed on a call, then written down. Four things get fixed, and all four belong in the engagement before money moves.
1. A commit, not a project. Scope is a repository, a branch and a specific commit hash. “Our protocol” is not a scope. github.com/yourorg/protocol, branch main, commit a3f91c2 is. Everything the report says is a statement about that commit.
2. A file list. Explicit in-scope and out-of-scope paths, in writing. Not a folder, a list.
3. The trust assumptions. What the auditors are asked to take as given: that the admin multisig is honest, that the oracle reports the truth, that the chain does not reorganise past finality. These are the boundary of the review, and they go in the report.
4. The threat model. Who the attacker is and what they are trying to take. A protocol holding user deposits and a points contract holding nothing are different reviews at the same line count.
What is usually in, out, and negotiable
| Typically in scope | Typically out of scope | By agreement |
|---|---|---|
| Your own contracts and libraries | Front end and web app | Deployment and upgrade scripts |
| Third-party code you modified | Off-chain indexers and keepers with no privileges | Off-chain signers and keepers that hold privileges |
| Access control and role configuration | Tests, mocks and fixtures | Unmodified dependencies you rely on economically |
| Upgrade paths and storage layout | Unmodified imported libraries | Forks, and how much of the base comes with the diff |
Transparency
Can we audit only part of the protocol?
Yes. Most teams do not need every line reviewed, they need the parts that hold value reviewed properly. The rule that makes a partial scope safe is this: scope by trust boundary, not by file count.
If an in-scope contract can be called by an out-of-scope contract, that contract’s behaviour becomes an assumption, and the assumption is load-bearing. Cutting a file out of scope does not cut it out of your risk. It moves it from something checked to something assumed.
Three things follow:
- Draw the line where value and privilege sit. Anything that can move funds, mint, pause, upgrade or set a price belongs inside.
- Anything calling into the in-scope set gets read for its call pattern even when it is not reviewed. That reading is cheap. Missing it is not.
- The report names every excluded path, because a partial audit that reads as a full one gets used as though it covered everything.
How lines of code are counted
The industry standard is nSLOC, normalised source lines of code: lines containing executable instructions, with comments, documentation and blank lines excluded (Cyfrin glossary). Multi-line statements count once.
The usual tool is Consensys Diligence’s Solidity Code Metrics, which Sherlock also uses to size its scopes:
npm install -g solidity-code-metrics
solidity-code-metrics src/**/*.sol > metrics.md
For a quick language-agnostic count that also covers Rust, cloc works:
cloc src/ --exclude-dir=test,mocks,lib,node_modules
An illustration of why the two numbers diverge. A repository holding 4,200 raw lines of Solidity might resolve like this:
| Lines | |
|---|---|
Raw .sol in the repo | 4,200 |
| Tests, mocks and fixtures | -1,600 |
| Comments, NatSpec and blank lines | -900 |
| Unmodified OpenZeppelin imports | -800 |
| In-scope nSLOC | ~900 |
Same repository, and the number that prices the work is a fifth of the number in the file browser. Send the nSLOC figure with your file list and the quote comes back closer to final.
Are forks and dependencies included?
Dependencies
Unmodified, version-pinned imports from an audited library such as OpenZeppelin are out of scope by default. They come back in for two reasons: you vendored a copy and changed it, or you pinned a version with a known advisory. Say which version you are on.
Forks
The audit is the diff, and the diff is priced as the audit. The modules the diff touches are read as context, and that context is not optional, because the dangerous part of a fork is rarely the code you changed. It is the invariant in the base that your change quietly broke. Adding a fee-on-transfer token to a fork of a router that assumed transfers are exact is the classic version, and no review of the diff alone catches it.
So a straight fork with no modifications is not a fresh audit. A modified fork is priced on the diff plus its blast radius.
What actually drives the price
What happens when the code changes
This is the part the category is quietest about, and it decides whether a report still means anything six months after it was signed.
An audit report is a statement about a commit hash. If the bytecode deployed on chain does not correspond to the commit named in the report, the report does not describe what is running. That check takes two minutes and almost nobody does it.
Code changes. Dependencies get upgraded. Parameters get retuned. Governance passes a proposal. Each makes the report slightly less true, which is why Fidesium treats security as a process rather than an event (the mechanics, in full). Commercially, here is what each change costs.
| What changed | What you need | How it is priced |
|---|---|---|
| Fixes to findings in your own report | Fix verification | Included. 2 rounds, no extra cost |
| An in-scope file edited, no new logic | Delta review of the diff | Quoted on the diff, small |
| Parameters or configuration retuned | Configuration review | Quoted, usually small |
| A dependency or oracle swapped, your code unchanged | Assumption review | Quoted, usually small |
| A new contract added to an audited system | Review of the new contract and its interfaces | New scope |
| Redeploy to another chain | Configuration and chain-difference review | Quoted, smaller than the original |
| Rewrite or structural refactor | Full re-audit | New scope |
Every manual audit includes two rounds of fix verification and one month of continuous scanning after delivery, so the first “we fixed it, is it fixed” cycle is already paid for. After that, scanning runs from $399 a month and re-checks the codebase on every commit and pull request instead of waiting for the next audit window. Monitoring and bug bounties sit on the security services side.
Turnaround, and why founders ask about slots
Audits are launch-blocking. Listings and liquidity plans hang off the report date, so scheduling is a commercial question.
- Quote returned within 24 hours of a request.
- Scoping call within 24 to 48 hours of submitting the repository.
- Report in 1 to 3 weeks from repo to delivery, depending on scope.
Book the slot before the code is frozen. A scoping call runs fine against a branch that is not final, and the commit hash gets fixed at the freeze.
How to get an accurate quote in one message
Send this, and the quote comes back tight rather than wide:
- Repository link, branch and commit hash (or “not frozen yet, targeting DD/MM”).
- The file list you want in scope.
- nSLOC for that file list.
- Chain or chains, and language.
- Every external protocol, oracle or bridge you integrate with.
- Whether anything is a fork, and of what.
- Upgradeability: proxy pattern, admin roles, timelock.
- Your hard date and what it is blocking.
Frequently Asked Questions
How much does a smart contract audit cost in 2026?
Fidesium’s manual audits start at $5,000 for standard contracts, with continuous scanning from $50 a month. Published entry prices are rare across the market and most firms quote on request. What you pay is driven by in-scope nSLOC, logic density, external integrations, chain and language, upgradeability and urgency.
Why do two audit quotes for the same protocol differ so much?
Almost always because they are quoting different scopes. One may be pricing every contract in the repository, the other only the contracts that hold value. Ask both firms for the file list and the nSLOC they priced and the quotes become comparable.
Can I audit only part of my protocol?
Yes. Scope by trust boundary rather than by file count: anything that can move funds, mint, pause, upgrade or set a price belongs in scope, and anything excluded becomes a documented assumption in the report rather than something that was checked.
How are lines of code counted for an audit quote?
By nSLOC, normalised source lines of code, which excludes comments, documentation and blank lines and counts a multi-line statement once. Tests, mocks and unmodified imported libraries are normally excluded too. Run solidity-code-metrics or cloc over the in-scope file list.
Are forks and dependencies included in the audit?
Unmodified, version-pinned dependencies are out of scope by default, and come back in if you vendored or patched them or pinned a version with a known advisory. For a fork, the diff is the audit and is priced as such, with the modules it touches read as context.
Do I need a new audit after I change my code?
Not always a full one. Fixes to your own findings are covered by the two rounds of verification included in the audit. An edit to an in-scope file is a delta review of the diff. A new contract or a refactor is a new scope. What never holds is a report whose commit hash no longer matches the deployed bytecode.
How long does a smart contract audit take?
1 to 3 weeks from repository to report for most scopes, with a scoping call within 24 to 48 hours of submission. Review time scales with in-scope code and complexity.
Is a cheaper audit worth it?
The question is not the price, it is what the price bought. Compare the in-scope file list, the nSLOC reviewed, whether fix verification is included, whether the report is published, and who did the work. Fidesium’s audits are run by its own engineers on in-house tooling, deterministic static and AST (abstract syntax tree) analysis rather than a contractor running a scan, and every report is published and minted on chain. The public audit portfolio is the evidence.
How much does a Solana program audit cost?
The same starting point, from $5,000, but Rust programs are not scoped by line count. Account model, program structure, cross-program invocation surface and integration complexity drive the estimate. Fidesium’s published Solana audits include Adrena, BlockAsset and Banana Zone.
Do you charge extra to verify the fixes?
No. Two rounds of fix verification are included in every manual audit, along with one month of continuous scanning after delivery.