Solana audit readiness checklist: 12 items

Before a Solana audit starts, freeze one tagged commit, finish the features in scope, write a short spec with your invariants, make the tests run in one command, agree the scope in writing and keep a developer on call. Teams that arrive prepared get more review time spent on real bugs and usually shorten the audit by days.

Key takeaways

Prepare a frozen commit, a short spec, a list of invariants and tests that run in one command.
Agree scope, exclusions and the fix review in writing before the start date.
Keep a developer available to answer auditor questions within hours.
Reserve engineering time for the fix window after the first report.
Preparation does not replace the audit. It makes the audit time count.

An audit is billed in engineer-days, and every day an auditor spends setting up your project or guessing what a function should do is a day not spent looking for bugs. The twelve items below are what a well-prepared team hands over before the start date.

Code

Freeze a tagged commit. Auditors review one exact commit. Keep new features on a separate branch until the report is final.
Finish the features in scope. Code that is half built or marked as a placeholder gets reviewed twice or not at all. Cut unlaunched features from scope.
Clean the build. The program should compile from a clean checkout with pinned Rust, Solana and Anchor versions, and no failing tests.

Documentation

Write a short spec. For each instruction: what it does, who may call it, which accounts it touches and what it must never allow.
List your invariants. Total supply equals the sum of balances, only the authority can move funds, debt never exceeds collateral. Auditors test what you state and find what you forgot.
Draw the trust model. Which keys exist, who holds them, what the upgrade authority can do, and which off-chain services the program relies on.

Tests

Ship tests that run in one command. Auditors who can run your suite in an hour find real issues on day one instead of fixing the setup.
Cover the failure paths. Wrong signer, wrong owner, wrong account, zero and maximum amounts. Happy-path-only tests tell the auditor little.
Add fuzzing or property tests where money moves. Even a small fuzz target on the core math raises the quality of the review.

Process

Agree scope and exclusions in writing. Programs, commit, what is out of scope (frontend, keepers, oracles, key management) and whether the fix review is included.
Name a developer on call. Answering questions within hours is the cheapest way to shorten the review.
Plan the fix window. Reserve your engineers for the days after the first report, so fixes land quickly and the fix review can start.

Do the spec and invariants first. Writing them often exposes a design problem before anyone is paid to find it, and it is the single most useful document you can give an auditor.

How preparation changes the timeline

Booking and the wait for a slot usually take longer than the review itself, so preparation cannot remove them. What it can do is keep the review from stretching: a frozen commit, clear spec and working tests avoid re-reading and back-and-forth. The full breakdown is in how long a Solana audit takes. For what the audit costs, see the audit cost guide and the cost calculator.

Once you are ready, choose the firm with the auditor checklist, and plan the rest of the launch with the pre-launch security checklist.

Frequently asked questions

How do I prepare for a Solana smart contract audit?

Freeze a tagged commit, finish the features in scope, write a short spec with the invariants that must always hold, make the tests run in one command, agree the scope and exclusions in writing, and keep a developer available to answer questions.

What do auditors need from me before they start?

The repository and exact commit hash, build instructions with pinned versions, a description of each instruction and who may call it, the trust model for keys and upgrade authority, and a working test suite.

Does preparing for an audit make it cheaper or faster?

It rarely removes the booking wait, but it avoids extra review days and back-and-forth, so the audit is less likely to overrun. Less time lost on setup means more time on your logic.

Should I fix known bugs before the audit?

Yes, and tell the auditors about the ones you know of. Paying for a review of issues you already knew about wastes engineer-days that should go to the problems you have not found.

Find a Solana auditor

Describe your program, timeline and budget. Smart Match suggests verified security firms with a reason for each match. Free for teams.

Find an auditor →

Solana audit readiness checklist: 12 things to prepare before the audit starts