Audit and Exploit History
Security audits and exploit history provide evidence about code risk, operational response and whether known weaknesses were actually remediated. An audit
Reading progress — saved on this device
Learning objectives
- Evaluate audit scope, date, version and unresolved findings.
- Research exploits by root cause, loss, response and remediation.
- Assess whether security processes improved after incidents.
What it is
Audits review specified code under time and scope constraints. They can detect vulnerabilities, design weaknesses and testing gaps, but they do not prove absence of bugs.
Exploit history includes direct contract bugs, oracle failures, governance attacks, compromised keys, bridge failures and operational mistakes. Classification matters because remediation differs.
Incident response reveals governance and operational maturity: pausing systems, communicating transparently, coordinating recovery and compensating users are separate capabilities.
How to analyse it
Map each audit to the deployed contracts or repository commit. Check whether major upgrades occurred afterwards and whether those changes received equivalent review.
Read findings by severity and status. “Resolved” may mean code changed, risk accepted or design modified; verify the final implementation where material.
For exploits, build a timeline from root cause to loss, containment, recovery and remediation. Distinguish funds stolen from temporary accounting losses or user-specific phishing.
Evaluate defence in depth: audits, formal verification, bug bounties, monitoring, pause controls, rate limits, upgrade procedures and insurance or reserves.
Research framework
| Check | Why it matters | What to verify |
|---|---|---|
| Audit scope | Defines what was reviewed | Match report to contract addresses/commit and deployment. |
| Findings | Shows known risk | Review severity, status and accepted residual issues. |
| Incident root cause | Guides recurrence risk | Classify code, oracle, key, governance or operational failure. |
| Remediation | Tests learning | Verify code changes, controls, monitoring and user recovery. |
Evidence hierarchy and limitations
Use original audit reports and post-mortems where possible. Marketing summaries often omit scope limitations and accepted findings.
A project with an exploit is not automatically worse than one without disclosed incidents. The latter may simply be newer or less transparent. Compare exposure time, code complexity, TVL and security process.
Worked example and thought exercise
A protocol advertises three audits, but all reviewed version 1 contracts. Version 2 introduced a new borrowing module after the last audit and now holds 80% of TVL. The headline audit count is less useful than coverage of the current system.
After an oracle exploit, the team adds circuit breakers, diversified price sources and monitoring. Those controls directly address recurrence, while a generic promise to “improve security” would not.
Thought exercise: Would you prefer a mature protocol with one well-remediated exploit or a new unaudited protocol with no incident history?
Common mistakes and practical workflow
- Counting audit logos instead of reading scope.
- Assuming audits eliminate smart-contract risk.
- Treating all exploits as the same failure type.
- Ignoring whether current contracts were deployed after the audit.
Practical workflow
- Collect every audit report and deployed contract version.
- Map findings to current code and status.
- Build a timeline of all known incidents and root causes.
- Verify remediation and defence-in-depth controls.
- Compare security maturity with protocol complexity and value at risk.
Knowledge checkpoint
- Why does audit scope matter?
- What does “resolved” mean in an audit report?
- Why classify exploit root causes?
- How can incident response improve the security thesis?
FAQs
❓ Does an audit guarantee safety?
No. Audits reduce uncertainty but are bounded reviews and can miss vulnerabilities.
❓ How many audits are enough?
There is no magic number; current scope, quality, complexity and remediation matter more.
❓ Are bug bounties useful?
Yes, they can attract continuous external testing, though they do not replace secure design.
❓ Should exploits permanently disqualify a project?
Not automatically. Root cause, losses, remediation and governance response should be evaluated.
Summary
Security due diligence checks whether the current deployed system was actually reviewed and how the project learns from failure. Audit scope, exploit root cause and verified remediation matter more than logo count.
Want this in a personalised order?
Take the crypto assessment and get a custom path of 10 modules matched to what you already know. Free, no card required.
Build my path →