A Solana smart contract audit is a manual review of your Rust program, and most of the hours go to three places: how each instruction validates the accounts it is handed, what happens across cross-program invocations, and who holds the upgrade key. Fidesium’s manual audits start from $5,000 and are quoted per codebase after a scoping call.
Think of a cloakroom. You hand over a ticket and get back the coat with the matching number. If nobody checks that the ticket was issued by this cloakroom, anyone with a printer can leave with a coat. That is roughly how a Solana program meets its data: the caller supplies every account the instruction touches, and the program has to check each one.
This guide covers what a Solana audit costs and why, how the scope is set, the bug classes an auditor looks for, the tools you can run before anyone reads your code, and what happens after the audit when the program is still upgradeable.
Key Takeaways
- Fidesium’s manual audits start from $5,000, including two rounds of fix verification, a public report and one month of continuous scanning.
- A Solana quote is driven by public instructions, account types, CPI surface and oracle integrations, not by line count alone.
- Eleven account-model bug classes are catalogued in the Sealevel attacks repository. Anchor constraints cover several of them, but not the ones you forget to declare.
- X-Ray, Radar and Riverguard are free to Solana projects. Trident, LiteSVM, cargo-audit and the Certora Solana Prover cover fuzzing, testing, dependencies and formal verification.
- An audit covers one commit. With an upgrade authority on the program, a verified build is how anyone checks that the deployed code is the audited code.
How much does a Solana smart contract audit cost?
A manual Solana audit from Fidesium starts at $5,000, the same published starting price as every manual audit, and the final figure depends on the codebase. The fee includes line-by-line human review, logic and economic risk analysis, two rounds of fix verification, a public report with a badge and an on-chain NFT record, and one month of continuous scanning.
Most firms do not publish a Solana price at all, which makes quotes hard to compare. One line worth checking in any quote you receive is how re-audit rounds after remediation are billed, because they are often priced separately. Two fix-verification rounds are already inside Fidesium’s fee.
| What moves a Solana quote | Why it adds review time |
|---|---|
| Number of public instructions | Each one is an entry point with its own account list to validate |
| Account and state struct types | Every type needs owner, discriminator and relationship checks |
| Cross-program invocations (CPIs) | Signer and writable privileges pass from caller to callee |
| Oracle integrations | Staleness, confidence and fallback logic are all attack surface |
| Token flows and fee maths | Rounding and accounting errors hide in code that runs correctly |
| Migrations and version changes | Old and new state layouts have to coexist safely |
| Upgrade and admin design | Who can change the program, and how fast |
Picture two teams that each send over about 6,000 lines of Rust. Maya’s team runs an NFT mint with four instructions and one CPI into the token program. Tomás’s team runs a lending market with thirty instructions, two oracle feeds and CPIs into a DEX.
On paper the codebases are the same size. In review, the lending market has several times the entry points, a price path that can be manipulated and a liquidation path that has to hold under every price. The two quotes will not be close, and they should not be.
If you already know your instruction count and your external dependencies, request a scoped quote for a manual audit. Those two numbers get you most of the way to a real figure.
How is a Solana program audit scoped?
A Solana audit is scoped by the program’s attack surface: instructions, account types, CPIs and integrations. Line count is a rough proxy at best. A thousand lines of maths helpers carry less risk than a hundred lines of account validation on an instruction that moves funds.
Our Adrena audit report shows what a large scope looks like in numbers: 33,747 lines of Rust across 168 source files, 125 public instructions and 63 state structs. The assessment ran for five weeks, and a separate review of the remediation followed the next month once the team had made its changes. So the honest answer to “how long” is that the calendar follows the attack surface, and the fix review is a second, shorter piece of work, not an afterthought.
Before a scoping call, have these ready:
- The repository and the exact commit you want reviewed, frozen for the review.
- The list of public instructions, and which of them move funds or change authority.
- The external programs you invoke: token programs, DEXs, oracles, bridges.
- Your framework and version (Anchor or native), plus the IDL if you have one.
- How the upgrade authority is held today: a single key, a multisig or none.
- Existing tests, fuzzing and any previous audit reports.
- What is out of scope, written down. Forks of audited code still need their changes reviewed.
The general sequence from scoping to final report is the same on every chain, and it is covered step by step in how a smart contract audit works. What changes on Solana is what the reviewers spend those weeks reading.
What does a Solana audit check that an EVM audit does not?
The biggest difference is the account model. On EVM, a contract owns its storage and reads it directly. On Solana, a program is stateless: every account it reads or writes arrives as an input from the caller. Solana’s documentation states the runtime rule: only an account’s owner program can modify its data or debit its lamports. Everything else, including “is this the account I expected?”, is the program’s job.
The community-maintained Sealevel attacks repository catalogues eleven classes of bug that follow from this. They are the backbone of any Solana review.
| Bug class | What goes wrong |
|---|---|
| Signer authorization | The program never checks that the authority actually signed |
| Account data matching | A stored field (an owner, a mint) is not compared with the account passed in |
| Owner checks | A look-alike account owned by another program is accepted as genuine |
| Type cosplay | An account of one type is passed where another type with the same layout is expected |
| Initialization | An existing account can be initialised again and its data overwritten |
| Arbitrary CPI | The program calls whatever program ID the caller supplies, such as a fake token program |
| Duplicate mutable accounts | The same account is passed twice, so two “separate” balances are one |
| Bump seed canonicalization | A non-canonical bump is accepted, so more than one address passes as the PDA |
| PDA sharing | One PDA signs for many users or pools because its seeds are too general |
| Closing accounts | A closed account is revived in the same transaction because its data was not cleared |
| Sysvar address checking | A fake sysvar account is accepted in place of the real one |
These are not textbook cases. The Adrena report lists a Medium finding for closed position accounts that could be revived because the discriminator was not zeroed. The closing-accounts row, in a production perpetuals DEX.
Does Anchor handle this for you?
Partly. Anchor’s account constraints turn several checks into one-line declarations: signer, has_one, owner, seeds with bump, and close. Declared correctly, they remove whole rows from the table above. The bugs move to the places the constraints do not reach: an UncheckedAccount, a relationship nobody thought to declare, a remaining-accounts list parsed by hand, or a constraint that checks the wrong field.
CPIs, logic and economics
Solana’s CPI documentation notes that signer and writable privileges extend from the caller to the callee. So every CPI is a question about trust: which program are you calling, and what are you letting it do with your signature? Beyond the account model, the expensive bugs are the same as on any chain. Oracle handling, fee and rounding maths, liquidation paths and governance weight are where logic works exactly as written and still loses money.
The upgrade key
When you deploy a Solana program, your deploying keypair becomes its upgrade authority by default, and that authority can update or close the program. An audit reads who holds it and what else runs under a single signature. The one Critical finding in the Adrena assessment was exactly this: privileged operations that executed immediately under one signature, with single-step authority transfer.
Which tools are used in a Solana audit, and which can you run first?
Tools clear the mechanical ground; people find the logic bugs. Run the free ones before the audit starts, fix what they find, and the paid review time goes on the parts no tool can reason about. In April 2026 the Solana Foundation listed X-Ray, Radar and Riverguard as free to all Solana projects, alongside free 45-minute security consultations from Sec3.
| Tool | What it does | When to use it |
|---|---|---|
| X-Ray (Sec3) | Open-source static analysis for Solana Rust programs | On every pull request, before the audit |
| Radar (AuditWare) | Template-based checks you can write and share | While building; encode your own invariants |
| Riverguard (Neodyme) | Simulates attacks against deployed programs | After deployment to devnet or mainnet |
| Trident (Ackee) | Stateful, manually guided fuzzing of Solana programs | Before the audit, on the instructions that move funds |
| LiteSVM | Fast in-process Solana VM for tests | Unit and property tests, and as a fuzzing base |
| Certora Solana Prover | Formal verification of rules written in CVLR | Core accounting invariants on high-value programs |
| cargo-audit | Checks Cargo.lock against RustSec advisories | In CI, on every dependency change |
| Verified builds | Proves the on-chain program matches a source commit | At every deployment |
| security.txt | Embeds your security contact in the program | Before mainnet, so researchers can reach you |
The same Foundation announcement introduced STRIDE, under which protocols with more than $10M TVL that pass an evaluation get funded monitoring, and those above $100M get funded formal verification. If you are in that band, it is worth knowing before you budget.
Here is the limit of tooling. Picture a team, call it Jonah’s, that runs X-Ray and a Trident campaign on its staking program. Both come back clean. The bug is in the reward maths: rewards round in the withdrawer’s favour, a fraction of a token each time, and a loop of tiny withdrawals drains the pool.
Every account check passes. The code does what it says, and what it says is wrong. A reviewer finds this bug by asking what the protocol is meant to do, then proving the code does it.
At Fidesium the tooling is deterministic static and AST analysis we built ourselves, not AI scanning, and the people who built it do the review. For the Adrena assessment the core team built a coverage-guided fuzzing harness on LiteSVM; the Adrena case study describes how it was put together.
For an outside view of how to get the most from an audit, this guest lecture covers what to do, and what not to do, before and during a Solana review.
<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/vw7fqOdf82I” title=”Solana security audits: what to do and what not to do” frameborder=”0″ allowfullscreen></iframe>
What happens after the audit, when the program is upgradeable?
An audit report describes one commit on one day. On Solana the program on chain can be replaced by whoever holds the upgrade authority, so the report and the deployed code can drift apart without anyone noticing. Verified builds close half of that gap: they let anyone compare the hash of the deployed program with a build from a named commit. Solana’s own documentation is careful here, saying a verified build “should not be considered more secure than an unverified build”. It proves which code is running, not that the code is safe.
Now picture a second team, Ana’s, that ships its audited commit to mainnet in June, with the upgrade authority on a single laptop keypair. In August a partner integration needs a new instruction, so the team adds it, tests it and deploys it on a Friday. Nothing about it was ever reviewed. The audit badge on its site still reads the same, and the program on chain is no longer the one the report describes.
Three things stop that from happening:
- Move the upgrade authority to a multisig, with a timelock on privileged changes, or make the program immutable with
--finalonce it is finished. - Publish a verified build for every deployment, so the audited commit and the running program can be matched by anyone.
- Review every change to an instruction that moves funds or changes authority before it ships, not at the next annual audit.
This is the whole argument of when a smart contract audit actually expires: code changes, so the review has to follow it. Every Fidesium manual audit includes a month of continuous scanning for that reason, and our post-deployment monitoring and security services carry it on after launch.
Frequently asked questions
How much does a Solana smart contract audit cost?
Fidesium’s manual audits start from $5,000 and are quoted per codebase, with two rounds of fix verification included. The quote is driven by instructions, account types, CPIs and oracle integrations more than by line count.
How long does a Solana program audit take?
It follows the attack surface. Fidesium’s Adrena assessment covered 33,747 lines of Rust and 125 public instructions in five weeks, followed by a separate remediation review the next month. A small program with a handful of instructions takes a fraction of that. The scoping call is where the calendar gets set.
Does using Anchor make a Solana audit cheaper?
It can shorten the account-validation part of the review, because constraints like signer, has_one, seeds with bump and close are quick to verify when they are declared. It does not remove logic, maths, oracle or upgrade-authority review, and unchecked accounts still need line-by-line reading.
Can I run Solana security tools instead of an audit?
No, but you should run them before one. X-Ray, Radar and Riverguard are free to Solana projects, and Trident and LiteSVM support fuzzing and fast tests. Tools catch known patterns. They do not know what your protocol is meant to do, which is where the costly bugs are.
Is a verified build the same as an audit?
No. A verified build proves that the program running on chain was built from a specific source commit. An audit is a review of what that commit does. You want both: the audit on a commit, and a verified build showing that the same commit is what is deployed.
Does Fidesium audit Solana programs?
Yes. Our public portfolio includes Solana protocols such as Adrena, a perpetuals DEX audited in 2026, BlockAsset, a real-world asset protocol audited in January 2025, and Banana Zone, audited in December 2025. For a wider list of firms, see the smart contract audit firms worth shortlisting.
Get a Solana audit quote
A Solana audit is priced by attack surface, scoped by instructions and accounts, and only as current as the commit it read. Run the free tools first, freeze a commit, and know who holds your upgrade key before the review starts.
When you are ready, tell us what you are shipping and when. Our manual smart contract audits start from $5,000, are carried out by the core team rather than a contractor, and each one ends in a public report. You can read all our published audit reports before you decide.
