MEV (Maximal Extractable Value) and Yield Farming

Detailed Instructions

On-chain monitoring is the foundational step. Searchers use specialized bots to scan protocols like Uniswap V3, Curve, and Aave for specific conditions. The primary targets are pools with high liquidity but low gas competition, or those with pending large transactions that can be front-run. Key metrics include the pool's Total Value Locked (TVL), recent swap volume, and the presence of pending transactions in the mempool that involve significant asset movements. For example, a searcher might monitor the WETH/USDC 0.3% pool on Uniswap V3 (address: 0x8ad599c3A0ff1De082011EFDDc58f1908eb6e6D8) for large swap orders.

• Sub-step 1: Deploy a Node: Run an Ethereum node (e.g., Geth or Erigon) with high-speed mempool access to see pending transactions.
• Sub-step 2: Filter Transactions: Use a script to filter for transactions calling swap or addLiquidity functions on major DEX routers.
• Sub-step 3: Calculate Implied Profit: For each candidate, quickly simulate the transaction locally to estimate profit after gas costs. A profitable opportunity might arise if a pending $500k USDC->WETH swap would move the price by 0.5%, creating an arbitrage window.

Tip: Focus on pools adjacent to yield farms, as large harvest or deposit transactions from farms create predictable price impacts.

Detailed Instructions

A sandwich attack is a classic MEV strategy where a searcher places one transaction before and one after a victim's transaction. In farming, the victim is often a user harvesting rewards (e.g., calling harvest() on a MasterChef contract) which typically sells the farm token for a stablecoin or ETH, creating predictable price slippage. The attacker's first transaction (front-run) buys the farm token, pushing the price up. The victim's harvest sells into this inflated price, and the attacker's second transaction (back-run) sells the token back, profiting from the difference.

• Sub-step 1: Detect Harvest Tx: Identify a pending harvest transaction to a contract like SushiSwap's MasterChefV2 (0xEF0881eC094552b2e128Cf945EF17a6752B4Ec5d).
• Sub-step 2: Construct Attack Bundle: Using a tool like Flashbots' mev-boost relay, build a bundle with three transactions: [Your Buy, Victim's Harvest, Your Sell].
• Sub-step 3: Simulate & Submit: Simulate the bundle to ensure profitability and submit it to a block builder via a private RPC endpoint. The buy and sell amounts must be calibrated to the pool's liquidity; a typical attack might use 50 ETH to move the market.

javascriptCopy
// Pseudo-code for bundle construction
const bundle = [
  {tx: buySushiTx, canRevert: false},
  {tx: victimHarvestTx, canRevert: false},
  {tx: sellSushiTx, canRevert: false}
];
await flashbotsProvider.sendBundle(bundle, targetBlockNumber);

Tip: Profitability hinges on precise gas estimation and ensuring your back-run sell transaction is in the same block as the front-run and victim tx.

Detailed Instructions

Cross-DEX arbitrage capitalizes on temporary price differences for the same asset. Yield farm tokens (e.g., SUSHI, SPELL, CVX) are often listed on multiple DEXs like Uniswap, SushiSwap, and Balancer. When a large farm distribution or harvest occurs, the sell pressure can cause the token's price to dip more on one DEX than another. A searcher's bot detects this imbalance and executes a buy-low, sell-high trade across the two venues in a single atomic transaction, profiting from the spread. This often requires flash loans to fund the arbitrage without upfront capital.

• Sub-step 1: Price Feed Monitoring: Continuously compare the price of the target token (e.g., CVX) between DEX pools. A difference exceeding 0.3% after fees may be exploitable.
• Sub-step 2: Flash Loan Acquisition: Borrow the necessary capital atomically using Aave's flash loan (flashLoan function on 0x7d2768dE...) or dYdX.
• Sub-step 3: Execute Arbitrage Path: In one transaction: Borrow USDC, buy CVX cheaply on Curve pool 0xbEbc44782C7dB0a1A60Cb6fe97d0b483032FF1C7, sell it at a higher price on Uniswap V3, and repay the loan.

solidityCopy
// Simplified arbitrage contract call
function executeArbitrage(
    address flashLoanPool,
    address buyPool,
    address sellPool,
    uint256 amount
) external {
    // 1. Receive flash loan
    // 2. Execute swap on buyPool (e.g., USDC -> CVX on Curve)
    // 3. Execute swap on sellPool (e.g., CVX -> USDC on Uniswap V3)
    // 4. Repay flash loan + fee
}

Tip: The profit margin is slim, so gas optimization is critical. Use contract calls that aggregate swaps, like uniswapV3SwapCallback to minimize overhead.

Detailed Instructions

Liquidation MEV involves repaying a borrower's debt in exchange for their collateral at a discount when their health factor falls below a threshold (e.g., below 1.0 on Aave). In yield farming, users often deposit collateral (like ETH) to borrow assets, which they then deposit into a farm. If the value of their collateral drops or the borrowed asset rises, their position becomes liquidatable. Searchers run bots that monitor health factors on protocols like Aave and Compound, competing to be the first to submit a liquidation transaction and claim the liquidation bonus (e.g., 5-10%).

• Sub-step 1: Track Positions: Monitor the getUserAccountData function on Aave's LendingPool (0x7d2768dE...) for accounts with healthFactor < 1.0.
• Sub-step 2: Calculate Profitability: Determine if the liquidation bonus exceeds gas costs. For a position with 100 ETH collateral and 70 ETH debt, a 5% bonus on 70 ETH is 3.5 ETH.
• Sub-step 3: Execute Liquidation: Call the liquidationCall function, specifying the collateral asset, debt asset, user address, and debt to cover. The transaction must be bundled and prioritized to beat competitors.

bashCopy
# Example cast command to call liquidation on Aave
cast send <LENDING_POOL_ADDRESS> \
  "liquidationCall(address,address,address,uint256,bool)" \
  <COLLATERAL_ASSET> <DEBT_ASSET> <USER_ADDRESS> 500000000000000000000 true \
  --private-key <YOUR_KEY> --rpc-url <YOUR_RPC>

Tip: Use private transaction relays (like Flashbots) to prevent front-running by other liquidators. Also, consider the impact of your liquidation on oracle prices, which could trigger further opportunities.

Detailed Instructions

Fair ordering protocols like Themis or Aequitas aim to order transactions in a decentralized, non-exploitable way, while commit-reveal schemes hide transaction details until a later block. This prevents bots from seeing and frontrunning profitable trades.

• Sub-step 1: Design the commitment phase. Users submit a hash of their transaction data (e.g., keccak256(abi.encodePacked(swapParams, secretSalt))) along with their bid to have it included.
• Sub-step 2: Implement the reveal phase. In a subsequent block, users reveal the original transaction data and salt. The protocol verifies it matches the hash.
• Sub-step 3: Enforce slashing conditions. Design penalties for users who commit but fail to reveal, wasting block space. This can involve burning the commitment bond.

solidityCopy
// Example commit function
function commit(bytes32 _hash) external payable {
    require(msg.value >= MIN_BOND, "Insufficient bond");
    commitments[msg.sender] = Commitment(_hash, msg.value, block.number + 1);
}

Tip: Use a VRF (Verifiable Random Function) or a decentralized sequencer to determine the final, fair ordering of revealed transactions, breaking the link between gas price and execution order.

Detailed Instructions

Design Automated Market Makers (AMMs) and yield vaults that are resilient to sandwich attacks and liquidation MEV. The goal is to make extraction unprofitable or to capture that value for protocol users.

• Sub-step 1: Introduce just-in-time liquidity and guarded launches. For new pools or large deposits, use a mechanism where liquidity is added in the same block it's used, preventing frontrunning. For example, the CowSwap protocol uses batch auctions.
• Sub-step 2: Implement MEV-resistant oracle designs. Use time-weighted average prices (TWAPs) from multiple sources (e.g., Chainlink, Uniswap V3 TWAP oracles) for liquidations and pricing, rather than instantaneous spot prices.
• Sub-step 3: Redistribute captured MEV. Design vaults that use MEV rebates or priority gas auctions (PGA) to redirect profits from searchers back to liquidity providers. For instance, a vault could sell the right to execute a profitable rebalance to the highest bidder in a sealed-bid auction.

typescriptCopy
// Pseudo-code for a simple MEV-redirecting vault function
async function harvestWithMEVRebate() {
    const profitableTx = await strategist.buildHarvestTx(); // Estimated profit: 5 ETH
    const auctionWinner = await mevAuction.sellTxRights(profitableTx); // Searcher pays 4 ETH
    executeTx(auctionWinner.signedTx);
    distributeRebate(auctionWinner.bid, vault.depositors); // 4 ETH goes to LPs
}

Tip: Consider integrating with Flashbots SUAVE or Cow Protocol as a plug-in solution for fair order flow and MEV redistribution, rather than building everything from scratch.

Detailed Instructions

Proposer-Builder Separation (PBS) is a core Ethereum roadmap upgrade that separates the roles of block proposer (validator) and block builder. Builders compete to create the most profitable block bundle, and proposers simply choose the highest-paying header. This creates a transparent market for block space.

• Sub-step 1: Integrate with a builder relay. Protocols and users can submit transactions through relays like Flashbots Protect RPC (https://rpc.flashbots.net) or BloXroute. This sends transactions directly to builders, bypassing the public mempool.
• Sub-step 2: Design for enshrined PBS (ePBS). For long-term planning, understand how native protocol logic will interact with the eventually enshrined PBS mechanism in Ethereum, ensuring transactions are not excluded from builder blocks.
• Sub-step 3: Utilize MEV-Boost in validator setups. If running a validator, configure it to use MEV-Boost software to outsource block building. This maximizes validator rewards and contributes to a healthier ecosystem.

bashCopy
# Example command to start a validator client (Lighthouse) with MEV-Boost
lighthouse vc --network mainnet --mev-boost --mev-boost-urls https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net

Tip: Monitor builder centralization. Encourage the use of multiple, reputable relays to prevent a single builder from dominating the market and potentially censoring transactions.

Detailed Instructions

User interfaces and smart contracts should implement protections that adjust to market conditions. Dynamic slippage tolerance and transaction batching are critical to mitigating swap-based MEV and reducing failed transaction costs.

• Sub-step 1: Calculate context-aware slippage. Instead of a fixed 0.5% slippage, use an algorithm that considers pool liquidity, trade size, and recent volatility. For a large trade in a shallow pool, suggest higher slippage or break the trade into multiple smaller transactions.
• Sub-step 2: Integrate with DEX aggregators and private RPCs. Route all swaps through aggregators like 1inch or 0x API, which often have built-in MEV protection and find the best price across multiple liquidity sources. Use their protocols parameter to exclude vulnerable AMMs.
• Sub-step 3: Implement batch transactions or meta-transactions. Bundle multiple user actions (e.g., approve and swap) into a single atomic transaction. This prevents sandwich attacks between the approval and the swap. Use smart contract wallets or systems like Gas Station Network (GSN) for gasless meta-transactions.

javascriptCopy
// Example using 1inch API to get a swap quote with MEV protection
const quote = await fetch(`https://api.1inch.io/v5.0/1/quote?fromTokenAddress=0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE&toTokenAddress=0x6b175474e89094c44da98b954eedeac495271d0f&amount=1000000000000000000&protocols=UNISWAP_V3,SUSHI, BALANCER_V2`);

Tip: For advanced users, provide an option to submit transactions with a high priority fee (e.g., 3-5 Gwei) and a short deadline (e.g., 1 block) to reduce the window for MEV bots to operate, while warning them of the risk of failure.