I’ve been observing a bad actor (or multiple) who are aggressively sandwiching trades on mento/ube/sushi/etc…
Prime example from tonight:
Someone traded WETH for Celo
In that block, the transactions to contract 0xc5364401cc1da9F8864a903C20Ed490D0A265104 performed the sandwich attack, “stealing” roughly $7 of extra slippage on the victim
This has been going on for at least 2 months, and I have some good ideas on how to build an automated bait system to trick the sandwich bots and force them out of the network (since each baited sandwich causes them to lose 60 bps swap fee).
The way that these sandwich bot work is they listen to the mempool and do eth_call/eth_gasestimate on any trades going into a DEX, and if that trade is valid and sufficiently large, they launch the sandwich.
For obvious reasons, we should not open source the bait bot or else these sandwich attackers will adapt to our strategy.
What does the community think of funding some R&D to build & operate bait bots to ward off these sandwich attackers?
The amount of funding requested for development & operating the bait system would be ~500 cUSD / month, and we can set the performance metric to be successfully weeding the entire network of these sandwich attackers.
I’m also just honestly really annoyed at bots that intentionally harm our users like this, it’s unethical.
I agree with you and feel the same. I would love to understand more about the mempool mechanics that allow these negative incentives and if there is anything in the mempool or AMM design that can prevent it from happening. Would you agree to an informal call to give some insights into the mempool mechanics & dynamics?
Do you have data on how much users are loosing and attackers are gaining per week?
On March 17th I noticed an interesting dynamics. I am wondering whether there was sandwich bot involvement during this time period?
the Celo price jumped
cUSD/USD depegged >1
Mento had massive negative net demand, i.e. contractions
My interpretation: Traders wanted either to get long Celo exposure really badly or to profit from delay arbitrage which is both in the opposite direction of the intended direction. This caused an increased demand and a depeg for cUSD. The slippage was very high, hinting at pressure to get Celo exposure rather than delay arbitrage.
The massive slippage on the CEX side is probably due to CEX/DEX arbitrage traders not coping with the large volume efficiently. I don’t trade on the CEX side so can only guess at why their systems failed to maintain the peg during high volatility. Most likely reason I can think of is that the amount of the spike was high enough that it saturated their non-CELO capital reserves, and their automated system for re-balancing was hitting its safety thresholds or not rebalancing frequently enough.
Over on the DEX side, March 17th had a bunch of market inefficiencies because when the sorted oracle short circuited (i remember 2 or 3 time that night), Moola’s price feed oracle (which reads from official SortedOracle) crapped out when the last price was more than 10mins stale (a consequence of circuit breaker).
The moola oracle wasn’t designed to fail gracefully, so any mcUSD/mcEUR ↔ cUSD/cEUR conversions straight up reverted Outside of mento, the deepest cUSD liquidity pool is Ube’s celo:mcUSD/mcEUR pool and almost all arb routes go through those pairs.
Specifically, arbs almost always run through the mcUSD/mcEUR pool, convert to cUSD/cEUR, and then trade back into mento to equalize the prices. This loop couldn’t be completed because Moola’s lending pool contract was failing, so for hours at stretch, many of the biggest arb bots on the DEX side were knocked out.
I’ve submitted a contract fix for the Moola oracle to do proper fallback in future circuit breakers, it will deploy soonish:
So the community as a whole already lost $649 to just this sandwich attacker, not counting any other current / future sandwich bots on network. The operator might also just tune their system for more aggressive extraction over time as well, it’s only been the first month for this particular one.
ETH mempool is a very adversarial place precisely because of predatory bots like these.
Celo didn’t have these predators last year, only in recent months they started popping up.
On ETH, it’s technically possible to run bait bots to ward off these sandwich bots, but it cost a lot of real world $ GAS and nobody’s funding it. On Celo, gas price is trivial, so all that really cost is R&D and operations of the bait bot.
Without giving away too much detail, at a high level, the network of bait bots need to do the following:
actually hold sufficient capital in its wallet for a large trade
submit a perfectly valid mento / ube / sushi / mobius trade that look just like an ordinary human swap tx
predator sandwich bot that is listening for victims in the mempool will submit its sandwich, paying 2*30bps for the two legs of the trade
some magic that cancels out / prevents the valid trade from actually going through (so that the bait bot’s capital is not depleted over time by the 30bps trading fee)
Secret sauce is all about the various ways to make #4 happen and randomizing the bait bot’s wallet over time so that sandwich bots cannot use a simple blacklist.
Successful bait cost sandwich bot to lose 0.6% of capital, compound this over a single night of baiting and we would whittle away any sandwich bot’s reserves in a few hours.
Run this baiting system on random intervals 24/7 and any new sandwich operators coming into Celo will be taught a painful lesson before they even get to scale up.
Love the idea of a bait bot as a defense. I would support and rally for this. Have you thought about where to get the funding from? Requesting funds from the on-chain community fund with an official CGP or a Celo foundation grant come into my mind.
This sounds like the perfect use case for a Celo foundation grant to me, especially as the outcome of less sandwich bot activity would be well measurable: Form
Sandwich attacks are the dominant MEV extraction method there, and the mining pools are being bribed to re-order transactions to carry out such sandwiches.
Here’s a simple idea I’ve been thinking about for a long time and never looked into the literature enough to tell whether it’d help, but thought I’d throw it out there in passing. Obviously, it’s very hard or impossible to eliminate MEV in a system where txs are gossiped, and you don’t have multiple steps to commit-reveal transactions, or validators make commitments to specific txs in a block, and orderings over them. But my idea was that since Celo includes on-chain randomness that is revealed by a proposer, that randomness could be used to determine and require transactions in that block to be ordered according a specific permutation (e.g sorted by randomness_N xor randomness_[N-1] xor txhash). The validator still gets to pick the txs to include, and still therefore is likely to include those whose gas price is highest or MEV is greatest, but they would need to grind parameters (eg amounts) in the tx rapidly to get a specific ordering. Since only the upcoming proposer knows this randomness, and only for the 1 block before proposing, this makes it very hard for bots snooping the mempool to assure any kind of ordering at all within a block. The proposer can still extract MEV – it would have <=5 secs to grind tx params to get the ordering it desires. The tx ordering logic could be added without a hard fork; of course, you’d need a hard fork to change the block verification code and make the ordering required. Would welcome thoughts.
Random TX ordering is going to cause a lot of chaos.
Today, MEV is a game of latency, the fastest bot wins.
If TX ordering is random, MEV becomes a spray and pray game and you will see bots shoot a ton of low gwei TX in the hope that it randomly lands at the right slot in the block…
I’m quite confident that I can stomp out all of these sandwich bots from the network with the bait system, and for each of the remaining malicious bot behaviors on the network, we can figure out strategies to dis-incentivize them.
Another idea for reducing the impact of sandwich attacks in a quick way could be asking DEX UIs to suggest (with a warning/disclaimer on the page) a lower slippage tolerance for high volume txs. Considering a lower slippage I think it could happen two thing depending on the sandwiching bot logic:
If the bot is taking into account the slippage/ amountOutMin of the tx they are sandwiching, with low slippage the profit will be reduced and eventually would be low enough to make it not attractive, reducing the losses for the legit user.
If the bot is not taking into account the slippage, the legit DEX tx could eventually fail, but the bot would commit losses for the gas but specially for the swap fee, which could be make very unattractive to run the bot any longer under these circumstances.
The drawback of this approach could be an increment of failed legit txs during more volatile periods, although I have not data about how well performs the DEX exchanges in terms of slippage, but at least I think personally that would be the approach I’d suggest someone that wants to make a high volume exchange in a DEX.
