Private audit or audit contest — which should you choose?

Contests are good at breadth and at finding what many eyes can find quickly. Private audits are better at deep protocol-specific logic, at systems that cannot be made public, and at continuity. Serious protocols increasingly use both, in that order: private audit first, contest after.

What a contest is structurally good at

A contest buys you many independent readers, which is genuinely valuable. Bugs that are findable within a few hours of reading tend to get found, and you pay largely for results rather than for time.

Contests also surface unusual perspectives. A researcher with an odd specialism may spot something a generalist team would not, and there is no roster constraint on who participates.

What a contest structurally misses

Incentives concentrate effort where the expected payoff is highest, which is the first few days and the most legible parts of the codebase. Deep protocol-specific economic logic — the kind that requires holding the whole system in your head for a week — is exactly the work the payoff structure discourages.

You also cannot run a contest on code you cannot publish, you get little continuity between reviews, and triage burden lands on your team. Duplicate submissions and severity disputes are your problem to resolve.

What a private audit is structurally good at

A private engagement buys sustained attention from a known team who can be held accountable for coverage. The auditors can be told about the parts that worry you, can read your specification, and can talk to your engineers.

It also handles the cases contests cannot: unreleased code, custody and backend systems, and anything under NDA. And it gives you continuity — the same team reviewing each new integration understands what they approved last time.

What a private audit structurally misses

You are buying a fixed number of people for a fixed period, so you get that team's blind spots. This is the honest weakness of the model, and it is worth asking any firm how they mitigate it.

Our answer is to make the engagement internally competitive: auditors work blind and commit hashes of their findings before comparing notes, so the team does not converge on the same three bugs, and a per-bug prize pool keeps effort up through the final day. It is a contest structure applied inside a private engagement, which recovers some of the independence a public contest gets for free.

A reasonable default

For most protocols with real value at stake: private audit first, so the deep logic gets sustained attention and the obvious issues are gone; then a contest on the hardened code, where many eyes are being spent on a codebase that is already clean.

Running a contest first tends to burn budget on findings a private review would have caught in a day.

LAST UPDATED

CHECK OUR ANSWERS AGAINST THE RECORD

Everything above is easier to trust if you can verify it. The full engagement record, with per-engagement severity counts and links to published reports, is public.

THE FULL RECORDOUR METHODOLOGYRAW DATASET

Ask us directly

We would rather answer the hard questions before the engagement than during it.

REQUEST FORM