How to Vet a Smart Contract Auditor Before You Pay

Anyone can print a PDF and call it an audit

There's no license required to call yourself a smart contract auditor. No bar exam, no continuing education, no regulator checking your work. That's fine when the person behind the report has five years of exploit research behind them — and a real problem when it's someone who read a Solidity tutorial, ran a linter, and started taking client money. Founders who've been burned usually made the same mistake: they picked based on a nice website and a fast turnaround quote, not on evidence the firm can actually find bugs.

Vetting an auditor is mostly about forcing them to show their work before you pay a deposit. Here's what that looks like in practice.

Start with past reports, not the sales call

Any firm worth hiring has public reports you can read in ten minutes. Ask for three to five recent ones — ideally in a protocol category close to yours (AMM, lending, bridge, NFT marketplace, whatever). Then actually read them, not just skim the executive summary.

What separates a real finding from padding:

## [H-3] Reward calculation rounds in favor of the last withdrawer,
allowing pool drainage via repeated small withdrawals

Severity: High
Status: Fixed in commit 4a91f2c

### Description
`_calculateShare()` in RewardVault.sol:142 truncates on division
before multiplying by `totalSupply`, so the last withdrawer in a
block receives the accumulated rounding dust from every prior
withdrawal that block. Over N withdrawals the error compounds to
~0.3% of TVL per 1,000 calls in our fuzz run.

### Proof of Concept
See `test/RewardVaultExploit.t.sol::test_dustDrainage` — reproduces
a 4.1 ETH drain from a 500 ETH pool in 340 transactions using a
single funded EOA.

### Recommendation
Multiply before dividing, or track remainder in a separate
accumulator per EIP-4626 reference implementations.

That's a finding you can trust: exact file and line, a runnable proof of concept, a quantified impact, a concrete fix. Compare it to what low-effort shops ship: "Potential integer overflow issue. Recommend review." No line number, no PoC, no severity justification. If three or four reports from a firm read like the second example, keep walking.

Two of our own writeups on adjacent topics are worth reading before you evaluate anyone else's report style: our breakdown of what a TON smart contract audit checklist should cover across FunC and Tact, and our piece on whether you actually need an audit before mainnet launch and what happens if you skip it.

Ask what's actually in the tooling stack

A serious firm uses layered tooling, not one scanner run through the whole codebase. At minimum, expect:

• Static analysis — Slither or Semgrep rulesets tuned for the target chain, run as a first pass to catch known patterns (reentrancy, unchecked calls, storage collisions in proxies).
• Symbolic execution / fuzzing — Echidna or Foundry's built-in fuzzer for invariant testing, Mythril or Manticore for path exploration on smaller, high-value functions.
• Formal verification for critical paths — not always necessary, but for anything handling more than a few million in TVL, Certora or a hand-written mathematical model of the invariants should at least be discussed, even if not fully applied.
• Manual line-by-line review — this is the part tooling can't replace. Business logic errors, access control gaps, and economic exploits (flash loan manipulation, oracle timing) almost never show up in a scanner report.

If a firm's answer to "what's your tooling stack" is just "we use industry-standard tools," ask them to name three and describe what each one is good at missing. A team that's actually run Echidna against a real invariant suite will talk about corpus seeding and shrinking; a team that hasn't will change the subject.

Certificates are marketing, not proof

"Audited by X" badges and PDF certificates verify almost nothing on their own — anyone can generate one. What actually matters:

1. The report is signed and dated, with a specific commit hash it applies to. If the report doesn't name a commit hash, you have no way to confirm the audited code is the code you're deploying.
2. The firm's identity is checkable. Real people with LinkedIn history, prior CTF placements, or a GitHub trail of actual security research. Anonymous "audit collectives" with no traceable individuals are a coin flip.
3. The scope is explicit. A report that says "audited the entire repository" without listing files, line counts, or exclusions is hiding something — usually that they didn't look at the parts that later break.

Ask the auditor to walk you through how a client of theirs would verify the certificate is genuine and matches the deployed bytecode. If they don't have a clean answer, that's your answer.

Realistic timelines, worked example

Turnaround time is one of the most reliable signals of quality, because thorough review takes time no matter how good the team is. For a mid-sized DeFi protocol — say 2,000–3,500 lines of Solidity across a vault, a staking module, and a governance contract — expect:

• 3–5 days: initial scoping, automated tooling pass, threat modeling
• 5–10 days: manual review, two engineers minimum working independently before cross-checking
• 2–3 days: report drafting, severity classification, internal QA
• 3–5 days: client fix window, then re-review of patched code (this step gets skipped by cheap firms constantly)

That's roughly three to four weeks end to end for one audit round. If a firm quotes 3 days for a protocol that size, they're running one tool pass and calling it done — this is the single biggest predictor of a bad audit relationship. For a fuller sense of what drives cost across chains, see our breakdown of smart contract audit pricing on EVM, Solana, and TON, since timeline and price move together for good reason.

Questions to actually ask before you sign

• How many engineers will independently review the code, and do you cross-check findings before the report goes out?
• Will you re-audit the patched commit at no extra cost, or is that a separate line item?
• Can I see a report where you found a critical bug the client initially disagreed with? How did that get resolved?
• What's your policy if a bug you missed gets exploited post-launch?
• Do you do a manual review pass, or is the report generated primarily from tool output?

A firm confident in its process answers all five without hedging. One built around volume and fast turnaround will get vague on at least two of them.

Price is a signal, not a verdict

Cheap audits aren't automatically bad and expensive ones aren't automatically good, but price that's wildly below the market range for the codebase size is almost always tooling-only work wearing a manual-review label. If you're also weighing a lighter code review against a full audit, our comparison of code review versus full audit scope explains where each one actually fits, and our smart contract development and dApp development teams can tell you honestly whether your contract even needs the full audit tier yet or a targeted review first.

If you want a second opinion on a report you already have, or you're scoping an audit for an upcoming launch, talk to our smart contract audit team before you sign anything.