Do You Need a Solana Program Audit Before Mainnet Launch?

Do You Need a Solana Program Audit Before Mainnet Launch?

A Solana program with mutable upgrade authority, no timelock, and $2M in a liquidity pool is not "launched" — it's a loaded gun sitting on a table with the safety off. The question isn't whether an audit is nice to have. It's whether your specific configuration of authority, capital, and admin power makes an incident a matter of "if" or "when."

I've reviewed programs where a full paid audit was overkill, and I've reviewed programs where skipping one was close to negligent. The difference wasn't team size or how much Rust experience they had. It came down to three variables you can actually measure before you ever open a ticket with an audit firm.

The three variables that actually matter

1. Upgrade authority. If your program's upgrade authority is a single keypair sitting in a .env file or a hot wallet, you have effectively zero on-chain guarantees — anyone with that key can push a new implementation that drains every account the program touches. If authority is set to a Squads multisig with a 3-of-5 threshold and a 24-48 hour timelock, the blast radius of a single compromised key drops close to zero. Run solana program show <PROGRAM_ID> and look at the "Authority" field before you do anything else. If it says "none" (immutable), that's a different risk profile entirely — no rug potential, but also no way to patch a bug you find in month two.

2. TVL at launch, not TVL at 6 months. This is where teams talk themselves out of an audit. "We'll only have $50k at launch, we'll audit before we scale." Fine in theory. In practice, a devnet-tested program that works fine at $50k of real liquidity can behave completely differently once arbitrage bots start hammering it, because your invariant checks were never stress-tested against adversarial transaction ordering. Solana's parallel execution and priority-fee auction create MEV dynamics that don't show up in a local validator test. If day-one TVL exceeds roughly $250k–$500k, or if the program is designed to scale past that within weeks, treat it as if the audit money is already spent — the cost of a bug is asymmetric with capital at risk.

3. Admin-key exposure inside the program logic itself. This is separate from upgrade authority. Does an admin PDA control fee withdrawal, pause functionality, oracle price feeds, or minting? Each admin-gated instruction is a privileged code path, and privileged code paths are exactly what auditors spend the most time on — missing signer checks, missing owner checks, and unchecked PDA derivation cluster around admin instructions more than anywhere else. If you want a sense of how common this specific bug class is, read our breakdown of missing signer and owner check vulnerabilities — it's the single most repeated finding across Solana audits, full stop.

A simple scoring framework

Score each variable 0-2 and add them up:

Upgrade authority:
  0 = immutable or multisig+timelock
  1 = multisig, no timelock
  2 = single keypair

Day-1 TVL:
  0 = under $50k, capped
  1 = $50k–$500k
  2 = over $500k or uncapped growth

Admin-gated instructions:
  0 = none
  1 = 1-2 (pause, fee collection)
  2 = 3+ or controls user funds directly (mint, withdraw, price feed)

Score 0-1: internal review is defensible. Have a second senior engineer who didn't write the code do a structured pass — Anchor constraint audit, signer/owner check sweep, integer overflow check on every arithmetic operation, and a manual trace of every PDA seed derivation. Budget two to four days.

Score 2-3: get a lighter-scope paid review. Not a full audit — a focused review targeting the admin instructions and the money-movement paths specifically. This runs cheaper and faster than a full audit because the auditor isn't reviewing your entire IDL, just the parts that can hurt you.

Score 4-6: full paid audit, no exceptions. At this score you're combining real capital, real admin power, and weak key controls — that combination is exactly what's been drained from Solana programs repeatedly over the past two years, usually through a bug that would have taken an experienced auditor under a day to find.

A worked example

Say you're launching a vault program: users deposit SOL, a keeper bot rebalances into a yield strategy, and an admin PDA can pause deposits and sweep performance fees. Upgrade authority is a 2-of-3 Squads multisig with no timelock (score 1). Expected day-1 TVL is $800k based on a marketing push already scheduled (score 2). Admin controls pause + fee sweep + strategy selection, which indirectly controls where user funds go (score 2). Total: 5. That's a full audit, and honestly it's a full audit with the fee-sweep and strategy-selection instructions flagged for extra scrutiny before you even send the code over — those are the two spots where a missing has_one constraint on the admin account would let anyone drain fees or redirect the vault's strategy.

What a lighter review can't catch that a full audit does

A same-team or internal review will catch obvious stuff: unchecked arithmetic, an unwrapped Option that should be a require!, a PDA seed that doesn't include the right discriminator. What it consistently misses is cross-instruction state manipulation — sequences of otherwise-valid instructions that combine to break an invariant, and economic attacks like flash-loan-style manipulation of an on-chain price oracle used inside your own logic. Those require someone who audits full-time and has seen the pattern before, which is really the whole value proposition of hiring out. If you're trying to figure out who to hire and what questions to actually ask them, we wrote a full guide on how to choose a Solana smart contract auditor that covers turnaround time, report quality, and re-audit policy.

One more thing worth planning before launch, not after: what happens when the audit comes back with findings. Teams that don't have a remediation process end up either shipping with known issues or blowing their launch date scrambling to fix things ad hoc. Our post-audit remediation process for Solana programs walks through how to triage findings by severity and re-verify fixes without re-auditing the whole codebase.

If your program is closer to a trading bot or MEV-sensitive infrastructure than a simple vault, the risk calculus shifts again — those programs interact with mempool dynamics and third-party liquidity in ways that create attack surface a generic checklist won't catch, which is a big part of why we scope sniper bot and arbitrage bot audits differently from standard program audits.

Run the score above honestly before you set a launch date — if it comes back 4 or higher, get a Solana program audit scheduled now, because audit firms book out 2-4 weeks and your launch date should be built around that lead time, not the other way around.