TL;DR: As it turns out, “general front-running arbitrage bots” that can steal earning opportunities on the Ethereum blockchain, which were only thought to be theoretically possible, are indeed very real. The existence of such bots proves once more that arbitrage trading is a game for professionals, not amateurs.
A few weeks ago, a DeFi thought leader named Dan Robinson published a great story on how his team lost a potentially profitable DeFi arbitrage to what he called “a monster.”
The monster he was describing was a generalized bot that can identify profitable DeFi transactions and kill them by getting there first and claiming this profit (an act known as “Front-running”).
In this post, we take a glimpse into this monster’s eye and provide new evidence that shows how the bot can devour generic opportunities, not only specific ones.
The monster attacks
The blog linked to above describes how Dan and his team tried to salvage users’ funds mistakenly locked in a Uniswap contract and vulnerable to extraction by anyone who knew what to look for. All that was required to extract the funds was to call a special `burn` function of the Uniswap contract, which would result in a contract rebalancing and payment of the locked funds to the caller.
Dan’s team was aware of the possibility of a front-running attack. They understood that all transactions are visible in the Ethereum txpool (mempool) for a short period before being executed. They knew observers of the network could see and react to the transaction before it was included in a block and could get ahead in the mempool by paying a more significant fee (front-run the transaction).
Taking this into account, Dan’s team wanted to cover their tracks as much as possible. This meant not executing the call to ‘burn` directly, but instead using a set of special smart contracts that only run the call to `burn` once carried out in the right order. However, this method wasn’t successful. The bot got there first, taking the $12K worth of tokens from the contract.
The evidence of this race is very much visible on the blockchain. In the screenshot of the Ethereum block below, we can see the bot’s transaction in the red frame at the bottom (lower is earlier). We can also see Dan’s transaction at the top with the red exclamation mark signifying it failed because the money was already taken.
Looking deeper into the abyss
The critical part of this story is the writer’s description of a “generalized” arbitrage bot. This bot knows how to watch specific transactions and arbitrage opportunities but can analyze any transaction that might make them a profit. Such a mechanism is much scarier because it means that no transaction is safe.
To find out more about how generalized this specific bot was, we performed a quantitative analysis of the bot’s activity in the last 30 days using duneanalytics.com. Over this period, approximately 8,000 of the transactions were on DEXs, such as Uniswap. Some liquidations were also performed on Compound (bot liquidation example), indicating that the bot is quite versatile.
However, this versatility doesn’t prove the bot is generic, so we dived deeper into Dan’s specific case. Following the trace of the bot’s transaction, we observed that the burn function of the Uniswap contract was called during the execution.
Usually, the call to `burn` emits the `Burn` event, which is triggered by calls to remove liquidity. However, in this case, the burn function was called directly in an unusual manner, precisely as it would if the team succeeded in executing their special obfuscation contract. This suggests the bot had “copied” it from the team’s transaction and was not pre-programmed to do so. (There may be other contracts associated with the same bot operator that have performed a “direct burn” before, but it is more complicated to find every transaction that could be associated with the operator).
To stress this point further, the only time (according to Dune Analytics), a `Burn` event was triggered by this bot was during this event. This means that even though the bot hadn’t previously executed a transaction in this specific scenario, it could still successfully intercept the call to the `burn` function. This implies that the bot is not programmed to do only specific tasks, but can exploit opportunities not seen before.
How to create a monster
As Dan and Georgios recently discussed on Hasu’s podcast in an episode about this very case, such a bot may be able to achieve this generalized behavior by replaying all transactions in the mempool, as if they originated from the bot’s address. If some profit is to be found, they copy the transaction and rebroadcast it as their own (or even a part of a transaction).
To circumvent this, the team tried to obfuscate the call to ‘burn’ by hiding it within a contract. The call to ‘get’ would fail unless a previous call to ‘set’ has already been complete. Unfortunately, in this case, the call to ‘set’ was completed long before the block where the ‘get’ was called. (In fact, ‘set’ was called several times). The getter was effectively already “unlocked,” making it easier for the bot to detect a successful execution.
Therefore, we can’t know whether this would have worked if the transaction were executed as intended. It’s possible to envision that even with a successful obfuscation, an advanced bot could run a modified EVM version, where simple reverts on ownership and source addresses are ignored and replaced with the bot owner’s address.
Conclusion
The existence of such generic front-running monsters proves once more that arbitrage trading is a game for professionals, not amateurs. In the long run, these types of bots pose some challenges to Ethereum and its applications.
For applications that rely on third-party arbitrage closing to function properly (e.g., Compound’s liquidations), these bots might be detrimental to security and lead to real arbitrageurs not participating in a game they know is unwinnable. The bad news is that all of the challenges discussed in this post get amplified if/when miners start running these types of bots themselves.
Ultimately, the next challenge for system and protocol designers is how to make the processes involved in arbitrage trading fairer by using a method that strengthens system security.
