You Got an Audit. Your Protocol Is Not Secure Yet.

Most teams treat an audit like a finish line. Get the report. Fix the Criticals. Deploy. Done.

Six protocols that did exactly this lost a combined $37.7 million in a single quarter. One of them had eighteen audits on record. The audit wasn't the problem. The mindset was.

What an Audit Actually Is

An audit is a trained security researcher reviewing your code under a defined scope, at a specific point in time, reporting what they found. That sentence has three important limits in it.

Defined scope: Auditors review what you give them. If your off-chain backend, deployment scripts, admin key setup, or new integration isn't in scope — it doesn't get reviewed. Most of the largest losses in recent history came from exactly these out-of-scope components.

Specific point in time: The report reflects your codebase on the day it was submitted. Every line of code added after that date is unreviewed. Every parameter change post-deployment is unreviewed. Every new integration is unreviewed.

Reporting what they found: Auditors are skilled, not omniscient. Two researchers working a fixed timeline on a complex codebase will miss things. That's not a failure of the auditor. It's a reality of the process.

An audit is a snapshot. It is not a warranty. It is not a security certification. It is the beginning of your security posture — not the end.

How to Actually Read a Severity Label

Most teams fix Criticals, skim Highs, and ignore everything below. This is exactly backwards for understanding risk.

Critical: This can be exploited right now to drain funds or take ownership. Treat it like a production outage. Fix it, have the auditor re-review the fix, write a Foundry PoC that confirms the attack is blocked. Don't deploy until this is done.

High: Significant risk under specific conditions. The instinct is to deprioritize because "the conditions are unlikely." Attackers specifically engineer the conditions you think are unlikely. Every High that ships unresolved is a bounty waiting to be claimed.

Medium: Limited direct impact in isolation — but this is where most teams check out. Three Medium findings that look harmless individually are frequently the components of a Critical exploit when composed together. They are a map. Read them as one.

Low and Informational: Not an immediate threat. But Low findings cluster around the same areas of the codebase that contain the unfound High findings. They tell you where to look harder.

The 5 Questions to Ask Before Marking Anything Fixed

1. Do we understand the root cause? Not the symptom — the underlying assumption the code was making that turned out to be wrong. If you can't explain it in one sentence, you haven't understood it yet.
2. Does the fix address the root cause or just the symptom? Adding a require() at one entry point doesn't help if the same flawed assumption exists in three other functions. Fix the assumption across the entire codebase — not just the line the auditor pointed to.
3. Has the fix been tested with a PoC? Write a Foundry test that reproduces the original vulnerability. Confirm the attack works pre-fix. Confirm it's blocked post-fix. Save that test permanently — it's your regression protection for every future refactor.
4. Does the fix introduce a new issue? Access control fixes sometimes break initialization logic. Reentrancy guards sometimes disrupt callback patterns. Any non-trivial fix deserves a mini-review of its own.
5. Does this pattern exist anywhere else in the codebase? Auditors report the instance they found. They don't guarantee they found every instance of the same root cause. Search the entire codebase for the same pattern.

What "Acknowledged" Really Means

What the Report Doesn't Cover

• Code added or changed after the audit was completed
• Protocol parameters set or adjusted post-deployment
• New integrations added after deployment
• The deployment process itself — initializer front-running, constructor validation, proxy setup sequence
• Off-chain components — backends, keepers, bots, relayers
• The key management setup for admin roles and multisig signers
• The devices and operational practices of the people holding those keys

The Actual Security Checklist

• Every Critical and High finding re-reviewed by the auditor after the fix — not just marked resolved internally
• Foundry PoC written for every Critical and High — confirms exploit works pre-fix, blocked post-fix, kept permanently
• Same root cause pattern checked across the entire codebase — not just the flagged instance
• All Acknowledged findings above Low have a named decision-maker, documented risk acceptance, and a mitigation plan
• Code added after the audit flagged for re-review before deployment
• Deployment sequence reviewed separately — initializer protection, constructor validation, proxy setup order
• Real-time monitoring configured and live before mainnet launch
• Off-chain components with on-chain write authority reviewed with the same adversarial lens as the contracts