Flash Loan Attacks: How They Work, Real Examples, and How to Prevent Them

Pseudocode: the borrower side

contract FlashLoanReceiver {
    function startFlashLoan(address asset, uint256 amount) external {
        flashLoanProvider.flashLoan(address(this), asset, amount);
    }

    function onFlashLoan(address asset, uint256 amount, uint256 fee) external {
        // 1. Use the borrowed funds while this transaction is still executing.
        executeStrategy(asset, amount);

        // 2. Repay the loan before the callback finishes.
        IERC20(asset).transfer(msg.sender, amount + fee);
    }
}

executeStrategy() runs before repayment, but both are inside the same atomic transaction. A failed repayment does not leave the provider short—it erases the entire execution as if it never occurred.

The important clarification

The exploit still depends on a pre-existing protocol flaw. If the protocol behaves correctly under arbitrarily large capital, a flash loan alone cannot create an attack. The loan is the amplifier, not the vulnerability.

The vulnerable pattern

function donateToReserves(uint256 amount) external {
    // User gives up part of their collateral position.
    eTokenBalance[msg.sender] -= amount;
    reserves += amount;

    // Missing check:
    // require(isAccountHealthy(msg.sender), "account unhealthy");
}

The actual vulnerability

The dangerous part is not the donation itself. It is allowing collateral to decrease without verifying whether the remaining collateral still covers the outstanding debt. This violated a fundamental lending invariant: a borrower’s collateral must always remain sufficient to secure their debt.

The Exploit Flow, Step by Step

1. Attacker borrowed approximately $30M in DAI using a flash loan from Aave.
2. Deposited the borrowed DAI into Euler, receiving eDAI (collateral tokens).
3. Called Euler’s mint() to synthetically amplify the position—creating far more eDAI and dDAI than the original deposit justified. This produced a large collateral balance and a correspondingly large debt balance.
4. Called donateToReserves() to donate a significant portion of the eDAI collateral into protocol reserves. The collateral balance dropped sharply; the debt balance did not move.
5. Because no health check was ran after the donation, the account was allowed to remain in an undercollateralized state.
6. A second attacker-controlled contract identified the unhealthy account and liquidated it, capturing the liquidation discount as profit.
7. The attacker repaid the Aave flash loan and retained the remaining extracted value.

The flash loan funded the operation and made it scalable. But the protocol failed because donateToReserves() allowed a state transition that broke the core solvency invariant without any validation.

Inverse Finance (June 2022): an LP token oracle built on movable balances

On June 16, 2022, Inverse Finance's Frontier money market lost $5.83 million in DOLA to an oracle manipulation attack; the attacker kept about $1.2 million. Frontier priced the yvCurve-3Crypto LP token from Chainlink prices for each underlying asset, multiplied by the live token balances in Curve's tricrypto pool. Those balances could be moved inside one transaction.

1. Flash-borrowed about 27,000 WBTC (roughly $579 million) from Aave.
2. Deposited 225 WBTC into Curve tricrypto, wrapped the LP tokens in Yearn's yvCurve-3Crypto vault, and posted about 4,906 vault tokens as collateral on Frontier.
3. Swapped the remaining 26,775 WBTC for about 75.4 million USDT in the same pool. The skewed balances lifted the oracle's LP token price from about 979 to 2,831.
4. Borrowed about 10.1 million DOLA against the overvalued collateral.
5. Swapped back, repaid the flash loan, kept the difference, and moved the proceeds through Tornado Cash.

Broken invariant: an LP token's price must not depend on pool balances that can change in the same transaction. Chainlink feeds didn't help, because the weak point was the balance-based LP formula, not the asset prices. It was Inverse's second oracle incident in about ten weeks: an INV price manipulation on April 2, 2022, cost about $15 million. The oracle had also been reviewed by a third-party team before the June attack.

Defense: vector 2 below—TWAPs, external price sources, and fair-value LP pricing that ignores reported pool balances.

Beanstalk (April 2022): governance votes bought for one transaction

On April 17, 2022, an attacker flash-borrowed around $1 billion in assets, deposited them into Beanstalk's governance silo, and gained about 79% of the voting power. Beanstalk's emergencyCommit function let any proposal with a two-thirds supermajority execute immediately. The attacker's proposal sent protocol funds to their own wallet, and the loans were repaid in the same transaction. The protocol lost about $182 million; the attacker kept about $76 million.

Broken invariant: voting power must reflect stake held before the vote, not tokens borrowed for one transaction.

Defense: vector 4 below—snapshot voting power at a past block and a time lock between a vote passing and execution.

Cream Finance (October 2021): a vault share price pushed up by a donation

On October 27, 2021, Cream Finance lost about $130 million. The attacker used flash-loaned funds to mint a large position in Yearn's yUSD vault and posted the shares as collateral on Cream. Cream valued those shares using the vault's live price per share. The attacker then sent underlying tokens straight into the vault, which roughly doubled the share price and the collateral value on paper. They borrowed every asset Cream had available against it.

Broken invariant: collateral value must not depend on a share price anyone can raise by transferring tokens into the vault.

Defense: vector 3 below—price shares against committed snapshots, and treat externally readable share prices as manipulable.

Rari Capital Fuse (April 2022): reentrancy, amplified

On April 30, 2022, several Rari Capital Fuse pools on Ethereum, run by Fei Protocol, lost about $80 million. The borrow function, inherited from a Compound fork, sent ETH to the borrower before updating the borrow record. The attacker's contract re-entered during that transfer and Rari Capital Fuse (April 2022): reentrancy, amplifiedwithdrew the collateral backing the loan. Flash loans supplied the collateral, so the loop ran at full scale across several pools.

Broken invariant: state must be updated before any external call that hands over control.

Defense: vector 5 below.

1. Lending Protocols: Enforce Health Checks After Every Risky State Change

Any operation that can reduce the collateral-to-debt ratio—including collateral withdrawal, donations, fee deductions, or collateral value adjustments—must trigger an account health evaluation before the transaction completes. This check cannot be optional or deferrable.

The Euler exploit is the clearest example of what happens when this rule is violated. The fix is not complicated: add a health check. But skipping it for gas optimization or convenience makes the protocol exploitable.

Rule: every function that touches collateral or debt must end with a solvency assertion, not just the ones that obviously change borrowing capacity.

2. Oracle-Dependent Protocols: Do Not Trust Spot Prices From AMMs

Flash loans can move the price of an asset inside a low-liquidity AMM pool significantly within one transaction. If a protocol uses that spot price as its reference for collateral valuation, liquidation triggers, or interest rate calculations, an attacker can manipulate the price, exploit the downstream protocol behavior, and let the price revert, all atomically.

Defenses include: time-weighted average prices (TWAPs) over multiple blocks, decentralized oracle networks like Chainlink that source prices externally, liquidity depth checks before trusting an AMM price, and maximum deviation thresholds that reject outlier prices.

3. Swap and Vault Logic: Use Slippage Limits and Avoid Mutable Balance Assumptions

Contracts that calculate exchange ratios, vault share prices, or redemption amounts based on current token balances can be manipulated if those balances can be changed atomically inside the same transaction. An attacker can front-load a swap to distort the balance before the target function reads it.

Slippage limits and minimum output checks protect against this at the trade level. Vault contracts should calculate share prices against committed, immutable snapshots rather than live pool balances.

4. Governance Systems: Add Time Delays Between Voting and Execution

Governance protocols that allow immediate execution of passed proposals are vulnerable to flash loan governance attacks. An attacker can borrow a large token supply, acquire enough voting power to pass a proposal in a single block, execute it, and repay the loan—all atomically.

The standard defense is a time lock: require a delay between when a vote passes and when it can be executed. Because flash loans must be repaid within the same transaction, borrowed voting power cannot survive across blocks. A time lock of even a few hours eliminates this attack vector. Snapshot-based voting power, recorded at a block before the proposal, closes it from the other side.

5. All Protocols: Close Reentrancy Paths Before Unlimited Capital Finds Them

Reentrancy is an old bug class, but flash loans change its payoff. A path that leaks a small amount per loop can drain a pool when each loop runs on borrowed millions.

Follow checks-effects-interactions in every function that moves value: validate, update balances and debt, and only then transfer. Use a reentrancy guard shared across functions, not just per function, since Rari's attacker re-entered through a different entry point than the one being called. Treat ETH transfers and token hooks (ERC-777, ERC-721 and ERC-1155 callbacks) as handing control to the attacker.

Why Flash Loan Caps and Fees Don't Stop These Attacks

A common suggestion is to limit flash loan size or raise flash loan fees. That doesn't protect a target protocol. The protocol under attack doesn't control the lender's settings, and an attacker can borrow from Aave, Balancer, Uniswap v3, and other providers in the same transaction. Some exploits also run on ordinary borrowed capital with no flash loan at all.

The only defense that holds is the one this article argues for: design every invariant as if the attacker has unlimited capital for one transaction.

Process-Level Defenses for Protocol Teams

Code-level fixes only work if someone finds the flaw first. Three process controls close the gap:

• Test invariants under unlimited capital before launch. A smart contract audit should model single-transaction, flash-loan-sized scenarios against every solvency, pricing and voting assumption, ideally on a mainnet fork. For high-value code, a crowdsourced audit puts many researchers on the same scope, so one team's blind spots don't become yours.
• Keep researchers looking after launch. Inverse Finance's oracle had passed a third-party review before it was exploited. A continuous bug bounty program pays researchers to find the next invalid state transition before an attacker does.
• Monitor and pause. Alert on oracle deviations, large borrow-and-repay sequences inside one block, and sudden collateral-ratio swings, with a pause guardian that can stop markets within minutes. Protect the keys behind that pause switch as carefully as the code, since operational failures outside the contract caused most of 2025's losses.

General rule for flash loan attack prevention

If a value can be manipulated within one transaction, never treat it as a stable source of truth in the same transaction. This includes prices, balances, voting power, and collateral ratios.

What is a flash loan attack?

A flash loan attack is an exploit funded by an uncollateralized loan that is borrowed and repaid within one transaction. The loan supplies capital; the damage comes from a flaw in the target protocol, such as a manipulable price oracle, a missing health check, or governance without a time lock.

How do you prevent flash loan attacks?

Design every invariant as if the attacker has unlimited capital for one transaction. Use time-weighted or external price feeds, run health checks after every collateral or debt change, price vault shares from snapshots, add time locks and snapshot voting to governance, and close reentrancy paths. Back it with audits, a bug bounty program, and monitoring.

What are the main flash loan risks for DeFi protocols?

Five patterns cover most incidents: price oracle manipulation, governance takeover, vault share-price inflation, missing solvency checks, and reentrancy at scale. Each relies on an assumption that only holds while capital is limited.

Can limiting flash loan size or fees stop these attacks?

No. A target protocol doesn't control lenders' settings, and attackers can combine loans from several providers in one transaction. The fix belongs in the vulnerable protocol's logic.

What are some well-known flash loan attacks?

Beanstalk lost about $182 million in April 2022 to a governance takeover. Cream Finance lost about $130 million in October 2021 to a vault share-price manipulation. Euler Finance lost about $197 million in March 2023 to a missing health check. Inverse Finance lost $5.83 million in June 2022 to LP token oracle manipulation.