Flash loans are one of those concepts that sound implausible until you understand how they work — and once you do, the attack surface becomes obvious. The confusion usually starts with the word "loan." In traditional finance, loans require collateral, creditworthiness, and time to settle. Flash loans require none of those things. What they require instead is that everything happens atomically: the loan, the activity, and the repayment, all within a single transaction.
This isn't a loophole. It's a deliberate feature of how smart contracts execute. And attacks that exploit it aren't really "flash loan attacks" in the sense that the loan is the problem — the loan is just the instrument. The vulnerability almost always lives somewhere else.
How Flash Loans Actually Work
A flash loan is an uncollateralized loan where the borrowed funds must be repaid before the transaction that issued them completes. If the repayment condition isn't met, the entire transaction reverts — as if it never happened.
This works because of how the Ethereum Virtual Machine handles atomicity. A transaction either completes entirely or fails entirely. There's no "partial execution" that gets written to the blockchain. Flash loan contracts exploit this by structuring the loan as follows: funds are released at the start of the transaction, the borrower does whatever they want with them in between, and a repayment check runs at the end. If the check fails, the EVM rolls everything back.
The practical effect is that anyone can access tens or hundreds of millions of dollars in capital for the duration of a single transaction — provided they return it. Protocols like Aave, dYdX, and Uniswap V3 offer flash loans as a legitimate feature used for arbitrage, collateral swaps, and self-liquidation.
How the Attack Works
Flash loans don't create vulnerabilities. They amplify capital, making attacks that would otherwise require enormous upfront funds suddenly executable by anyone with gas fees.
The most common attack pattern targets price oracles. Here's how it typically runs:
- An attacker borrows a large sum — say $50 million in ETH — via flash loan.
- They dump it into a low-liquidity trading pool, crashing the ETH price in that pool.
- A protocol elsewhere in the same transaction is using that pool's spot price as its oracle — to calculate collateral values, liquidation thresholds, or exchange rates.
- The attacker exploits the now-distorted price signal: borrowing against inflated collateral, liquidating healthy positions at wrong prices, or extracting underpriced assets.
- They unwind, repay the flash loan plus fee, and pocket the difference.
The bZx attacks in February 2020 were among the first high-profile cases — two separate exploits in a single week, each built around this oracle manipulation pattern. The Harvest Finance attack in October 2020 used the same basic structure, extracting roughly $34 million by manipulating Curve pool prices then draining the protocol's USDC and USDT vaults.
Beanstalk in April 2022 demonstrated a different variant: rather than manipulating prices, the attacker used a flash loan to temporarily acquire enough governance tokens to pass a malicious proposal in a single transaction — $182 million extracted before any human could intervene. That attack exploited the same flash loan logic, just applied to governance rather than price feeds.
The through-line across all of these isn't the flash loan itself. It's that the target protocol was designed with an assumption that capital access takes time and that markets self-correct. Flash loans eliminate both assumptions.
Where the Vulnerability Actually Lives
There's a consistent structural weakness underlying most flash loan attacks: spot price oracles.
When a protocol reads price data from a decentralized exchange's instantaneous state, it's creating an input that can be moved in a single transaction. The protocol can't distinguish between a "real" price and a price temporarily manipulated by $100 million in borrowed capital that will be gone in 13 seconds.
Governance systems that allow immediate voting — no timelock, no holding period requirement — have the same problem: voting power that can be borrowed, exercised, and returned in one block is effectively untethered from meaningful ownership.
These weren't design failures in the ordinary sense. They were rational choices in early DeFi. Most teams genuinely didn't anticipate atomic capital access at this scale when they first built their oracle and governance logic.
What's Changed
The main mitigation is time-weighted average prices (TWAP). Instead of reading a pool's current spot price, TWAP oracles average the price across multiple blocks — often several minutes of activity. Manipulating a TWAP oracle would require sustaining an artificial price for dozens of consecutive blocks, which is prohibitively expensive and highly visible. Uniswap V3's TWAP oracles are now widely integrated as a result.
Chainlink and other external oracle networks provide price feeds sourced from aggregated exchange data, entirely bypassing DEX pool spot prices. For protocols handling significant TVL, relying on an external oracle rather than an on-chain pool is increasingly standard practice.
Governance attacks are mitigated by timelocks and voting-power requirements that don't recognize recently acquired tokens. Both are now near-baseline expectations in serious DAO governance. Auditors specifically test for flash-loan sensitivity — Trail of Bits, OpenZeppelin, and other firms include explicit oracle manipulation and governance attack simulation in scope for major protocol audits.
Confirmation and Invalidation
Confirmation that defenses are working: Declining losses from oracle-manipulation attacks relative to total DeFi TVL; major protocols with multi-billion TVL have not suffered flash loan oracle attacks after adopting TWAP and external oracle design.
What would invalidate this: Novel oracle manipulation techniques that work on TWAP (theoretically possible with sustained multi-block manipulation at scale but increasingly impractical); new attack patterns targeting protocol logic not currently in audit scope; continued losses at protocols that treat auditing alone as sufficient.
Timing
Now — active risk on any protocol still using single-block spot prices as its primary oracle. New protocol launches are lower risk if they've inherited current-standard oracle architecture from the start.
Next — TWAP and external oracles becoming non-negotiable baseline; governance attacks largely addressed at major protocols through timelocks and holding period requirements.
Later — intent-based architectures and cross-chain protocols introduce timing and pricing assumptions that could be flash-loan-sensitive in ways not yet fully characterized.
Boundary
This is a mechanism explanation of how flash loan attacks work and where the vulnerability actually lives. It doesn't constitute a protocol security assessment, an audit, or a safety guarantee for any specific DeFi application. The oracle and governance design choices described here reduce flash loan attack surface — they don't eliminate all protocol risk.
Not financial advice. The static explanation is here.
