How audit pricing works

Audit pricing is widely assumed to track lines of code. It tracks the effort required to reason about a system, and the consequence of being wrong about it. Those correlate with size only loosely.

A thousand lines implementing a novel incentive mechanism with an oracle dependency and an upgrade path takes longer to review than five thousand lines of conventional token logic. The first requires the reviewer to construct a mental model nobody has built before. The second is pattern recognition against classes already catalogued.

The factors that actually move a number:

Equivalent scope in Rust, Move or a zero-knowledge circuit costs more to review than in Solidity, and the reasons are structural rather than opportunistic.

The reviewer pool is smaller. Solidity has had the largest security community for the longest; the population of auditors who can competently review a Move resource model or an arithmetic circuit is a fraction of it, and scarce expertise prices accordingly.

The tooling is less mature. Solidity has years of accumulated static analysers, fuzzers and invariant-testing frameworks. Equivalent coverage in a newer stack leans harder on manual reasoning, which is slower.

And the bug classes differ. A zero-knowledge circuit fails through under-constrained signals, where a constraint that should bind a variable simply does not and the proof system accepts values nobody intended. That has no Solidity analogue, so experience in one does not transfer cleanly to the other.

In plain terms: if you are quoted the same figure for a Rust protocol as for an equivalent Solidity one, that is worth a question rather than a celebration.

Four arrangements are in common use. The difference that matters to a buyer is which party carries the risk of the work taking longer than expected.

A quote is priced against a scope. Four things commonly change that scope mid-engagement, and all four legitimately change the price.

Code churn. A branch that keeps moving means findings land against lines that no longer exist, and coverage of a changed file is not coverage of the file that shipped.

Added contracts. A module introduced after scoping is new work, not a revision to existing work.

Compressed timelines. Shortening a schedule does not reduce the work; it requires more reviewers in parallel, with the coordination overhead that implies.

Added phases. A contest round, a formal verification component or a compliance review bolted onto a technical audit are separate engagements with separate scopes.

In plain terms: a firm that absorbs scope changes silently is either padding the original quote or cutting the review short. Neither serves you. The useful behaviour is to say the scope has changed and requote.

Budgets break on exclusions more often than on the headline figure. These are routinely outside an audit quote unless explicitly named inside it.

The front-end and the off-chain infrastructure. An audit reads code that runs on chain; the application, the APIs, the cloud account and the deploy pipeline are a separate discipline and usually a separate engagement.

Monitoring after deployment. An audit describes a commit. Oracle drift, a parameter change at an odd hour, a key movement, an upgrade outside the review process — none of those is a code defect, and none is visible to a review that finished last month.

Re-audits triggered by new features. A re-audit round covering your fixes is standard and should be included. A review of functionality written after the engagement is new scope.

Economic and incentive analysis. Many technical audits stop at implementation correctness and do not ask whether the mechanism can be gamed by a participant behaving rationally. If that matters to your design, confirm it is in scope rather than assuming.

These are worth putting to any firm, including this one. The answers tell you more about what you are buying than the figure does.

Who actually performs the review, and what is their experience with this stack? A quote is for people, and the names on the engagement matter more than the name on the letterhead.

What is in scope, what is explicitly out, and will the report state the exclusions? A report that does not record what was not examined is harder to act on.

Is a re-audit round included, and what triggers one? The difference between fixes verified and fixes shipped unverified is the whole point of the exercise.

What will the report let us say publicly? Firms differ on whether you may publish in full, publish excerpts, or use a badge, and that is worth knowing before rather than after.

What happens if a critical finding appears in week one? The answer should be that you hear immediately, not that it waits for the scheduled report.

In plain terms: a firm that answers these crisply is describing a process it already runs. A firm that treats them as unusual is improvising.

No price list, because there is no standard engagement. The factors above determine the figure, and none of them is knowable from a company name and a chain. We quote within 48 hours of seeing the scope, which is a commitment about how fast we reply rather than a booked slot or a delivery deadline.

Each service is scoped and quoted on its own. A protocol audit, a compliance review that traces features to the licences they trigger, and a due diligence engagement commissioned by an investor are different work against different scopes. A blended figure would hide which part you are paying for and make it impossible to drop one without renegotiating the other.

Per engagement rather than per hour. The number in the quote is the number on the invoice, and if a review takes longer than we estimated that is our problem. A change to the scope is a different matter, and we requote rather than letting the figure drift.

The re-audit round is part of the engagement. You submit fixes, each one is verified, we confirm nothing new was introduced, and the final report records what was resolved.

Bank wire in conventional currency, or payment in crypto. You choose.

The second is worth stating because it is often assumed and rarely confirmed. A firm auditing on-chain systems that cannot accept on-chain settlement puts its clients through a conversion their treasury may not want to make, and some teams hold operating funds entirely in crypto.

Currencies, schedule and the milestones a payment attaches to are agreed in writing before work starts and recorded in the engagement letter, which is the document that governs. Nothing on this page replaces it.

At no cost, and its purpose is to establish what is in scope, what sits deliberately outside it, and whether the engagement you are asking for is the one you need.

That last part matters more than it sounds. A team still changing its architecture usually needs a design review rather than a line-by-line audit. A team that already has an audit and no monitoring usually needs the second rather than a second audit. We would rather say so than sell the engagement you walked in asking for.