6

I am working on a trading bot with ethers.js and I would love if someone could elaborate on the following topic.

Many sniping bots try to buy as fast as liquidity is added to the pool. This can be done by listening to pending transactions that include for example the method that adds the liquidity to the pair, if you successfully listen to this method you could purchase the tokens in the same block.

However if the user who adds liquidity uses a custom (proxy?) contract to add liquidity (a contract that calls the addLiquidity function for the DEX), only the call for this custom contract would be registered, and it would be impossible to know what it did, not until its block was mined and you could process the events (which should include an event that attests liquidity was added).

My question is: This looks like a very straightforward way of avoiding sniping bots. Is there any catch, besides the additional difficulty of adding liquidity this way? Or is there a way to purchase in the same block, even when the liquidity was added though an obscure call?

Thanks!

Improve this question

1 Answer 1

Reset to default
4

That is not going to make a difference, bots are looking for pending transactions that execute the addLiquidity method. In order for that to work, the addLiquidity method on the router contract needs to be executed. Whether it is executed directly or via a proxy contract, it does not matter because the method on the router contract is always executed and that is what bots are listening to.

Improve this answer
7
  • I dont think this is correct, but please, correct me. bots listen to addLiquidity, but lets see the bot deployed contractProxy a beforehand. This contract has a method called proxyLiquidity() which has no arguments. This method internally calls addLiquidity for the pair of interest to the bot. However, if you were to listen to the transaction to the contract, on its data you could only see a call to this proxyLiquidity (without its name, no way to decode it) and since it has no argument, you cannot know this pending tx will trigger the liquidity. Do I have anything wrong?
    – lobis
    May 27, 2021 at 6:47
  • 2
    Some bots actually replay all transactions to see how they change the state of liquidity pools. But they must have some limitations to their capacity so playing tricks could get you rid of at least some of the bots.
    – Mikko Ohtamaa
    May 27, 2021 at 8:19
  • I have been reading about this. sounds expensive.
    – lobis
    May 27, 2021 at 9:35
  • 2
    @LuisObis it's a lot cheaper than you'd think. If a bot has a local node (which they should, or they wont be competitive), then they can get traces for any arbitrary call almost for free. They'll track mempool and likely get traces for every single tx that happens, scan those traces for calls like addLiquidity, and act on that information
    – natewelch_
    May 27, 2021 at 13:30
  • 1
    Reading about this it doesn't seem that hard, you are right. I am not sure what type of node I would need, should this be an Archive Node? what would be the minimum node that would allow for me to do this @natewelch_? I have been toying with the idea of building a node, but the cost is too high for me right now if I run it on the cloud, I have estimated more than 500€ / month (I am doing this for learning, not to profit, won't invest much, atleast not until its proven to work reliably). Do you know if running a node locally (house), would be competitive? or would it be too slow?
    – lobis
    May 27, 2021 at 16:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.