MEV Is a Trap and the Smartest Bots Are the Prey

syang · July 1, 2025, 2:39pm

There is nothing new under the sun.

And if you gaze long into an abyss, the abyss also gazes into you.

Searchers — often regarded as some of the most sophisticated actors in blockchain / DeFi — continuously monitor on-chain state to identify and exploit profit opportunities. Through these mechanisms, many searchers have extracted substantial profits — as illustrated in the libmev leaderboard screenshot below.

However, as they hunt for arbitrage and extraction in the dark forest of MEV, one must ask: are they also at risk of becoming prey themselves? In this post, we examine real-world incidents through case studies, focusing on traps that MEV searchers have fallen into — what we call MEV phishing attacks, where an adversary crafts a deceptive MEV opportunity as bait to exploit the MEV searchers.

Background

Why have MEV searchers become targets — or “prey” — for hunters? The simplest answer is: by continuously extracting MEV opportunities, these searchers accumulate large amounts of ERC-20 tokens in the smart contracts they use (i.e., MEV bots). This concentration of assets naturally attracts attackers, who aim to take control of the tokens held by the searchers.

What is the security issue behind?

Long story short, the key issue lies in the access control mechanism of the MEV bots’ contracts. Ideally, the contract should enforce access control that blocks any external calls while allowing expected calls from specific contracts, such as a Uniswap V3 pool. However, implementing such fine-grained access control on-chain is expensive due to gas costs. For example, a rigorous check to determine whether the caller is a Uniswap V3 pool would cost about 450 gas.

contract UniswapV3PoolAccessControl {
    address FACTORY = 0x1F98431c8aD98523631AE4a59f267346ea31F984;
    bytes32 POOL_INIT_CODE_HASH = 0xe34f36d28c5efcd7c58e2e84af79e2adffbe52f705d05dca7e6a181f8a19baf1;
    function verifyPoolAccess(
        address token0,
        address token1,
        uint24  fee
    ) public view returns (bool) {
        bytes32 salt = keccak256(abi.encode(token0,token1,fee));
        address computedAddress = address(uint160(uint256(
            keccak256(abi.encodePacked(
                bytes1(0xff),
                FACTORY,
                salt,
                POOL_INIT_CODE_HASH
            )))));
        return computedAddress == msg.sender;
    }
}

Meanwhile, a cheaper solution is to use tx.origin to block direct external calls. For example, if tx.origin does not equal a predefined address, the execution will revert. Such a check only consumes 8 gas.

Then we would know that this is insecure, as once an attacker successfully becomes part of the call chain of the MEV bot contracts, they can bypass the tx.origin access control check. Though this may seem difficult, the nature of searchers — constantly searching for and extracting MEV opportunities — creates such an opening.

MEV supply chain

When can a malicious attacker successfully become part of the call chain of MEV bot contracts? The simplest way is to participate in the MEV supply chain.

An illustration of the MEV supply chain is shown below.

(a) The searchers listen to the mempool and blockchain state to identify an MEV opportunity.
(b) Once a searcher identifies an MEV opportunity, it sends a transaction to invoke its MEV bot contracts.
(c) The MEV bot contract then performs a trade on the DEX, which involves the transfer of specific tokens.
(d) The transaction is sent to the builder for inclusion and eventually finalized on-chain through MEV-Boost auctions between builders and proposers. While this part is out of scope, we will not elaborate on it.

The important point is that the DEX and the tokens involved in the searcher’s transaction are already part of the MEV bot contract’s call chain — tx.origin is the searcher’s address.

MEV-phishing Attacks

The term MEV-phishing attacks is used because the strategy closely resembles traditional phishing attacks. In classic phishing, an attacker lures the victim into taking an action — such as clicking a malicious link — by presenting a seemingly legitimate opportunity. Similarly, in MEV-phishing attacks, the attacker crafts a malicious MEV opportunity to bait MEV searchers into interacting with it.

When a searcher captures the MEV opportunity and submits the transaction, their MEV bot contract executes as usual. However, the opportunity was crafted in such a way that the attacker becomes part of the call chain during execution. This allows the attacker to bypass common access control mechanisms (tx.origin checks) used in many MEV bot contracts. Once inside the call chain, the attacker can drain the contract’s balance. Just like traditional phishing, the attack hinges on deception and baiting the victim into initiating the harmful interaction themselves. Here we analyze three variants of MEV-phishing attacks, each leveraging a different party in the MEV supply chain to execute the attack.

Variant 1 - Token-based MEV-phishing Attack

A typical example of a token-based MEV phishing attack was first studied by https://x.com/bertcmiller/status/1421543838569705474, where a victim searcher attempted to arbitrage the CHUM token, which was specifically created as bait.

The workflow is not hard to understand:

The attacker first creates a malicious token such as CHUM. In the token contract, the attacker modifies the standard implementation of transfer so that, when this function is executed, it exploits the vulnerable function within the target MEV bot contract to drain its balances.
The attacker then creates a Uniswap V2 pool (or any other pool) for the malicious token.
After creating the pool, the attacker generates an MEV opportunity using this pool — for example, by performing a swap. This transaction is broadcast to the public mempool so that the targeted searcher will detect it. The searcher follows its usual workflow to extract MEV.
a. First, the searcher identifies the MEV opportunity from the mempool.
b. To capture the MEV opportunity, the searcher invokes its MEV bot contract.
c. The MEV bot contract performs a swap on the pool to extract MEV.
d. As part of the swap, the pool transfers the malicious token. Now, the malicious contract is successfully included in the call chain! (call chain: searcher → MEV bot → pool → malicious token, so tx.origin is always searcher)
The predefined malicious logic is triggered. The malicious token contract can invoke a specific vulnerable function in the MEV bot’s contracts and drain the ERC-20 token balances.

Variant 2 - Pool-based MEV-phishing Attack

The second variant of the MEV phishing attack is based on a malicious pool — once the searcher performs a trade through this pool, it initiates an external call to the MEV bot contract to drain its ERC-20 token balances.

A typical example of a pool-based MEV-phishing attack occurred in March 2025: https://etherscan.io/tx/0x1b539dbd898971f5296cea65c5af766df34f13dd7c1bea38e6700364847dc0d9 . Instead of using a malicious token, the attacker created a malicious pool for attacking.

The workflow is also easy to understand:

The attacker first creates a malicious pool. All tokens in the pool are benign. In the pool contract, once a swap is executed, it will exploit the vulnerable function within the MEV bot contract.
Similarly, the attacker creates an MEV opportunity and broadcasts it. The searcher’s workflow is similar.
When the MEV bot performs the swap in the pool, it follows predefined logic that is crafted to attack the MEV bot contract. (call chain: searcher → MEV bot → malicious pool.)

For example, in the attack example, the MEV bot executes ExactETHForTokensSupportingFeeOnTransferTokens to perform the swap. During execution, the DEX protocol pays a protocol fee to the deployer.
```
// 50% of buy protocol fees go to the deployer
(bool sent1, ) = IXpPair(UniswapV2Library.pairFor(factory, path[0], path[1])).payableProtocol().call{
    value: buyProtocolFee_
}("");
```
Although the code appears normal — it pays protocol fees to the developer — payableProtocol() actually returns a malicious address. Once this malicious address receives the protocol fee, it invokes a vulnerable function in the MEV bot contract and drains the balances (the tx.originaccess control is bypassed). The specific call chain in this example is: searcher → MEV bot → malicious pool → malicious protocol fee address.

Variant 3 - Refund-based MEV-phishing Attack

The third variant of the MEV-phishing attack is also sophisticated — it exploits a feature of certain MEV refund services that require the searcher to send a refund to a user address within the same transaction. A typical example of this variant is https://etherscan.io/tx/0x26361798094d7532c0b8dfbed4c857265c66391040eef07f91fafcd420d47df0

To enable this attack, the attacker first deploys a malicious contract to serve as the refund address.
The attacker then creates an MEV opportunity involving a swap, which is submitted to the MEV refund service. Both the tokens and the swap pool conform to standards, thereby avoiding detection mechanisms that target non-compliant tokens or pools. The attacker specifies that the malicious contract address is the address that should receive ETH refunds.

Similarly, the searcher follows the same workflow as before (b–d), except that:

(a) It receives the MEV opportunity from the MEV refund service;

(e) As part of the protocol, the searcher must send a refund to the specified address when attempting to capture MEV from this opportunity.
Upon receiving the refund, the malicious logic in the malicious refund contract is triggered and invokes vulnerable function within the MEV bot contract using crafted calldata. Because the transaction originates from the searcher, it bypasses tx.origin based access control and allows unauthorized token transfers to the attacker. (Call chain: searcher → MEV bot → malicious refund address.)

Summary

In summary, in MEV-phishing attacks, the attacker deploys a malicious contract (such as a token, pool, or refund address), and this contract contains predefined logic that is triggered during MEV extraction. For a malicious token, the logic is triggered during token transfer; for a malicious pool, it is triggered during a swap; and for a malicious refund address, it is triggered when the contract receives ETH. The triggered logic exploits a vulnerable function within the MEV bot contract and drains its balance.

Conclusion

In this post, we introduce the background of MEV-phishing attacks and study its three variants, token-based, pool-based and refund-based. Through these case studies, we can draw the conclusion that MEV is a dark forest, and searchers can also become someone else’s prey. This post highlights potential threats to searchers, with the broader goal of enhancing the MEV ecosystem and promoting a more decentralized and transparent MEV environment.

This post is part of my joint work with Kaihua Qin, Aviv Yaish and Fan Zhang. In this paper, we find that MEV-phishing attacks targeting MEV searchers occurred from 2021 to 2025, causing at least $2.76 million in losses to searchers. From both the time span and the amount of financial loss, such an attack represents a serious issue that cannot be ignored.

There are some lessons we must learn (or suggestions for searchers):

Be cautious with MEV opportunities. Always simulate the transaction beforehand and verify the balance differences after the simulation.
Attackers can exploit any party involved in the MEV supply chain. This could be a malicious token, a malicious pool, or a malicious refund address. As DeFi and MEV continue to evolve, more parties become involved—and any of them could be malicious. For example, with the introduction of Uniswap V4 hooks, extra caution is needed, as a hook could also be designed to perform an attack.
Please check the MEV bot contracts. If any issues arise, please upgrade promptly. They could already be the targeted prey of the hunters.