Front-running is when an attacker uses information about a transaction that has not yet been processed by the blockchain in order to gain a benefit. For example, if an attacker finds out that someone is going to buy a large amount of tokens, they can quickly send their transaction with a higher fee so that it is processed faster and take all the tokens before the original transaction is processed. https://ibb.co/mcMSv2Q
The standard protection mechanism is to add an additional input parameter in your contract function, indicating the minimum amount that you're willing to receive (for example, when you trade by source amount), or the maximum amount that you're willing to spend (for example, when you trade by target amount).
1 Like
I don't understand. Could you elaborate more.
Hi @RuslanKhaliapov,
@barakman is talking about implementing a slippage protection in the contracts. With that kind of protection you limit the amount of tokens that will be swapped/bought to a maximum amount.
However this does not protect you fully from front-running as an attacker could manipulate the price to take advantage of that maximum amount, and they would still extract some value.
If you really want to be as protected as you can I would suggest finding a node that provides with a private mempool. This way you send your transaction privately to the node and nobody else knows about the transaction, so they cannot front-run it. You could also run your own node and use it privately to send the transaction.
Hello . One option is to create a transaction queue in a smart contract?
How is going to clear that queue and have all transactions in it executed from time to time?
And why would anyone want to submit a transaction without knowing when it is going to be executed?
I do not know exactly. The moment I simulate that I am building a defense, other vulnerabilities appear. I don't think I'm smart enough to completely block the runner in front. It's easy money, a lot of people do it. I tracked coins on trackers. And I did not notice these bots only in smart contracts that have a tangible tax function.
If we add a 2.5% purchase tax and 2.5% sales tax function in a smart contract, will it make it harder for a hacker to use Front-running ?
1 Like
The only way to protect from front running is by the contracts that do the buying & selling like uni swap/pancake swap. As a pure token contract there is nothing you can do about it.
What are you offering? Set price slippage protection when buying and selling on the DEX? For example, price slippage should not be higher than 0.5%?
1 Like
Exactly, set low slippage like that will prevent frontrunning/sandwich’s attacks from being profitable.
1 Like
In my opinion, limiting the maximum slippage with a condition of no more than 0.5% will limit losses. But this will require more liquidity, because in order to buy or sell in the DEX pool for $20 in one transaction, there must be more than $4,000 in the pool, in order to buy or sell for $100, you need to have more than 20,000 dollars in the pool. ) But if liquidity increases greatly in the pool. Then the guys with the MEV bots will become profitable again..... Once the likely profit exceeds their commission, they will do it again. Yes, they will not be able to raise it above 0.5%. But in this case, as an option, you can add a function to adjust the allowable slip, so that after the liquidity becomes too large, reduce the allowable slip to 0.1%.
1 Like
First it should be noted that it depends upon the LP versions are being used in the routing. For Uniswap V2 LPs we can use the following heuristic breakdown for determining worthwhile swaps to backrun.
I provide this breakdown to illustrate a point: doing a single transaction will always incur greater risk of being 'abused', if possible doing a 'TWAP' or multi-block transaction for larger trades is preferable to a single block transaction. Transaction sizes should be limited per block based off of the solution provided.
Backrunning Heuristic for Identifying Swap targets
The back running result is that the function makes financial sense only when the amounts swapped by the 'victim' are large.
If the initial amount of token A in the pool is a and the victim will swap a quantity d of A tokens, when can the backrun make a profit, and what values x of A tokens does the attacker need to swap in step (a)?
The heuristic cost-benefit analysis comes down to a cubic inequality:
Problem:
{a>0, d>0, x>0, -0.003 x^3 + (0.997 d - 0.009 a) x^2 + (1.994 a d + d^2 - 0.006 a^2) x + a d^2 - 0.003 a^2 d>0}
Solution
We can therefore deduce that under equilibrium, the swap size (of the user / victim) generally needs to be greater than 0.1 % of the pool size to be a profitable back-run. Or 0.3 % as we have here:
a>0, \quad d>\frac{3 a}{1000}, \quad 0<x<\frac{1}{3}(1000 d-3 a)
Using a private RPC provider only provides some protection with no guarantee of the block builder doing the frontrunning themselves ultimately.
Reference
1 Like