security-audit

Security Audit

Production authority on smart contract security: identifying, exploiting, and remediating the full taxonomy of EVM vulnerabilities. Covers manual review methodology, static analysis tooling, fuzz-based invariant testing, and professional audit report structure. Use this skill when auditing a contract, reviewing a PR for security issues, or building security tooling.

Core Concepts

Audit Methodology

A systematic audit follows four phases: (1) scope and threat modeling, (2) automated analysis, (3) manual line-by-line review, (4) report drafting. Never start with automated tools alone — they miss business logic bugs that are the most expensive class of exploit.

Threat modeling questions: Who calls each function? What invariants must always hold? What is the economic value at risk per function? Can any state transition happen out of order? What happens if any external call returns false, reverts, or re-enters?

Reentrancy

The canonical exploit pattern. Attacker's receive() or fallback() re-enters the victim before state is updated.

// VULNERABLE — state updated after external call
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    (bool ok,) = msg.sender.call{value: amount}("");  // re-enters here
    require(ok);
    balances[msg.sender] -= amount;  // too late — attacker already drained
}

// FIXED — checks-effects-interactions
function withdraw(uint256 amount) external nonReentrant {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;  // effect first
    (bool ok,) = msg.sender.call{value: amount}("");  // interaction last
    require(ok);
}

Cross-function reentrancy: nonReentrant on withdraw does not protect harvest() if both read balances. Apply nonReentrant to every entry point that touches shared state. Read-only reentrancy (Curve bug 2023): a view function called mid-execution sees inconsistent state — lock views during state transitions for protocols others integrate with.