Aave
Aave flash loans fund operations that settle within one transaction
Aave flash loans provide temporary liquidity without upfront collateral when repayment completes within the same blockchain transaction. For repayment-only settlement, the receiver must hold the borrowed assets plus any applicable premium and authorize the Pool to collect them before execution ends. Failed settlement reverts the transaction. Aave V3 also supports a separately selected debt-opening path, which requires sufficient collateral and any necessary credit delegation.
The distinction matters when choosing between temporary funding and an ongoing borrowing obligation. Contract details here concern Aave V3's EVM Pool interfaces. Their repayment rules, receiver requirements, and settlement modes determine what an operation can leave behind.
Supplied liquidity and collateral impose different limits
A repayment-only flash loan draws on available reserve liquidity without using the caller's collateral to establish borrowing capacity. The reserve must support flash loans and satisfy its operating restrictions. Available liquidity limits the amount the Pool can actually transfer; the protocol's total supplied balance isn't a promise that every deposited token is immediately available.
Choosing to open debt changes the collateral requirement. The account taking that debt must support the resulting obligation. When someone borrows against another account's collateral, credit delegation supplies the necessary authorization. Delegation doesn't remove collateral requirements or make another account's borrowing capacity unlimited.
The receiver needs a valid callback and repayment allowance
A receiver is a smart contract implementing the callback the selected flash-loan function expects, including the parameters needed to handle borrowed assets and premiums. For the single-asset interface, the Pool calls executeOperation() with the asset, amount, premium, initiator, and additional operation data.
For each asset selected for immediate repayment, the receiver must finish its work with enough of that token to cover principal and premium. It also needs to authorize the Pool to collect that amount. A sufficient balance without sufficient allowance fails, and allowance without a sufficient balance fails too. The settlement amount belongs in the receiver's calculation before its trading or position-management logic runs.
A repayment-only operation from transfer to settlement
Suppose you want your receiver to complete an operation without opening ongoing debt and revert its contract changes if settlement fails. Before submission, the receiver must be ready to execute its callback and authorize repayment before collection. The selected reserve also needs sufficient available liquidity. That liquidity is a changing condition; settlement within the transaction is the governing rule.
| Execution stage | Condition for completion |
|---|---|
| The Pool transfers the requested asset | The reserve must permit the operation and provide the requested liquidity. |
| The receiver executes its callback | The callback must complete successfully and prepare sufficient repayment funds and allowance. |
| The Pool collects repayment | The receiver must cover principal plus the applicable premium before the transaction completes. |
With repayment-only settlement selected, the expected outcome is a completed flash loan without a new borrowing obligation from that loan. Compare the confirmed receipt and flash-loan event with the account's resulting debt balance. A successful callback alone doesn't establish that the later collection succeeded.
If the transaction reverts, its contract changes don't persist, although execution gas remains payable. Approvals confirmed in earlier transactions remain separate. Successful execution commits the operation's changes; it doesn't create a later option to undo them.
A debt-opening mode would produce a different account record, including a continuing obligation. It therefore doesn't satisfy this particular requirement, even when its transaction succeeds.
Single-asset and multiple-reserve calls have different settlement choices
The V3 flashLoanSimple() function handles one reserve and requires repayment, while flashLoan() supports multiple reserves and additional settlement choices. The simpler interface avoids the extra machinery needed for multiple assets and debt selection.
With flashLoan(), repayment mode is selected for each asset. Mode 0 requires immediate repayment; the supported variable-debt path uses mode 2 and must pass borrowing checks. One call can therefore repay some assets and open debt for others. Insufficient repayment funds don't automatically convert a repayment-only request into a loan.
The premium differs from ongoing borrowing interest
The flash-loan premium is a charge associated with the borrowed amount, rather than interest accumulating over a holding period. Its configured value can change. Aave V3 passes the applicable premium to the receiver's callback. The receiver uses that amount when preparing repayment, avoiding assumptions based on an old advertised percentage.
Network charges and any exchange costs remain separate. Assets settled by opening variable debt incur ongoing borrowing interest rather than a flash-loan premium. Comparing that path with immediate repayment requires recognizing the continuing obligation, rather than treating both as temporary access to funds.
Why can a profitable quote still lose money?
A quoted trading surplus can disappear when execution prices change, transaction ordering changes, or the operation's costs exceed what remains after repayment. Arbitrage competes with other transactions seeking the same price difference. A quote describes an available calculation, not a reserved opportunity.
Minimum-output conditions can stop a swap from accepting less than the contract permits. They don't reserve liquidity or prevent another transaction from changing the market first. Increasing the borrowed amount can also worsen execution because the trade itself affects available prices.
A reverted attempt still consumes gas. Even a successful transaction can lose money overall if its net proceeds after repayment are worth less than execution costs. When measuring the outcome, compare costs and proceeds in consistent units, and avoid deducting exchange fees twice if the output quote already includes them.
Position changes use temporary liquidity differently from arbitrage
Collateral swaps and repayment using collateral employ flash liquidity to coordinate changes to an existing position. Their intended outcome is a different collateral or debt balance. Arbitrage instead seeks a trading surplus, while liquidation funding supplies assets needed to repay eligible debt and obtain collateral under the liquidation rules.
Aave's V3 swap adapters support operations involving supplied collateral, debt repayment, and exchanges. Those operations still require the relevant permissions and an executable exchange route. A completed flash loan doesn't establish that every position change was desirable: the resulting collateral and debt balances determine the remaining exposure. Lower borrowing interest alone doesn't describe that full change.
Atomic execution ends at the transaction boundary
Atomic execution means the enclosing transaction either commits its contract changes or reverts them when an uncaught failure reaches that boundary. It doesn't provide time between borrowing and repayment for someone to inspect a trade and approve the next step manually.
External actions requiring a later transaction cannot supply funds needed before the original transaction finishes. This excludes a repayment plan dependent on a later exchange withdrawal or asynchronous bridge delivery. A successful transaction also differs from finality: the chain's confirmation rules govern when its inclusion becomes sufficiently settled.
Reserve restrictions and receiver logic determine the remaining failure cases
An active lending reserve doesn't automatically permit flash loans: the implementation checks flash-loan permission separately, and a paused reserve blocks the operation. A request can therefore fail before the receiver gets any funds.
For a repayment-only call, ordinary borrowing capacity isn't the same limit as available flash liquidity. If the selected call opens debt, borrowing restrictions become relevant as well. The settlement choice determines which additional conditions apply.
Receiver code must also constrain who may initiate its operations and which callbacks it accepts. Otherwise, funds left in the receiver can be exposed to unwanted operations or premium payments.
The Pool enforces settlement, not the owner's intended profit or recipient. A receiver using existing funds to cover a trading shortfall can repay successfully. Whether that outcome is acceptable depends on the balance and authorization conditions the receiver actually enforces.
Questions people ask about Aave flash loans
Can a normal wallet initiate an Aave flash loan?
A normal wallet can initiate the Pool call, but the borrowed funds must go to a compatible receiver contract. The wallet doesn't replace the callback implementation. An interface may prepare the transaction, while the receiver handles the operations and settlement requirements.
Does repayment in another transaction within the same block count?
Repayment must complete inside the original flash-loan transaction. A second transaction in the same block is too late for repayment-only settlement. The block groups transactions, but it doesn't combine their execution into one shared borrowing and repayment operation.
Must the receiver repay the exact token it borrowed?
Repayment-only settlement requires the borrowed asset plus its applicable premium. Holding a different token with an equivalent quoted value doesn't satisfy collection. Any required exchange must finish before settlement and leave enough of the correct token in the receiver.
What happens if executeOperation returns false?
The Pool rejects a callback returning false and reverts the flash-loan transaction. Merely receiving the funds or completing an intermediate trade doesn't satisfy that check. Returning true is also insufficient on its own: the subsequent repayment or authorized debt settlement must succeed.
Who qualifies for the V3 flash-loan fee waiver?
The V3 fee waiver applies to approved flash borrowers using flashLoan through the protocol's access-control mechanism. It isn't an automatic benefit of holding a token or having supplied collateral. The flashLoanSimple interface doesn't apply that waiver.
Are leftover funds automatically sent to the initiating wallet?
The Pool's repayment collection doesn't define a payout of leftover funds to the initiating wallet. The receiver's code determines where any remaining assets stay or go. A transaction can repay successfully while leaving its surplus in the receiver rather than transferring it to the initiator.