Anatomy of a DeFi Security Audit: What We Look For

The Stakes Are Real

DeFi protocols hold billions in TVL. A single vulnerability can — and has — led to catastrophic losses. Security auditing is the last line of defense.

Common Vulnerability Classes

Reentrancy — The classic. External calls before state updates.

Flash Loan Attacks — Price manipulation via uncollateralized borrowing.

Access Control — Missing or incorrect permission checks.

Integer Overflow — Arithmetic errors in token calculations.

Oracle Manipulation — Exploiting price feed dependencies.

Audit Methodology

Phase 1: Automated Analysis
├── Slither (static analysis)
├── Mythril (symbolic execution)
└── Echidna (property-based fuzzing)
Phase 2: Manual Review
├── Line-by-line code review
├── Business logic verification
├── Economic attack modeling
└── Cross-contract interaction analysis
Phase 3: Formal Verification
├── Invariant specification
├── Mathematical proof of properties
└── Certora / K Framework verification

A Real Example

// VULNERABLE: reentrancy
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount; // State update AFTER external call
}
// FIXED: checks-effects-interactions
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount; // State update BEFORE external call
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
}

Every audit is a race against creative attackers. The methodology must be systematic, thorough, and paranoid.