Balancer keeps a list of its audits on GitHub, and above the table sits a warning: “Audits are not a guarantee of correctness. Some of the contracts were modified after they were audited.” (Balancer audit page). On 3 November 2025 its V2 stable pools were drained anyway, for more than $120 million by OpenZeppelin’s count, which includes forks of the code. The reports were public the whole time, and read properly they said what they had not looked at.
Ten minutes with a blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract audit report is enough to find that information yourself, once you know where to look: the commit, the scope, the findings, their status, and the distance between the audited code and what runs today. The worked example is a pair of real reports on the same Aave V3 code, followed by a trace of the live Aave contract back to its audits and by cases where an audit did not prevent a loss.
A smart contract cannot be patched as easily as a website, and it holds money from its first minute. That is why protocols pay for outside reviews. The previous lesson, on MEV and how to protect a trade, showed how a contract working as designed can still cost a user. An audit looks at a different problem: code that does not do what its authors meant.
A time-boxed review of one version of the code
Forget the word “certified”. An audit is a fixed amount of expert time spent on one snapshot of the code. Trail of Bits spent 12 person-weeks on Aave V3, with three engineers, between 25 October and 24 November 2021, working from commit 14f6148 (Trail of Bits report). OpenZeppelin says that three of its auditors worked on the same commit over seven weeks (OpenZeppelin report). When the time runs out, the review stops, whether or not every bug has been found.
The commit is the part most readers skip. A commit hash is the fingerprint of one exact state of the code in the repository. Change one line and the fingerprint changes, and strictly speaking the audit no longer describes that code.
The client pays and the report is addressed to the client, which shapes what you read. The findings are real and the firm signs them, but the scope was agreed with the team that paid, and the team chooses when and whether to publish. None of the reports used in this lesson states a price: the figure you can read is the effort, and person-weeks say more than a logo does.
You will meet three kinds of document. A manual audit is written by a named team of reviewers. A formal verification report tests code against mathematical rules. A contest report gathers what many competing researchers submitted and judges confirmed. Each has limits of its own, covered below. Contract bugs are one family among the others mapped in our DeFi risk taxonomy: an audit says nothing about most of the rest.
Anatomy of a smart contract audit report, step by step
Step 1: the cover and the dashboard
Every smart contract audit report opens with the facts that identify it. Note four things on the first pages: the date, the repository, the commit hash, and the dates of the engagement. Trail of Bits reports add a dashboard with effort and a count of findings per severity. Look at the changelog too. The Aave report carries two dates, an initial report on 29 November 2021 and a fix log added on 21 January 2022, which tells you the firm came back to check.
A report with no commit hash is close to useless for you, because you cannot tell what it describes.
Step 2: the scope and what was left out
Go next to the section called scope, or “coverage limitations”, and read it slowly. This is where the firm protects itself and informs you. OpenZeppelin’s Aave report states: “We assume all price oracles work as intended since they are out of scope for this audit.” That is a fair statement, and a large one, since an oracle is a common route to a loss (our lesson on oracle design and manipulation explains why).
Trail of Bits was just as plain on Balancer’s Composable Stable Pool in 2022 (report). It wrote that it “did not look for opportunities to conduct high-level economic attacks” and did not cover the StableMath and WordCodec libraries, “explicitly marked as out of scope”. Those lines matter later in this lesson.
Step 3: the findings table
Now the summary: a table of findings with severity and, in the final version, status. Count the high and critical items, then jump straight to their status. A long list of informational notes is often a sign of a careful reviewer, not of bad code, so the raw total tells you little.
Step 4: severity scales differ from firm to firm
There is no common scale. Each firm defines its own words, usually in an appendix. High at one firm may be Critical at another, as the Aave example below shows.
| Who | Levels | How the top level is defined | Source (as read 1 November 2026) |
|---|---|---|---|
| Trail of Bits | Informational, Undetermined, Low, Medium, High, plus a separate difficulty rating | High: could affect numerous users, with serious reputational, legal or financial implications for the client | Aave V3 report, Appendix A, 2021 |
| OpenZeppelin | Critical, High, Medium, Low, Notes | Headings only in the Aave report: no definition printed there | Aave V3 report, 2021 |
| Sherlock (contest and audit judging) | High, Medium | High: “Direct loss of funds without (extensive) limitations of external conditions” | Judging guidelines |
| Bug bounty programs | Set per program | Read the severity table of that program’s page | Each program page |
Trail of Bits also rates difficulty separately. A High severity with Low difficulty is worse news than a High that needs a rare set of conditions. And watch for “Undetermined”, which means, in the firm’s own definition, that the extent of the risk was not determined during the engagement. It is an open question left on the table. It is not a mild finding.
Step 5: the status words
Severity says how bad a problem was. Status says what became of it. The vocabulary varies, but these are the words you will meet:
- Fixed means the team changed the code, and the report usually links the pull request. Check whether the auditor reviewed the fix.
- Partially fixed means part of the problem remains. Read what part.
- Acknowledged means the team has seen the finding. It says nothing about a change in the code.
- Risk accepted by client means the team decided to live with it, often with written reasons.
- Not fixed means what it says, and you should look for the reason.
- Intended behaviour means the team disputes that this is a bug.
“Acknowledged” is the word that trips readers. In the Aave OpenZeppelin report, finding H03 warns that the protocol mints aTokens for the amount requested without checking what it received, a problem for any token that charges a transfer fee. Its status is Acknowledged, and the Aave team’s reason is quoted: “It is a design choice to not have any implementation to handle nonstandard behaviors in the default codebase”. That can be a defensible choice. It is still a live property of the code, and you now know about it.
Step 6: the fix log and the re-review
A finding marked fixed by the team is a claim, and a fix reviewed by the auditor is stronger. The Trail of Bits fix log describes the firm’s own review of the fixes made after the assessment. OpenZeppelin’s conclusion on Aave adds that “we always recommend submitting the code for another round of auditing after all the fixes are applied”. Fixes are new code, and new code can carry new bugs.
Worked example: two firms, one Aave commit
Aave V3 is a useful case because two firms audited the same commit and published the same kind of document. Aave is the teaching example here: it was not hacked in the cases discussed later.
| Report on commit 14f6148 | Effort | Critical | High | Medium | Low | Informational or notes | Total |
|---|---|---|---|---|---|---|---|
| Trail of Bits, 29 November 2021 (fix log 21 January 2022) | 12 person-weeks, 3 engineers | n/a | 5 | 1 | 2 | 7 | 15 |
| OpenZeppelin (file dated 1 November 2021 in the repository) | 3 auditors, 7 weeks | 2 | 3 | 1 | 7 | 14 | 27 |
The Trail of Bits fix log closes the loop: 11 findings fixed, 4 risk accepted by the client, all four rated Informational. OpenZeppelin’s statuses are written finding by finding, so there you read each “Update” line.
One bug in plain words
Aave lets one user borrow on credit delegated by another. Trail of Bits finding TOB-AAVE-007 says the borrow function “incorrectly fetches the eMode category of msg.sender instead of onBehalfOf”. In other words, the code looked up the settings of the person making the call, not of the person whose collateral stood behind the loan.
The report gives numbers. Assume DAI has a loan-to-value ratio of 80% and a liquidation threshold of 85%, while the stablecoin eMode (a high-efficiency setting for correlated assets) allows 97% and 98%. Alice, without eMode, delegates credit on her 100 DAI to Eve, who has eMode on. Eve borrows 97 USDC. Alice can now be liquidated, because a loan sized for the 97% rule sits on a position bound by the 85% one. The severity is High, and the difficulty Low.
OpenZeppelin’s C02, “eMode category is skipped in borrows”, is the same defect, and the reports let you prove it. Both point to the same fix, pull request 204 of aave-v3-core, which changes one argument in Pool.sol from _usersEModeCategory[msg.sender] to _usersEModeCategory[onBehalfOf]. Trail of Bits rates the bug High. OpenZeppelin rates it Critical. That is the clearest argument against comparing severity counts across firms.
What two audits add
The reports overlap and differ. Both flagged isolation-mode debt that was not updated properly (Trail of Bits finding 11, OpenZeppelin H01). OpenZeppelin also reports C01, on minting debt tokens with the wrong user’s state. Trail of Bits reports finding 2, a missing chain ID check that would let signatures be reused across forks, rated High and fixed. Two separate teams looking at one commit caught things in common and things apart, which is the case for paying twice.
What “risk accepted” looks like in practice
Read the reasons, because they show how a team thinks. On compiler optimisations (finding 1), the Aave team answered that the benefits “outweighs the risks” and that its community would monitor the compiler. On a deprecated Chainlink interface (finding 13), the report records that the recommended one costs more gas and that the change was left to the Aave community. You may agree or not. The point is that you can read the decision and date it.
Audited scope versus deployed code
A report describes a commit. Your money sits in a contract at an address. The gap between the two has a name, used by the security firm Zellic: audit drift. Closing that gap is the most useful skill in this lesson, and anyone can do it with a block explorer.
Tracing the live Aave Pool to its audits
Here are the steps, with the results we got on 1 November 2026.
- Get the address from the project’s own documentation or address book, never from a search ad or a social post. For Aave, the address book gives the Ethereum Pool as 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2.
- Open that address on Etherscan and go to the Contract tab. Look for the verified mark. The page shows verified source with an exact match, and the contract is a proxy.
- Locate the implementation. A proxy holds the money and forwards calls to logic stored elsewhere, at a location standardised by ERC-1967. Etherscan shows it directly: 0x728a138A4823392C2EFA55e028d434F526fE03CF, named PoolInstance, also verified. Our own read of the storage slot returned the same address.
- Identify the release. In “Read as Proxy”, the function POOL_REVISION returns 11.
- Match the release in the repository. The v3.7.0 tag sets POOL_REVISION to 11, so the revision number matches that release.
- List the audits of that release, not of the protocol in general. The audits folder holds six reports on v3.7, dated 26 to 31 March 2026: MixBytes, Sherlock, Pashov, Certora, Savant and Enigma.
- Open those reports and compare their commit with the tag. GitHub dates the v3.7.0 release 5 August 2026, months after the reports. A gap in dates is not a fault in itself. It is your cue to check which commit each firm reviewed and what changed after it.
Now see what the first audit is worth to you here. The 2021 reports studied above describe code that is many releases older than the live Pool. A protocol that cites its first audit is telling you about the past. Count audits per release, not in total: the Aave folder holds 49 files as of 1 November 2026, or 47 reports once you set aside two that appear in both PDF and Markdown. They span more than four years and many versions, and a few cover side contracts rather than the Pool.
A revision number is strong evidence, not proof. For proof, a developer compares a compile of the tagged code with the bytecode on chain. And Etherscan’s verified mark proves one narrow thing, that the published source compiles to the deployed bytecode. As the page itself says, “Source code verification does not imply the contract is safe to interact with.”
Upgrades and admin keys
Upgradeable contracts add a second gap. Whoever controls the proxy can replace the implementation, and the new code has no audit until someone commissions one. So ask who holds that power: a single key, a multisig, or a governance vote with a delay. An ERC-1967 proxy emits an Upgraded event at each change, so the contract’s event log shows how often that power has been used. A contract that changed last week and an audit from last year do not describe the same thing.
What usually sits outside the scope
Expect these outside the perimeter unless the report says otherwise: price oracles, third-party components such as rate providers, shared base contracts, the website you actually click on, the keys of the operators, and other protocols plugged in later. Trail of Bits noted in the Balancer 2022 report that it only partially covered base components such as BasePool.
More than one audit: the layers of assurance
Serious teams stack methods, because each catches different things. Uniswap v4 is the standard example: its team reported on 26 November 2024 nine independent audits, naming six firms, then a $2.35 million security competition with more than 500 researchers, in which “no critical vulnerabilities were found”, and finally a $15.5 million bug bounty on the Cantina platform.
Formal verification: proof of the rules someone wrote
Tools such as the Certora Prover check code against written rules in every possible state, where a test only tries some. That is a stronger method and a narrower one. The result holds only for the rules written and the model used. Certora’s report on Balancer says so itself: “the guarantees of the Certora Prover are scoped to the provided specification” (report, 2022). To keep the problem solvable, that same work replaced the StableMath library with a stand-in returning “arbitrary, but consistent values”, and set _upscaleArray() and related functions to return nondeterministic values. When you read such a report, go to the assumptions and the list of simplified functions before the list of proved rules.
Contests: many eyes, and a market that moved
In a contest, a sponsor posts code and a prize pool, researchers compete for a limited time, and judges decide what is valid and how severe. You get breadth for a fixed period. Sherlock’s guidelines define a High as a direct loss of funds without extensive limits from external conditions, and a Medium as a loss needing certain conditions or one that is highly constrained.
That market has changed. Code4rena, the name most associated with the format, announced on 13 May 2026 that it was winding down, with Immunefi partnering to onboard its bug bounty customers. Its site still displays the tally as of 1 November 2026: 512 audits and 1,607 unique high-severity vulnerabilities. Its past reports stay useful. Sherlock’s documentation now leads with Collaborative Audits, an Audit Engine combining AI and human researchers, and bug bounties. So when a project cites a contest, check the platform, the date and the final report.
Bug bounties: the audit that never stops
A bounty pays outsiders for bugs in live code, which covers the time after the auditors have left. Immunefi’s study of 593 programs, published on 20 April 2026 and covering January 2021 to February 2026, gives the numbers below. Immunefi sells this service and the data covers only its own programs, so treat it as vendor research.
| Age of the program | Share with at least one confirmed, paid critical bug |
|---|---|
| 1 year or more | 61.4% |
| 2 years or more | 73.9% |
| 3 years or more | 87.2% |
| 4 years or more | 92.9% |
| 5 years or more | 93.9% |
Read that against any “fully audited” claim: the longer a program ran, the more likely it was to surface a critical bug. The same study puts the median critical bounty at $20,000 and the mean at $114,355, with $107.3 million paid for criticals. The maximum on a program page is a ceiling, not a payment. The best-known payment is Wormhole‘s, a record at the time: $10 million to a researcher known as satya0x, who reported an uninitialised proxy implementation on 24 February 2022. It was fixed the same day, and no user funds were lost, according to Immunefi. Earlier that month, the bridge had suffered an exploit that The Block put at close to $323 million; the FBI notice cited below says about $320 million.
| Layer | What it does | What it cannot do |
|---|---|---|
| Manual audit | Experts reason about one commit for a fixed time | Cover later changes, or anything out of scope |
| Formal verification | Proves written rules in every modelled state | Check rules nobody wrote, or parts simplified away |
| Contest | Many reviewers compete for a limited period | Cover later changes; quality varies with prize and date |
| Bug bounty | Pays for bugs in live code, with no end date | Stop an attacker who prefers to exploit than to report |
| Monitoring and operations | Watches live contracts and keys | Replace any of the above, or prevent a signer being deceived |
Why an audit guarantees nothing: real cases
Audited protocols keep losing money. Unaudited ones do too, and more often in one count: Zellic wrote in November 2022 that 15 of the top 20 hacks on the Rekt leaderboard were unaudited, a count that includes Nomad, and Zellic sells audits. Nobody publishes a clean ratio of audited to unaudited failures, so distrust anyone quoting one. The cases below show how a loss happens around an audit, and none of them is a verdict on the firm named.
Balancer, November 2025: the warnings in the reports
On 3 November 2025, an attacker drained Balancer V2 stable pools and forks of that code. The preliminary report blamed a rounding error in the upscale step of exact-out swaps inside batchSwap, as The Block summarised it. Tiny rounding errors, repeated in a chain of swaps within one transaction against pools pushed to low balances, added up. OpenZeppelin gives a detailed account. Loss figures differ with the method: about $116 million in Cointelegraph on 5 November, over $120 million with forks for OpenZeppelin, and $128.64 million on PeckShield’s running tally. Balancer said at the time that the figures were unconfirmed.
| Date | Document | What it says, on its own terms |
|---|---|---|
| 22 December 2021 | Trail of Bits, Linear and Phantom Pools | Finding TOB-BALANCER-004 on rounding, severity Undetermined, difficulty Low: no significant risk identified, yet “an attacker could use them to turn a profit” |
| 22 September 2022 | Trail of Bits, Composable Stable Pool | Six findings. StableMath and WordCodec out of scope; no search for high-level economic attacks; BasePool partly covered |
| 23 September 2022 | Certora, Stable Pool | Three issues, none above Low. StableMath replaced by a stand-in; _upscaleArray() set to nondeterministic values |
| 3 November 2025 | Exploit | Rounding in the upscale step of exact-out swaps |
Be careful here. The 2021 finding is about rounding in LinearMath and LinearPool, and it notes that _upscaleArray is used similarly in all Balancer pools. It belongs to the same family of concerns as the 2025 exploit: it is not a description of that attack, and the firm said it found no significant risk. What the table shows is that a patient reader in 2022 could have seen three things: rounding had been flagged and left undetermined, the maths library was outside one audit, and the scaling step was simplified away in the proofs. That is a statement about what the documents covered. It does not show that any firm should have caught the attack.
OpenZeppelin, which audited earlier Balancer V2 code in 2021, dates the first scaling override to 16 July 2021 and says the pools carrying the attack vector were added after its second audit ended, so its reports did not cover them. That is the firm’s account of its own work, and the same article assigns fault to no auditor. It also speaks only for OpenZeppelin: Balancer’s page lists the two September 2022 reports above on the Composable Stable Pool, each with the limits shown in the table.
Euler, March 2023: a later change
Euler lost about $197 million on 13 March 2023, by Rekt’s tally. The route ran through donateToReserves, which Rekt says came into Euler through a contract upgrade called EIP-14, and which lacked the liquidity check applied to ordinary transfers (Zellic analysis). Rekt counted six auditors. It also reported that Sherlock, which it called a smart contract insurance protocol, had taken responsibility for missing the flaw in its review of EIP-14. The Block reported on 14 March that Sherlock agreed to pay a $4.5 million claim. Accounts differ on the details of that review, so we go no further. The ending was unusual: Euler said on 3 April 2023 that the attacker had returned all “recoverable funds” (CoinDesk).
The attack used a flash loan, explained in our lesson on flash loans. The reading lesson is simpler: a count of auditors does not tell you who reviewed a given function.
Nomad, August 2022: audited code and deployed code
The Nomad bridge lost about $190 million in August 2022. Zellic wrote that, according to Quantstamp, the auditor, “the buggy code responsible for the hack was introduced after the audit had begun”, and its tracker showed only 18.6% of the on-chain code in Replica.sol as audited. Cointelegraph reported on 3 August 2022 that the flaw had been flagged in Quantstamp’s June report, then added Nomad’s claim that the vulnerability Quantstamp highlighted was different from the cause of the exploit. These are the parties’ statements as relayed by others, and we take no side. Only a commit-by-commit comparison settles what was reviewed.
2026: signers and messaging layers
Drift lost $285 million on 1 April 2026. Nexus Mutual’s incident report calls it “the result of an operational security failure, not an exploit of Drift’s smart contracts”, and describes malware on contributors’ devices and pre-signed approvals from two of five Security Council members. On 18 April 2026, Kelp DAO’s bridge released 116,500 rsETH, about $292 million, after an attacker got LayerZero’s messaging layer to accept a false instruction as valid, according to CoinDesk, which noted that Kelp had not yet explained how the validation was bypassed. A report on a contract tells you little about its signers, or about the messaging layer it trusts.
What the FBI told investors
The FBI’s notice of 29 August 2022 told investors: “Ensure the DeFi investment platform has conducted one or more code audits performed by independent auditors”. The same notice cited a flash loan attack of about $3 million, a bridge signature flaw that cost about $320 million, and a price oracle manipulation of about $35 million. The notice does not say whether those platforms had been audited, so read the audit line as one precaution among several, not as a promise.
Fake and misleading audit badges
A logo on a landing page costs nothing. CertiK warned on 17 January 2024 that scam sites were using counterfeit audit certifications in its name, and named Lymex, an exit scam of about $300,000 that listed CertiK as auditor though, according to CertiK, it never received the service. That is a vendor protecting its brand, so it speaks for its own case, but the method is general. Our guides to the rug pull and to avoiding crypto scams show where such badges appear.
Six checks on a smart contract audit report take a few minutes:
- Look for the report on the auditor’s own site or official GitHub. A PDF on the project’s site proves nothing alone.
- Check that the date and commit hash exist and that the commit is in the project’s public repository.
- Expect named reviewers and a stated scope. A real report says what was not covered.
- Expect findings with IDs and statuses. A report with nothing but praise deserves suspicion.
- Compare the contract address or commit in the report with what is deployed.
- Ignore any “verification” link sent by private message, and go to the auditor’s site by your own bookmark.
A score on a security rating page is also not an audit. Read what the score measures before you lean on it. And a genuine report on a different contract, an old version or a small part of the system is the subtler trick: “audited by” on a website may be true and still say nothing about the code holding your money.
A ten-minute checklist for any report
- Write down the date, the repository and the commit.
- Read the scope and the coverage limitations before any finding.
- Count Critical and High findings, using that firm’s definitions.
- Check the status of each one: fixed, acknowledged, risk accepted or not fixed.
- Read every “Undetermined” and the reasons for every accepted risk.
- Check that the auditor reviewed the fixes.
- Note what is assumed: oracles, admins, external tokens, simplified functions.
- Trace the live address to its implementation and release.
- List the audits of that release, and note any upgrade since.
- Look for an active bug bounty, and what a successful report would pay.
How to weigh what you found
After those ten minutes, you hold facts, not a verdict. A clean smart contract audit report on the code in use, with fixes reviewed, several firms and a live bounty, lowers one kind of risk. It does nothing for oracle failures, signers, governance or bridges. Open findings on the top severities, a scope that skips the part you rely on, or an upgrade after the last audit are questions to pursue, and a protocol’s public response to them tells you a lot.
The next lesson of this path takes the attacks themselves apart, family by family, with reentrancy, flash loans and manipulated oracles, and a dated list of the largest cases.
