Cart is empty 
The title of this positing includes terms associated with blockchain and crypto, and many of you will have heard of them, but do you really know what they are, how they work, and the impact they can have on crypto trading?
Front-running is a bit like having “insider information” on a large trade that’s about to occur, which will drive the price of an asset up or down. Imagine knowing that next week, a huge company is going to invest in a smaller company on the stock market. The price of shares in the smaller company is currently tiny (let’s say $0.01 per share), but you know that as soon as the bigger company comes along and invests $500m in this company, it’s going to make the smaller share company soar to $2.00 per share. If you had your “unethical hat” on, then you could see that potentially buying some shares in that smaller company before next week, could provide an opportunity to make some profit, as you can purchase them now at $0.01 and sell them next week at $2.00
If you apply this example to the world of crypto trading, this is known as front-running, however the actual “insider information” is available for all the world to see…. you just need to be super, super quick to take advantage of it.
You see, when someone goes to a DEX to make a buy or sell order, no matter how big or small, the trade itself isn’t executed instantaneously. The speed of execution depends on the blockchain in question, but if we focus on the Ethereum Blockchain for the rest of this posting as an example, you’ll know (if you’ve ever traded with Ethereum) that there’s a delay between actually placing a trade, and the trade itself ultimately being “executed” and appearing on the blockchain.
Each Ethereum “block”, which is where all transactions have been added, takes around 12 seconds to be added to the chain. It doesn’t seem like a long time, however 12 seconds for a programmable script or “Bot” is a very long time to get things done!
So let’s explore what happens during that potentially 12-second period…
You place a trade, and the trade goes into the “mempool” — At a high-level, a mempool is basically a waiting room for pending transactions. They get sent to a node on the blockchain, and wait around before they are eventually processed and added to the blockchain.
In fact, there’s no guarantee that your transaction will even get processed in the current block. When the network is busy, you may even have to wait until the next block is processed, or even the block after that! In some cases, you might even be waiting over a minute for your transaction to get processed!
The interesting thing about mempools is that they are visible for all the world to see. Everything on a blockchain is public. Every transaction can be viewed. You can see the senders wallet address, the receiving wallet (or smart contract) address, the amount sent, etc.
So if you were a super-rich crypto “whale” trader, and wanted to buy $500m worth of Ethereum, then that pending trade will first go to the PUBLIC mempool, and wait around for a little while before it’s processed.
The other interesting thing about mempool is that they DO NOT operate on a “First-In-First-Out” (FIFO) basis.
If Bob and Mary both send a transaction Chris in the same block, and Bob sends his transaction 1 second before Mary, it doesn’t necessarily mean that Bob’s transaction will arrive at Chris’s wallet before Mary’s — How can this be? One of the critical factors is how much gas both Bob and Mary paid for their transaction.
You see, if Mary paid a significantly higher gas fee than Bob, then it’s highly likely that Mary’s transaction will arrive in Chris’s wallet before Bobs transaction.
When you use Metamask to make a transaction, you have the option to accept the default “Market Rate” gas fee, or instead edit the amount of gas you’d like to pay. You can see from the image below the estimated times for processing your transaction based on network conditions and current gas rates:
You don’t even have to accept one of the three default gas values…. you could reduce the amount of gas you want to pay to an amount even lower than the “low” value, although the risk of doing this is that the transaction takes a VERY long time to process, or potentially never get processed!
At the same time, you can pay a higher gas fee than “Aggressive” if you really want your transaction to get processed as soon as possible.
For all the transactions currently sat in the mempool, the transactions willing to pay the highest gas fee are the ones most likely to get processed first.
So going back to the example of Bob, Mary and Chris, you can see that if Mary paid a significantly higher amount of gas for her transaction than Bob did, her transaction is likely to reach Chris’s wallet before Bob’s transaction, even though Bob sent his transaction 1 second before Mary.
Front-Running Bots
With that information in mind, what if you knew the following information:
- A HUGE buy/sell transaction is sitting in the PUBLIC mempool, which will inevitably move the price of the asset once the transaction is processed
- This particular transaction was made using an average gas price, and it’s expected to take around 10 seconds to process
So what if you could create a “Bot” script that sits around all day, scanning the mempool, looking for huge (pending) transactions that will shift asset market prices, and when the “Bot” sees one of these transactions, it makes an instant transaction to buy the same asset, but pays a far higher gas fee?
You can probably see what will happen here! The “Bot” will receive the asset at the current price (probably still a low price) FIRST and then the huge transaction will get processed SECOND. By the time the Bot has received it’s asset at the low price, the new asset price (formed by the HUGE transaction) has now inflated the price, in which case the owner of the Bot can make a profit by selling the asset back to the market at the new higher price!
The smaller the pool, the bigger the impact
Up to this point I’ve described how you could use a bot for “front-running” a huge transaction that will move asset price, but it’s worth noting that this is based upon moving the price of an asset that is part of a huge liquidity pool.
For example, as of the time of writing this post, the USDC/ETH liquidity pool on Uniswap v3 sits at $221.94m
If you wanted to impact the asset price by just 0.1%, you have to spend $1.5m USDC!
But this is a huge liquidity pool, so it would require huge amounts to move the price. But what about smaller liquidity pools?
Imagine you were following a smaller crypto project that has been making steady progress, and starting to gain some attention. The current liquidity pool is small when compared to the USDC/ETH pool, and average daily transactions reflect this…. but then one morning a front-running bot spots a large transaction on this smaller project pair that will move price.
Here is an example of a fun new meme project on Ethereum called “Mouseworm”
For this liquidity pair, you could impact the price of Mouseworm by over 20% by investing just $25,000 in the project.
So before this example trade is placed, 1 Mouseworm would cost $2.24 USDT, but after this $25,000 trade is placed, the price of 1 Mouseworm would be somewhere around $2.68. That’s a significant increase. So if you programmed a “Front-running” bot to place a trade (using more gas) than this $25,000 trade, then you could get the token at a lower rate than $2.68, and know that immediately after the bot makes the purchase, the rate will jump up considerably, potentially providing a sell opportunity at a profit.
This is why it’s not always necessarily a good thing to try and save on gas fees when trading on assets. When you next go to place a crypto trade on your phone, you might think that you’re not in any mad rush for your trade to go through, so you may as well just save some gas fees…..but there might be a bot watching what you’re doing, and preparing to front-run you!
Sandwich bots
Sandwich bots use similar techniques, only they normally consist of a pair of trades (both a buy AND sell) which are carefully constructed and timed to form what is known as a “Sandwich Attack”.
The sandwich attack involves placing two trades on a DEX, with the intention of profiting from the price movement that occurs BETWEEN the two trades. This process is a combination of “front-running” and “back-running”.
The first trade allows the bot to get the asset at a low price, as the real trade (executed after the bot’s trade due to not paying as much gas) will cause the price to go up.
The second trade will then execute immediately after the real trade to instantly sell the asset, before anyone even noticed. The attacker got in, made a profit, then sold the asset back to the market, all in the blink of an eye!
Whilst this would be practically impossibly for a human to do, sandwich bots on the other hand automate this process by continuously monitoring the order book of a DEX and placing the necessary trades at the appropriate times. They can be used to repeatedly profit from small price movements, and can be particularly effective when used on illiquid markets with low trading volumes.
What can be done?
There are some obvious ways to avoid front-running and sandwich bot attacks.
- The first is to trade within a large (or aggregated) liquidity pool. The likelihood of your trade moving market prices is miniscule, so the opportunity for a bot to profit from that trade (particularly when DEX fees are factored in) is negligible or doesn’t exist.
- Keep slippage low! If you set your slippage too high, then you are begging to be front-run! The slippage amount accounts for the likelihood of your trade succeeding or failing, and many crypto traders tend to set slippage too high as they are desperate to get hold of some tokens as the price is climbing fast and they don’t want to miss out. This could prove costly, and bots WILL take advantage of this!
- Pay Higher gas fees. If you want your transaction to get processed quicker than someone else, you’ll generally have to pay more gas than the competition. It’s usually better to pay more gas and keep slippage low, rather than the other way round.
- Make multiple low value orders rather than one big order. Bot developers are smart and they’ve already factored in gas fees, slippage, asset price etc., so there comes a point when a bot simply won’t try to execute a front-running trade, because it won’t be profitable when fees have been accounted for. In contrast, if you’re making a big trade on a smaller liquidity pool, the changes of the bot making a decent profit increase substantially.
- Use a reputable DEX — Most of the leading DEX exchanges include features such as quick matching, randomized transaction processing, trade match engines and periodic auction matching to minimize the odds of front-running.