flash-loan-attacks

name	flash-loan-attacks
description	Flash loan attack vectors and defenses for DeFi protocols. Use when designing governance, oracles, AMMs, or any system where large capital can be borrowed atomically. Covers governance manipulation, oracle attacks, price impact, and liquidity pool exploits.

Flash Loan Attacks

What Makes Flash Loans Dangerous

Flash loans allow borrowing unlimited capital with zero collateral, provided it's returned within the same transaction. This means any attack that's profitable with enough capital becomes free to execute.

Attack Pattern: Governance Manipulation

Borrow tokens → acquire voting power → pass malicious proposal → profit.

1. Flash borrow 10M governance tokens from Aave/dYdX
2. Delegate voting power to attacker
3. Create + vote on malicious proposal (if single-block voting)
4. Proposal executes: drain treasury / change parameters
5. Return flash loan

Defense: Snapshot-Based Voting

contract SafeGovernor {
    // Voting power is snapshotted at proposal creation block
    // Flash-borrowed tokens have no voting power for existing proposals
    function propose(...) external returns (uint256 proposalId) {
        uint256 snapshot = block.number; // or block.number - 1
        proposals[proposalId].snapshotBlock = snapshot;
        // ...
    }

    function castVote(uint256 proposalId, uint8 support) external {
        uint256 snapshot = proposals[proposalId].snapshotBlock;
        // Uses historical balance, not current
        uint256 weight = token.getPastVotes(msg.sender, snapshot);
        // ...
    }
}

Additional defenses:

• Voting delay: require N blocks between proposal creation and voting start
• Time-weighted voting: voting power based on average balance over time
• Proposal threshold: minimum token holding period to create proposals

Attack Pattern: Oracle Manipulation

Borrow tokens → manipulate spot price → exploit protocol using stale/spot price.

1. Flash borrow large amount of token A
2. Swap token A → token B on a DEX, crashing A's spot price
3. Protocol reads spot price (or manipulable TWAP)
4. Borrow against token B using deflated A price as collateral
5. Swap back, restoring price
6. Return flash loan, keep profit

Defense: TWAP Oracles

// Use Uniswap V3 TWAP (multi-block) instead of spot price
function getTWAP(address pool, uint32 twapWindow) internal view returns (uint256) {
    uint32[] memory secondsAgos = new uint32[](2);
    secondsAgos[0] = twapWindow; // e.g., 1800 for 30 minutes
    secondsAgos[1] = 0;

    (int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgos);

    int56 tickDelta = tickCumulatives[1] - tickCumulatives[0];
    int24 averageTick = int24(tickDelta / int56(int32(twapWindow)));

    return OracleLibrary.getQuoteAtTick(averageTick, baseAmount, baseToken, quoteToken);
}

Better: use Chainlink oracles with staleness checks (see oracle-manipulation skill).

Attack Pattern: Liquidity Pool Manipulation

1. Flash borrow large amount of asset
2. Deposit into lending pool → inflate share price or available liquidity
3. Another protocol reads inflated state
4. Exploit the inflated reading (over-borrow, incorrect liquidation)
5. Withdraw from lending pool
6. Return flash loan

Defense: Multi-Block Delay

mapping(address => uint256) public lastDepositBlock;

function deposit(uint256 amount) external {
    lastDepositBlock[msg.sender] = block.number;
    // ...
}

function borrow(uint256 amount) external {
    // Cannot deposit and borrow in the same block
    if (lastDepositBlock[msg.sender] == block.number) {
        revert SameBlockBorrow();
    }
    // ...
}

Attack Pattern: Price Impact Sandwich

1. Flash borrow tokens
2. Large swap moves price significantly
3. Target protocol executes at manipulated price
4. Swap back at a profit
5. Return flash loan

Defense: Slippage Protection + Deadlines

function swap(
    address tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 amountOutMin,   // slippage protection
    uint256 deadline         // expiration
) external {
    if (block.timestamp > deadline) revert Expired();

    uint256 amountOut = _executeSwap(tokenIn, tokenOut, amountIn);

    if (amountOut < amountOutMin) revert SlippageExceeded(amountOut, amountOutMin);

    // ...
}

Flash Loan Detection

You cannot reliably detect flash loans, but you can detect same-block operations.

// Track last interaction block per user
mapping(address => uint256) private _lastBlock;

modifier noSameBlockAction() {
    if (_lastBlock[msg.sender] == block.number) revert SameBlockAction();
    _lastBlock[msg.sender] = block.number;
    _;
}

This prevents same-block deposit+borrow, deposit+withdraw, etc.

Defense Summary

Attack Vector	Defense
Governance vote manipulation	Snapshot-based voting, voting delay
Spot price manipulation	TWAP oracles, Chainlink, multi-source
Liquidity inflation	Multi-block delay, deposit-borrow separation
Price impact sandwich	Slippage protection, deadline parameters
Share price manipulation	Virtual shares/assets (ERC-4626 inflation defense)

Flash Loan Defense Checklist

• No reliance on spot prices for critical calculations
• Governance uses snapshot-based voting with delay
• Oracles use TWAP or Chainlink (not spot prices)
• Deposit and borrow separated by at least 1 block
• Slippage protection on all swap operations
• Deadline parameters on time-sensitive operations
• Share price calculations resistant to first-depositor attacks
• Consider: can an attacker profit by temporarily moving any onchain state?