How does one get such precise ordering of transactions in the same block?

Question

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.

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?

Answer 1

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:

• How do fronrunning and sniper bots work?
• What is Miner Extracted Value (MEV)?

---

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)