For educational purposes only; not investment advice. Investing may result in loss.
Direct answer
A flash loan is smart-contract liquidity made available for the duration of one atomic transaction. In the classic form, the borrower posts no collateral because the lending contract requires the principal and fee to be returned before that transaction finishes. If the required settlement does not occur, execution reverts and the transaction’s state changes do not persist.
This design lets a contract use temporary capital for an arbitrage, liquidation, collateral swap, or debt refinancing without the operator funding the full principal in advance. It does not create free money: the strategy must cover the loan fee, trading fees, slippage, gas, and any adverse execution or MEV. Some protocol variants can open an ordinary debt position instead of requiring immediate repayment, but that path needs collateral or credit delegation and should not be confused with a collateral-free flash loan.
Flash loans can amplify both useful transactions and attacks. They supply capital; a loss-producing exploit still depends on another weakness, such as a manipulable price input, faulty accounting, unsafe callback, or governance rule.
How it works
- Request: A receiver contract asks a liquidity pool for an asset and amount, such as
10,000,000 USDC, and supplies any parameters needed by its strategy. - Transfer and callback: The pool transfers the asset, then calls the receiver. Every swap, liquidation, repayment, or collateral change occurs through contract calls nested inside the same transaction.
- Strategy execution: The receiver uses the temporary funds. Because external calls can re-enter contracts or produce unexpected prices, implementations need explicit access control, validated inputs, slippage limits, and safe approval handling.
- Settlement check: The receiver authorizes or transfers the amount owed. In a simple Aave-style flow, the pool pulls principal plus premium after the callback; an insufficient balance or allowance causes a revert.
- Atomic result: If every call succeeds, the final state is recorded. If an uncaught error occurs or settlement fails, Solidity’s state-reverting exception undoes changes in the call and its sub-calls. The sender can still lose gas spent on the failed transaction.
Atomicity removes the lender’s intra-transaction credit exposure; it does not guarantee that the borrower’s strategy is profitable, private, or correctly coded. Available liquidity, enabled assets, premiums, callback interfaces, debt-conversion options, and pause controls are protocol-specific and can change through governance.
Example
Suppose a contract borrows 10,000,000 USDC to buy an asset in one pool and sell it in another. Let A be principal, F the flash-loan fee, G gas and execution costs, S slippage and other trading costs, and R the USDC received from the sale. A simplified break-even condition is R >= A + F + G + S.
Assume the two swaps return 10,012,000 USDC, the loan requires 10,009,000 USDC including principal and fee, and gas plus other execution costs equal 2,000 USDC. The simplified profit is 10,012,000 - 10,009,000 - 2,000 = 1,000 USDC.
That apparent margin can disappear before inclusion. Other searchers may copy or outbid the transaction, pool reserves may change, a token may charge an unexpected transfer fee, or the transaction may revert after consuming gas. The contract should enforce a minimum acceptable output and revert when the realized result is below it; a dashboard quote is not executable profit.
Risks
- Strategy and contract risk: A coding error, unsafe approval, malicious token, re-entrancy path, or incorrect callback authorization can lose funds already held by the receiver contract.
- Price, liquidity, and slippage risk: A quoted spread may vanish as reserves move. Thin pools can produce severe price impact, and an oracle based on a manipulable spot market can let temporary capital distort protocol decisions.
- MEV and ordering risk: Public pending transactions can be copied, sandwiched, front-run, or back-run. Private submission reduces some exposure but introduces builder or relay dependencies and does not guarantee inclusion.
- Fee and revert risk: Loan premiums, exchange fees, gas, token transfer fees, and priority fees must all be covered. A reverted trade normally loses gas even though its state changes are undone.
- Protocol and governance risk: Pauses, upgrades, changed premiums, liquidity withdrawals, oracle failures, and failures in any integrated protocol can invalidate an otherwise sound strategy.
- Operational and legal risk: Compromised keys, incorrect addresses, unreliable automation, sanctions, tax, or other jurisdiction-specific rules can create losses or obligations outside the smart-contract calculation.
For protocol reviewers, a flash loan in an incident trace is evidence of temporary financing, not proof of the root cause. Reproduce the state transitions and identify which invariant, price source, permission, or accounting rule allowed value to leave.
Common misconceptions
Myth 1: A flash loan is free capital
It is temporary liquidity with strict settlement conditions. A viable strategy must repay the required amount and still cover every execution cost; otherwise it reverts or loses money.
Myth 2: The borrower can keep the funds until later in the block
The classic loan must settle inside the same transaction call stack, not merely somewhere in the same block. Funds cannot be moved to a wallet and repaid in a later transaction.
Myth 3: Atomic execution means zero downside
Atomicity reverses state changes after an uncaught failure, but it does not refund gas already consumed. It also does not prevent bad pricing, leaked approvals, MEV, or losses in funds the receiver owned before the call.
Myth 4: Every flash loan is an attack
Arbitrage, liquidations, collateral swaps, and debt refinancing are ordinary uses. The exploit is the broken oracle, permission, accounting, governance, or callback assumption; the flash loan may only make enough temporary capital available to exploit it.
Myth 5: A large quoted spread guarantees profit
Profit depends on executable prices and transaction ordering after all fees and slippage. Simulate against the intended block state, set minimum outputs, and treat a failed or outbid transaction as a real cost.
Related topics
Sources
- FlashLoanLogic.sol - Aave DAO (accessed: 2026-08-20)
- Expressions and Control Structures - Solidity (accessed: 2026-08-20)
- DeFi risks and the decentralisation illusion - Bank for International Settlements (accessed: 2026-08-20)