6

This looks like a "sandwich" (aka front running) attack executed in the same block 12564977. The transaction in the middle was buying KEK from a Uniswap pool. Someone was able to "wrap" this transaction with with a "pre" and "post" transactions. The "pre" transaction bought KEK from the same pool and pushed the KEK price up so the "victim" tx was force to buy at a higher price. The "post" tx sold KEK to the pool and realized 0.145 ETH in profits.

enter image description here

My questions are:

  1. How is it possible to control transactions ordering so accurately?
  2. How come "pre" and "post" transactions have 0 fee yet they appear at the very top of the block and right around the "victim" tx? Is it the miner creating those transactions themselves?
2
  • Interesting find, I wonder if it could be an "inside job" with the miner?
    – JVillella
    Jun 4 at 16:11
  • My guess would be that the 0 fee strongly suggests the miner wrapped the victim transaction with the extraction transactions before starting the search for the nonce. Possibly someone else will chime in with another way a 0 fee transaction gets mined. Jun 4 at 16:22
3

This looks like a "sandwich" (aka front running) attack executed in the same block

Yes.

How come "pre" and "post" transactions have 0 fee yet they appear at the very top of the block and right around the "victim" tx? Is it the miner creating those transactions themselves?

The miner was paid directly, rather than through gas fees, by an attacker wanting to front-run the victim's trade.

If you look at the "post" transaction, specifically at the internal transactions, you'll see there was a transfer of 0.129472988593493943 ETH directly to the miner's address.

This is only paid on the post transaction, therefore incentivising the miner to construct the pre-vitim-post bundle, in that specific order.

To bring all this about, the attack - via this contract - involves a block.coinbase.transfer(<amount>) call. (When the block is mined, block.coinbase is set to the miner's address.)

Miners can watch the mempool for transactions offering to pay them directly, and will then construct the sandwiches if the direct fees are sufficient.

For more information on Miner-Extractable Value (MEV), see:


Edit:

While miners can watch the mempool for transactions that pay them directly, in this specific case, that didn't happen.

If you look at the top of the page for any of the transactions in the bundle, you'll see a purple "Private Transaction" label, below the page title. This means that Etherscan didn't see the transaction being broadcast to the public mempool, which means the attacker was either a) the miner themselves, or b) someone with access to the miner's dark pool. (A dark pool is a private/permissioned mempool that users pay to get access to. See: Escaping the Dark Forest)

2
  • thank you @richard-horrocks! How does bot or its owner communicate to the miner which TX should be "sandwiched"?
    – regata
    Jun 4 at 20:24
  • 2
    Good question - not entirely sure in this case, but in general I think you'd use a bundler, such as github.com/flashbots/ethers-provider-flashbots-bundle. Though I've just spotted something interesting about this set of transactions - I've added an addendum to my answer :-) Jun 5 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.