Flash Loan Arbitrage Tutorial: Aave + Uniswap Step-by-Step

Published January 25, 2026 · Updated March 7, 2026 · By JaredFromSubway

Flash loan arbitrage is one of the most powerful strategies in decentralized finance. It allows anyone to borrow millions of dollars with zero collateral, exploit price differences across decentralized exchanges, repay the loan, and pocket the profit — all within a single Ethereum transaction. If any step fails, the entire transaction reverts as if nothing happened. You risk nothing except gas fees on a failed attempt.

In this tutorial, we walk through the complete flash loan arbitrage workflow using Aave V3 as the lending protocol and Uniswap V3 plus SushiSwap as the trading venues. Whether you are a Solidity developer looking to build your first arbitrage bot or a DeFi researcher studying MEV extraction, this guide covers every step from theory to pseudocode to profitability math. JaredFromSubway uses flash loans as a core component of its MEV infrastructure, and this tutorial distills lessons learned from thousands of on-chain arbitrage executions.

Why Flash Loans Make Arbitrage Zero-Capital

Traditional arbitrage requires holding significant capital. If ETH is $3,900 on one exchange and $3,920 on another, you need to already own ETH (or stablecoins to buy it) to capture that $20 spread. Professional trading firms deploy millions of dollars across exchanges to earn from these tiny differences.

Flash loans eliminate this requirement entirely. Aave V3 lets you borrow up to the total available liquidity in a pool — often hundreds of millions of dollars — for the duration of a single transaction. There is no credit check, no collateral deposit, and no application process. The only requirement is that you repay the borrowed amount plus a 0.09% fee before the transaction completes. If you cannot repay, the EVM reverts every state change in the transaction, and it is as if the loan never existed.

This means anyone with the technical skill to write a smart contract can compete with multi-million-dollar trading desks. The playing field shifts from "who has more capital" to "who can find and execute opportunities faster." JaredFromSubway leverages flash loans extensively for this exact reason — capital efficiency is maximized when you never need to hold inventory.

Step 1: Identify a Price Discrepancy Between DEXs

The first step in any flash loan arbitrage is finding a profitable price difference. Every AMM-based DEX prices tokens independently based on its own liquidity reserves using the constant product formula (x * y = k) or a similar variant. When a large trade hits one pool, its price shifts while other pools remain at their previous price — creating an arbitrage window.

Your bot must continuously monitor reserve states across multiple DEXs. On Ethereum, this means subscribing to Sync events on Uniswap V2-style pools and Swap events on Uniswap V3 pools, then computing the effective price at each venue. When the price difference between two venues exceeds the combined cost of the flash loan fee, gas, and builder tip, you have a viable arbitrage opportunity.

Advanced bots like JaredFromSubway also monitor the mempool for pending large swaps that will create predictable price dislocations. By simulating the state after a pending transaction lands, the bot can precompute the arbitrage opportunity and submit a back-run transaction in the same block.

Step 2: Borrow via Aave Flash Loan

Once you identify a profitable discrepancy, your smart contract initiates a flash loan from Aave V3. The contract must implement the IFlashLoanReceiver interface, which requires a single callback function: executeOperation. When you call pool.flashLoan() on the Aave Pool contract, Aave transfers the requested tokens to your contract and immediately calls executeOperation. Inside this callback, you perform all your trading logic. At the end of the callback, Aave automatically pulls back the borrowed amount plus the 0.09% fee. If your contract does not hold enough tokens to cover the repayment, the entire transaction reverts.

The interface is straightforward. Your contract receives the borrowed assets, an array of amounts, an array of premiums (fees), and any custom parameters you passed in. All your arbitrage logic lives inside this one function.

Step 3: Buy Cheap on DEX A, Sell Expensive on DEX B

Inside your executeOperation callback, you execute the actual arbitrage trades. Suppose USDC is the borrowed asset and ETH is cheaper on Uniswap V3 than on SushiSwap. Your contract:

1. Approves USDC spending on the Uniswap V3 Router.
2. Swaps USDC for ETH on Uniswap V3 (the cheaper venue) using exactInputSingle.
3. Approves ETH (WETH) spending on the SushiSwap Router.
4. Swaps ETH for USDC on SushiSwap (the more expensive venue).
5. Now holds more USDC than was borrowed — the difference is profit.

The key insight is that both swaps happen atomically in the same transaction. There is no risk of the price changing between the buy and the sell. Either both trades execute at the expected prices and you profit, or the transaction reverts and you lose nothing (except gas on the failed attempt).

Step 4: Repay Loan + 0.09% Fee in the Same Transaction

After the arbitrage trades complete, your contract must hold enough of the borrowed asset to repay Aave. The repayment happens automatically at the end of the executeOperation callback — Aave's Pool contract calls transferFrom on your contract to reclaim the principal plus the premium. You simply need to ensure your contract has approved the Aave Pool to pull the tokens and that the balance covers the total owed amount.

For Aave V3, the flash loan fee is 0.09% of the borrowed amount. If you borrow 1,000,000 USDC, the fee is 900 USDC. Your arbitrage profit must exceed this fee plus gas costs plus any builder tip to be worthwhile. Any remaining tokens after repayment stay in your contract — that is your profit.

Pseudocode: The executeOperation Callback

Below is a simplified pseudocode example of the flash loan callback that executes a two-DEX arbitrage. In production, JaredFromSubway uses heavily optimized assembly-level contracts, but this illustrates the core logic.

Real Example: ETH/USDC Arbitrage Between Uniswap and SushiSwap

Let us walk through a concrete scenario. Suppose a whale sells 500 ETH on Uniswap V3, pushing the ETH/USDC price down to $3,880. Meanwhile, the SushiSwap ETH/USDC pool still reflects $3,920 because no large trade has hit it yet. That $40 spread is the arbitrage opportunity.

In practice, slippage on both legs reduces this figure. A 500,000 USDC buy would itself move the Uniswap price, and the SushiSwap sell would push that price down. The optimal trade size is the one that maximizes the net spread after accounting for price impact on both venues. Professional bots like JaredFromSubway use binary search or convex optimization to compute the ideal trade size for each opportunity.

Profitability Calculation

Not every price discrepancy is worth exploiting. The full profitability formula for a flash loan arbitrage trade is:

• Revenue: The USDC (or other token) gained from the price difference after both swap legs, accounting for slippage and DEX fees (typically 0.3% per swap on V2, variable on V3).
• Gas Cost: A flash loan arbitrage transaction is complex — multiple external calls, token approvals, and swaps. Expect 300,000-500,000 gas. At 30 gwei base fee, that is 0.009-0.015 ETH (~$35-$58 at $3,900 ETH).
• Flash Loan Fee: 0.09% of borrowed amount. On a 500,000 USDC loan, this is 450 USDC.
• Builder Tip: If submitting through Flashbots or MEV-Boost, you must tip the block builder to include your transaction. The tip is set competitively — often 50-90% of your expected profit.

Using our earlier example: Revenue of $4,679 minus gas ($50) minus flash loan fee ($450) minus a 70% builder tip ($2,925) leaves a net profit of approximately $1,254. These numbers illustrate why flash loan arbitrage requires large trade sizes and tight spreads to be worthwhile after all costs.

Why Most Flash Loan Arbitrage Bots Fail

Despite the theoretical elegance of flash loan arbitrage, the vast majority of bots built by independent developers lose money or break even. There are several compounding reasons for this.

Extreme competition. Hundreds of searchers monitor the same pools for the same opportunities. When a price discrepancy appears, multiple bots submit competing transactions. Only one wins — the one that offers the highest builder tip and arrives first. The rest waste gas on failed or reverted transactions.

Latency matters. Receiving blockchain state updates, computing the optimal trade, and submitting the transaction to a builder must happen in single-digit milliseconds. Bots running on consumer hardware or distant servers cannot compete with firms co-located near builder infrastructure.

Gas cost of reverts. When your arbitrage transaction is outbid by a competitor, your transaction may still land on-chain and revert, consuming gas. If you submit 100 transactions per day and only 5 succeed, the gas cost of the 95 failures can easily exceed your profits.

Smart contract inefficiency. A naive Solidity implementation with multiple external calls and redundant approvals consumes far more gas than an optimized one. Professional bots use hand-written assembly, pre-approved token allowances, and minimal proxy contracts to shave off every possible unit of gas.

How JaredFromSubway Combines Flash Loans with Sandwich Attacks

Pure flash loan arbitrage reacts to existing price discrepancies. But JaredFromSubway goes further by combining flash loans with sandwich attack strategies to create guaranteed profit opportunities. Here is how the combination works.

When JaredFromSubway detects a large pending swap in the mempool, it can front-run the trade to push the price in one direction, let the victim's trade execute at the worse price, and then back-run to capture the difference. The front-run leg requires capital to buy tokens before the victim — and this is where flash loans become invaluable.

By borrowing via flash loan for the front-run purchase, JaredFromSubway avoids tying up capital in inventory. The entire sandwich — borrow, front-run buy, victim trade, back-run sell, repay — can execute atomically. The profit is the difference between the back-run sell revenue and the front-run buy cost, minus the flash loan fee and gas. Because the bot controls the ordering of transactions within the bundle (via Flashbots), the profit is virtually guaranteed as long as the victim's trade lands.

For a deep dive into how sandwich attacks work mechanically, see our crypto arbitrage bot guide.

Triangular Arbitrage with Flash Loans

Triangular arbitrage extends the basic two-venue model to three or more trading pairs. Instead of buying on DEX A and selling on DEX B, the bot cycles through three tokens: A → B → C → A. If the exchange rates across these three pairs are misaligned, the bot ends up with more of token A than it started with.

For example, consider the following cycle on Uniswap V3: USDC → ETH → WBTC → USDC. If the ETH/USDC pool prices ETH at $3,900, the WBTC/ETH pool prices WBTC at 15.2 ETH, and the WBTC/USDC pool prices WBTC at $59,500, there may be a profitable cycle. Starting with 100,000 USDC: buy 25.64 ETH, swap for 1.687 WBTC, sell for 100,380 USDC. Gross profit: 380 USDC from the triangular mismatch alone.

Flash loans are particularly powerful for triangular arbitrage because the capital requirement is even higher — you are executing three swaps instead of two, and each one needs to be large enough that the per-trade spread exceeds the cumulative fees. Borrowing the starting capital via flash loan makes triangular strategies accessible to bots that would otherwise need to hold millions in stablecoins.

JaredFromSubway monitors thousands of pool combinations in real time, evaluating multi-hop arbitrage paths using graph-based algorithms similar to Bellman-Ford for detecting negative-weight cycles. Each cycle that produces a net positive return after flash loan fees, gas, and builder tips is submitted as a Flashbots bundle.

Essential Tools for Flash Loan Arbitrage Development

Building and testing flash loan arbitrage contracts requires specialized tooling. Here are the tools that professional MEV searchers, including the JaredFromSubway team, rely on.

Foundry is the gold standard for Solidity development and testing. Its forge test --fork-url command lets you fork mainnet state and simulate your flash loan contract against real pool reserves. You can test whether your arbitrage would have been profitable at any historical block without spending gas. Foundry's cast tool is also essential for quick on-chain reads and transaction decoding.

Flashbots is critical for transaction submission. Instead of broadcasting your arbitrage transaction to the public mempool (where competitors can see and front-run it), Flashbots lets you submit bundles directly to block builders. Your transaction is either included at the exact position you specified or not included at all — no risk of partial execution or public exposure. Use the eth_sendBundle RPC method to submit bundles to the Flashbots relay.

Additional tools include Tenderly for transaction simulation and debugging, Dune Analytics for historical MEV data analysis, and custom Rust or Go implementations for low-latency mempool monitoring and state tracking.

Frequently Asked Questions