flash-loan-attacks

# Flash-loan attack detection ## When this applies - AMMs, lending markets, ERC-4626 vaults, staking with voting power - Governance using `getVotes` or `balanceOf` at the moment of vote-casting - Liquidations / collateral health checks that use spot price - Reward distributions proportional to balance held at a snapshot - Any protocol whose state depends on its own `address(this).balance` or token balance ## Detection patterns ### Governance flash-loan voting (CRITICAL) ```solidity function castVote(uint256 propId) external { uint256 power = token.balanceOf(msg.sender); // ← spot balance proposals[propId].votes += power; } ``` Fix: snapshot at `proposalCreated` via `ERC20Votes` checkpoints + sufficient voting delay. ### Vault donation / inflation attack (CRITICAL on ERC-4626) First depositor mints 1 share, attacker sends huge `transfer` directly to vault → share price inflates → subsequent depositor's small deposit rounds to 0 shares. ```solidity // vulnerable mint math shares = assets * totalSupply / totalAssets; // ← totalAssets manipulable by direct transfer ``` Fix: virtual shares + virtual assets (OpenZeppelin v4.9+ ERC4626), or dead-shares pattern, or minimum first deposit. ### Spot-price collateral check (CRITICAL) ```solidity function isHealthy(address user) public view returns (bool) { uint256 collateralValue = oracle.spotPrice() * collat[user]; // ← spot return collateralValue >= debt[user] * MIN_RATIO; } ``` Flash-loan moves spot → tempo...