$npx -y skills add quillai-network/quillshield_skills --skill reentrancy-pattern-analysisSystematically detects all reentrancy vulnerability variants in smart contracts — classic, cross-function, cross-contract, and read-only reentrancy. Builds call graphs, verifies CEI (Checks-Effects-Interactions) pattern compliance, traces state changes relative to external calls,
| 1 | # Reentrancy Pattern Analysis |
| 2 | |
| 3 | Systematically detect **all variants** of reentrancy vulnerabilities by mapping the relationship between external calls and state changes across the entire contract system. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - Auditing any contract that makes external calls (ETH transfers, token interactions, cross-contract calls) |
| 8 | - Reviewing contracts integrating with callback-enabled token standards (ERC-777, ERC-1155) |
| 9 | - Analyzing DeFi protocols with multi-contract architectures |
| 10 | - Verifying reentrancy guard coverage across all entry points |
| 11 | - When traditional tools only check for classic reentrancy but miss cross-function or read-only variants |
| 12 | |
| 13 | ## When NOT to Use |
| 14 | |
| 15 | - Pure state variable analysis without external calls (use state-invariant-detection) |
| 16 | - Access control consistency checking (use semantic-guard-analysis) |
| 17 | - Full multi-dimensional audit (use behavioral-state-analysis, which orchestrates this skill) |
| 18 | |
| 19 | ## Core Concept: The CEI Invariant |
| 20 | |
| 21 | **Checks-Effects-Interactions (CEI)** is the fundamental safety pattern: |
| 22 | |
| 23 | ``` |
| 24 | 1. CHECKS — Validate all conditions (require statements, access control) |
| 25 | 2. EFFECTS — Update all state variables |
| 26 | 3. INTERACTIONS — Make external calls (ETH transfers, token calls, cross-contract) |
| 27 | ``` |
| 28 | |
| 29 | **Any function that performs INTERACTIONS before completing all EFFECTS is potentially vulnerable to reentrancy.** |
| 30 | |
| 31 | ## The Five Reentrancy Variants |
| 32 | |
| 33 | ### Variant 1: Classic Single-Function Reentrancy |
| 34 | |
| 35 | 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. |
| 36 | |
| 37 | ```solidity |
| 38 | // VULNERABLE |
| 39 | function withdraw(uint256 amount) public { |
| 40 | require(balances[msg.sender] >= amount); |
| 41 | (bool success, ) = msg.sender.call{value: amount}(""); // INTERACTION before EFFECT |
| 42 | require(success); |
| 43 | balances[msg.sender] -= amount; // State update AFTER external call |
| 44 | } |
| 45 | ``` |
| 46 | |
| 47 | **Detection**: Find functions where state writes to variables used in `require` checks occur AFTER external calls. |
| 48 | |
| 49 | ### Variant 2: Cross-Function Reentrancy |
| 50 | |
| 51 | Two or more functions share state, and an attacker re-enters through a DIFFERENT function than the one making the external call. |
| 52 | |
| 53 | ```solidity |
| 54 | function withdraw(uint256 amount) public { |
| 55 | require(balances[msg.sender] >= amount); |
| 56 | (bool success, ) = msg.sender.call{value: amount}(""); |
| 57 | require(success); |
| 58 | balances[msg.sender] -= amount; |
| 59 | } |
| 60 | |
| 61 | // Attacker re-enters HERE during withdraw's external call |
| 62 | function transfer(address to, uint256 amount) public { |
| 63 | require(balances[msg.sender] >= amount); |
| 64 | balances[msg.sender] -= amount; |
| 65 | balances[to] += amount; |
| 66 | } |
| 67 | ``` |
| 68 | |
| 69 | **Detection**: For each external call in function F, check if any OTHER public function reads/writes the same state variables that F modifies after the call. |
| 70 | |
| 71 | ### Variant 3: Cross-Contract Reentrancy |
| 72 | |
| 73 | The re-entry occurs through a different contract that shares state or trust relationships with the vulnerable contract. |
| 74 | |
| 75 | ```solidity |
| 76 | // Contract A |
| 77 | function withdrawFromVault() public { |
| 78 | uint256 shares = vault.balanceOf(msg.sender); |
| 79 | vault.burn(msg.sender, shares); |
| 80 | // External call — attacker can re-enter Contract B |
| 81 | (bool success, ) = msg.sender.call{value: shares * pricePerShare}(""); |
| 82 | require(success); |
| 83 | } |
| 84 | |
| 85 | // Contract B (attacker re-enters here) |
| 86 | function borrow() public { |
| 87 | uint256 collateral = vault.balanceOf(msg.sender); // Reads stale state! |
| 88 | // Shares not yet burned, so collateral appears inflated |
| 89 | uint256 loanAmount = collateral * maxLTV; |
| 90 | token.transfer(msg.sender, loanAmount); |
| 91 | } |
| 92 | ``` |
| 93 | |
| 94 | **Detection**: Map all cross-contract dependencies. For each external call, identify which other contracts read the state that should have been updated. |
| 95 | |
| 96 | ### Variant 4: Read-Only Reentrancy |
| 97 | |
| 98 | A view/pure function returns stale state during a reentrancy callback. No state is modified during re-entry — the attacker exploits the READING of inconsistent state by a third-party contract. |
| 99 | |
| 100 | ```solidity |
| 101 | // Pool contract |
| 102 | function removeLiquidity() external { |
| 103 | uint256 shares = balances[msg.sender]; |
| 104 | // Burns LP tokens (updates internal accounting) |
| 105 | _burn(msg.sender, shares); |
| 106 | // External call BEFORE updating reserves |
| 107 | (bool success, ) = msg.sender.call{value: ethAmount}(""); |
| 108 | // Reserves updated AFTER the call |
| 109 | totalReserves -= ethAmount; |
| 110 | } |
| 111 | |
| 112 | // This view function returns stale data during the callback |
| 113 | function getRate() public view returns (uint2 |