reentrancy-pattern-analysis

Reentrancy Pattern Analysis

Systematically detect all variants of reentrancy vulnerabilities by mapping the relationship between external calls and state changes across the entire contract system.

When to Use

• Auditing any contract that makes external calls (ETH transfers, token interactions, cross-contract calls)
• Reviewing contracts integrating with callback-enabled token standards (ERC-777, ERC-1155)
• Analyzing DeFi protocols with multi-contract architectures
• Verifying reentrancy guard coverage across all entry points
• When traditional tools only check for classic reentrancy but miss cross-function or read-only variants

When NOT to Use

• Pure state variable analysis without external calls (use state-invariant-detection)
• Access control consistency checking (use semantic-guard-analysis)
• Full multi-dimensional audit (use behavioral-state-analysis, which orchestrates this skill)

Core Concept: The CEI Invariant

Checks-Effects-Interactions (CEI) is the fundamental safety pattern:

1. CHECKS   — Validate all conditions (require statements, access control)
2. EFFECTS  — Update all state variables
3. INTERACTIONS — Make external calls (ETH transfers, token calls, cross-contract)

Any function that performs INTERACTIONS before completing all EFFECTS is potentially vulnerable to reentrancy.

The Five Reentrancy Variants

Variant 1: Classic Single-Function Reentrancy

The original and most well-known pattern. A function makes an external call before updating its own state, allowing the callee to re-enter the same function.

// VULNERABLE
function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}(""); // INTERACTION before EFFECT
    require(success);
    balances[msg.sender] -= amount; // State update AFTER external call
}

Detection: Find functions where state writes to variables used in require checks occur AFTER external calls.