MEV Bundle Failure: Troubleshooting Why Your Bundle Didn’t End Up On-Chain

Opportunities for extracting MEV have exploded as DeFi has transformed into a multi-billion dollar industry. This has led to an increasing number of web3 participants turning to MEV searching as a potentially lucrative exercise.

While the process for submitting bundles is fairly straightforward, the competition is fierce. Newer searchers may have questions regarding what went wrong with their bundle submission. Below, we’ll outline basic information on MEV bundles and some of the reasons why your bundle may have failed to make it on-chain.

What is an MEV Bundle?

In crypto, users submit transactions to the mempool - which, for the most part, is public - for inclusion into the next block. This means that MEV searchers can see pending transactions in the mempool and know what the effects will be once they finalize on-chain. 

They use this visibility to strategize and execute MEV strategies. Let’s take the example of a simple arbitrage.

Once a searcher detects a transaction that might cause an arbitrage opportunity, they can send two transactions that will complete the arbitrage opportunity directly into the mempool or to a block builder that will execute the transactions as an MEV bundle. 

Sending these transactions as a bundle offers a significantly greater chance of success to searchers than using the mempool directly. This is because bundles allow searchers to provide higher direct payments to validators for the same MEV opportunities. If they use the mempool instead, they have to bid the same gas price as the mempool event they are trying to utilize for arbitrage. This extra cost could be the difference between getting the bundle on-chain or losing out in competition to another searcher.

If a bundle is sent correctly, the same block will include the mempool transaction that creates the opportunity + the searcher’s transactions. As a result, the moment the arbitrage opportunity emerges it is also completed by the searcher’s bundle. 

The process of constructing bundles is complex and usually involves more than the simple arbitrage strategy outlined above. We outline how to construct bundles within our article on refining MEV strategies with Blocknative. For further education on identifying arbitrage opportunities in the wild, we recommend our guide to building an MEV bot.

Why do Bundles Fail?

Now that we know what bundles are, let’s tackle why a bundle might fail to make it on-chain.

Reason 1 (Most Likely): Bundle outpriced — the bundle scored lower than someone else’s

The most important job for an Ethereum block builder is to deliver high-value blocks. MEV-Boost works by selecting the highest value blocks from available builders, so builders in turn select searcher bundles based on the value they provide.

Builders use proprietary algorithms to monitor the bundles being submitted to them and calculate which ones will produce the most valuable block. This means that more profitable transactions will generally be favored. Fee per gas used, priority fee, and direct validator payments (coinbase transfer) determine bundle profitability.

If a searcher’s competitors bid more for the inclusion of transactions related to the same arbitrage opportunity, the searcher’s bundle will fail to make it on-chain. This is the one cause of bundle failure because, as the number of searchers and attention paid to MEV opportunities has grown, new methods have emerged for leveraging competitive advantages in bundle profitability.

While searchers cannot compare their bids to competitor bids in real-time, it is possible to analyze the situation after the fact by:

1. Identifying the exact bundle (if any) that conflicted
2. Comparing the conflicting bundle's effective priority fee

In the case where a bundle is being outbid, the effective priority fee will need to be increased. Searchers can either pay more to the builder or validator, or use less gas to accomplish the same opportunity, this is known as gas golfing. Gas golfing is primarily focused on optimizing how searchers interact with a contract’s use of storage.

Reason 2: Reputation scoring

Block builders offer publicly available RPC endpoints for searchers to submit bundles. While this is convenient from a searcher’s perspective, it puts builder infrastructure at risk of being spammed or DOSed by inexperienced or malicious actors. 

To counter this, most builders put in place reputation scoring systems to filter out searchers who use an excessive amount of computation resources. For example, Flashbots uses the reputation scoring formula found here. In general, the best practice for increasing searcher reputation amongst builders is to submit bundles that consistently land on-chain by being more profitable than the competition. This is done by either using smart contracts in a more gas efficient manner or finding other ways to increase validator payments.

Reason 3: blocknumber that is incorrect

Every bundle must designate a specific block number to be included in. Usually, this is blockNumber +1, where blockNumber refers to the current block. 

It’s important to note, however, that every millisecond counts for searchers. If a searcher is using a local node that is slightly behind the rest of the network, there is a chance that they could submit a bundle as blockNumber +1 when that block has already been propagated to portions of the network. 

Reason 4: Latency issues kept the bundle from reaching the block builder in time

Similar to the issue above, it is possible for a searcher’s bundle to be sent at the proper blockNumber but to have an invalid block number by the time the bundle is ready for inclusion. This is because all of the following actions need to be completed before a bundle officially goes on-chain:

1. Reach the block builder
2. Pass block builder simulation
3. Get included in the builder’s block
4. Reach the validator via an MEV-Boost relay

Since completing all 4 of these steps can take roughly 1-2 seconds, a bundle sent with a designation of blockNumber +1 a ½ second before the next block is discovered may suddenly be in a situation where their bundle is trying to propose transactions for a block that is already created.

In a worst-case scenario where there are extreme latency issues causing delays of multiple seconds or longer, it would be nearly impossible to land a bundle on-chain.

Reason 5: The block could be outside the bundle’s designated timestamp

In addition to a designated blockNumber, searchers also have the option to list designated minTimestamp and maxTimestamp information for their bundles. These stand for:

• The minimum timestamp for which the bundle is valid, in seconds since the unix epoch
• The maximum timestamp for which the bundle is valid, in seconds since the unix epoch

If the block being built does not fall within the timestamp ranges identified, the bundle will fail to be included.

Reason 6: You didn't simulate the bundle and one or more of the bundle’s transactions failed

The scenarios below would both result in failed transactions eliminating your bundle from being eligible:

1. A reverting transaction (unless specified via optional argument revertingTxHashes or uncled)
2. Gas price below base fee (would create an invalid block if included)

Searchers can utilize Blocknative’s Transaction Preview capabilities to simulate their bundles before submission and protect against transaction failure. 

Searchers can use the eth_callBundle RPC call to test before sending bundles. eth_callBundle is similar to eth_call which you might already be familiar with, but offers these key benefits:

• Operates on an array of signed transactions, instead of a single [unsigned] transaction description. These transactions are executed in sequence starting at the top of the specified block. Simulating with signed transactions leaves very little difference between how your system creates transactions and how they will be processed on-chain (e.g. you can never use an incorrect from field when simulating a signed transaction)
• Returns gas used and coinbase transfer, per transaction. (Coinbase transfer factors into effective gas price)
• Allows specifying the exact values for the following arguments, allowing more accurate simulation:
• State block number (what values are read from SLOADs)
• EVM block number (what value is returned from block.number)
• EVM timestamp (what value is returned from block.timestamp)

Reason 7: Something not listed here

It’s important to remember that the game of MEV in the Dark Forest of public blockchain mempools is one of the most cutthroat and cutting-edge arenas imaginable. While our goal is to provide a comprehensive resource regarding potential pitfalls, a searcher could check all the boxes above and a novel approach from a competing searcher could still outperform them.

For further reading

Much of the information here was primarily sourced via the Flashbots searcher documentation: https://docs.flashbots.net/flashbots-auction/searchers/advanced/understanding-bundles. If you would like live support directly related to submitting bundles to Blocknative’s builder, we recommend contacting us via our Discord. 

Build with Blocknative

Use Blocknative’s world-class mempool infrastructure to search with an edge and securely get MEV bundles on-chain by submitting to our RPC endpoint https://api.blocknative.com/v1/auction. Create a free Mempool Explorer account today and begin prototyping your strategies.

Validators can earn more by connecting MEV-Boost to the Blocknative Relay endpoint. Connect to our relay todayto maximize your block rewards.

If you’re a dapp or wallet interested in #ShareTheMEV, we would love to chat with you. Follow us on Twitter@Blocknativefor the latest updates from our team.