What It Means to Work with a Good Auditor

Most guides on choosing an auditor list qualities you cannot verify: “deep expertise”, “proven track record”, “thorough methodology”. Every auditor claims all three. This one is about the signals you can actually check before you spend anything.

Ask for a report before you ask for a price

The report is the product. Everything else is packaging. Any auditor worth hiring can show you a real one — redacted if necessary, or from a public engagement. Read it and ask:

Do findings come with reproduction steps, or just prose describing a concern?
Is there a concrete fix for each issue, or generic advice like “consider adding proper validation”?
Are severity ratings justified with impact and likelihood, or simply asserted?
Are there findings about protocol logic, or is it all missing zero-address checks and gas optimisations?

That last one is the tell. A report consisting entirely of low-severity hygiene items usually means the reviewer ran tools and tidied up the output. It does not mean your code was clean.

If an auditor cannot show you a single example of their written work, you are being asked to buy a document sight unseen from someone who has apparently never produced one worth showing.

Watch what they ask you

The scoping conversation is the highest-signal moment in the whole relationship, and it happens before you have paid anything.

An auditor who asks only for a repository link and a line count is going to review your syntax. An auditor who asks what the protocol is for, who holds privileged roles, where value accumulates, what you are most worried about, and which external contracts you depend on is going to review your system. The second conversation is less comfortable and much more useful.

Good questions at this stage sound like: what happens if this oracle stops updating? Who can pause this, and what breaks if they do it at the wrong moment? Is this token standard, or does it do something unusual on transfer? If nobody is asking these, nobody is going to be testing them either.

Communication during, not just after

A review that goes silent for ten days and then produces a PDF is worth much less than one where a critical finding reaches you the day it is found. You want severe issues immediately — you may want to start fixing before the report exists, and if a finding changes your design you would rather know on day two than day ten.

You should also be able to argue. Sometimes an auditor flags something as high severity that your architecture already prevents for reasons not visible in the code. A good reviewer engages with that and either downgrades it or explains precisely why your mitigation does not hold. A weak one restates the finding and moves on.

Honesty about limits

This is counterintuitive but reliable: the auditors worth hiring are the ones who tell you what their review does not cover.

A trustworthy engagement is explicit about the boundaries of scope, about areas where specialist expertise would be needed, about the residual risk that remains after every finding is fixed, and about the plain fact that no audit can prove code is free of bugs. Anyone selling certainty in this field is selling something they do not have.

“Certified secure”, “100% coverage”, and guarantees against exploitation are marketing claims, not security claims. Their presence should lower your confidence, not raise it.

Verifying a track record

Concretely checkable, in rough order of usefulness:

Public reports. Named clients, real findings, dated.
Competitive audit results. Platforms such as Code4rena and Sherlock produce a public record of findings judged valid by other security researchers. That is much harder to manufacture than a testimonial.
Responsible disclosures. Evidence of finding real bugs in live systems, not only in engagements they were paid for.
Relevant domain experience. Someone who has reviewed several AMMs will see AMM problems faster. The same holds for gambling logic, lending, or bridges.

Testimonials are the weakest signal on this list, because they are selected by the person being evaluated. Weight them accordingly.

Firm or independent

Firms bring multiple reviewers, a brand your investors may recognise, and process. They also cost considerably more, often queue for weeks, and may assign a junior reviewer while you speak to an account manager.

Independents cost less, start sooner, and the person you spoke to is the person reading your code. The trade-off is real: one reviewer, one perspective, no bench if they are unavailable. For a small-to-medium codebase the independent route often produces a deeper review for less money. For a large protocol holding significant value, multiple reviewers are worth paying for — and plenty of teams sensibly do both.

After the report

Fixing findings is where audits quietly fail. Patches written under deadline pressure introduce new bugs at an alarming rate, and a fix applied to one function while three others share the same flawed assumption has not fixed very much.

So: confirm the auditor will answer questions while you patch, and get the fixes re-reviewed. An engagement that ends at the PDF leaves the riskiest step — changing contract code in a hurry — entirely unverified.