Buy a Licensed Company 
Explore VASP Data 
Talk to an Expert 
Audited Up to Here: What a Smart Contract Audit Checks
- Smart contract exploits cost $905.4 million across 122 protocols during 2025.
- Cetus lost $223 million and Balancer roughly $128 million, and in both cases the broken code sat outside the scope of the audits covering those protocols.
- Automation is fast and partial, and the best three-tool combination in a 2025 evaluation caught 76.78% of annotated vulnerabilities in about 56 seconds.
- Severity labels are firm-specific, so finding counts do not compare across reports.
- Dubai requires an independent smart contract audit every year and before every new product, while the EU has proposed deleting its own smart contract requirements.
Smart contract exploits took $905.4 million across 122 protocols during 2025, on the incident data behind OWASP’s Smart Contract Top 10 for 2026. Access control failures carried 30 of those incidents and $220 million, and business logic carried another 58 and $188.7 million. Neither category is a Solidity syntax problem, and neither one surfaces in a scanner run.
The year’s two largest losses both ran through code the reviews had set aside. Cetus lost $223 million on 22 May 2025 when a flawed overflow check in a Move math library let an attacker open an enormous liquidity position for a single token. Dedaub’s analysis found that the library code doing the numerical work had been out of scope in the reviews covering the protocol. Balancer lost roughly $128 million on 3 November 2025 to rounding inside a scaling function. OpenZeppelin, which had audited Balancer V2, stated that the vulnerable ComposableStablePool and LinearPool contracts were added after its audits concluded and were never in scope.
An audit report names a repository, a commit hash, a file list, a compiler version, a set of trust assumptions, and a list of components the reviewers did not open. Everything outside that boundary is a residual the protocol keeps carrying. The word audited carries none of that detail. The boundary does the work, and in 2025 it was where the money went.
What the scope section of an audit report fixes
Take a short engagement and read what it pins down. OpenZeppelin’s Fiamma Bridge audit ran from 14 to 16 May 2025 and covered one Solidity file, src/BitVMBridge.sol, at commit 935e2cb. The report then lists what it assumed instead of checked. The bridge server validates inputs correctly and calls mint with accurate recipient values. Operators finalize peg-out transactions. The Bitcoin-side incentivization model works as designed and was audited by a third party. The BtcTxVerifier contract and the btc-light-client library validate Bitcoin transactions reliably.
Four load-bearing assumptions, three days, one file. That is a normal shape for a well-run engagement, and the report is honest about all of it.
On Fiamma the owner sets peg limits, block confirmation minimums, and the address of the verifier contract, and the owner calls mint. An auditor who signs off on the code is signing off on behavior under an honest owner. Key compromise, a hostile governance vote, or a careless multisig signer produces a different system than the one reviewed.
Consensys Diligence puts the limit in writing on every report. The review is “limited to a review of code” and “does not extend to the compiler layer, or any other areas beyond specified code that could present security risks.” The same disclaimer says a report “is not a guarantee as to the absolute security of the project.” The findings list records problems the engagement found and the client fixed, while the exclusions list records the components it left untested.
The domains a smart contract audit covers
A competent reviewer starts from the protocol’s security model and builds the checklist from there. The first question is which properties must hold for users to keep their money, and the second is whether any sequence of permitted actions can break one. The table below is what those two questions expand into on a real engagement.
| Domain | What gets checked | How it fails |
| Access control | Every privileged function, role grant, ownership transfer, timelock and emergency power | Missing modifier, wrong role, permanent lockout |
| Accounting | Conservation of assets, shares against assets, fee accrual, collateral and withdrawal math | Unbacked supply, share inflation, hidden bad debt |
| Business logic | Whether steps can be skipped, reordered or repeated across the state machine | Correct functions composed into an illegal outcome |
| Arithmetic | Overflow, unchecked blocks, decimals, fixed-point math, rounding direction | Insolvency through dust, value created from nothing |
| Oracles | Price source, liquidity depth, staleness, decimals, fallback and TWAP windows | Flash manipulation, stale price, decimal mismatch |
| Reentrancy | External calls, token hooks, callbacks, read-only reentrancy, update ordering | Repeated withdrawal, stale state read mid-callback |
| Token integrations | Fee-on-transfer, rebasing, hooks, non-standard returns, multiple entry points | Accounting divergence against the host protocol |
| Upgradeability | Initializers, implementation locking, storage layout, upgrade authorization | Uninitialized proxy, storage collision, takeover |
| Liveness and gas | Unbounded loops, adversarial array growth, revert griefing, worst-case cost | A safety function priced past the block gas limit |
Platform assumptions sit underneath all of it, and they do not transfer. The Cetus bug turned on a property of Move, where a left shift does not abort on overflow. Solana review covers cross-program invocation, program-derived address validation, account ownership and signer checks, while Cairo review turns on L1 to L2 address conversion, message replay and handler sender verification. Depth in one execution model is evidence about that model. A buyer commissioning work on a Move or Cairo deployment should ask which named reviewers have shipped on that platform.
Invariants and economic security
The reviewer’s first job is writing down what must always hold and then trying to break it. For a lending market the solvency invariant runs something like assets held plus collectible debt being at least redeemable claims. For a vault it runs closer to no permitted sequence of deposits, withdrawals and donations reducing one depositor’s redeemable value without a priced transfer. An invariant phrased that way survives a refactor, while one phrased as “the withdraw function behaves correctly” tests the implementation against itself.
Rounding direction decides most of these in code, since every division picks a winner. Balancer is the worked example. The _upscale function multiplied by a scaling factor using mulDown, and the original code carried a comment saying there was no rounding error unless the scaling factor was overridden. ComposableStablePool overrode it with a live exchange rate. An attacker pushed pool balances down to roughly a hundred thousand tokens, at which point a swap amount of 17 against a factor of 1.058 truncated to zero on the floor division. That deflated what the swap owed the pool, moved the invariant, and repriced the pool token against every holder.
Cetus is the same category with a different mechanism. The checked_shlw guard was meant to reject values above 2^192 before a 64-bit left shift, and it validated against a 256-bit bound. An attacker supplied liquidity near 2^113 against a price difference near 2^79. The product exceeded 192 bits, passed the check, wrapped near zero in the shift, and the function reported that one token was enough to open the position.
Flash loans sit in this category too. OWASP ranks flash-loan-facilitated attacks fourth for 2026, and the loan itself is financing. It strips the capital requirement out of an attack the protocol already permitted. The auditor’s question is what an attacker spends to move a price and what the protocol pays out at the moved price, evaluated with no capital ceiling. Oracle review runs on the same arithmetic, and the depth of the pair a feed reads from is settled in deployment configuration.
Where each analysis technique stops
The Enterprise Ethereum Alliance splits assurance into three levels and the split is worth borrowing. EthTrust Security Levels version 3, approved in March 2025, defines level [S] as requirements testable by automated static analysis. Level [M] covers requirements that need expert human judgment. Level [Q] adds analysis of the business logic, confirming that code “correctly implements what it claims to do.” Work sold as an audit usually lands between [S] and [M], and the methodology section of the report says which.
A 2025 evaluation ran the SmartBugs tool set against 2,182 line-level annotated vulnerability instances. The best three-tool combination, Conkas with Slither and SmartCheck, caught 76.78% in about 56 seconds. The same study tested ChatGPT-4o and watched its performance collapse on real-world contracts to 5.6% precision and 3.3% recall. Cheap, fast and roughly three-quarters complete is a fair description of what automation buys.
Each technique fails in its own direction.
| Technique | Finds | Stops at |
| Static analysis | Known patterns, call graphs, data dependencies, upgrade structure | Intent. It cannot tell a valid rule from a ruinous one |
| Stateful fuzzing | Invariant violations across long transaction sequences | Unwritten properties and states the harness cannot reach |
| Symbolic execution | Concrete transaction sequences that reach a bad path | Path explosion, bounded by transaction depth and timeout |
| Formal verification | Proofs that modeled properties hold on all modeled executions | The specification itself, and every assumption baked into it |
| Manual review | Economics, trust, governance, composition, intent | Reviewer hours, reviewer background, and reviewer attention |
Mythril exposes its own limits in its command line, where -t caps the number of transactions explored and –execution-timeout caps the run. Medusa, described by its maintainers as “parallelized, coverage-guided, mutational” fuzzing built on go-ethereum, mutates coverage-increasing sequences from a corpus to push into new code. Coverage reports which regions the generator reached, and the assertions waiting in those regions still have to encode solvency correctly.
Formal verification carries the sharpest version of the same limitation. A prover establishes that a stated property holds across every execution the model admits. A wrong property yields a valid proof of the wrong claim. A model that omits a fee-on-transfer token or a governance call that rewrites a parameter yields a proof about a protocol that was never deployed. The value concentrates where failure is catastrophic, on properties like mint authority resting only with governance, liabilities never exceeding backing, withdrawals never exceeding entitlements, and upgrades preserving storage.
Manual review is the only technique that asks whether the intended behavior was worth intending, and it is the one priced by the hour. A reviewer reconstructs the state machine, maps every externally callable function and every privileged action, traces where assets move, and looks for sequences of individually legal steps that end somewhere illegal. That work scales with reviewer-days and with how much of the protocol class the reviewer has seen before.
Severity labels across audit firms
Firms use similar words for different things, and the definitions are published. Consensys Diligence calls Critical issues “directly exploitable security vulnerabilities that need to be fixed” and Major issues vulnerabilities that “may require certain conditions in order to be exploited.” Its Medium issues are “objective in nature but are not security vulnerabilities,” and Minor issues are “subjective in nature.” A Medium at Consensys is a code-quality finding by definition, while several other shops apply Medium to an exploitable bug with awkward preconditions.
Spearbit scores on a likelihood and impact matrix, with gas optimizations and informational notes kept outside the severity ladder entirely. Price, timelines and the researcher team breakdown all live in the statement of work. Two engagements both labeled audit can differ by an order of magnitude in reviewer days.
Counting findings is therefore a weak proxy for anything. Fiamma’s report totals 19 issues, split as zero Critical, one High, two Medium, four Low and 12 notes. The single High was the one that would have allowed unbacked minting. A report with 40 findings and no High is a cleaner piece of code than a report with six findings and two Criticals, and neither number says how hard anyone looked.
Impact covers deposited value, minting authority, permanent freezes, cross-chain contagion and downstream integrators. Likelihood turns on permissions needed, capital needed, oracle depth, timing, and whether a mempool watcher can see the setup coming. Preconditions describe the state the protocol has to be in, and blast radius describes who else holds the token when it breaks. A finding rated Medium against $2 million of deposits reads differently at $200 million, and the report was written at the first number.
Integrations, upgrades, and the code added after sign-off
Composition breaks protocols that were individually sound. In February 2022 ChainSecurity found that TUSD’s two contract implementations let an attacker route a sweepToken call through the legacy address and drain TUSD from Compound’s cTUSD contract. OpenZeppelin’s retrospective on the Compound-TUSD issue estimates that full exploitation “would have approximately halved the value of any redemptions made using cTUSD tokens issued prior to the exploit.” The Compound TUSD market held around $88 million at the time. The retrospective also records the part that generalizes, since the vulnerability “was in code that was not part of OpenZeppelin’s originally intended audit scope.” TrustToken patched the root cause on 23 February 2022 and no funds were lost.
Upgrade machinery is the second boundary. OpenZeppelin’s upgrade documentation warns that “an uninitialized implementation contract can be taken over by an attacker, which may impact the proxy.” It also states that developers “cannot change the order in which the contract state variables are declared, nor their type” without corrupting proxy storage. Its plugins validate parent initializer ordering and storage layout, and ERC-7201 namespaced storage exists to keep inheritance changes from colliding. The bytecode a report describes is whatever sat behind the proxy on the day of the review.
Then there is the patch. Fiamma’s High-severity finding was resolved by adding destination verification for Bitcoin transactions, and the fix pulled in a new BLS cryptographic library. OpenZeppelin recorded that “the BLS library was not audited by OpenZeppelin.” Spearbit handles the same problem contractually, with a two-week fix period where researchers work on standby. Its rule is that if “the fixes alter the protocol’s behavior or aren’t related to the issue, a new SOW must be signed.” The remediation commit is frequently the least reviewed code in the repository.
Smart contract audit requirements at VARA, the SFC and in the EU
Three regulators have taken three positions, and the spread is wide. Dubai sits at the strict end. VARA’s Technology and Information Rulebook, effective from 19 June 2025, requires under rule I.E.1 that VASPs engage “a qualified and independent third-party auditor” for vulnerability assessments and penetration testing. The same rule extends that to “comprehensive audits of the effectiveness, enforceability and robustness of all smart contracts,” to the extent relevant to the firm’s activities. The cadence is “at least on an annual basis and prior to the introduction of any new systems, applications and products,” with evidence documented and produced to VARA on request. A licensed firm in the UAE buys an audit every year and again before every product launch.
Hong Kong sets a standard in place of a schedule. The Securities and Futures Commission’s circular on tokenizedinvestment products, reference 26EC22, is dated 20 April 2026. It says product providers should “upon SFC’s request, obtain third party audit or verification on the management and operational soundness” of the arrangement, covering record keeping of ownership and “integrity of the smart contracts.” A footnote sets the underlying obligation higher, asking providers to demonstrate that “the smart contracts are not subject to any contract vulnerabilities or security flaws with a high level of confidence.”
Europe wrote binding requirements and then moved to delete them. Article 36 of the Data Act, applicable from 12 September 2025, obliges smart contract vendors to meet four essential requirements. They cover resistance to functional error and third-party manipulation, safe termination and interruption, data archiving and continuity, and strict access control. Compliance runs through a conformity assessment and an EU declaration of conformity. On 19 November 2025 the Commission’s Digital Omnibus proposal removed “the prescriptive ‘smart contracts essential requirements'” from the Data Act. That proposal is still working through the Council and Parliament, and vendors remain in scope of a regime the Commission has proposed repealing.
Questions that set the price of an engagement
No serious firm publishes a rate card, and the reason is structural. Complexity, integration count and mathematical depth drive cost far harder than line count does. A three-day review of one bridge contract and a six-week review of a lending protocol with formal verification are both called audits.
Five questions separate the two before anything is signed. How many reviewers work the engagement, for how many days, and which of them has shipped on this protocol class. What is excluded, named as files and components. Which properties get written as invariants and fuzzed, and who writes them. Whether fix review is included, and what happens when a fix changes behavior. What the engagement assumes about oracles, privileged keys, off-chain services and dependencies.
Those answers also decide what a second audit buys. Two firms working the same narrow scope under the same assumptions replicate each other’s blind spots and produce two reports with the same hole in them. Two firms with different specialisms, or one firm alongside a competition with a live bounty, cover more ground. ChainSecurity found the Compound and TUSD issue while auditing cToken contracts, with OpenZeppelin engaged on Compound at the same time. Diversity of reviewer is worth more than a second logo.
A protocol should also do the cheap work before paying for the expensive kind. Static analysis, compiler warnings, upgrade validations and invariant fuzzing belong in continuous integration, where a three-tool run costs under a minute. Expert hours spent on findings a linter would have caught are expert hours not spent on the economics. Every material change afterward reopens the question the report answered, since the report described one commit.
Frequently Asked Questions (FAQ)
What does a smart contract audit cover? +
It covers a named commit of named files under stated assumptions. A serious engagement checks access control, accounting invariants, business logic and state transitions, arithmetic and rounding, oracle handling, reentrancy, token integrations, upgrade machinery and worst-case gas. It also documents privileged roles and the external dependencies it assumed were sound. The exclusions list arrives in the same report and names the components the engagement did not open.
Does an audit mean a protocol is safe? +
No. Consensys Diligence states on its reports that a review "is not a guarantee as to the absolute security of the project" and is "limited to a review of code." An audit is evidence about one revision at one point in time. Cetus and Balancer both had audit coverage before losing $223 million and roughly $128 million respectively during 2025.
Why do audited protocols still get exploited? +
Most often the exploited code sat outside the reviewed scope, arrived after sign-off, or ran across two systems that were reviewed separately. Balancer's vulnerable pool contracts were introduced after OpenZeppelin's audits closed. The Compound and TUSD issue lived in an integration between two separately reviewed systems. Remediation commits and upgraded implementations also tend to get less scrutiny than the original code.
Can tools replace a human auditor? +
Not yet. The best three-tool combination in a 2025 evaluation found 76.78% of annotated vulnerabilities, and an LLM tested in the same study fell to 5.6% precision on real-world contracts. Tools handle known patterns. Business logic, economic incentives, governance powers and cross-protocol composition still need someone who understands what the protocol is supposed to do.
How do I compare severity ratings between audit firms? +
Read the rubric printed in each report. Consensys Diligence defines Medium issues as "objective in nature but are not security vulnerabilities," while other firms apply Medium to exploitable bugs with preconditions. Spearbit scores likelihood against impact and keeps gas and informational notes off the ladder. Finding counts across firms are not comparable figures.
Do regulators require smart contract audits? +
Some do. Dubai's VARA rulebook requires an independent third-party audit of smart contracts at least annually and before any new product. Hong Kong's SFC can require third-party audit or verification for tokenized investment products and expects providers to demonstrate the absence of vulnerabilities with high confidence. The EU wrote essential requirements into the Data Act and has since proposed removing them.
What should be fixed before an audit starts? +
Anything a tool finds for free should already be gone. Static analysis, compiler warnings, upgrade validations, unit and fork tests, and invariant fuzzing belong in continuous integration long before an engagement begins. Documented specifications and invariants carry more weight still, since an auditor cannot judge whether behavior is correct without knowing what the protocol intends to do.
What happens to an audit after an upgrade? +
It goes stale. The report describes the reviewed commit, so a new implementation behind a proxy is unreviewed code. Storage layout changes, initializer ordering and upgrade authorization are all live risks at that moment. Spearbit's own process requires a new statement of work when a fix alters protocol behavior, and the same logic applies to every upgrade.
