Smart Contract Audit Report Examples: Ten Public Documents Annotated

Selection criteria

The useful question is what a public report lets you verify. Smart contract audit report examples should show how an assessor connects a defined codebase to findings, limitations and subsequent changes. A polished cover and a long issue list do not establish that the deployed version was reviewed.

We selected documents from the Ethereum and EVM section of Trail of Bits' public archive. The sample is deterministic and limited to that publisher. It is neither a ranking of audit firms nor a claim that these are the best reports available. A single archive makes it easier to examine changes in document structure without pretending to compare different firms' assessment quality.

Selection also exposed a classification problem. The publisher's EVM category contains files whose names identify desktop or wallet work. We excluded those filename matches before sampling because this article concerns contract assessment documents. That rule is reproducible, but it cannot guarantee that every remaining report has identical technical scope.

Historical documents answer a historical question. A finding in one of these reports is not evidence that the current deployment remains vulnerable. Conversely, a resolved finding does not certify every later release. Keep the report's version and the system's current version separate throughout the review.

The audit report reading guide covers the basic vocabulary. Here, the comparison goes further: it distinguishes a full assessment from a document that revisits earlier findings, then checks where a simple text search misclassifies those functions.

Ten PDFs and the limits of keyword counts

Method

Source and selection

Unique reviews/*.pdf links listed under Ethereum/EVM in the fetched Trail of Bits README. Exclude filename matches desktop or wallet because the publisher taxonomy includes non-contract systems. Sort remaining paths lexically; first 10. Fetch immutable tree revision and extract complete PDF text with pdftotext. Signals require manual reading.

Retrieved

2026-09-05

Observation

162 unique EVM-listed PDFs became 160 eligible after 2 filename exclusions. The first 10 lexical paths were fetched successfully from an immutable repository revision.

Results

Manual reading classified 3 of the 10 documents as standalone fix reviews: Beanstalk, Increment Protocol and GSquared. The other 7 are assessment documents. This is a document-type classification, not a count of distinct audited projects.

The Aave v3 assessment illustrates a false negative in the automated fix-review signal. Its Appendix E is a Fix Log, but the searched vocabulary did not match that label. The Beanstalk assessment illustrates the opposite problem: general incident-response advice includes remediation language, which is not itself evidence of a completed fix review. We retain the automatic counts and explain these distinctions instead of relabeling them as substantive coverage scores.

Limits

• One publisher and lexical ordering create a historical sample, not a representative market survey.
• PDF text extraction and narrow vocabulary affect matches; absence is not proof that the report omits the underlying information.
• A standalone fix review and its original assessment can both enter the sample, so 10 documents must not be described as 10 independent engagements.

The reproducible record is kept in the repository: seo/research/articles-32-41-2026-09-05/surveys.py and seo/research/articles-32-41-2026-09-05/survey-41.json. These file paths are not public downloads.

Annotated reports

Open the linked document before adopting its format. The annotations identify a reading task and a limitation, not a recommendation to purchase a service. Each link is fixed to the repository revision used for the measurement, so later archive edits do not silently replace the sampled file.

Follow one finding across documents

The Increment pair is useful because an assessment and a follow-up appear separately. Start with the original description of the governance role, then read its disposition in the fix review. The status is partially resolved. That wording carries information about the assessor's conclusion that would disappear if a dashboard reduced every reviewed patch to closed.

The two Beanstalk documents create a similar navigation task. The original assessment records what the team examined and where coverage was limited. The fix review addresses responses to earlier findings. A reader who opens only the follow-up can mistake a narrower review of fixes for a new examination of the entire system.

Aave v3 presents another layout. Its fix log lives inside the assessment PDF rather than in a separate sampled filename. The changelog records the addition of that appendix. Searching filenames for fix review would miss this arrangement. Searching the PDF for only the phrase fix review can also miss a section whose heading uses different words.

Read limitations as technical information

The Maple Finance v2 assessment explicitly distinguishes understanding the upgradeability mechanism from looking for security flaws in that mechanism. That is a useful boundary to preserve in a procurement summary. Describing the whole protocol as audited without this qualification would expand the report's assurance beyond its stated work.

Increment's coverage limitations identify external math libraries and a view-only component that were not reviewed, alongside a dynamic-testing constraint. Those are different kinds of limitation: a dependency boundary, an excluded component and a testing method that could not be completed. A useful summary keeps them separate because the follow-up work differs.

Avoid converting these examples into present-day vulnerability claims. The documents describe the engagement and its recorded outcomes. A current decision requires the deployed implementation, subsequent changes and any later assessments. The archive is evidence of what a report says, not a live security scanner.

Section-by-section comparison

Compare sections by the decision they support. A table of contents is useful for navigation, but a matching heading does not establish that the content underneath answers the reader's question. Conversely, a report may provide the information under an unfamiliar heading.

Revision evidence deserves a manual check. Our automatic search found commit or revision language in only two sampled PDFs. That is not a valid basis for saying that the other eight lack version information. A hash may sit in a table or use another label. The defensible result is the vocabulary count; the procurement task is to locate the actual version record.

The same caution applies to limitations. All ten documents matched the signal, including shared language about the limits of automated techniques. That does not make every report equally specific about excluded components. An assessor's general methodological caveat and a named out-of-scope module answer different questions.

1. Identify the code and configuration examined by the original assessment.
2. Retain the finding identifier, preconditions and supported impact.
3. Locate the patch and the assessor's explanation of the follow-up work.
4. Check whether the actual release incorporates that reviewed change.

Do not infer quality from issue counts

An assessment of a mature, narrow component and an assessment of an unfamiliar protocol can produce different finding counts for reasons unrelated to auditor competence. The sampled documents are not controlled experiments. We did not normalize code size, engagement duration, prior review or system complexity, so the article does not rank reports by severity totals.

An individual issue also needs its threat assumptions. A privileged-role finding may describe an accepted trust model rather than a path available to an arbitrary user. A reader should retain the role and preconditions when extracting a summary. Removing them can turn a conditional concern into an unsupported claim about permissionless exploitation.

Our severity interpretation guide helps separate impact from classification labels. When comparing a firm's public material, use the Pharos Production member profile as a directory reference and the audit company analysis hub to locate additional evidence. A directory entry cannot substitute for reading the relevant report.

What to copy for your own report

Copy the evidence relationships, then write sections that fit the actual engagement. A report template should make it difficult to lose the connection between scope, a finding, its disposition and the release decision. It should not encourage the author to paste an assurance statement that the work does not support.

Use stable finding identifiers. If a finding changes during review, preserve enough history for the client and assessor to identify the same issue. A title can be clarified without creating the impression that the original finding vanished. Separate the original consequence from the later decision about remediation or acceptance.

This checklist is an editorial proposal derived from the reading exercise. It is not a certification standard or a claim that every sampled report contains every field. Teams can use it to agree deliverables before an engagement, then record exceptions explicitly instead of discovering them when the report is needed for a release.

1. Freeze the review target and record the artifact identifiers with the agreed exclusions.
2. Write each finding so another engineer can understand its preconditions and supported consequence.
3. Keep the client response separate from the assessor's follow-up conclusion.
4. Record unresolved and accepted items with the relevant decision owner.
5. Connect the final reviewed artifacts to the release record before using the report in a deployment decision.

A fix log should say more than done. Record what changed and what the assessor checked. If a change was not reviewed, say so. If the project accepted a risk, retain the reasoning and the accountable decision rather than making the record look like a code fix.

The same discipline applies to exclusions. A dependency that was intentionally outside scope remains outside scope after the client fixes an unrelated finding. The release owner needs to know whether separate evidence covers that dependency. Our dependency risk guide provides a way to distinguish imported source, deployed dependencies and administrative controls.

A report becomes useful when its claims can be traced. The PDF supplies part of that record; the source revision, follow-up evidence and deployment identity complete the connection. Use the examples to inspect those links, and preserve every qualification that changes the decision.

Redaction should preserve the report's logical boundaries. If a public version omits sensitive implementation details, explain which evidence remains available through the appropriate private review process. Do not replace a removed finding with a statement that no issue existed. The public reader should still be able to distinguish withheld detail, an unresolved question and a completed remediation decision without receiving information that the disclosure process has not authorized.