What Is a Flash Loan?

In brief

A flash loan rents temporary liquidity plus transaction atomicity. The borrower contract can route the assets through exchanges, lending markets, liquidations, or other contracts before settling. All intermediate calls may be complex, but the lender checks the result before allowing the enclosing transaction to succeed.

The common rule is “repay in the same transaction or revert.” Aave v3 has an important qualification: its broader flashLoan() path may convert an amount into a permitted collateral-backed or credit-delegated debt position instead of immediately repaying it. flashLoanSimple() does not offer that debt option. Fees, enabled reserves, available liquidity, and governance-set parameters are protocol-specific and can change.

How the atomic transaction works

A simplified EVM flow is:

1. A borrower contract asks a pool for one or more assets.
2. The pool transfers the assets and calls the borrower’s callback.
3. The borrower executes its programmed sequence of swaps or other calls.
4. The pool verifies repayment and fee, or another settlement mode the protocol explicitly permits.
5. If the final condition is not met, the call reverts; that reversion unwinds the state changes made by the enclosing transaction.

“Unwinds” does not mean the attempt was costless. A submitted transaction can still consume gas even when execution reverts. It also does not mean every external system is reversible: an on-chain transaction cannot undo an off-chain message or action merely because contract state reverted.

No credit check is needed for the ordinary repay-or-revert path because the lender does not end the successful transaction with an unsecured receivable. The borrower nevertheless needs code, a viable route, enough liquidity, and enough value at the end to cover fees and gas.

Legitimate uses

Flash liquidity can reduce the amount of inventory a developer must keep idle:

• Arbitrage: buy where an asset is cheaper and sell where it is dearer, provided the complete route clears after price impact, fees, gas, and competition.
• Liquidation: repay an undercollateralized borrower, receive discounted collateral, sell enough collateral, and settle the flash loan in one transaction.
• Collateral or debt swaps: change the asset backing or comprising a lending position without separately funding every intermediate step.
• Liquidity management: move a position between supported markets or complete another multi-contract operation atomically.

These uses do not guarantee profit. Searchers compete for opportunities, transactions can be copied or reordered, prices move as the transaction trades, and a route that looked profitable in simulation can revert or lose money when included.

Why “flash-loan attack” is imprecise

A flash loan supplies temporary capital; it does not itself create a bad oracle, broken accounting rule, or unsafe governance design. An exploit succeeds when another system accepts a state that can be cheaply distorted or fails to constrain a call sequence. Calling the financing primitive the vulnerability can hide the control that actually failed.

Examples of underlying weaknesses include:

• valuing collateral from one thin pool’s manipulable spot price;
• calculating shares, rewards, or exchange rates from inconsistent state;
• allowing reentrancy or an unexpected cross-contract call order;
• measuring voting power from a fleeting balance without an appropriate snapshot, delay, or other policy;
• trusting a token or callback with behavior the protocol did not model.

Academic and industry risk work treats flash liquidity as an amplifier of composability and oracle risk. Defenses belong in the affected protocol: robust price design, manipulation-cost analysis, transaction and block delays where appropriate, invariant checks, access controls, and testing of adversarial call sequences. Blocking one lender is generally not a complete defense because equivalent temporary capital may come from another venue or from an attacker’s own funds.

Flash loans versus Uniswap v2 flash swaps

Uniswap v2 sends output tokens before enforcing that enough input has arrived. When the recipient supplies non-empty callback data, it can use those tokens elsewhere and return the required value before the pair finishes its checks. If the pair is not made whole under its invariant and fee rules, the transaction reverts.

That is a flash swap, not an Aave loan. The shared idea is atomic access to liquidity. The source and settlement rule differ: a Uniswap v2 pair exposes its AMM reserves through swap, while Aave exposes enabled lending-pool reserves through flash-loan functions.

Practical limits and risks

• The whole repay-or-revert strategy must fit within one transaction and the execution environment’s limits.
• Available pool reserves cap the amount.
• Borrow fees, swap fees, price impact, gas, and MEV competition can erase the expected margin.
• Tokens with unusual transfer behavior can break assumptions.
• A bug in the receiver contract can lose any funds it already holds; Aave specifically warns against leaving funds permanently on a receiver base contract.
• Simulating a transaction helps but cannot guarantee the same state or ordering at inclusion.
• Protocol parameters and supported assets differ by deployment and may change through governance.

For readers, the useful distinction is simple: a flash loan is same-transaction financial plumbing. Whether the surrounding operation is a liquidation, an arbitrage, or an exploit depends on what the borrower does and which other protocol assumptions it exercises.