I was doing some trading this morning using my favorite dex and one of my transactions was front-run due to me leaving my slippage high from a few (questionable) trades the night before. This irritated me a bit and I’ve been hungrily consuming articles on MEV (Miner Extractable Value), mining tunnels and ‘dark-forest’ related topics lately, so I decided to take the opportunity to do a little investigation on the bot that nailed my transaction.
I pulled the contract address up for the bot’s contract and it had self-destructed, but the deployer was another contract that was still live. Using etherscan’s ‘decompile bytecode’ tool, I was able to get an abstraction of the logic that the contract was hopefully using to look for front-run opportunities. A quick glance over the decompiled code, and I was able to separate it out into recognizable libraries. The ‘safemath’ library in particular is a bit of a Rosetta Stone in these circumstances, as the math overflow checks are apparent and there are some very telling revert messages (e.g. “revert with 0, ‘mul-overflow’”).
Digging some more, it appeared that I had found a bit of a dead end. Most of the relevant code was just calling for the creation of the actual front-runner contracts and was passing arguments to them on construction. But then I noticed something, a check to see if the block’s coinbase was a certain address (0x99c85bb64564d9ef9a99621301f22c9993cb89e3) and to revert if equal.
For those unaware or unfamiliar, the coinbase of an ethereum block is the recipient address of the block reward. Meaning that whoever was running this front-runner was conveniently not front-running transactions that were mined by a certain miner. I pulled the address up on etherscan: BeePool.
After a little pondering, it dawned on me that I was staring at a brick with an advertisement for window repair attached to it.
* * * * *
It seems to me that most of the discussion revolving around MEV and mining tunnels of late has a ‘benefit of the doubt’ type tone. For a fee, mining tunnels can protect user’s transactions from being front-run usually by rearranging transaction order in a block, allowing the protected user’s transactions to be processed before the front-runner’s and causing the malicious transactions to fail. And when these tunnels are pitched to us collectively as being a value-add for the space, it is perhaps naively assumed to mean that we are being protected from unseen foreign assailants in the dark forest.
The code I observed this morning has fortunately shattered that illusion for me. This mining pool is offering protection from being front-run by bots, which is fine by itself. But this proposition seems a bit more Machiavellian when you realize that the pool is running the very bots they are offering to protect you from. Sounds a bit like extortion to me.
At the risk of sounding hyperbolic, what does it mean for the future of this space, when the monsters in the dark forest are the one’s offering us safe passage for a fee?
How many other pools out there are doing this?
How long will it be until safe passage through the dark forest is impossible without an escort?
-
Above claims can be independently verified by decompiling the deployed contract bytecode and viewing the result yourself: https://etherscan.io/bytecode-decompiler?a=0x94edc4a3065a7a42db6c57614e513992b2eb3ee4
Contract bytecode and decompiled code has been pinned on IPFS for further analysis in case contract in question is self-destructed, it can be found here: https://gateway.pinata.cloud/ipfs/QmdTGPEnejyLES9BnvW5achUeb8QAAHrreywDUszETXk7B
