All articles
Solana·April 26, 2026·6 min read

How to Vet a Solana Smart Contract Auditor Before You Pay

A vendor-vetting framework for how to choose a Solana auditor: sample reports, Sec3/Trident tooling, hour breakdowns, and re-verification terms.

The Question That Matters More Than Price

Every Solana founder shopping for an audit asks "how much does it cost" before they ask "what am I actually buying." That's backwards. A $15,000 audit that misses a missing signer check is worthless at any price, and a $60,000 audit from a firm that spends three weeks on a 400-line program is probably burning your runway on process, not coverage. The only way to tell the difference before you sign is to vet the vendor like you'd vet a contractor pouring the foundation of a building — check the tools, check the hours, check what happens when they're wrong.

Here's the framework we use when founders ask us to sanity-check a competing quote, plus what we'd want a client to ask us.

Ask for a Sample Report First, Not Last

Every serious firm has a redacted or public sample report. If they won't send one before you sign, that's the first red flag — it usually means their deliverables are thin and they don't want you comparing.

A real audit report has four things a marketing PDF doesn't:

  • Severity-tagged findings (Critical / High / Medium / Low / Informational) mapped to specific functions and line numbers, not vague paragraphs about "access control concerns."
  • Proof-of-concept exploits for anything Critical or High — either a Trident fuzz harness, a TypeScript integration test against a local validator, or both. A finding without a PoC is a hypothesis.
  • A remediation column showing the fix that was actually applied, with a commit hash or diff reference, not just "recommend adding a check."
  • Scope and methodology sections stating exactly which commit hash, which programs, and which out-of-scope items (e.g., "off-chain relayer not reviewed") were covered.

If a sample report reads like a checklist with checkmarks and no code, they're running an automated scanner and calling it a manual review. That's fine as a first pass, not as a $20k+ deliverable.

The Tooling Stack Tells You the Depth

Ask directly: "What tools run against my program before a human reads a line of code?" A firm that can't answer in specifics hasn't built a real process. What you want to hear:

  • Sec3 X-ray (or equivalent static analyzer) for the automated first pass — catches known Anchor anti-patterns, unchecked accounts, integer overflow candidates, and CPI misuse fast. This should take hours, not days, and its output should feed the manual review, not replace it.
  • Trident for coverage-guided fuzzing of instruction handlers, particularly on programs with complex state transitions (AMMs, lending, order books). Fuzzing catches the invariant violations that manual review misses because a human doesn't have the patience to try 50,000 input permutations.
  • Manual review hours, stated as a number. This is the line item that actually matters. A 500-line Anchor program with one PDA-derived vault and a handful of instructions should see 24-40 manual reviewer-hours minimum from a senior engineer. If a quote implies 8 hours of manual time on a program that size, you're paying for a scan with a report template wrapped around it.

Ask how many reviewers touch the code. Two independent reviewers who cross-check findings before the report goes out catch materially more than one person working alone — this is standard practice at firms like Neodyme, OtterSec, and Trail of Bits, and it should be standard at whoever you hire too.

A Worked Example: Pricing a Real Scope

Say you're launching a Solana perp DEX with five programs: core margin engine, oracle adapter, liquidation keeper, fee vault, and governance. Total roughly 3,200 lines of Rust across the workspace, with cross-program invocations between margin and liquidation.

A defensible quote breaks down like this:

Static analysis (Sec3 X-ray + custom linting)     : 4-6 hours
Manual review (2 senior engineers, cross-checked)  : 90-120 hours
Trident fuzzing harness (margin engine + oracle)   : 20-30 hours
Report writing + PoC development                   : 15-20 hours
Fix review round (post-remediation)                : 15-25 hours
-----------------------------------------------------------------
Total                                              : ~145-200 hours

At blended senior rates ($150-$220/hr for firms with real Solana security engineers, not generalist smart contract auditors moonlighting from EVM work), that lands the engagement somewhere between $22,000 and $44,000. If you're quoted $8,000 for that same scope, ask what's being cut — usually it's the fuzzing and the second reviewer. If you're quoted $90,000, ask for the hour breakdown; you may be paying for a brand name, not more coverage.

Before you even get to this stage, though, confirm you actually need the audit scoped this wide — our piece on whether you need a Solana program audit before launch walks through which programs genuinely carry economic risk versus which are low-stakes enough to defer.

Re-Verification Terms: The Clause Everyone Skips

This is the part founders forget to negotiate, and it's the part that determines whether the audit is worth anything six weeks after delivery.

Ask, in writing, before signing:

  1. Is a fix-verification pass included, and for how many rounds? You will find issues that need fixing. The auditor should re-check the actual diff, not just take your word that it's resolved.
  2. What's the window? 30 days is standard. If remediation drags past that window, some firms charge a re-engagement fee — know this before it happens, not after.
  3. Does a scope change trigger a new audit or an addendum? If you add a new instruction or swap the oracle provider after the audit, that code is unaudited by definition. A good firm will quote a delta review instead of a full re-audit, which is faster and cheaper.
  4. Who owns the PoC exploits after delivery? You want these for your own regression test suite. Some firms will hand over the Trident harnesses and integration tests; some treat them as proprietary. Get this in the contract, not implied.

Skipping this clause is how teams end up shipping a patch for a Critical finding, never getting it re-verified, and reintroducing the same bug — we cover exactly this failure mode in our post-audit remediation process breakdown. It's also worth reading up on specific classes of findings that slip through weak reviews, like the missing signer and owner check vulnerability that shows up in nearly every Anchor program that skips explicit has_one constraints.

What to Actually Do With This

Get three quotes. Ask each firm for a sample report, an hour breakdown by category, and their re-verification terms in writing before you compare price. The firm that answers all three specifically, with numbers, is very likely the one that will find your Critical before mainnet does instead of after.

If you're building anything that touches user funds — an AMM, a sniper bot with custodial logic, or an MEV/arbitrage bot holding inventory on-chain — treat the audit line item as insurance, not overhead, and vet the vendor with the same rigor you'd want them applying to your code.

Need a second opinion on a quote you already have, or ready to scope a review against your actual repo? Talk to us about a Solana smart contract audit.

Need a bot like this built?

We design, build and run trading bots on Solana, Hyperliquid and Polymarket.

Start a project
#Solana#Smart Contract Audit#Security#Vendor Vetting#Anchor