What it is
A flash loan lets anyone borrow assets from a lending pool with no upfront collateral, on the condition that the loan is borrowed and fully repaid within a single blockchain transaction. Because a transaction either completes entirely or is rolled back entirely (atomicity), the lender never actually bears default risk: if repayment (principal plus a fee) doesn't happen by the end of the transaction, the entire transaction — including the loan itself — is reverted as if it never occurred.
How it works
- A borrower's smart contract calls a lending pool's flash-loan function, requesting an amount of a given asset.
- The pool transfers the funds to the borrower's contract immediately, within the same transaction.
- Control passes to the borrower's own code, which can now do anything with the borrowed funds: trade across exchanges, repay a debt elsewhere and take out a cheaper one, liquidate a position, or exploit price differences (arbitrage).
- Before the transaction ends, the borrower's contract must transfer back the original amount plus a fee to the lending pool.
- The lending pool checks that its balance has been restored (principal + fee) as the very last step.
- If the check passes, the transaction finalizes and all the intermediate actions become permanent.
- If the check fails — the borrower didn't repay enough — the blockchain reverts every step in the transaction, including the initial loan disbursement, so no funds ever actually left the pool in any lasting sense.
- This means the "risk" to the lender is purely computational (does the code correctly repay?), not credit risk, so no collateral or credit check is required.
Why designers use it
- Enables capital-efficient arbitrage and liquidations without requiring traders to hold large amounts of capital themselves.
- Democratizes access to large-scale trading strategies — anyone with the right code, not just well-capitalized players, can execute them.
- Lets protocols offer self-liquidation or debt-refinancing tools (e.g., swapping collateral types) that would otherwise require the user to have idle capital on hand.
- Generates fee revenue for lending pools from a use case that carries no default risk to the pool.
Failure modes
- Oracle price manipulation: a borrower uses a flash loan to move the price on a thinly-traded market that another protocol relies on for its price feed, then exploits that distorted price elsewhere in the same transaction before repaying the loan — a well-known attack pattern behind numerous DeFi exploits.
- Governance flash-loan attacks: temporarily borrowing enough tokens to pass a malicious governance vote within one transaction, then repaying the loan immediately after, effectively renting voting power for seconds.
- Composability cascades: because flash loans can chain interactions across many protocols in one transaction, a bug in any one integrated contract can be leveraged at nearly unlimited scale.
- Reentrancy interactions: flash loan callbacks are a common vector for reentrancy bugs if a protocol doesn't properly lock state during the callback.
- False sense of security from "no collateral": teams sometimes underestimate flash loans because no capital changes hands lastingly, missing that the same lack of capital requirement is what makes attacks cheap to attempt repeatedly.
What to check before using it
- If your protocol relies on any on-chain price or balance snapshot, use manipulation-resistant oracles (time-weighted averages, external oracle networks) rather than spot reserves that can move within one transaction.
- If governance or voting power is token-weighted, require holding periods, snapshots taken before a proposal is visible, or non-flash-loanable voting checkpoints.
- Audit reentrancy protections specifically around any callback your contract exposes to a flash-loan borrower.
- Model worst-case borrow size (the largest amount in your pool or any pool a borrower could stack) when reasoning about how much value an attacker could move in a single atomic transaction.
- Consider whether your flash-loan fee and pool design create acceptable revenue versus the systemic risk it exposes to other protocols that might integrate with your price feeds or token.