We've shipped multiple protocols that went through major audits. Here's what auditors catch, what they miss, and how we think about security from day one.
An audit from a reputable firm is table stakes for any DeFi protocol. It's also not enough. We've worked on protocols that passed major audits and still had economic attack vectors that could have drained liquidity under the right market conditions. The audit didn't miss them because the auditors were bad — it missed them because economic security is a different discipline from code security.
What audits are actually good at
Standard security audits excel at catching well-known vulnerability classes: reentrancy, integer overflow/underflow, access control issues, improper state updates, and unsafe external calls. A good audit firm will also catch logic bugs that manifest through careful manual review — the kind of off-by-one errors and edge-case mishandlings that testing suites miss.
This is valuable. These are real vulnerabilities that have cost protocols hundreds of millions. You absolutely need an audit. The mistake is assuming an audit is comprehensive.
The three gaps audits consistently miss
1. Economic attack vectors
Flash loan attacks, oracle manipulation, and liquidity death spirals are economic — not code — vulnerabilities. The contract can be perfectly correct and still be exploitable if the economic design creates arbitrage opportunities that an attacker can exploit at scale. Auditors typically flag these as 'out of scope' or note them as design considerations without fully modelling the attack surface.
2. Cross-contract interactions
Most audits scope individual contracts. DeFi protocols live in an ecosystem of composable contracts, and the danger is often in the interaction layer — how your protocol behaves when called by another protocol under unusual conditions, or how it handles tokens that have non-standard ERC20 implementations (fee-on-transfer tokens being the classic example).
3. Governance attack surfaces
Governance contracts — timelock controllers, multi-sigs, proposal systems — are frequently audited superficially. A governance takeover via token accumulation, a malicious proposal that sneaks through during low-participation periods, or a timelock that provides insufficient delay for user exit are risks that require threat modelling, not just code review.
Our pre-audit security process
Before any external audit, we run our own internal process that covers the gaps above. We model economic attacks explicitly: build a simulation of the protocol under adversarial conditions, identify the maximum extractable value at each attack surface, and set parameter bounds that make attacks economically irrational.
- Formal threat modelling before writing a line of Solidity
- Economic simulation with adversarial agents in Foundry
- Integration tests covering non-standard ERC20 tokens
- Governance simulation with low-participation attack scenarios
- Manual invariant documentation — every state the protocol should never reach
- Fuzzing with Foundry's built-in fuzzer across all critical functions
The monitoring layer nobody talks about
Security doesn't end at deployment. On-chain monitoring is non-negotiable for any protocol handling real value. We set up alerts for: unusual transaction patterns, oracle price deviations beyond expected bounds, governance proposals with unusual voting patterns, and liquidity movements that exceed normal baselines.
The best exploit response we've seen was a protocol that detected a suspicious transaction pattern, paused the contract, and investigated — all within 4 minutes of the first malicious call. That response time was only possible because monitoring was designed before launch, not after.
Get your audit. Then do everything an audit doesn't cover. Security in DeFi is a practice, not a certificate.
