delegatecall-risks

# Delegatecall risk detection ## When this applies - Any `delegatecall` site - Proxy implementations (UUPS, Transparent, Beacon, Diamond) - `Multicall` / `Multicall3` / batch-execute on the contract itself - Governor's `execute()` flow - Library `using X for *` where X uses delegatecall - Generic call-forwarder / Safe modules ## Detection patterns ### delegatecall to user-controlled address (CRITICAL) ```solidity function exec(address impl, bytes calldata data) external { impl.delegatecall(data); // ← attacker provides impl, owns storage + can selfdestruct } ``` ### Uninitialized UUPS implementation (CRITICAL) The *implementation* contract, if uninitialized, can be `initialize`d by anyone, then UUPS-upgraded to a `selfdestruct` impl, bricking the implementation. (Famous: Parity multisig.) Always `_disableInitializers()` in constructor. ### Storage slot collision in proxy (CRITICAL) Proxy uses slot 0 for admin, impl uses slot 0 for `owner` → impl writes corrupt proxy admin. Use EIP-1967 namespaced slots. ### delegatecall + `msg.value` (MEDIUM-HIGH) Forwarding `msg.value` via delegatecall to a function that doesn't expect ether → trapped funds or double-accounting. ### Multicall + delegatecall + msg.sender confusion (HIGH) `Multicall` via delegatecall preserves `msg.sender`, so signed-payload-based functions (`permit`, ERC-2771) can be combined in surprising ways. Audit each function for "what if called via multicall with attacker-controlled previous step?" ### D...