Audit or bug bounty: which, and when

The distinction that matters is not price or duration. It is coverage: whether the exercise is bounded and systematic, or unbounded and opportunistic.

An audit fixes a scope, names a commit, and works through it. The deliverable is a statement about that scope — including, in a report worth reading, an explicit account of what sat outside it. Coverage is the product.

A bug bounty inverts every one of those properties. Scope is broad, duration is open-ended, and payment attaches to discovery rather than to effort. You are buying attention from a population of researchers, and what that attention lands on is not something you specify in advance.

A bounty programme opened on unaudited code is a procurement error rather than a security one. The defect classes a systematic review covers in its first week are the same classes a researcher will report and invoice for at bounty rates.

Consider what that means concretely. A reentrancy path in a withdrawal function, an ERC-20 transfer whose return value is never checked, an initializer callable by anyone between deployment and configuration — these are checklist items in a competent review. Each is also a legitimate, payable bounty submission.

In plain terms: you are paying a premium price for a commodity finding, and paying it repeatedly, because several researchers will find the same thing before you can fix it.

Our own position on this is on the service page and has not changed: programmes launched without an audit mostly generate expensive reports about things a review would have caught in week one.

An audit is strongest against known defect classes evaluated against a specific implementation: access-control boundaries, reentrancy, arithmetic and precision loss, oracle freshness and manipulation, upgrade and proxy wiring, and the economic assumptions a mechanism rests on. These are found by working through the code deliberately, which is why coverage is the thing being purchased.

A bounty is strongest where a reviewer's assumptions were wrong rather than their coverage incomplete. Novel compositions across protocols nobody modelled together. Behaviour that only appears under real liquidity and real adversarial incentive. Integration failures at a boundary each side considered the other's responsibility.

The honest limitation runs in both directions, and it is the sentence most useful to a buyer: an audit cannot prove that no defect exists, and a bounty cannot demonstrate that anything was covered. A programme with no valid submissions after six months is evidence of nothing in particular. It may mean the code is sound. It may mean nobody competent looked.

A public programme produces volume, and the volume is mostly not findings. Duplicates of a known issue. Submissions outside the declared scope. Raw output from automated scanners, pasted without analysis. Reports that are simply incorrect.

Every one of those still has to be reproduced before it can be dismissed. That is the part teams underestimate: a submission cannot be safely rejected on the strength of the title. The work of determining that a report is invalid is close to the work of determining that it is valid.

In plain terms: each submission consumes senior engineering hours, and those are the same hours assigned to shipping. The programme shows up in the budget as bounty payouts; the larger cost shows up in the roadmap as delay.

There is also a correctness risk in the other direction. A team under submission volume develops a reflex for dismissing reports quickly, and the valid one eventually arrives dressed as the invalid ones.

Both describe code at a point in time. An audit states what was true at a commit; a bounty states what someone found at some moment. Neither addresses the system as it changes after deployment.

The uncovered surface is specific and it is where live losses occur: an oracle whose feed stalls while the market moves, an admin key that executes a parameter change at an unusual hour, a proxy upgrade that lands outside the review process, a role granted during an incident and never revoked.

None of those is a code defect. Every one is a state change in a system that passed its audit, which is why the two instruments above cannot see them. Our own framing of this is short: an audit is a photograph, production is a film.

For a protocol intending to hold meaningful value, the ordering is reasonably settled. Each stage assumes the previous one is complete.

A bounty requires something worth attacking. Before deployment, with no value at risk and no public code, a programme has no population to attract and no incentive to offer. Opening one early buys scanner output.

An audit has a different precondition: the code has to be close to final. A review of a codebase still under active architectural change describes something that will not exist by launch, and the re-audit after the rewrite is a second full engagement rather than a discount.

In plain terms: if the architecture is still moving, the useful spend is a design review rather than a line-by-line audit. The question at that stage is whether the shape is right, not whether the implementation of a shape you are about to change is correct.