Smart contract security review

What this actually solves

You are about to put contracts on mainnet that will hold money, and everything you know about them comes from the people who wrote them. That is not a comment on your team. It is a structural problem — the person who built a system tests the paths they had in mind, and the attack that costs you money will come down a path nobody had in mind. Once it is deployed, there is no rollback, no chargeback, and no support line. The money leaves and the incident keeps your project's name attached to it permanently, in search results, for years.

There is a second reason people buy this, and it is worth naming because it changes what a good report looks like. A review is also a document you hand to other people. It goes to your investors, to an exchange's listing team, onto your own site. That makes the honesty of the report part of its value. A report that says everything is fine is worth nothing to a sophisticated reader, because they know what such a report costs to obtain. A report that states its scope precisely, ranks what it found, and is explicit about what it did not examine is the one that survives being read by somebody's technical adviser.

How the review runs

1. Scope, freeze and read the intent. We agree exactly which files, which commit hash and which deployment parameters are in scope, then read the specification, whitepaper and documentation before the code. Serious findings are often not bugs in the usual sense at all — they are places where the code does something the specification does not describe, and you can only see that if you read the intent first. Two to four days.
2. Manual review, line by line. The slow part, and the part that finds the expensive things. Access control on every state-changing function. Arithmetic and rounding direction. Ordering of effects against external calls. Assumptions about the tokens your contracts will interact with. What happens at the boundaries — zero, one, maximum supply, an empty pool, a paused dependency. One to three weeks depending on size and novelty.
3. Tooling and adversarial testing. Slither and Semgrep rules for the known patterns, then Foundry invariant testing and Echidna to attack the properties that must never break, and Tenderly to simulate specific transactions against forked state. Tools do not replace the reading — they cover the ground that reading does badly, which is the long tail of random inputs. Three to six days.
4. Write the attacks, not just the observations. Every candidate finding is pushed toward a concrete question with a yes or no answer. Can I move an external price with a flash loan and profit inside a single transaction. Can I withdraw against another user's balance. Can the admin, acting alone, take everything and leave. A finding that cannot be turned into a sequence of calls gets ranked lower and labelled as such, rather than padding the report. Three to five days.
5. Report, then re-review the fixes. Findings arrive ranked Critical, High, Medium, Low and Informational, each with the damage it causes and a concrete remediation. Critical means money can be taken now. Informational is housekeeping. After your team fixes, we look again at the diff and mark each item Fixed or Acknowledged, and the final report records which is which. Report 2 to 3 days, re-review 2 to 5 days.

Two things are deliberately absent from the process. We do not use an AI assistant to produce findings — it is genuinely useful for cleaning up code before a review, but it does not reason about the relationship between two contracts, it does not invent the economic attacks that dominate real incidents, and, most disqualifying of all, it cannot tell you what it failed to look at. And we do not describe our own security work on a contract we built as an independent review, because it is not one.

What moves the price

Size and novelty of the code. Lines matter, but a fork of a widely deployed protocol with limited changes is a fundamentally different job from a new design, because on the fork the reviewer's attention goes straight to the diff and the assumptions the original made that your changes break.

How many external protocols you touch. Every oracle, router, lending market or bridge you integrate adds an interface whose behaviour under stress has to be reasoned about — what your contract does when that dependency pauses, returns a stale price, or is manipulated for a single block.

Whether the economics are part of the scope. Reviewing that a contract does what its specification says is one job. Reviewing whether the specification itself can be gamed — incentive design, liquidation thresholds, fee routing — is a larger one. The range is $3,000–$40,000 over 2–6 weeks, and this distinction moves a project across most of it.

What usually goes wrong

A clean static analysis run is presented as an audit. This misunderstanding is common and it is expensive. A static analyser matches known patterns. It does not know that your reward accountant is supposed to conserve a funded pool, so it will never tell you that it does not. Reporting a clean tool run as evidence of security is only ever a statement that nothing from a published list of generic weaknesses was matched.

Findings get quietly downgraded during the fix window. A High becomes Acknowledged because the fix is awkward and the launch date is fixed, and the report goes onto the website anyway with that column not especially prominent. Whoever is doing real diligence on you reads that column first. If you are going to accept a risk, accept it explicitly and say why in the report — that reads far better than an unexplained Acknowledged.

The deployed code is not the reviewed code. The commit drifts. A fix is applied, then a small unrelated improvement goes in on top, then a parameter is tweaked at deployment time. Now the report describes something that no longer exists, and the difference is exactly where nobody has looked. The controls are a frozen commit hash printed in the report, a re-review of the fix diff, and reading every deployed parameter back off the chain and comparing it against what the review assumed.