Morpho Blue flash loans require the caller to approve repayment

The contract balance and the approved spender

The repayment allowance belongs to a specific token, owner, and spender. Each address must match the pending flash-loan execution.

The balance owner

An ERC-20 balance belongs to an address. During a Blue flash loan, the recipient is the contract that invokes flashLoan. Its callback executes with the borrowed tokens available at that address. Blue collects repayment from the contract that called flashLoan. Funding an external wallet does not increase that contract's balance. If callback operations move tokens elsewhere, the original caller still needs the repayment amount when control returns. Allowance authorizes spending; it cannot supply missing tokens.

The approved spender

The calling contract grants allowance on the borrowed token to the configured Blue contract. Approving a router or another contract grants a different permission. An approval from your wallet covers that wallet's tokens, even if your wallet started the transaction. Existing allowance can satisfy the requirement if it remains sufficient at the repayment pull.

What happens after Blue transfers the borrowed tokens?

Blue calls onMorphoFlashLoan(assets, data) on the same contract that received the tokens, then attempts repayment after that callback returns. The callback runs inside the original execution; there is no later repayment transaction.

Callback inputs

The callback receives the requested amount and arbitrary bytes that the calling contract supplied. The token address is an input to flashLoan, but not a separate callback argument. The implementation therefore needs a reliable association between its callback data and the selected token. It can retain that address in contract state or encode it in the callback data.

Return to the repayment pull

Callback logic can call other contracts or combine lending operations while the temporary funds remain available. Before returning, it must leave enough of the borrowed token and keep the required allowance in place. An approval can exist before the loan or be established during the callback; repayment depends on its final usable value.

A repayment failure reverts the flash-loan call and its nested operations. An uncaught failure also reverts the enclosing transaction.

Sending tokens back and granting repayment permission

A direct token transfer to Blue does not replace the approval that the repayment pull uses. After a successful callback, the core function attempts transferFrom regardless of any earlier token transfer. Sending the principal to Blue during that callback reduces the caller's available balance, while leaving the automatic collection unchanged. If the caller cannot also cover that collection, the call fails.

The relevant comparisons are caller balance versus assets and caller-to-Blue allowance versus assets, using the same token contract. An unlimited approval is not required by the flash-loan interface. An allowance that covers the requested principal suffices for the repayment transfer, provided the token follows the expected transfer rules. Other callback operations can consume balance or allowance, so their effects matter at that boundary.

How much can Blue lend in a flash loan?

Blue can flash-lend up to the selected token's balance at its own contract address when the outgoing transfer executes. This is the aggregate balance of the singleton contract, which holds assets for multiple markets. The available flash-loan balance includes deposited collateral, unborrowed lending assets, and donated tokens of the selected type. A particular market's liquidity figure therefore does not describe the entire flash-loan capacity.

Token balances can change between a preliminary read and execution. The requested amount has to fit the balance at the transfer itself. Borrowing those tokens also temporarily reduces the assets that other callback operations can draw from Blue. A withdrawal inside the same callback can fail if the remaining actual token balance cannot cover it.

Flash loans and collateralized borrowing

A flash loan supplies temporary execution funds without creating a Blue market debt position. Its caller must return the principal in the same transaction. A collateralized market borrow creates debt under that market's collateral and health rules, and the debt can remain after execution. Vault deposits follow a separate share-based allocation model. Neither a market position nor vault shares substitute for the token balance required by the flash-loan pull.

Blue charges no protocol fee for its flash loans. The amount that the core flash-loan function collects equals the requested principal. Transaction gas and fees from external callback operations remain separate costs. A failed transaction can still consume gas. Returning the principal therefore establishes repayment, while any gain or loss depends on the callback's actual asset flows and execution costs.

View image file

Callback permissions and token transfer behavior

The borrower contract controls callback access and token handling. Blue's repayment mechanism cannot make an unsafe callback implementation safe.

Authenticate the callback

The callback should reject a sender other than the configured Blue contract. That check authenticates the protocol call; the wrapper's entrypoint still needs its own rules for who may initiate operations and supply instructions. Blue's callback signature contains no separate initiator argument. Retained balances can fund later calls, so arbitrary entrypoint access combined with arbitrary callback instructions can expose those balances to unintended spending.

View image file

Handle token return values

Blue's transfer helper accepts successful token calls that return either no data or a true boolean. It rejects calls that revert or return false. This handling covers return-value differences, not every token behavior. The protocol assumes that transfers move the exact specified amount; tokens that deduct transfer fees violate that assumption. A callback's approval handling must also match the selected token's behavior and detect approval failure.

A repayment check before transaction submission

Simulation tests the proposed flash-loan call without committing changes on-chain. Use the intended token, requested assets, and callback data together, through the actual contract entrypoint. Continue only when the simulation completes the repayment pull and the enclosing call without reverting. A successful simulation applies to the state it used; execution may encounter a different balance or allowance.

1. Inspect the simulated callback's ending token balance and the caller's allowance to Blue. Both must cover the requested principal.
2. Confirm the callback accepts only the configured Blue sender and the entrypoint restricts instructions as intended.
3. Submit the signed transaction only after confirming that its token, amount, callback actions, and spending permissions match the call you simulated.
4. Record a successful transaction receipt with the matching FlashLoan event from Blue and the repayment token transfer.
5. Read the calling contract's remaining token balance and residual allowance after execution, including any funds left available to future calls.

A transaction hash alone establishes no repayment. A confirmed repayment transfer records execution without implying that the callback produced a profit.

View image file