Research Summary: Coding a DeFi arbitrage bot


  • The author provides a detailed guide to coding a DeFi arbitrage bot. The bot uses flash loans to borrow assets from dYdX and sells them on 1inch exchange when profitable.



Core Research Question

  • How can an arbitrage between DEXes be automatically performed using flash loans?


  • Arbitrage is the purchase and sale of an asset in order to profit from a difference in the asset’s price between marketplaces.
  • Price slippage refers to the difference between the expected price of a trade and the price at which the trade is executed. It usually happens when the market is highly volatile within a short period of time or when the current trade volume exceeds the existing bid/ask spread.
  • Flash Loan is a type of uncollateralized loan that is only valid within a single transaction. It can be implemented through a smart contract. The transaction will be reverted if the execution result is not as expected.
  • Decentralized exchanges (DEX) are a type of cryptocurrency exchange which allow peer-to-peer cryptocurrency exchanges to take place securely online, without needing an intermediary.
  • DEX aggregators source liquidity from different DEXs and thus offer users better token swap rates than any single DEX.
  • Liquidity pool is a collection of funds locked in a smart contract to provide liquidity for DEXes. The advantage of a liquidity pool is that it doesn’t require matching orders between buyers and sellers, and instead leverages a pre-funded liquidity pool with low slippage.
  • An Orderbook consists of a collection of bid-and-ask orders. Orders are matched and executed only when a bid and ask price are the same.
  • An Automated Market Maker (AMM) uses a liquidity pool instead of an orderbook and relies on mathematical formulas to price assets. The assets can be automatically swapped against the pool’s latest price, making it more efficient than traditional orderbooks.
  • Wrapped ETH (WETH) is the ERC20 tradable version of Ethereum. WETH is easier to trade within smart contracts than ETH is. Users can also revoke access to their WETH after sending it to an exchange, which is not possible with ETH.


  • The author describes the advantages of DeFi arbitrage over centralized exchanges:
    • DeFi
      • Insolvency risks are minimized as smart contracts execute automatically following predetermined parameters. A trade will be reverted if it cannot be executed as expected.
      • Traders can perform arbitrage using borrowed funds with flash loans.
    • Centralized exchanges
      • Since a trader cannot execute trades simultaneously, they may suffer from price slippage if a trade is delayed.
      • Traders need to own funds or borrow them from a bank.
  • Arbitrage between DEXes that use AMM
    • Popular platforms
    • Result
      • Bring prices into efficiency between two liquidity pools
    • Scenario
      • When the pools on different DEXes offer different prices to exchange assets.
    • Execution
      • Exchange from asset A to asset B on one pool and exchange it back on another pool to benefit from the price spread between two pools.
  • Arbitrage between DEXes that use classic orderbook
    • Popular platforms
    • Scenario
      • Traders can fill limit orders from a DEX and then see if the tokens acquired could be sold to any other liquidity pools for better returns.
  • The author describes the basic operation of an arbitrage bot.

  • However, the above opportunity may not actually exist in practice, because we would need both limit orders to exist at the same time for the arbitrage to work.
  • The author thus proposes to perform the arbitrage using a flash loan.
    • Steps
      • Get a flash loan DAI from DyDx exchange
      • Buy WETH from 0x using the DAI borrowed with the flash loan
      • Use 1inch to find the best exchange to sell the WETH acquired in step 2
      • Pay back the flash loan DAI and keep the remainder as profit
  • The author provides the code and explains how the arbitrage smart contract works
    • The contract inherits the DyDxFloashLoan smart contract.
    • Functions
      • Swap
        • Perform the trade
      • getExpectedReturn
        • Get the current asset price
      • getWeth
        • Turn any ETH sent into WETH
      • approveWeth
        • Approve the 0x proxy to collect WETH as the fee for using 0x.
      • getFlashloan
        • Called whenever a profitable arbitrage is found by the client.
        • All of the parameters for this function will be constructed and passed in from the client script.
      • callFunction
        • Has to be deployed in our smart contract to receive a flash loan from dYdX.
      • _arb
        • Arbitrage function that is called when the loan is successful.
        • Tracks the balance of our smart contract before and after the trade.
        • If the end balance is not greater than the start balance, the operation will revert.


  • The prerequisite for the arbitrage bot is to have a browser with the Metamask extension installed.
  • The programming language used is NodeJS.
  • Project structure: only two files
    • index.js
      • a node.js server that continuously fetches crypto prices on exchanges looking for arbitrage opportunities, trying to guarantee that the trade is possible before even attempting to execute it.
    • TradingBot.sol
      • a smart contract that gets called by the node app only when a profitable arbitrage is found, it will borrow funds with a flash loan and execute trades on DEXes.
  • Detailed setup
    • Install Metamask browser extension
    • Create an Ethereum Mainnet account with some ETH for paying gas fees.
      • Don’t use your personal account for this, create a new account for the bot in order to limit accidental losses.
    • Go to Remix online IDE and paste the smart contract solidity code
    • Compile the code using compiler version 0.5.17.
    • Deploy with an initial 100 wei, which is enough for 100 flash loans on dYdX.
  • Environment setup
    • By cloning the project’s code repository, users will find a file called .env.example inside the /src folder
    • Fill in the fields:
      • RPC_URL : the public address of an Ethereum node, the easiest one to set up is the Infura RPC provider, register an account in order to get an API key.
      • ADDRESS and PRIVATE_KEY: fill in the public Ethereum address of the bot account, and its corresponding private key.
      • CONTRACT_ADDRESS : paste in the smart contract’s address that was returned from Remix after the deployment step.
      • GAS_LIMIT : how much gas the contract is allowed to use, leave as 3000000 or decrease to 2000000 which should be fine
      • GAS_PRICE : change this depending on how fast you want the transaction to be mined, see for info.
      • ESTIMATED_GAS : leave as is
  • Running the bot
    • Execute the command from the project’s root directory.
      • node src/index.js


Discussion & Key Takeaways

  • The author created an open-source DeFi arbitrage bot that uses flash loans to borrow assets from dYdX and sells them on 1inch exchange when profitable.
  • The author explains the main components of the arbitrage bot and the underlying logic of how arbitrage works.
  • After following this tutorial, users can create a working example of a customizable flash loan arbitrage bot.
  • The most efficient way to perform a flash loan arbitrage is to continuously fetch the real time prices using NodeJS client and execute the contract with profitable parameters when an opportunity is found.

Implications & Follow-ups

  • Arbitrage is a zero-sum game. There are a finite number of arbitrage opportunities for a large group of people competing to find and execute them.
  • To make the bot more efficient, the author suggests the following improvements:
    • Consider taker fees when calculating profits
    • Use Partial fills
    • Check orders again
    • Handle failures to continue execution
    • Execute multiple orders simultaneously
    • Dynamically calculate gas fees
  • If such arbitrage bot becomes prevalent, the price differences between different DEXes will be minimized. DEX aggregators such as 1inch may no longer be needed as the price differences become more and more negligible in the future.
  • It may be interesting to measure the actual APR of running this bot, considering the cost of server hosting and contract deployment.



Always fun to see so many edgy concepts combined in a single bot, especially the use of DEX aggregators in conjunction with flash loans.

Given the historical volatility in gas prices, seems like a dynamically adjusted GAS_PRICE field would be a requirement for this bot to survive in the long run. A predefined gas price of 200 provides a good cushion at current levels, but the bot would likely be priced out in times of high gas vol.

If unsupervised, such a bot could ultimately lead to losses if transactions are continuously priced out by more sophisticated arb traders. If the bot’s creator does not adjust the GAS_PRICE field quick enough, transactions will start failing and the contract’s ETH drained. Extropy is a fun PoC, but experimenters beware! :laughing:


Has anyone published the results of running the bot? Even if it’s consistently not profitable it would be useful to understand why.

In Flash Boys they setup multiple globally distributed nodes in order minimize the impact of latency a node can experience. Any consideration given to latency?

Given that price movements create arbitrage opportunities are there any studies examining the relationship between price volatility and gas prices?

1 Like

Can you give us a sense of how important these bots are to the DeFi ecosystem? Are they simply a nuance or do they provide some kind of stability to the system? I’d also be really curious about how arbitrage bots and trading bots fit into the debate about Miner Extractible Value.

1 Like

Most DeFi applications rely on arbitrageurs to function properly so these trading bots are critical for markets to reach price efficiency.

When it comes to node latency, that seems to be of less relevance in recent times because of new approaches to MEV. Don’t get me wrong, it’s still important to have sufficient data on the different corners of the network’s topology. Since the mempool functions as an auction, you need to know if another arbitrageur outbid your tx and whether it’s worth it to engage in a bidding war.

However, it has been observed that new approaches to MEV entail sending transactions directly to the mining pool and issuing payments out-of-band (without even sending it to the mempool). That circumvents the need for low latency as miners will receive your transactions directly, thereby circumventing the need to engage in bidding wars.

1 Like