Our investigation starts with this massive - but otherwise innocuous - Flashbots transaction that has 0 gas price and a payment of 80 ETH to a miner. Makes sense.
It looked at first like someone sniping a new token on Uniswap.
Token snipers watch the mempool for new tokens on Uniswap. If they find a new token they'll use Flashbots to place a huge buy transaction immediately after the token is listed. Then they dump them later.
Here's an old thread about a different token sniper
I expected to find a new token listing right before this bot's buy, but I realized immediately something was off.
There was no token listing and in fact the token sniper with the 80 ETH Flashbots transaction actually got rekt by a sandwich bot with 1 gwei txs!
What happened?!
This time I knew what to look for. There was an uncle block right before, so I pulled up the tx data from Alchemy again, and searched for the Flashbots transaction's hash. Immediate hit.
An uncle bandit struck again, this time for much more ETH.
The unfortunate thing for the token sniper is that their transaction paid the miner 80 ETH. And since the miner was Ethermine they paid the party that rekt them.
So Ethermine's take home here: 80 + 45 = 125 ETH or about 1/3rd of a million dollars.
To be clear about this Ethermine was using public data that others could have gotten.
Other non-miner bot operators could have sandwiched it using Flashbots. This probably would have happened eventually had Ethermine not done so first.
However Ethermine runs their own bot and doesn't accept bundles from others. Since they mined a block immediately after the uncle there was no chance for a Flashbots bot to capture this MEV.
Of course we hope that changes and Ethermine joins Flashbots sometime soon.
Lastly the token sniper and other Flashbots bot operators can defend against this happening by using a contract that checks the block # or block parent hash. There are many other bots that do this now.
That is the end of our story today.
As always check out Flashbots' Github to learn more and get involved if you're interested in mitigating MEV's negative externalities:
Today 95% of blocks on Ethereum are built by just two parties. This centralization threatens Ethereum's neutrality and resilience.
BuilderNet provides a decentralized, neutral, and open alternative, and the first release is live today.
The first release is a big step towards decentralized building by introducing "multioperator" building - where many parties can operate the same builder in a TEE, which users can verify. The initial operators are the Beaverbuild, Flashbots, and Nethermind teams.
The most vain searcher on-chain and all the ways they flex 🧵
We're looking at 'bigbrainchad.eth' from the dark forest; a bot that exploits contracts the block after they become vulnerable
Beyond the name and the MEV extraction, they flex on chain in a few ways that you might not have ever seen before
To start, all their transaction hashes start with 0xbeef - a flex I've seen any of the other mempool monsters do where they proof-of-work style mine a transaction hash prefix!
So not only do they extract MEV, they also take the time to mine a vanity hash
A brief thread on a novel MEV searching strategy, where we chase the trail of a mysterious bot backrunning private flow and reveal how they do it.
@blairmarshall pointed out a bot that appears to have private access to user orderflow that was landing bottom-of-the-block blocks on the Flashbots builder. That didn't make sense to me. We don't run backrunning bots! So we investigated.
MEV-Boost payments were at an alltime high yesterday, totaling 7691 ETH (!) which is nearly double the previous ATH of 3928 ETH during the FTX fiasco this fall.
A few statistics on MEV on Ethereum yesterday in this thread
You can't compare stats these 1:1, but the ATH for daily miner profit from mev-geth was 6397 ETH in June 2021. That's the *profit* of running mev-geth vs a vanilla mempool mining client.
A similar metric here would be the difference in payment for validators from running mev-boost or not. There's not a great up to date estimate of this out there I think
You could derive it by looking at the value of the mempool builder we submit (0xa1defa) and the winning block