5

Recently a trader extracted significant profits from sandwich attackers with a contract called Salmonella. The contract modifies the standard transfer function to send only a fraction of the requested amount to non-owners of the contract.

I assume that by this point (or in the near future) many others have copied this and deployed similar contracts.

Is there any way that generalized sandwich attackers can defend against this, or does this actually stop generalized sandwich attacks?

5

Is there any way that generalized sandwich attackers can defend against this, or does this actually stop generalized sandwich attacks?

It's important to note that these are not two zero-sum options. They could be impossible to defend against, and still not stop sandwichers. One reason would be if sandwichers are still earning (significantly) more than they're losing to the occasional food poisoner. Another would be that we can't assume that every bot operator is so aware of what happens to their bots, and may keep on running them even if they're technically getting rekt.

That all being said, Salmonella works by deploying a "poisoned" token, and seeding a Uniswap pool with it, then launching txs as bait. First, it's important to note that this attack can't be launched by simply anyone - I don't know how big the txs/gains will have to be to attract sandwichers, but this means having enough capital to seed the pool and be able to make txs of the size that attracts sandwichers. (I think I'll start calling sandwichers Earls because I think it's funny, hope you don't mind.)

Assuming that there are enough of these poisoned pools out there for Earls to be scared (a fair assumption, Ethereum can certainly be a dark forest at times, even for dark forest denizens), there should be some low-hanging fruit. (This is evidenced in the Salmonella repo, where the author even notes that the Earls detected the attack and adapted.)

  1. The attack counts on Earls simply hitting the whole list of Uniswap tokens for potential targets. If the Earls would restrict their hits to known tokens (filter by token address, not token symbol!), that should avoid all attacks, even if the Earls won't be able to attack as many pools
  2. Earls can send test txs to potential pools with a small amount and see how much they get back, and keep a whitelist of pools that have been tested
  3. Earls can verify the code of token they interact with, and not interact with non-verified tokens

I feel like it's cheating to say the Earls could focus on Sushi or another exchange, because it would be just as easy to deploy Salmonella there (and probably already has been), though the original Salmonella was on Uniswap.

This all being said, there will be future iterations on this attack. It is impossible to predict all the possible permutations of attacks in this vein. Then again, sandwiching is also hard to defend against in volatile pools where slippage pretty much has to be set high.

None of this is meant as approval of sandwich attacks, which often prey on people too naive to defend against them. In the dark forest, it would seem that we can observe that for every large fish swallowing a smaller one whole, there can be an even larger fish in the process of swallowing it too.

0

Does whitelisting tokens count as answer? Not sure if it violates the generalized frontrunner criterium.

Another way to avoid food poisoning would be to simulate the transactions on a local fork first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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