How to Choose a Smart Contract Auditor: A Vetting Checklist

Why the cheapest bid is usually the wrong bid

You post an RFP, get five quotes back ranging from $4,000 to $60,000 for the same 800-line contract, and the instinct is to sort by price. Don't. Audit pricing tracks the amount of senior engineer time a firm is willing to put against your code, and a $4,000 quote almost always means one junior reviewer running Slither for two days and pasting the output into a template. That's not an audit. That's a linter with a PDF wrapper.

The firms worth hiring price based on complexity, not line count: a 400-line staking contract with a custom reward-distribution curve can take longer than a 2,000-line token fork. If a quote doesn't ask you clarifying questions about your protocol's economic assumptions before naming a number, that's already a signal about how they work.

Read their past reports before you read their pitch

Every serious audit firm publishes past reports, either on their own site or through the project that hired them. Pull three or four and check:

• Finding density and severity distribution. A firm that only ever reports "informational" and "gas optimization" findings either audits very clean code or doesn't dig. Real audits of real production contracts turn up medium and high findings more often than not.
• Specificity of the writeup. Good findings name the exact function, the exact line, the exact call sequence that breaks it, and a suggested fix with tradeoffs. Vague findings like "consider adding more input validation" are filler to pad the report.
• Whether they explain why, not just what. A finding that says "reentrancy possible in withdraw()" is table stakes. A finding that traces the actual exploit path, including which function the attacker would call first and what state it corrupts, tells you someone actually modeled the attack.

If a firm can't point you to reports for contracts similar to yours, ask directly what they've audited in your specific niche. A team that's spent two years on EVM lending protocols will miss things in a Solana program that a Solana-focused shop won't, and vice versa. The mechanics differ enough that generalist experience only gets you so far — our own breakdown of what changes when you move from EVM to TON is a good example of how chain-specific the checklist actually gets.

Tooling stack: table stakes, not a differentiator

Every credible firm runs Slither, Mythril, and some flavor of fuzzing (Echidna or Foundry's built-in fuzzer) as a baseline pass. Ask what they use and you should hear at least two static analyzers plus a fuzzer or symbolic execution tool. If the answer is just "we read the code carefully," that's a red flag in the other direction — automated tooling catches the boring stuff (unchecked return values, integer overflow in unusual spots, missing zero-address checks) fast, freeing human reviewers for the parts machines can't reason about.

But tooling is the floor, not the differentiator. Ask what fraction of the engagement is manual review versus automated scanning. For a competent shop, automated tools take a day or two out of a two-to-four week engagement; the rest is a human reading every function, building a mental model of state transitions, and asking "what happens if this gets called in an order the developer didn't expect."

A concrete example of what tooling misses

Take a vault contract implementing something close to ERC-4626:

function deposit(uint256 assets) external returns (uint256 shares) {
    shares = totalSupply() == 0
        ? assets
        : (assets * totalSupply()) / totalAssets();
    _mint(msg.sender, shares);
    asset.transferFrom(msg.sender, address(this), assets);
}

Slither and Mythril will pass this clean. No reentrancy in this path, no overflow in a modern Solidity version, no obvious access control gap. A fuzzer might not trigger it either, because the bug depends on an attacker taking a specific first action, not on random inputs.

The actual problem: the first depositor can mint 1 share for 1 wei of assets, then directly transfer a large amount of the underlying token to the vault contract (not through deposit()). That inflates totalAssets() without minting new shares, so the next legitimate depositor's shares calculation rounds down to zero — they deposit real funds and get nothing back. This is the ERC-4626 inflation attack, and it's a business-logic problem, not a syntax problem. Catching it requires someone to think like an attacker with capital and a plan, not run a scanner. It's exactly the kind of pitfall covered in our writeup on jetton and NFT standard security gaps, where the standard itself creates the opening and no static tool flags a spec-compliant contract as broken.

This is the single best question to ask a candidate auditor: describe a finding from a past engagement that no tool would have caught. If they can't produce one, they're selling you tooling output with a markup.

Remediation support isn't optional

A report with unresolved findings is a liability, not a deliverable. Before signing, confirm in writing:

• A fix-review pass is included, where the auditor re-checks your patches against the original findings — not a fresh audit, but a diff-level verification that the fix doesn't introduce a new bug (a shockingly common outcome).
• Turnaround time on the fix review. Two to five business days is normal. If it's not specified, you'll find yourself blocked on launch waiting on an auditor who's moved to the next client.
• Who signs off publicly. Some firms will only publish the final report after fixes are verified; others will publish the initial report with an addendum. Know which one you're getting, since your community will ask.

If your contracts are still mid-design, it's often cheaper to get a strategy consultation before the code is frozen — catching an architectural issue on a whiteboard costs a conversation; catching it in a completed audit costs a rewrite and a second audit pass. And budget for it properly: our cost breakdown across EVM, Solana, and TON walks through what actually drives the quote up or down before you start collecting bids.

The checklist, condensed

• Three or more past reports for contracts of comparable complexity, with real findings, not just gas-optimization notes
• Named tooling stack (2+ static analyzers, at least one fuzzer or formal verification tool)
• Manual review time disclosed as a fraction of total engagement time
• A specific example of a finding no automated tool would have caught
• Written remediation/fix-review terms with a turnaround commitment
• Chain-specific experience matching your stack, not just generalist EVM background

Run any candidate against this list before the price conversation even starts. If you're ready to scope an engagement, our smart contract audit service walks through exactly this process with a report structure you can review before committing.