How to Prevent Pool Drainage - FXSwap DEX

1

Hi everyone!

As the community might be aware, our flagship product DEX - FXSwap - will be launching soon on the FX-EVM mainnet.

One of the issues the engineers will be facing is how to prevent malicious users from draining the liquidity pool available on the platform.

In particular, I would like to get in touch with our community users - @SCENE @FrenchXCore.

* How would you drain the pool using various arbitrage strategies available?
* How could we prevent malicious actors from doing this in the first place?

If there is a well known method to do this, it would be much appreciated if you guys/girls could let us know in advance.

Thanks,

Dexter

4 Likes
2

Didn’t know you were already working on it…
And didn’t think about ways to drain a LP.
I’m gonna think about it next wrrk and i’ll Come back to you.

1 Like
3

Could you describe in more details how you intend to deploy the FX Swap EVM contract, how you intend to manage transactions, etc. ?
In my opinion, you should act as in the real lire, i.e. limit the number and volume of transactions made by a single party, based on how much it owns and how much it stakes, limit the daily volume based on a mobile average, etc.
The main points of failure are :

  1. to not set any limit (volume and number),
  2. to not monitor closely warnings of unusual mouvements,
  3. to not monitor flash loans moves.

Most hacks are coming from a single point of failure :

  1. oracles
  2. non-audited EVM contracts,
  3. flash loans moves…

Regards,
@FrenchXCore

4

One of the most common arbitrage method is the sandwich bots or frontrunning bots where they front-run and back-run non stop.

Not exactly illegal but yeah, this is super common on Uniswap, PancakeSwap, Sushiswap and many others. They siphon the liquidity slowly.

  • I guess some will argue that it actually makes the market more efficient.

image
image1177Ă—317 46.5 KB

If the bot notices someone is trying to purchase a token in the mempool, the bot will front-run and purchase the token first at a cheaper price. Once the buyer buys it, the bot will then exit the position at a profit.

image

  1. Normal User places a buy order of token A
  2. Bot sees this in the mempool and front-runs it, pushing the price up
  3. Causes high slippage and the user gets a worse fill
  4. Bot back-runs user, selling back tokens at a higher price at a profit

In actual scenario, it looks like a simple buy and sell order from the same wallet.

  1. They can also manipulate gas price & timestamps to frontrun for slow-matching dexes.

They don’t need to target large value transaction, it can also be done with small/mid value.

image

Enable “Limit Order” on FXSwap, this is what PancakeSwap did.

Not exactly a solution to the bots but this give users an extra layer of protection if they can buy/sell using limit order. With this, bots will have a harder time targeting people who just market swap.

PSC implemented a chart + limit order so the average user know what is going on in real-time at all times.

I private messaged you already, Dexter.

  • There is no 1 solution that can fix this but one of the MOST important thing is to have a large liquidity pool.

Suggestion:

  • I would suggest opening the liquidity provider pool first before the swap so the foundation and community members can help by providing enough liquidity to the pool first.

Just like how some exchanges open deposits first and wait till there is enough liquidity in the system before they open the trading for the new pair.

The method is designed to make frontrunning “harder” to execute, not totally prevent it from happening.

Frontrunners LOVE low liquidity pool because they can take advantage of the pool weight.

  • Periodic auction matching
  • Keep slippage as low as possible
  • Frontrunners love slow transactions and they will always overpay gas fee to go first
  • Quick matching - Fast block time will make most (not all) frontrunners not able to react

I think there are some more but i think too many to type here.

Not sure if this article will be of any help but some devs are trying to build something to protect users against bots. Maybe you will be able to find some ideas here.

  • Another method is triangular bots i guess

https://blog.coinbase.com/quantitative-crypto-insight-an-analysis-of-triangular-arbitrage-transactions-in-uniswap-v2-1b572284bfa8

1 Like
5

I think I was out of subject in my response. @SCENE is much more relevant.
Another solution would be to set a time limit between buy and sells, like 1-3 blocks minimum, to prevent flash frontrunners.

1 Like
6

For the average user who do not want to get front-run or at least lower the chance of getting frontrunned, always use “Fast” when swapping instead of “Normal” or “Slow”.

Consider overpaying in gas fee if you plan to do a large transaction. This will not give the attackers enough time to target your order. If not, always do it in small orders.

Note: This doesn’t mean it will protect you 100% from getting sandwiched. This is to reduce the probability only.

Tips:

  • Consider overpaying gas fee if you want to do a large transaction
  • Avoid low liquidity pools ( Bots love the imbalance weight )
  • Set the slippage as low as possible
  • Place smaller orders over a gradual period of time while letting the liquidity refill itself

These are some of the tips given to reduce your chances of getting front-runned.

image

1 Like
7

Thanks @SCENE @FrenchXCore - I will go over both your material in depth and once I understand the content, I will get back to you with more questions.

In the meantime, please look forward to our FXSwap - this will be launching soon! :grinning:

Cheers

Dexter

2 Likes
8

For anyone that wants to know more about MEV / Frontrun bots.

Noxx recently did a deep dive into MEV bots.

  • This is a very interesting article, i recommend you to read it.

This concept was first applied in the context of proof-of-work.

  • Initially referred to as “miner extractable value”.

This is because in proof-of-work, miners control transaction inclusion, exclusion, and ordering.

However, after the transition to proof-of-stake via The Merge, validators will be responsible for these roles, and mining will no longer be applicable. The value extraction methods here will still persist after this transition, and thus the term “miner extractable value” is no longer valid.

  • “Maximal extractable value” is now used as a more inclusive replacement

image

PoS & EIP-1559 is still vulnerable to MEV / Frontrunning bots.

You can follow Noxx on his twitter - he does a lot of deep dives about blockchain.
→ https://twitter.com/noxx3xxon

Bertcmiller’s Twitter too - A thread of all MEV related threads
→ https://twitter.com/bertcmiller/status/1402665992422047747