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).
I don't understand. Could you elaborate more.
@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 ?
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%?
Exactly, set low slippage like that will prevent frontrunning/sandwich’s attacks from being profitable.
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%.