How to Choose a Smart Contract Auditor: A Founder's Checklist

Start with what the auditor actually runs, not what they claim

Ask any audit firm for their methodology and you'll get a slide with four bullet points: manual review, static analysis, testing, formal verification. That tells you nothing. What matters is which specific tools they run against your specific stack, because Solana programs, TON contracts, and EVM code fail in completely different ways and get caught by completely different tooling.

For EVM work, ask whether they run Slither as a baseline pass and then actually triage the output — Slither alone produces so many low-severity and false-positive detectors that a lazy shop will just paste the raw report into your findings doc. A competent one uses it to rule out the boring stuff (reentrancy patterns, unchecked returns, shadowed state variables) fast, then spends the saved hours on business-logic bugs no scanner catches. Ask if they write Foundry invariant tests for your protocol's core properties — "total supply never exceeds cap," "sum of user balances equals contract balance," "collateral ratio never drops below liquidation threshold" — and run them with enough depth (fuzz_runs in the thousands, not the default 256) to actually stress the state space. Echidna is the other serious option here; some firms run both because Echidna's coverage-guided fuzzing finds different corners than Foundry's.

For Solana, the tooling story is thinner and that's exactly why you need to ask pointed questions. There's no Slither-equivalent with the same maturity. A serious Solana auditor will tell you they lean heavily on manual review of account validation — missing is_signer checks, missing owner checks, PDA seed collisions — because these are the bugs that have drained the most Solana protocols historically (Wormhole's $325M loss traced back to a missing signature verification, not some exotic math bug). If a firm quotes you a Solana audit and can't describe how they check for account confusion attacks specifically, that's a red flag, not a nitpick.

For TON, ask directly whether they've audited Tact or FunC before and whether they understand bounced messages, carry-value patterns, and the gas-accounting quirks that don't exist anywhere else. TON's actor-model architecture means a bug that's impossible on Ethereum — a message getting bounced back and re-processing state twice — is a routine finding category. We wrote about the specific failure modes we see repeatedly in our breakdown of TON jetton and NFT audit pitfalls; if an auditor's pitch doesn't mention anything in that territory, they're probably applying EVM habits to a chain that doesn't work like EVM.

Certora and formal verification — when it's worth the premium

Certora Prover and similar formal verification tools prove properties mathematically rather than testing them empirically. This matters most for protocols where a single edge case is catastrophic — lending markets, bridges, anything holding nine figures. It's expensive (specs take real engineering time to write correctly) and it's overkill for a straightforward token launch. Ask a candidate auditor when they'd recommend it versus skip it. If they say "always" or "never," they're selling a product, not giving you an assessment. The honest answer is: formal verification pays for itself when the cost of a missed invariant is measured in eight figures, and it's wasted spend on a vesting contract with 200 lines of code.

What a report should actually contain

A lot of audit reports are padding. Severity-ranked findings with a paragraph of description and a one-line fix suggestion look thorough but tell you almost nothing about whether the auditor understood your protocol's economics. Look for these specifically before you sign:

• Reproduction steps for every finding above low severity. If they claim a reentrancy vector exists, there should be a Foundry test or transaction trace that demonstrates it, not just prose.
• A scope section that lists exact commit hashes and file line counts. Vague scope ("the core contracts") is how firms later claim a bug was "out of scope" after launch.
• Gas and design tradeoffs, not just bugs. A report that only flags severity-tagged vulnerabilities and never comments on architecture choices was probably done by someone running tools, not reading code.
• A public verification artifact — a signed report hash, or a certificate posted somewhere third parties can check, tying the audit to the exact deployed bytecode. Anyone can PDF a report; fewer firms will cryptographically commit to which contract address it covers.

Here's a minimal invariant test structure worth asking a Solidity-side auditor if they'd write for a vault contract, just so you can gauge their answer:

function invariant_totalAssetsCoversShares() public {
    uint256 totalShares = vault.totalSupply();
    uint256 totalAssets = vault.totalAssets();
    assertGe(totalAssets, vault.convertToAssets(totalShares) - 1); // rounding tolerance
}

If the answer is "we don't usually write invariant tests, we just review manually," that's fine for a 300-line contract and a real gap for anything handling deposits and withdrawals.

Remediation verification is where firms cut corners

The audit itself is maybe 60% of the value. The other 40% is confirming your fixes actually close the finding without introducing a new one — a shockingly common failure mode when a team patches a reentrancy bug by adding a lock that itself breaks a legitimate multi-call flow. Ask upfront: is a remediation review included, or is it a separate paid engagement? How many rounds? Does the final certificate reference the exact commit that was re-reviewed, or the original submission? Firms that don't verify fixes are selling you half a service and letting you discover the other half in production.

If you're still deciding whether you need this at all before committing budget, we laid out the actual risk math in when a pre-launch audit is worth it versus optional — short version, if you're holding user funds even briefly, skip nothing.

Red flags worth walking away over

• Fixed-price quotes given before they've seen your codebase or LOC count
• No sample report available, or a sample report that's all boilerplate
• Guarantees of "zero vulnerabilities" or bug-bounty-free assurances — no legitimate firm promises this
• Turnaround under a week for anything beyond a 200-line token contract
• No named lead auditor with a public track record (GitHub, prior published reports, conference talks)

Pricing reality

Expect $8K–$15K for a single-contract token or NFT project, $20K–$45K for a DeFi protocol with multiple interacting contracts, and $60K+ for anything with a bridge, an oracle dependency, or formal verification in scope. The spread is driven almost entirely by LOC, external call surface, and whether upgradeability is involved — proxy patterns roughly double review time because you're auditing storage layout collisions on top of logic.

If you want a second opinion on scope and cost before committing to a vendor, a short strategy consultation upfront usually saves more than it costs. And once you know what you're vetting for, our smart contract audit engagement runs exactly the tooling and remediation-verification process described above across EVM, Solana, and TON.