Read the Audit Report First: The 10-Minute Shortcut That Saves Hours

There's a lending protocol called CapyFi. It has a whitelist mechanism that restricts who can mint the protocol's tokens — only approved liquidity providers can supply funds. I spent two hours documenting what I was convinced was a whitelist bypass vulnerability: an edge case where a user could mint without being on the whitelist through a specific combination of deposit and redemption operations.

Then I downloaded the Coinspect audit PDF. Page seven: "Finding CAPY-02 — The access restriction on minting is an intentional design decision that dictates who can supply liquidity to the protocol."

Two auditors. Six months prior. Had flagged it, been told it was intentional, and documented the decision in a PDF that had been public the entire time.

That was my most expensive lesson in the value of audit reports. It was also the fastest I ever lost two hours.

What audit reports actually contain

Every serious DeFi protocol that has run a professional audit has a report. These reports are usually public — posted on the auditor's website, linked from the protocol's documentation or GitHub, sometimes indexed on databases like Solodit. They document:

• Every finding the auditors raised, including ones the team acknowledged-and-won't-fix
• The severity classification and the team's response to each finding
• Intentional design decisions that could be mistaken for vulnerabilities
• Known limitations and trust assumptions

That last category — intentional design decisions — is the one that saves the most time. When a protocol team tells their auditors "yes, we know about this, it's intentional," they usually explain why. That explanation is exactly what you need to not file the same finding as a bug three months later.

The CapyFi failure, unpacked

Here's what would have prevented the two-hour waste:

Step 1: Look up CapyFi audit reports
         → Coinspect (June 2025), OpenZeppelin (July 2025)
         → 2 audits in 6 months = well-covered protocol

Step 2: Scan for "mint" in the PDFs
         → CAPY-02: whitelist bypass, acknowledged as intentional
         → CAPY-07: access control on redeem, same pattern

Step 3: Update search criteria
         → If whitelist bypass is documented intentional: skip
         → Focus on interaction patterns not present in either audit

Total time: about ten minutes. Time saved versus starting the audit blind: two hours. That's a 12x efficiency ratio. There's almost no other optimization that delivers 12x.

The protocols that need this most

Not every protocol has audit reports. New protocols (launched in the last 6 months), small protocols, and protocols that skipped auditing to save money may have no public reports. For these, there's no shortcut — you have to start from scratch.

But protocols with 2+ recent audits are a different category. They have:

• Professional auditors who already found and documented the obvious patterns
• Team responses that explain which findings were accepted (and fixed) versus declined (and intentional)
• Low marginal alpha for a new auditor — the low-hanging fruit is gone

For a protocol with two audits in the last six months, I now spend more time reading the reports than reading the code. The reports tell me what's already known. The remaining alpha is in what the auditors missed — which tends to be cross-module interaction bugs, post-deployment state changes, and protocol-specific edge cases that require deep knowledge of the system.

Where to find audit reports

Most reports are findable in one of these places:

• Protocol documentation: Usually linked from "Security" or "Audits" page
• GitHub: Many teams commit audit PDFs to their repo under audits/
• Auditor websites: Spearbit, Trail of Bits, OpenZeppelin, Coinspect, Cyfrin all publish their reports
• Solodit: Aggregates DeFi security findings with protocol search

For Cantina programs specifically, I check whether the program is linked to any prior audit contests — Cantina itself runs both competitive audits (many researchers) and private audits (one firm), and the findings from competitive audits are often public and searchable.

What you can still find after 2 audits

Reading audit reports doesn't make a protocol unauditable — it makes your audit more targeted. The findings that survive two professional audits tend to be:

• Bugs introduced after the audit (post-deployment contract upgrades, new integrations)
• Interactions between the protocol and external dependencies the auditors didn't test
• Edge cases in novel mechanisms that the audit checklists don't cover
• The very hard-to-find accounting bugs that require deep simulation to discover

None of these are easy. But they're the right category to search. The alternative — re-auditing patterns that are already documented — wastes time and damages credibility when you file a duplicate of a finding that was publicly acknowledged eighteen months ago.

Read the PDF first. Every time. It takes ten minutes and it's always worth it.