How Flash Loans Use Atomic Transactions

A flash loan must be borrowed and repaid, plus its fee, inside one transaction; if repayment fails, the entire transaction reverts.

What does atomic execution mean here?

Atomic execution means the Ethereum Virtual Machine treats the transaction as one state change: every contract call succeeds in sequence, or none of the resulting state changes are committed. A lender can therefore transfer assets before it has been repaid because the transaction still has to reach its final repayment check.

Suppose a contract borrows DAI, swaps it for WETH on one decentralized exchange, sells the WETH for more DAI on another, and returns the original DAI plus the flash-loan fee. If the second swap produces too little DAI, the repayment transfer fails and the transaction reverts. The temporary DAI, the swaps, token balances, and approvals disappear from the chain's final state as though the failed attempt had not happened. Gas used by the failed attempt is still spent.

What are the two ways to obtain temporary liquidity?

There are two common implementations: a dedicated flash lender with a borrower callback, and an automated-market-maker pool that sends tokens first and checks its balance afterward.

How does a dedicated flash lender work?

A dedicated lender such as Aave exposes a flash-loan function that transfers assets to a receiver contract and immediately calls that contract back. The receiver performs its strategy in the callback, then approves or transfers the principal and fee so the lender can settle before the outer call returns.

1. The caller chooses the asset, amount, lender, and receiver contract.
2. The lender sends the asset to the receiver and invokes its callback.
3. The receiver executes swaps, collateral changes, liquidations, or other contract calls.
4. The receiver makes the required repayment available to the lender.
5. The lender checks repayment and returns successfully, or reverts the whole transaction.

ERC-3156 describes a standard version of this pattern with a lender interface, a borrower callback, a quoted fee, and a required callback return value. Not every protocol uses that exact interface. Aave, for example, has its own receiver conventions. The important boundary is the same: the lender controls the final repayment check.

This model is the better fit when the strategy needs a known quantity of one or several assets from a lending market. It also makes the developer responsible for validating the callback caller, the initiator, the asset, and the amount. A receiver that trusts arbitrary callback data can be tricked into approving funds or executing an unintended strategy.

How does an AMM flash swap differ?

An AMM flash swap reverses the usual order of a trade: the pool sends out one or both tokens, calls the recipient contract, and only then checks that the pool received enough tokens to preserve its invariant and cover the fee.

Uniswap v2 uses this design for every swap internally. With nonempty callback data, the pair calls uniswapV2Call on the recipient. The recipient can use the withdrawn token elsewhere, acquire the required input, and send it back before the pair finishes. Uniswap v3 exposes a related flash function with a flash callback and explicit fees.

The line between the two approaches is the source of liquidity and the rule that settles the debt. A dedicated lender asks for principal plus a quoted fee. An AMM pool asks for the balances required by its pool formula after the callback. Both depend on atomic rollback, but they are not interchangeable interfaces, and a strategy must obey the checks enforced by the specific contract.

When is it worth building on flash-loan atomicity?

It is worth building when several individually valid actions only become profitable or useful as one operation. Typical examples include arbitrage between price venues, refinancing a lending position, swapping collateral while preserving a debt position, and liquidating an account when the liquidator does not already hold enough capital.

The contract needs more than a borrow call. It must encode the entire route, enforce minimum output amounts, verify pool and callback addresses, account for the lender fee and gas, and reject a result that does not meet the strategy's profit or solvency requirement. A human wallet cannot improvise these conditions safely in the middle of execution. MetaMask Wallet may sign the transaction, but the receiver contract supplies the logic that makes the sequence atomic.

Atomicity also has a hard boundary: it normally applies inside one chain's transaction, not across a bridge or a series of wallet submissions. A Manta Bridge route moves value or messages between network domains, so a loan borrowed on Ethereum Mainnet cannot remain open while a later transaction waits for funds to arrive on Manta Network. The bridge leg must settle separately, or the whole strategy must be redesigned around liquidity already available on the destination chain.

That is the practical verdict: flash loans remove the need to pre-fund a multi-step strategy, but they do not remove cost, contract risk, slippage, or chain boundaries. Build on them when the value comes from completing the whole sequence in one execution window, and choose the lender or pool whose repayment rule matches the strategy.