What Is a Smart Contract Audit? Cost & Timeline

A smart contract audit is a hostile read of your code, done before someone with real money at stake does it for you. Security researchers try to break the contracts the way an attacker would, then hand you a report: every finding ranked by severity, each with a recommended fix. Once you patch, they check the patches.

The rest of this post covers what that work involves, what it costs, how long it takes, and how to pick the level of review that fits your code.

What an audit is, and what it isn’t#

Reviewers read every line, but they also run the thing. Scanners clear the obvious problems first. Fuzzing throws malformed inputs at your functions for hours, and invariant tests check the rules you can’t afford to see broken: total supply, solvency, who is allowed to call what. For your core logic, formal verification can prove a property holds for every input, not just the ones someone thought to try.

The limits matter as much as the method:

• A clean report isn’t a guarantee. It means the reviewers found nothing in the time they had, in the code they were given.
• It isn’t insurance.

How does a smart contract audit work?#

Most serious firms run something close to the same four steps. Ours:

1. Scope. We read the repo, agree what is in and out, and send a fixed quote. This is where the commit hash gets pinned: that exact snapshot is what gets reviewed.
2. Adversarial review. An AI scan triages the obvious. Then senior researchers do the line-by-line pass, with fuzzing and invariant testing alongside and formal verification on the core logic.
3. Report. Findings are ranked by severity, critical first. A critical doesn’t wait for the PDF: you hear about it the same day, privately.
4. Fix review. You patch, and we re-check every patch before you ship. This step is where audit quality shows, because a wrong fix is just a new bug with a clean bill of health.

The full engagement is described on our smart contract audit page, and the sample report shows what the output looks like.

What do auditors look for?#

The famous bug classes are real, and a competent review checks all of them:

• Reentrancy. A contract sends funds or calls out before updating its own state, so the callee can loop back in and repeat the action. The 2016 DAO hack was this, and the pattern still turns up in code we read.
• Broken access control. Functions that should be owner-only and aren’t, initializers anyone can call, admin keys that can drain the whole system.
• Oracle manipulation. A price taken from a source an attacker can move, usually with a flash loan, for exactly one transaction.
• Arithmetic edge cases. Rounding that favors whoever withdraws first, division by zero on an empty pool, behavior nobody tested at the extremes.

The reentrancy case, in its simplest form:

// vulnerable: the balance is cleared only after the external call
function withdraw() external {
    uint256 amount = balances[msg.sender];
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok);
    balances[msg.sender] = 0;
}

Zero the balance before the call, or add a reentrancy guard, and the loop is closed. On Solana the classics look different: missing signer checks, accounts that were never validated, unchecked arithmetic. The discipline is the same.

That list is the easy half, though. The harder half is flaws in the protocol’s own logic, where the code does exactly what you wrote and what you wrote can be exploited. Rewards that pay out for the wrong behavior. Accounting that drifts after one particular sequence of deposits and withdrawals. An upgrade path that gives a single key too much power. No scanner finds these, because finding them means understanding what the protocol is for. That is why the manual part of an audit exists.

How much does a smart contract audit cost?#

It depends on the code, and nobody can price it honestly without reading it. For orientation only: a simple token or staking contract tends to cost a few thousand dollars, a DeFi protocol with real integrations usually lands in the tens of thousands, and novel mechanisms, cross-chain components or very large codebases cost more than that. What moves the number:

• Size and complexity. Five hundred lines of straightforward Solidity is a different job from fifteen thousand lines of novel math.
• Integrations. Every oracle, bridge or external protocol you touch imports someone else’s assumptions into your system.
• Your deadline. A compressed timeline costs more, everywhere in the industry.

Whoever you hire, insist on a fixed price agreed before the work starts. Hourly billing pays the firm to go slowly. We send a fixed quote within 24 hours of getting your repo, fix review is included, and there is no meter running. If you have a budget in mind, tell us and we’ll say which level of review fits inside it.

How long does an audit take?#

A small, clean codebase can be reviewed in about a week. A serious protocol should plan for three to six weeks of review, then time for your team to patch and for the fix review after that.

Two things stretch a timeline more than code size does. One is slow answers: a review moves fastest when a developer who knows the code can reply within hours, not days. The other is a moving target. If the code keeps changing mid-review, parts of it get audited twice, or the wrong version ships.

So book early, freeze the commit once the review starts, and put your launch date in the first message. We schedule backward from it, and if the review can’t fit, the quote says so instead of rushing the work. The cheapest bug is the one found before deployment.

Getting a quote takes very little: a repo link, the commit you want reviewed, any docs or specs, the chain you’re deploying to, and your target date. A repo alone is enough.

Which level of review do you need?#

Not every project needs the same thing.

• Still on the whiteboard? A protocol design review threat-models the architecture before code exists. A flaw caught at that stage costs a meeting. The same flaw after deployment costs a treasury.
• Early code, tight budget? An AI scan flags the obvious issues while they’re cheap to fix. It is no replacement for a human reading the code, but it’s a sensible first pass, and free scan credits are aimed at exactly this stage.
• Launching soon? A hybrid AI plus manual audit suits most launches.
• High-value or novel code? A pure manual audit, with formal verification on the core logic, is where someone reads every line with hostile intent.
• Already live? It isn’t too late. We review what is deployed, including upgrade paths and admin permissions, and rank findings so you know what to fix first.

Not sure where you fall? That’s a normal question. Our FAQ covers what founders ask most, or tell us where the code stands and the quote will name the level we recommend.

Is one audit enough?#

For a protocol holding serious value, usually not. One audit is one team’s view at one moment, different reviewers catch different things, and nothing written after the report has been read by anyone. A second independent review is common practice at that scale, and a good firm will tell you when it isn’t worth paying for.

Before you ship#

An audit isn’t a badge for your landing page. It decides who finds your worst bug first: a researcher you chose, or an attacker you didn’t. If your code will hold money, have someone hostile read it before launch.

When you’re ready, send us the repo and you’ll have a fixed quote within 24 hours.