How Much Does a Solana Audit Cost? (From an Actual Solana Audit Firm)

A Solana smart contract audit typically costs between $7,000 and $150,000+, with most standard DeFi protocol audits landing in the $20K–$100K range. The price is driven almost entirely by how long your code takes to review properly, and how many auditors are assigned — because auditor time is the single biggest cost in this industry.

I'm the founder of Accretion, a 100% Solana-dedicated audit firm. We've audited 50+ protocols protecting over $1.5B in TVL, including Light Protocol (4 engagements), MetaDAO, Ellipsis, Jupiter, and Realms. I scope and price these engagements daily. This post gives you the honest breakdown I wish existed when founders ask me "so... how much is this going to cost?"

Why Solana Audits Cost What They Do

Before I throw numbers at you, you need to understand why audits cost what they do. It's not arbitrary, and it's not because audit firms are gouging you.

Auditor Time Is the Cost

An audit firm is, at its core, paying highly specialized security researchers to read, understand, and break your code. These people are rare. A competent Solana auditor — someone who actually understands the runtime, knows where the footguns are in CPI, can reason about PDA derivation security, and has found real bugs in production protocols — commands serious compensation.

Salaried auditors at reputable firms make $100K–$350K/year depending on seniority, with most in the $180K–$300K range. Senior freelance auditors can charge $5K–$20K per week. This is comparable to what experienced lawyers charge, and it's not a coincidence — the dynamic is similar. You're paying for deep domain expertise applied to your specific problem, where mistakes have direct financial consequences.

A typical engagement puts 2 auditors on your code. The firm's cost for those two auditors alone is often $10K–$30K per week before you factor in the operational overhead of running the business: project management, report writing, infrastructure, insurance, legal, and the margin that keeps the firm alive.

This is why most audit firms charge roughly $15K–$45K per week for an engagement. If you want more auditors (some complex protocols warrant 3–4), the weekly cost goes up proportionally.

Time Scales With Size and Complexity

There's a minimum amount of time it takes to properly understand and review your code. You can't shortcut this. An auditor needs to build a mental model of your entire program — the state transitions, the trust boundaries, every place where external input touches internal logic — before they can meaningfully identify vulnerabilities.

This time is a direct function of three things:

1. Code size — measured in nSLOC (net source lines of code, excluding comments and blanks). More code = more surface area = more time.
2. Code complexity — not all lines are equal. A line that does a simple balance check is not the same as a line that handles a CPI into a program you don't control.
3. Code quality — messy, undocumented, or buggy code takes dramatically longer to audit. If your code has a lot of bugs, the auditor spends more time tracing issues, verifying fixes, and re-analyzing affected logic.

That's the whole pricing model. Everything else is just detail on how these three factors manifest in Solana specifically.

What Actually Drives Your Audit Cost

When I'm scoping an engagement, here's what I'm actually looking at:

nSLOC (net source lines of code): This is the starting point. A 1,000 nSLOC program is a fundamentally different engagement than a 10,000 nSLOC program. We'll estimate how long each section takes to review and sum it up.

Anchor vs. Native vs. Pinocchio: Anchor programs use a framework that handles a lot of boilerplate safety checks (account validation, deserialization, signer checks). Native Solana programs do all of this manually, which means more surface area for bugs and more time to review. Pinocchio (zero-copy, ultra-optimized) programs require auditors who understand low-level memory layout and are significantly more time-intensive to audit.

Logic density: Some programs are heavy on straightforward CRUD operations. Others pack complex financial math, custom AMM curves, or liquidation engines into relatively few lines. High logic density means each line takes longer to analyze.

Number and complexity of instructions: More instructions means more entry points, more state transitions to map, and more potential for cross-instruction vulnerabilities.

CPI (Cross-Program Invocation) surface: Every CPI is a trust boundary. If your program invokes Token Program, that's well-understood. If it invokes three other custom programs with their own state, each CPI needs careful analysis for reentrancy-like issues, privilege escalation, and state consistency.

Token-2022 extensions: If your program interacts with Token-2022 and supports transfer hooks, confidential transfers, or other extensions, that's meaningful additional complexity. These extensions introduce edge cases that many auditors (honestly) aren't deeply familiar with.

ZK components: If your protocol uses zero-knowledge proofs — on-chain verifiers, custom circuits, or integrations with ZK compression — expect this to significantly increase scope. ZK review requires specialized expertise that not every auditor has.

Integration complexity: A program that exists in isolation is simpler to audit than one that's designed to compose with external protocols, oracles, or governance systems. Each integration point adds scope.

What You Get at Each Price Point

Here's what engagements actually look like at different price ranges. These are generalizations — your mileage will vary based on the factors above — but they'll give you a realistic mental model.

One thing I want to be clear about upfront: you get a full audit at every price point. The cheaper engagements aren't a lesser service — there's just less code to review. The methodology, the rigor, the report quality, the severity coverage — it's all the same. You're not paying more for "premium" findings. You're paying more because there's more code and complexity to analyze.

$7K–$20K: Simple Program, Full Audit

At this level, you're typically looking at a small, well-scoped program: maybe a single-purpose staking contract, a basic escrow, or a simple SPL token with custom mint logic. Think 500–2,000 nSLOC in Anchor.

You'll get 2 auditors for up to a week, often less. We always use a minimum of 2 auditors — we don't recommend single-auditor engagements. The report covers everything: critical, high, medium, and low severity findings with full detail.

Don't assume this tier is only for low-stakes programs. If your program handles significant TVL but is genuinely simple and well-written, it belongs here. Simplicity is a feature, not a limitation.

$20K–$60K: Standard DeFi Protocol Audit

This is where most serious DeFi audits land. You're looking at a lending protocol, a DEX, a vault strategy, or a moderately complex governance system. Typically 2,000–6,000 nSLOC.

You'll get 2 auditors for 1–3 weeks. Full analysis of access control, economic logic, state transitions, CPI safety, arithmetic issues, and protocol-specific attack vectors. Detailed report with severity classifications, proof-of-concept descriptions, and remediation guidance.

$60K–$100K: Complex Protocol or Large Codebase

At this range, you're dealing with protocols that have multiple interacting programs, complex financial logic, significant CPI surfaces, or a codebase that's simply large. Think full-featured DEXs with multiple pool types, complex lending protocols with liquidation engines, or protocols with native + Anchor hybrid architectures.

2 auditors for 2–5 weeks. The review goes deep into economic attack vectors, cross-program state consistency, and edge cases in the interaction model.

$100K–$150K+: Critical Infrastructure or Highly Complex Systems

This tier covers protocols with ZK components, custom virtual machines, novel cryptographic primitives, multi-program architectures with deep composability, or anything that's genuinely pushing the boundaries of what's been built on Solana before. Or simply very large codebases with high complexity throughout.

3+ auditors, 4+ weeks. Often involves auditors with specialized expertise (ZK, cryptography, low-level Solana runtime). At this level you may also be looking at multiple audit phases or re-audits of significantly changed code.

Rush Timelines

Auditors are often booked out weeks or months in advance. If you need an audit ASAP, it's still possible — but it costs more, typically a 20–100% premium depending on how aggressive the timeline is. For the firm, rush engagements mean engaging additional expensive external auditors, rearranging other scheduled engagements (if those clients allow it), and often working weekends. That all costs money.

The best way to avoid this: plan ahead and contact audit firms early, even before your code is fully complete. Getting on the schedule is half the battle. If your launch date is flexible, don't pay the rush premium.

How to Reduce Your Audit Cost

This is the most actionable section of this post. Every one of these directly reduces the time auditors spend on your code, which directly reduces your bill.

Reduce your code size. Remove unused code, dead branches, commented-out experiments, and anything that isn't part of the final program. Every line in scope is a line an auditor has to read and reason about. Fewer lines = less time = lower cost.

Reduce code duplication. If five of your instructions start with the same long sequence of validation checks, extract that into a shared function. Without that refactor, the auditor has to carefully review what looks like the same logic five separate times — because they can't assume it's identical. They have to verify. One function reviewed once is dramatically faster than five near-copies reviewed five times.

Reduce code complexity. Simpler code is faster to audit. If you can restructure a convoluted state machine into something more straightforward, or break a 500-line function into smaller composable pieces, do it. You'll benefit from fewer bugs and a lower audit bill.

Write good documentation. A clear technical spec that explains the intended behavior of each instruction, the trust model, and the expected invariants saves auditors from reverse-engineering your intentions from the code. Hours saved on understanding = hours saved on your invoice.

Have meaningful test coverage. Tests signal code maturity and give auditors confidence about intended behavior. They also surface your own assumptions, which helps auditors identify where those assumptions might be wrong.

Provide a known issues list. If you already know about certain limitations, trade-offs, or non-critical issues, tell us upfront. Nothing wastes audit time like spending hours investigating something the team is already aware of and has intentionally accepted.

Write clean code. Convoluted control flow, inconsistent naming, and spaghetti architecture all increase review time. Refactor before the audit, not during it. For concrete guidance, see our 100 Solana tips.

Don't change code during the audit. Every change means auditors need to re-analyze affected code paths. This is the single most common cause of scope creep and unexpected cost increases. Freeze the codebase before the engagement starts.

Scope tightly. If only 3 of your 7 programs are ready for audit, scope those 3. You can audit the rest later. A well-defined scope keeps the engagement focused and predictable.

Get multiple quotes. It's straightforward for an experienced auditor to review your repository and give you a specific number. Share your code with a few firms and compare. More on this at the end.

Why the Cheapest Audit Is Usually the Most Expensive

I need to be direct about this: we find critical or high-severity vulnerabilities in roughly 80% of the audits we do. Not medium-severity theoretical issues — actual exploitable bugs that could have drained funds. That includes protocols that had already been audited by another firm.

A cheap audit that misses a critical vulnerability isn't saving you money. It's giving you a false sense of security while leaving a ticking time bomb in your code. If that bomb goes off post-launch, you're looking at lost funds, lost users, reputational damage, and potentially the end of your project. The cost of that outcome dwarfs any difference in audit pricing.

The uncomfortable truth is that audit quality varies enormously across firms. Some firms assign auditors who've never touched Solana to your Solana audit. Some spread their auditors across too many concurrent engagements. Some rely on junior auditors to do the heavy lifting and slap a senior partner's name on the report.

A few things to watch out for:

Large firms with big names and VC backing often overcharge relative to the actual quality of the audit. You're paying for the brand, not necessarily for better security outcomes. What matters is not the company name on the report — it's who actually sits down and reviews your code. Ask which specific auditors will be assigned. Look at their track record. Have they found real bugs in Solana programs? Do they understand the Solana runtime, or are they Solidity auditors who learned Rust last month?

Stick with firms where you can verify that the individual auditors doing the work are experienced in Solana specifically. A great EVM auditor is not automatically a great Solana auditor. The security models, common vulnerability patterns, and runtime behavior are fundamentally different.

What's NOT Included in Most Audit Quotes

Standard audit quotes across the industry typically do not include:

• Re-audit of significant code changes — if you rewrite major portions after the initial audit, that's a new scope.
• Ongoing security monitoring — the audit is a point-in-time review, not continuous coverage.
• Formal verification — this is a separate, specialized engagement.
• Frontend/off-chain code review — unless explicitly scoped.
• Incident response — if you get exploited post-launch, most firms aren't on call.

What Accretion Includes

We've structured our engagements differently because we've seen the gaps that cause problems for teams after the audit is "done":

• All fix reviews included at no extra cost. You fix the issues we find, we verify the fixes. This isn't an upsell.
• No surprise charges for minor code changes. If your code doesn't significantly change in scope, we don't nickel-and-dime you for small adjustments during the fix phase. Other firms are notorious for this.
• 6 months of post-audit support. Questions come up after launch. New integrations raise security questions. You can reach us.
• 24/7 emergency response. If something goes wrong, you have a direct line to people who already understand your codebase.

FAQ

How long does a Solana audit take?

Most audits take 1–6 weeks depending on codebase size and complexity. A simple Anchor program might be 1 week. A complex multi-program DeFi protocol could be 4–6+ weeks. Rush timelines are possible at additional cost.

Is a Solana audit worth it?

If your program handles user funds or any form of value, yes. The cost of an exploit — financially, reputationally, and legally — almost always exceeds the cost of a thorough audit. The more relevant question is whether you're getting a good audit, not whether you need one. For protocols with admin functions, read our guide on designing better authority structures as a complement to auditing. You should also understand what verified builds actually prove (and don't prove) — see our analysis of how we hacked Solana verified builds.

Can I audit my Solana program myself?

Internal reviews are valuable and should be part of your security process, but they don't replace an external audit. The people who wrote the code carry assumptions about how it works that make it difficult to spot certain classes of bugs. External auditors bring fresh eyes and adversarial thinking.

Do I need an audit before mainnet launch?

Strongly recommended if your program handles any value. Some founders launch on mainnet with limited TVL caps as a form of progressive security, which can be reasonable — but you're accepting residual risk. An audit before significant TVL is the standard practice.

How do I choose between audit firms?

Ask who specifically will audit your code. Look at their individual track records on Solana. Ask for references from past clients. Get multiple quotes — pricing and timeline differences can be significant. Don't choose purely on brand name.

Should I get multiple audits from different firms?

For protocols handling significant TVL, yes — multiple independent reviews catch more bugs. No single auditor or firm catches everything. Two audits from different firms will almost always surface issues that either one alone would miss.

When should I start thinking about an audit?

Ideally, when your code is feature-complete but before mainnet launch. Starting the conversation with audit firms early (even a few weeks before you're code-complete) helps with scheduling — good firms book up, and last-minute requests mean rush pricing.

Getting a Quote Is Easy

One thing I want founders to know: getting a specific quote for your project is usually fast and painless — at least with us. We don't need weeks of back-and-forth. Share your repository, and an auditor reviews the codebase for size, complexity, and maturity. We'll give you a concrete number, not a vague range.

My honest advice: reach out to a few reputable Solana-focused audit firms, share your code, and compare quotes. You'll get a much better sense of what your specific project will cost than any blog post can give you.

If you want to start with us, reach out via DM to me on TG, share your repository, and we'll get back to you with a quote quickly.