reentrancy

# Reentrancy detection ## When this applies Trigger on any of: - External calls via `call`, `delegatecall`, `staticcall`, `transfer`, `send` - `safeTransferFrom` / `onERC721Received` / `onERC1155Received` callbacks - ERC-777 `tokensReceived` / `tokensToSend` hooks - Cross-contract calls preceding state writes - View functions that read state which is mid-update (read-only reentrancy) - Custom token callbacks, governance vote-cast hooks, flash-loan callbacks - Compound/Aave-style accounting that updates user balances after external transfers ## Detection patterns ### Classic reentrancy (CRITICAL / HIGH) ```solidity function withdraw() external { uint256 amt = balance[msg.sender]; (bool ok,) = msg.sender.call{value: amt}(""); // ← external call require(ok); balance[msg.sender] = 0; // ← state update AFTER call } ``` **Signal:** state mutation after external call. CEI (Checks-Effects-Interactions) violated. ### Cross-function reentrancy (HIGH) Two functions sharing state where one calls externally and the other reads/mutates the same state. Attacker re-enters via the second function. ### Cross-contract reentrancy (HIGH) Contract A updates state, calls B; B calls back into a *different* contract C that reads A's stale state. ### Read-only reentrancy (HIGH — frequently missed) Victim contract reads `getReserves()` / `getPrice()` from a pool mid-callback, before the pool finalizes its state. Example: Curve pools, Balancer vaults, Un...