Smart contract audit: what the scope covered, and nothing beyond it

A scoping document pins a repository, a branch and a commit hash, and lists which contracts, libraries and deployment scripts are in. The out-of-scope list matters as much: frontends, indexers, off-chain keepers, the governance multisig's operating procedure and any protocol the contracts integrate with are normally outside, and their absence is the reason an audited protocol can still lose funds through a component nobody reviewed.

Code stability during the engagement is the practical condition. Sherlock's description of the process puts the right moment for an audit after the design has settled and the contracts are tested, with the team able to hold a stable version for the duration. A scope that shifts mid-review stretches the timeline and leaves parts reviewed against assumptions that no longer hold. Simple contracts run one to two weeks; a complex protocol with external integrations runs three to six, plus the fix verification round afterward.

A competent review runs in two passes over the same code. The first pass establishes what the code is supposed to do: the intended behavior, the developer's assumptions and the invariants that must always hold. The second pass attacks those assumptions. Dedaub describes this split as legitimate-use analysis followed by adversarial analysis, and the order matters, because you cannot subvert an assumption you have not written down.

Four techniques carry the work, and each finds a different class of defect. Static analysis runs pattern algorithms over the code and catches the known shapes: a missing access modifier, an unchecked return value, an arithmetic pattern that drifts. Fuzzing generates large volumes of inputs and drives the contract into states a hand-written test never reaches, and stateful fuzzing across long call sequences finds the bugs that only appear in a particular ordering. Formal verification proves a small number of critical invariants mathematically, which is expensive and therefore reserved for the guarantees whose failure would be total. Manual expert review finds what none of the three can: a business logic error where the code does exactly what it says and what it says is wrong.

The techniques do not substitute for each other, and the gap each leaves is predictable. Static analysis stops at anything requiring an understanding of intent. Fuzzing only finds a violation of a property somebody stated, so an unstated invariant is never tested. Formal verification proves the property you specified about the model you built, and a wrong specification verifies cleanly.

A report that can be relied on names four things. The scope: repository, commit hash and the boundaries, including what was excluded. The method: which techniques ran, which tools, how many reviewers. The findings: each with a severity, an explanation of the impact in terms of what an attacker gets, and a path reproducible enough that a developer can confirm it. And the remediation per finding, specific enough to act on.

Then the fix verification round, which is the part firms skip under deadline pressure. The auditors re-test the patches instead of accepting the claim that they work, and they confirm that the code finally deployed matches the code reviewed. A report without that section documents a set of problems and not a resolution. Where a finding was accepted as a risk instead of fixed, the rationale belongs in the document, because the next reader needs to know that the decision was deliberate.

The usual ladder is critical, high, medium, low and informational, and the label is less informative than it looks. Firms apply the boundaries differently: one classifies by the money at risk, another by the likelihood of the path being reachable, a third by a matrix of both. A finding one firm calls high appears as medium in another firm's report on the same code.

That makes finding counts useless as a comparison between reports. Two audits of the same protocol by different firms produce different totals because they counted differently, not because one found more. The usable signal is the content: what each finding would cost if exploited, whether the path is reachable from an unprivileged caller, and what the team did about it. A report with three findings that each explain the impact concretely tells you more than one with thirty informational notes.

The OWASP Smart Contract Top 10 collects what actually causes losses, and the top entries have not changed much in years. Access control failures come first: a privileged function reachable by a caller who should not reach it, usually a missing modifier or an initialization that can be run twice. Reentrancy follows, where an external call lets the callee re-enter before the first execution finished its state updates.

Price oracle manipulation is third and is where the audit boundary bites hardest, because the contract may be correct and the input wrong. A contract that reads a spot price from a single pool can be attacked by moving that pool, and no amount of review of the contract fixes a design that trusts a manipulable source. Then logic errors in the money flows, where the code compiles and produces the wrong outcome under a specific condition, and unchecked external calls, where a return value nobody inspected means a failure that the contract treats as success.

Rounding is the quiet one. A division that truncates in the protocol's favor is fine; the same truncation in the user's favor, repeated, drains a pool one wei at a time. Finance Loop covers the forensic side at blockchain forensics and the development practice at blockchain software development.

Four reasons, and all four are outside the report. The deployed code differs from the reviewed code, through a late change or a different build. The deployment parameters differ, so a reviewed contract is initialized with a configuration nobody modeled. A dependency arrives afterward: a new oracle, a new token with transfer-fee behavior, a bridge. Or the contract is upgraded, and the new implementation was never reviewed.

The composability case deserves its own mention, because it defeats careful teams. Two protocols, each correctly audited in isolation, can produce an exploitable interaction when one reads a value the other can move in the same transaction. Nobody's scope covered the pair. This is the argument for runtime monitoring and for a bug bounty on live code, which neither replaces an audit nor is replaced by one: an audit looks at a snapshot, a bounty pays attackers to look at what is running.

Three models that answer different questions. A private audit puts a small number of senior reviewers on the code for a fixed period, which produces depth, a named counterparty and a report a regulator or an investor can read. An audit contest opens the code to a large field of researchers in parallel, which produces breadth: a hundred people looking find the shallow issues fast and occasionally the deep one that a small team's blind spot hid. A bug bounty runs continuously against deployed code and pays per valid finding.

What a regulated issuer needs is the private audit, because the deliverable has to name who reviewed what and stand behind it. A protocol with substantial value at risk usually ends up with all three in sequence: the private review before launch, a contest for the breadth, and the standing bounty afterward.

When a smart contract carries a security, the audit stops being a developer's choice. A tokenized security's register has to be legally effective, so the issuer needs to evidence who can move a holding, who can freeze or recover one, and under which authority an upgrade changes that answer. The audit is the document that shows the privileged roles were identified and the upgrade path examined. Finance Loop covers the instrument at tokenized securities.

Supervisors elsewhere have written the requirement down. Dubai's VARA and Hong Kong's SFC both set expectations for the smart contract behind a regulated activity, and the EU Data Act's draft requirements for smart contracts in data-sharing agreements went through a public argument before being narrowed. The direction is the same in each: a contract that performs a regulated function needs a reviewed termination or interruption path, so that something can be stopped. Finance Loop treats the operational resilience side at cybersecurity in finance in Germany.

A smart contract audit is a structured security review of the code that will control user funds and protocol logic on a blockchain, performed against a fixed version of that code and delivered as a report of findings with severities and remediation. It is a review and not a certification: the auditors state what they examined and what they found, and the responsibility for the deployed system stays with the team that deploys it.

One to two weeks for a simple contract, three to six for a complex protocol with external integrations, plus a fix verification round after the team has patched. The factor that stretches a timeline most is not code size but code churn: a scope that keeps moving forces parts of the review to be redone. A team that freezes the branch before the engagement gets the schedule it was quoted.

Everything outside the scope document, which usually means the frontend, the off-chain services, the key management of the privileged accounts, the governance process, and any protocol the contracts integrate with. It also does not cover the future: a later upgrade, a new dependency or a changed parameter is unreviewed code, whatever the earlier report said. And it does not cover economic design, unless the engagement specifically included it, so a mechanism that is exploitable while every line behaves as written passes an audit.

A static analyzer over the source and the bytecode for the known defect shapes, a property-based fuzzer such as Echidna or Medusa where the team states invariants that the fuzzer then tries to break across randomized inputs and long call sequences, a formal verification tool for the handful of invariants worth proving, and a test and simulation framework to reproduce a finding on a fork of the live chain. The tools produce candidates; the reviewers decide which candidates are real, which is why a report consisting of tool output is not an audit.

No general law requires it, and in practice the counterparties do. A listing venue, a custodian, an insurer and an institutional investor each ask for the report before they take the exposure, and a regulated issuer of a tokenized security needs it for its own documentation of the register's integrity. The requirement arrives commercially before it arrives legally.