Front-Running
CivTrade innovates DeFi trading: start multiplying your gains today!
What is front-running?
Front-running on a blockchain happens when a miner looks at pending transactions and finds exploitable opportunities at the expense of a trader. In short: it’s stealing money from you.
The Mempool is the waiting queue where your blockchain transactions wait to be packaged into blocks and executed. Depending on market conditions, the queue may be several minutes or hours long and it is publicly accessible by anyone.
It is relatively easy to write automated software to look at all the transactions in the queue, review them one by one, and opportunistically extract profit by creating an instant order that is constructed solely to execute before yours, with you as the targeted victim.
The poisonous sandwich
Automated scripts are overwhelming and any profitable trade is potentially subject to their attack, with virtually no way to resist or avoid it.
The front-running robot analyzes and finds targets that can be attacked by continuously scanning transactions in the Mempool. Among types of front-running attacks, the most typical and most dangerous are sandwich attacks, which steal profit from traders. Let’s take a closer look at an example of a sandwich attack.
In the image above, three transactions are packaged in the same block, as you can see by the identical date/time-stamp. The normal transaction in the middle is sandwiched between two attack transactions marked by the red-hat icon symbol for hackers. These kinds of attacks are carried out as follows:
The trader submits an order.
In our example, Uniswap transaction to buy CIV (well done! ;~) ) with 1.84 ETH at a price of around 2243 ETH per CIV (zeroes omitted for simplicity), a gas price of 192 Gwei (as you can see from Etherscan), and slippage incorrectly set to 5% (as you can infer from the events).
The bot detects a potentially lucrative transaction to exploit. The bot then attacks the user by initiating a buy transaction at the price of the trader out in for.
In our example, this was exactly 2243, picking the ETH value to cause a price impact of exactly 5%.
By doing this, the bot gets the initial price set by the trader. Note from Etherscan that this first bot transaction was set with its gas price at 190 Gwei, a hair lower than the trader, but still executed first, signaling that it likely colluded with the block miner to artificially reorder transactions.
The bot launches another trade, to sell right after the poor trader, who at this point will have paid the artificially inflated price.
In our example, the inflated price is 2361.
This sell order was made with a gas price at 1,108 Gwei, almost 10x the market rate, to guarantee it would be executed immediately after the trader’s order was executed and insure it successfully jumped ahead of all other orders, as well as not to risk profit being eaten away by other bots. This is how the miner who wrote the bot also profits.
After all said and done, the simple yet flawlessly executed attack extorted 0.1 ETH (about $440 market value at the time). The gas costs for the two transactions were $73 and $375, totalling exactly $448. What does this mean? The bot paid its ENTIRE profit to the miner, which is logical, as it’s the miners themselves running bots these days. They are using the most direct way to eat away and pay themselves all profit!
Your mitigating counter-measures
Front-running is financially devastating to the victim. To mitigate the risk of being caught up in one of these attacks, you generally can:
Set low slippage thresholds (think 0.1% or so), greatly curtailing the front-running bot’s ability and opportunity to extract from you.
Doing this, however, increases the risk of orders never being executed due to organic price movement while the order is pending.
You also risk paying gas fees for nothing in the event your order isn’t executed.
Increase your gas price offer, and subsequently increase the cost of being attacked.
This also directly increases your transaction costs, however.
While both these mitigating counter-measures should always be carefully implemented, Civilization offers an entirely new, superior option to solve the problem and eradicate the risk of front-running: CivTrade, executing limit orders through the CIV smart contract.
It should be said that there are also other types of automated interactions, such as arbitrages, which can play a more healthy role of keeping markets well functioning and are not intrinsically exploitative like front-running sandwich attacks.
How CivTrade prevents front-running
How can you prevent the risk of frontrunning on Decentralized Exchanges? CivTrade.
CivTrade opens one-sided liquidity pools on Uniswap v3 on your behalf. One-sided means that, unlike traditional liquidity pairs, we can now deposit just a single token in your pool: this is the reason for the name one-sided. You will face zero risk of sandwich attack as described above, unlike those users trading against the Liquidity Pool created for you by CivTrade.
Let’s assume you want to buy CIV using ETH as an exchange token. CivTrade makes you a liquidity pool provider, so the risk of being the target of a sandwich attack is eliminated. Even if the trader that trades against your tokens deposited in the pool becomes the victim of a sandwich attack due to one of the causes described above the position opened by CivTrade is not affected, in fact it benefits from the extra volume and liquidity fees earned.
You are not subject to frontrunning bot attacks, because CivTrade operates as a liquidity provider on Uniswap v3.
CivTrade will complete your limit order transaction as soon as the market meets your target price, so you will receive the exact number of CIVs in exchange for the ETH you have decided to exchange, while earning you liquidity fees in the process. With CivTrade, you stand to benefit even from the otherwise poisonous attacks of frontrunning bots!
Last updated
Was this helpful?