A Solana audit takes about 1-2 weeks of review for a simple or standard program of up to 1,500 lines, 3-5 weeks for a 3,000-line DeFi protocol, and 6-12 weeks for a large multi-program protocol in native Rust. Including booking, the wait for a slot, fixes and the fix review, plan 6-12 weeks from first call to final report.
| Project | Code in scope | Engineer-days | Review time |
|---|---|---|---|
| Simple (token vesting) | 500 lines | 3.5 | 1-2 weeks |
| Standard (staking) | 1,500 lines | 7.5 | 1-2 weeks |
| DeFi (lending, 2 programs, oracle) | 3,000 lines | 23 | 3-5 weeks |
| Large DeFi (perps DEX, native Rust, 3 programs) | 6,000 lines | 56.5 | 6-12 weeks |
From our audit cost calculator method: Anchor unless noted, fix review included, no rush. Short end: two engineers in parallel; long end: one engineer. Booking and waiting for a start date come on top.
- The review itself usually takes one to four weeks; the whole process, from first call to final report, more often takes six to twelve.
- The longest wait is often the queue: established Solana auditors are commonly booked several weeks ahead.
- Code size and complexity set the review length; two engineers in parallel roughly halve the calendar time.
- Plan the fix review into the schedule. A report without re-checked fixes is not the end of the audit.
- Contact auditors as soon as the scope is stable, not when the code is finished.
"We launch in three weeks, can you audit us?" is one of the most common messages Solana auditors receive, and the honest answer is usually no. Not because the review takes three weeks, but because everything around it does: finding the right firm, waiting for a slot, fixing what they find and having the fixes checked.
The short answer
For a single Anchor program of a few thousand lines, the review itself typically takes one to three weeks with two engineers. Large DeFi protocols with several programs, custom math and integrations can take a month or more. Counting booking, waiting and the fix review, most teams should plan six to twelve weeks from the first call to a published report.
Where the time goes
| Phase | Typical time | What happens |
|---|---|---|
| Finding and booking an auditor | 1 to 2 weeks | Shortlist, scoping calls, quotes, contract |
| Waiting for the start date | 2 to 8 weeks | Good firms are booked ahead, more so before big launches |
| The review itself | 1 to 4+ weeks | Depends on code size, complexity and team size |
| Fixing findings | 3 days to 2 weeks | Your team, in parallel with report drafting |
| Fix review and final report | 3 to 10 days | Auditors re-check every fix and publish the report |
These ranges are typical, not guaranteed. A small program with a firm that has a gap in its calendar can go from first call to report in two weeks; a novel protocol in a busy season can wait two months just to start.
What makes the review longer
- Code size in scope: the main driver. Auditors estimate engineer-days from lines of program code, excluding tests.
- Complexity: custom pricing curves, liquidations, CPIs into other protocols and upgrade logic take far longer per line than simple state updates.
- Native Rust instead of Anchor: more hand-written account validation to check, so more time per feature.
- A moving target: code that changes during the audit forces auditors to re-read parts of it, and leaves gaps.
- Missing context: no specification, no tests and no one available to answer questions all slow the first week down.
How to get audited sooner
- Book early: contact auditors when the design and scope are stable, typically four to eight weeks before you need the report. You can move the start date; you cannot create a free slot.
- Freeze a commit: audit a tagged commit and keep new features on a separate branch.
- Send a short spec: what each instruction does, who may call it, and the invariants that must always hold.
- Ship tests and a local setup: auditors who can run your tests in an hour start finding real issues on day one.
- Cut scope: leave unlaunched features out and audit them when they ship.
- Keep a developer on call: answering auditor questions within hours, not days, is the cheapest way to shorten the review.
Do not forget the fix review
The first report is a list of findings, not a clean bill of health. Your team fixes them, and the auditors check every fix before the final report. Budget three to ten days for this, include it in the quote, and do not schedule the launch for the day the first report lands. Our audit readiness checklist covers what to prepare, and our guide to reading an audit report explains what to check before you call it done.
A realistic plan for a mainnet launch
Work backwards from the launch date: at least a week of buffer before launch, the fix review before that, your fixes before that, the review itself, and the start date the auditor gave you. If that puts the first call in the past, either move the launch or cut the scope. For the rest of the launch, go through the Solana pre-launch security checklist, and to compare firms, see how to choose a Solana auditor.
Frequently asked questions
How long does a Solana smart contract audit take?
The review of a single Anchor program of a few thousand lines typically takes one to three weeks with two engineers; large DeFi protocols can take a month or more. Including booking, waiting for a slot and the fix review, plan six to twelve weeks from first call to final report.
How far in advance should I book a Solana auditor?
Contact auditors four to eight weeks before you need the report, as soon as the scope is stable. Established Solana security firms are often booked several weeks ahead.
Can a Solana audit be done in a week?
For a small, simple program with a clear spec and tests, sometimes. For complex protocols, a one-week review usually means less engineer time on your code; ask how many engineers, for how many days, and what is out of scope.
How long does the fix review take?
Usually three to ten days after your team has fixed the findings. Include it in the quote and the schedule; the first report is not the end of the audit.
How many days does a Solana audit take?
Measured in engineer-days, from about 3.5 for a 500-line simple Anchor program to about 23 for a 3,000-line lending protocol with an oracle, by our calculator method with the fix review included. Two engineers working in parallel roughly halve the calendar time, so a small audit can finish in 1-2 weeks.
Why does it take so long to start a Solana audit?
Because established Solana auditors are booked ahead. The wait for a start date is typically 2 to 8 weeks, longer before big launches, and it is often longer than the review itself. Contact auditors when the scope is stable, typically 4 to 8 weeks before you need the report.
Estimate your audit timeline
Enter lines of code, complexity and framework to get an indicative cost and calendar time, then get a hand-picked shortlist of Solana auditors. Free for teams.
Open the calculator →Related reading
- Solana audit readiness checklist: 12 things to prepare before the audit startsWhat to prepare before a Solana audit: a frozen commit, a short spec, invariants, tests that run in one command, agreed scope and a developer on call.
- Breakpoint 2026: what Solana teams should sort out before launchLaunching around Solana Breakpoint 2026 (15-17 November, Olympia London)? A checklist for security, authorities, token launch, legal and growth, and what to book before the event.
- How to compare Solana audit firms: a neutral frameworkCompare Solana smart contract audit firms on evidence you can check yourself: public Solana reports, Anchor or native Rust experience, engineer-days, fix review and timing.