Flash loan attacks: how they work, what they cost, how to stop them

A flash loan attack is an exploit whose capital is borrowed and repaid inside the same transaction. The loan is not the flaw. It removes the barrier that used to shelter protocols with an economic weakness, the attacker’s need for money: anything that would pay with a hundred million dollars held for one transaction is open to anyone who can write the contract.

This analysis covers what flash loans cost, an attack computed step by step on a model pool and lending market, the inequality that decides whether it pays, the flaws it funds, four public incidents, and detection and review. Oracle designs are compared in our analysis of oracle designs and are not repeated here.

What a flash loan is

A flash loan is an uncollateralised loan that must be repaid, with its fee, before the transaction that took it ends. The lender sends the funds, calls the borrower’s contract, then collects repayment; if that fails, the whole transaction reverts, loan included. ERC-3156 standardises the pattern with an onFlashLoan callback.

1// Simplified, illustrative. Not production code.2// ERC-3156-style lender: lend, call back, collect, or revert everything.3bytes32 constant CALLBACK_SUCCESS = keccak256("ERC3156FlashBorrower.onFlashLoan");4 5function flashLoan(IERC3156FlashBorrower receiver, address token, uint256 amount, bytes calldata data)6    external7    returns (bool)8{9    uint256 fee = flashFee(token, amount);10    IERC20(token).safeTransfer(address(receiver), amount);                          // 1. lend11    bytes32 ok = receiver.onFlashLoan(msg.sender, token, amount, fee, data);         // 2. borrower logic runs here12    if (ok != CALLBACK_SUCCESS) revert CallbackFailed();13    IERC20(token).safeTransferFrom(address(receiver), address(this), amount + fee); // 3. collect, or revert all14    return true;15}

Atomicity makes the loan riskless on both sides: the lender cannot end the transaction unpaid, and a borrower whose plan fails loses only the gas of a reverted transaction. The capital costs the fee alone, so borrowing 2 million of a stablecoin for one transaction costs between nothing and about 6,000.

Anatomy of an attack

The threat model is an unprivileged attacker that deploys a contract, borrows from any flash lender and orders its own calls within one transaction, but cannot hold a price across blocks for free. Almost every attack has five phases.

1. Borrow the capital; execution continues in the attacker’s callback.
2. Manipulate a value another protocol reads: a spot price, an exchange rate, a balance, a vote count.
3. Exploit the dependent protocol while the value is wrong: borrow, mint, redeem, vote or liquidate.
4. Unwind the manipulation to recover most of the capital, for example by trading back.
5. Repay principal and fee; the remainder is profit.

The vulnerability sits in the third phase: the dependent protocol accepted a value one transaction could change and restore.

A worked example

Consider a model with the following parameters. Token X is a volatile asset with a fair price of 2,000; Y is a stablecoin worth 1. Values are in Y.

• Pool. Constant product: x₀ = 2,000 X and y₀ = 4,000,000 Y, so k = 8 × 10⁹ and the spot price y / x is 2,000. The 0.30% fee on each swap’s input is paid to liquidity providers outside the reserves, so x·y = k holds exactly.
• Lending market. Values X at the pool’s spot price and lends up to 75% of that value, at most 1,350,000 Y in total against X.
• Attacker. Holds 400 X bought at the fair price (800,000 Y), to be abandoned as collateral; pays a 0.05% flash premium and an assumed 100 Y of gas; aims to multiply the spot price by m = 2.25 (√m = 1.5).

Since the spot price is y / x = y² / k, multiplying it by m means leaving y₁ = y₀ × √m and x₁ = k / y₁. Selling Δx back, net of fee, moves the X reserve to x₂ = x₁ + Δx and pays out y₁ − k / x₂. Values are computed exactly and rounded for display.

The cash reconciles: 1,995,996.00 + 1,350,000 = 3,345,996.00 Y, less 2,007,021.06 repaid, 800,000 of abandoned collateral and 100 of gas, leaves 538,874.93. The market’s shortfall of 550,000 is split between the attacker (538,974.93 before gas), the liquidity providers (10,022.06) and the flash lender (1,003.01).

The round trip costs exactly its two fees: 6,018.05 Y in, and 2.00 X out, for which the pool would have paid 4,004.00 Y. Uniswap v2 keeps fees in the reserves, where the attacker recovers part of them, so there the round trip would cost about 8,012 Y. Nor need the 400 X be the attacker’s own: bought on a deep venue inside the transaction, they add only 400 Y of premium.

Deeper liquidity, a TWAP, an external feed

Change one parameter at a time. Every amount in a constant-product round trip scales with the reserves, so ten times the depth means ten times the fees and premium, for the same extracted value.

Depth alone is a weak defence for a spot price. Ten times the liquidity cuts the profit at the same move by less than a fifth, and a bigger move then pays better, because the value extracted per unit of collateral grows with the price move while the swap needed grows with its square root. The attack fails at every move only once the pool is about 50 times deeper: roughly 200 million Y per side, or 150 times the borrow cap.

A price that one transaction cannot move removes the extractable value. Under a TWAP or an external feed the 400 X are still worth 2,000 each, 600,000 of borrowing is an ordinary loan, and the swaps simply cost 11,125. Moving such a price means holding it across blocks, which a flash loan cannot fund; that cost is the subject of our primer on the cost of manipulation.

The profitability inequality

A flash-funded attack is profitable when

V > C + F + G

where V is the value extracted while the protocol is misled, C the cost of moving and restoring what it reads (here the round-trip fees), F the flash-loan fee and G gas. In the base case, V is about 49 times C + F + G. The loan supplies only F; its real effect is that the right-hand side carries no cost of capital and no market risk.

One caveat: a deviation bound stops borrowing against inflated collateral, but a price pushed down by almost d can still liquidate honest positions within d of their threshold, and the liquidation bonus becomes V.

The loan is rarely the vulnerability

Every term except F belongs to the protocol under attack. “Flash loan attack” names the funding, not the flaw, and each underlying flaw has a defence that works whether or not a loan is involved.

Donation-sensitive accounting is the weakness behind vault inflation attacks; borrowed voting power is examined in our analysis of governance attacks. For the price class, the fix belongs in the market.

1 // Simplified, illustrative. Not production code.2 function collateralPrice() public view returns (uint256) {3-    (uint112 rx, uint112 ry, ) = pool.getReserves();4-    return uint256(ry) * 1e18 / rx;                 // spot: any trade in this transaction moves it5+    uint256 p = _feedPrice();                       // external feed, sign and age checked6+    uint256 ref = _twap(TWAP_WINDOW);                // a reference one transaction cannot move7+    if (_deviationBps(p, ref) > MAX_DEVIATION_BPS) revert PriceDeviation();8+    return p;9 }10 11 function borrow(uint256 amount) external {12     uint256 value = collateral[msg.sender] * collateralPrice() / 1e18;13     require(debt[msg.sender] + amount <= value * LTV_BPS / 10_000, "LTV");14+    require(totalDebt + amount <= BORROW_CAP, "cap"); // bounds what any mispricing can extract15     debt[msg.sender] += amount;16+    totalDebt += amount;17     stable.safeTransfer(msg.sender, amount);18 }

Four public incidents

Each incident below was funded with flash loans; in each, the flaw lay elsewhere. Figures are those of the cited sources, at prices of the time.

A first bZx attack, three days earlier, used a 10,000 ETH flash loan; Qin et al. note that it “could have been avoided if bZx checked the negative equity and reverted the transaction”, a check that existed but was not invoked. In Euler’s case, CertiK’s analysis of one transaction shows a 30 million DAI flash loan from Aave funding the position that was then donated into insolvency.

Detection signals

An attack of this shape leaves a recognisable trace in its own transaction. The strongest signal combines:

• a call to a known flash lender followed by a callback, large relative to the pool traded next;
• two opposite swaps in one pool, so that its spot price leaves its recent range and returns;
• between them, a borrow, mint, redeem, vote or liquidation in a protocol that reads that pool;
• an account that ends the transaction with debt above its collateral valued at a reference price.

Arbitrage and liquidation bots produce the first two signals all day; the last two mark an attack. A monitor that decodes each transaction touching the protocol, measures how far each price it reads moves within it, and compares borrowing prices with a reference feed can flag the combination in the same block. That transaction is final, but attacks repeat: Harvest’s post-mortem records 17 transactions against one vault within four minutes and 13 against another within three, so a pause after the first few would have limited the loss. Earlier signals are covered in our analysis of suspicious on-chain behaviour, and Security Monitoring follows recorded incidents through these stages.

Review checklist and invariant tests

Treat flash loans as a given, and ask what one transaction with unlimited capital could do to each value the protocol trusts.

• List every price, rate, balance and vote weight the protocol reads; mark those one transaction can change.
• For each, write the inequality at current liquidity, caps and loan-to-value, with capital free.
• Check that every path that reduces collateral or adds debt, donations included, ends with a solvency check.
• Check that votes come from a checkpoint before the proposal, and that nothing executes in the voting transaction.
• Check external calls made mid-update, including reads of this protocol’s views by others.

Each item maps to an invariant: the price used does not move within a transaction when reserves do; no account ends a transaction undercollateralised at the reference price; a donation raises nobody’s redeemable value or borrowing power; counted votes never exceed the checkpointed supply. The first is a short fuzz test.

1// Simplified, illustrative. Not production code.2// Foundry fuzz test against the model pool and market described in this article.3contract PriceIndependenceTest is Test {4    ModelPool pool;5    ModelMarket market;6    address alice = makeAddr("alice");7 8    function setUp() public {9        // deploy the pool (2,000 X and 4,000,000 Y) and the market; alice deposits 400 X10    }11 12    function testFuzz_tradeDoesNotMoveBorrowingPower(uint256 yIn) public {13        yIn = bound(yIn, 1e18, 100_000_000e18);14        uint256 before = market.maxBorrow(alice);15 16        deal(address(pool.tokenY()), address(this), yIn);17        pool.tokenY().approve(address(pool), yIn);18        pool.swapExactYForX(yIn, address(this));     // moves the spot price inside this transaction19 20        assertEq(market.maxBorrow(alice), before, "borrowing power follows the spot price");21    }22}

Against the spot-price market, any swap changes the result, so the test fails on its first input; against the fixed market it holds for every swap size. The solvency invariant needs a stateful handler that swaps, deposits, borrows and donates in any order, and catches combinations nobody wrote down.

Conclusions

A flash loan pays for an attack; it does not break a protocol. Free capital for one transaction turns any value that can be moved and restored within a transaction into a liability, and any safety margin that assumed attackers need money into none.

In the model, the attacker’s costs were 2% of what it extracted, and ten times the liquidity still left a large profit; the attack stopped paying only with a pool about 50 times deeper, or once the market stopped reading a price one transaction could move. The defences that matter change the protocol: what it reads, how much it lets anyone take, and when it counts a balance or a vote.

Recommendations