There’s a bug in Wild Credit’s code, and 10 million dollars of user funds are at risk.

It takes just 46 hours for someone to realize that the “initialize” function is public. Anyone can claim ownership of the smart contract.

An attacker abuses this owner privilege to mint tokens and drain the pool of all its Bancor.

But their transaction fails.

Mere milliseconds after submitting this transaction, a bot noticed and copied it, sniping 600 thousand dollars before the original attacker could get to it.

Before a transaction is executed, it is first sent to the mempool, a dark and scary place filled with monsters waiting to strike. To the uninitiated, a venture into this realm quickly becomes a cautionary tale. To the predator, it’s a battleground where wars are waged over blocks.

This is Ethereum’s Dark Forest.

The mempool is the waiting room where pending transactions are submitted. Roughly every 13 seconds when a block is mined, miners pick transactions to include into the new block.

To maximize profits, miners pick transactions with the highest priority fee. By convention, transactions are ordered based on this fee.

This means that if a profitable transaction is spotted in the mempool, a bot can resubmit the transaction with a higher gas fee and front-run it.

One day in the Uniswap support channel, someone asked whether it was possible to recover Uniswap liquidity tokens that had been accidentally sent to the pair contract itself.

See, when you provide liquidity on Uniswap, you get a token that represents your share of the pool. But what happens when you send the tokens back to the contract that just minted you them?

At first, the task seemed impossible. Nobody holds the private keys of a smart contract, so the tokens should stay locked there forever. However, there happens to be a low-level function in the code called “burn”, which checks its own balance of LP tokens, burns them, and returns the underlying tokens back to a specified address.

This was a ticking clock. Even if nobody else noticed the free money, anyone could remove their own liquidity at any time, which calls the burn function. They would accidentally receive these extra tokens from the contract.

So to get their funds back, the user just had to call the burn function on their own address, right? Except it’s not that simple.

The burn function could be called by anyone. If you submitted a transaction calling burn, it would be like a flashing a “free money” sign pointing directly at this profitable opportunity. Bots would copy, mutate, and front-run the transaction, taking the money first.

This free money had been sitting on-chain for about eight hours, undetected, waiting to be swept by anyone who called burn. But any attempt to pick it up would get instantly sniped.

The Uniswap support team had a plan though. They deployed two smart contracts, a getter that would only call burn if activated by the setter contract. If an attacker only tried executing the get transaction, it would revert without calling the burn function.

The idea is that the team would call the set and get functions back to back in the same block, which would hopefully execute before a bot figured out what was going on.

But they made a fatal mistake.

Because the get transaction was designed to revert without the set, Infura rejected the get because it looked like it would fail. The get transaction only got submitted in the next block, after the set had already been mined.

But it was too late. The monsters had already won.

Uniswap works with a basic principle: if you buy a token, the price goes up. And if you sell it, the price goes down.

Before your buy executes, a bot could front-run it to buy first, then back-run it to sell after. This is commonly referred to as a sandwich attack, and bots have made millions in profit from doing this at the expense of the user.

However, you can mitigate the damage by setting an appropriate slippage. This is a feature of Uniswap that tells the router to output at least some amount of tokens or revert the purchase entirely. The idea is that you can set your slippage low enough so it’s not profitable to sandwich you. But sometimes, even this protection is useless.

Recently, I was trying to buy my favorite food token on Ethereum, and I made sure to set my slippage low to 0.1%. There was barely any trading activity on this Uniswap pair, so it was extremely unlikely that my slippage would cause my transaction to revert. But my transaction still failed.

A monster was lurking in the mempool and bought thousands of tokens right before me, pumping the price by 10%. Because 10 is higher than 0.1, my buy failed.

Now, this made me mad. I had just wasted gas to do a failed swap, and now, it was 10% more expensive to buy the same tokens that I had wanted. But I had no other choice but to submit another transaction and buy the tokens at this inflated price.

Surprisingly, the bot didn’t sell right after my buy. Instead, it waited for another user to buy after me. Then, when someone else tried to sell, it front-ran it and sold first, causing that user’s transaction to fail. In total, the bot made a $750 profit: all the upside of the buys and none of the downside of the sells.

This bot does this hundreds of times a day, preying on unsuspecting users who have no idea why their transactions are failing.

Are you ready to get exit scammed? The game is simple.

To play, all you need is to buy a key. Countdown starts at 24 hours but increases by 30 seconds every time someone purchases another key. Some of the money spent is distributed to all key holders while the rest is sent into a centralized pot. The last person who purchases a key before the timer runs out wins it all.

FOMO3D was a game that was perhaps one of the most intriguing experiments in Ethereum history. It contained some classic ponzinomics for early key buyers to get a stream of money from later buyers. But at its core, FOMO3D was a “War of Attrition”. Keys only cost a few dollars while the prize pool grew to millions. The nature of the game had many convinced that there would always be another key buyer, drawing the round out to forever.

But one month later, the final key had been purchased, and the round came to a surprising end. For 12 blocks after purchasing a key, the winner used a custom smart contract to stuff Ethereum with useless transactions at high gas prices, suppressing any attempts to buy another key until the round ended.

In total, the winner spent 2 ETH in gas to win a prize of over 10,000.

Maybe the Ethereum blockchain isn’t the best place to run a time-sensitive ponzi when censorship pays.

So far, we’ve looked at ways external accounts can attack incoming transactions through the public mempool by shifting the order of transactions. But ultimately, miners are the ones who control this power.

Miner extractable value is a measure of how much profit a miner can extract through their ability to arbitrarily include, exclude, or re-order transactions from the blocks they produce.

But this term is a bit misleading, as it sounds like miners are extracting all the value. In reality, the MEV present on Ethereum today is mostly captured by bots who search for profitable opportunities. Miners only indirectly profit from the increased transaction fees.

Also, Ethereum will soon transition to proof-of-stake, so miners won’t exist after the merge. Thus, a better acronym was created to represent MEV: Maximal Extractable Value.

MEV emerges on the blockchain in a few ways.

Decentralized exchange arbitrage is the most well-known MEV opportunity. If two DEXes are offering a token at two different prices, someone can buy the token on the lower-priced DEX and sell it on the higher-priced one in a single transaction for pure profit.

Another common opportunity is liquidations. Lending protocols like Aave require users to deposit some collateral to borrow other tokens. But if the price of their collateral goes down relative to their borrowed amount, they could get liquidated.

Smart contracts can’t automatically do things by themselves, so Aave relies on external transactions to call the liquidate function and repay the loan. In this case, the borrower has to pay a hefty liquidation fee, which goes to the liquidator.

Searchers compete to parse blockchain data as fast as possible to determine which borrowers can be liquidated and be the first to submit a liquidation transaction.

MEV is not all bad. Many DeFi projects rely on economically rational actors to ensure the stability of their protocols. Arbitrage ensures that users get the best prices for their tokens, and lending protocols rely on speedy liquidations to ensure lenders get paid back.

But as these opportunities get diluted, searchers will look for more obscure ways to profit, often at the expense of users. Watch your step. The mempool is an unforgiving environment.

At the application layer, some forms of MEV, like sandwich trading, result in a worse experience for users in the form of worse prices and failed transactions.

MEV also leads to higher gas prices for users. Sometimes, multiple bots will try to front-run the same transaction, leading to a gas auction where each bot tries to outbid the other. In the end, only one bot will succeed and the rest will be left with failed transactions. This inefficient communication between bot operators and miners for order preference creates deadweight loss by wasting gas and block space.

Because of this, some bot operators bypass the mempool entirely and send their transactions to miners themselves. MEV extraction could likely go in a direction where it’s centralized to a few players, with secret transaction pools and deals between large traders and miners.

This is a problem. The power and capital centralization is a security weakness that erodes the core properties of Ethereum. But there might be a better way to utilize MEV.

Flashbots is an organization formed to mitigate the negative externalities and risks posed by MEV. They propose a fair ecosystem for MEV extraction to preserve the ideals of Ethereum.

Flashbots Auction provides a private communication channel between searchers and miners for preferred transaction order within a block. It’s a piece of software miners can run on top of traditional Ethereum that allows bots to bid for transaction ordering off-chain. Over time, more miners started running it, and more bots started to use Flashbots over the public mempool.

This greatly reduced the number of failed transactions from MEV bots and eased gas costs for users. Additionally, by democratizing MEV extraction, Flashbots ensures all miners have equal access to MEV.

Flashbots also lets users avoid the dark forest with Flashbots Protect. It’s a custom RPC you can add to MetaMask. Your transactions are sent to Flashbots instead of the public mempool. This means your transactions can’t get front-run, and if it will fail, it doesn’t get mined so you don’t waste gas.

Finally, there’s Flashbots Data, a set of tools for exploring MEV. With this, Flashbots hopes to illuminate the dark forest and quantify its effects. To date, over 600 million dollars have been extracted from MEV.

In the end, Wild Credit somehow got in touch with the owner of the frontrunner bot, who was willing to return the tokens. All user funds were recovered with zero losses. Had this transaction not been front-run, maybe things would have turned out differently. The dark forest is scary, but it looks like there are still some good people out there.

https://docs.google.com/document/d/1AV7p4sWXRL5wCA4kcfb8PWpA1hIZOYxyAmGm9svqhP8/edit?usp=sharing