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.