MEV Searcher Infrastructure and Bundle API

See how MEV searchers use BlockRazor for earlier on-chain signals and faster transaction submission.

As competition becomes increasingly fierce, Searchers can no longer win solely with Alpha strategies; they must also possess Beta competitiveness to further improve their chances of success.

What is Beta competitiveness? If we liken the competition among Searchers to a war, Alpha strategies are the strategies and tactics, while Beta competitiveness represents the infrastructure such as equipment and supplies, which are prerequisite for competition.

Beta competitiveness consists of speed, inclusion certainty, and cost, which helps to increase Searcher’s chances of winning from different aspects.

Speed

The time interval of block production is fixed. To send the bundle to the Builder in time on the assembly line, the Searcher needs to minimize the time spent processing the bundle. The main steps for the Searcher to process a bundle are as follows:

1. Subscribe to target transactions and synchronize the latest block.

2. Based on the world state of the latest block, calculate the arbitrage opportunities for each transaction according to the Alpha strategy.

3. Filter the arbitrage opportunities and assemble the selected target transactions and strategy transactions into a bundle in a specified order.

4. Send the bundle to the Builder.

From the steps mentioned above, the time the Searcher takes to process the bundle is composed of the lantency of transaction subscription, the arbitrage calculation time, and the lantency of bundle sending to builders.

Furthermore, synchronizing the latest world state is a prerequisite for calculating arbitrage opportunities (calculating based on old state would distort the arbitrage action and lose the competitiveness of the Alpha strategy). If the state synchronization lantency is high, it will severely compress the time available for arbitrage calculation, especially during periods of network congestion, which can put immense pressure on computational performance.

In the last step of the bundle processing, the Searcher need to submit the bundle consisting of the target transaction and the arbitrage transaction to the mainstream Builders, ensuring that the bundle is included in all blocks participating in the auction, to increase the speed of the bundle inclusion.

Cost

Cost directly affects the profit of a Searcher. Searchers that are evenly matched in terms of Alpha strategy, speed, and inclusion certainty may not differ much in capturing arbitrage opportunities and calculating arbitrage space. However, if the average cost per arbitrage opportunity varies significantly, over the long term, Searchers with higher costs will gradually become less competitive due to lower profits.

The costs for a Searcher mainly include the execution cost of the Alpha strategy, the cost of improving speed, the cost of enhancing inclusion certainty, and transaction fees. Increasing costs can improve Beta competitiveness, but it also impacts profits. Therefore, it is essential to prioritize and make appropriate trade-offs.

Execution Cost of The Alpha Strategy

The execution of Alpha strategies incurs computational costs. Since the Alpha strategy is the core competitive advantage of a Searcher, and its execution speed also directly affects the processing time of bundles, this cost cannot be reduced.

Cost of Speed Improvement

Improving speed invloves cost of development and server. To reduce transaction subscription latency, bundle sending latency, and the latency in synchronizing the latest world state, it is necessary to develop algorithms and build a high-speed backbone network. This is too costly for a Searcher, so utilizing established third-party services is a cost-effective choice.

Enhancing inclusion certainty primarily involves the cost of removing Builder rate limits. Searchers can attempt to freely integrate with RPCs that allow sending bundles, which will forward the bundles to mainstream Builders. This approach not only saves costs but also ensures speed and inclusion certainty of transactions.

How does BlockRazor enhance the Beta competitiveness?

Speed

BlockRazor provides Searchers with Public Mempool and Block Stream services, enabling them to subscribe to transactions and synchronize blocks with extremely low latency.

Benchmark shows that compared to the industry-leading high-performance network provider bloXroute, BlockRazor can receive the latest transactions with lower latency. Detailed data comparisons are as follows:

Additionally, BlockRazor also demonstrates excellent performance in terms of latency of synchronization of the latest world state, better meeting the needs of speed-sensitive users. For the complete comparison results, please refer to the benchmark.

Searchers can directly integrate with Bundle, constructing a bundle consisting of mempool transactions and strategy transactions and submitting it to BlockRazor RPC, which will forward it to mainstream Builders at the earliest opportunity. Additionally, based on a globally distributed network, BlockRazor RPC achieves end-to-end low-latency forwarding at the network level.

The benchmark client sends transactions to BlockRazor RPC, A RPC, and B RPC, recording the difference between the latest block number at the time of sending the transaction and the block number in which the transaction is included. A smaller difference indicates a faster on-chain speed.

The chart data shows that transactions submitted to Scutum have a probability of being included in the next block as high as 95%, and 100% probability being included in the next 2 blocks, which significantly surpasses that of competitors.

How to use BlockRazor Service

Arbitrage of Private Mempool

1. Register for BlockRazor

2. Log in to BlockRazor, purchase Private Mempool, and go to the account module to obtain the auth token

3. Subscribe to the Private Mempool

4. Execute the arbitrage strategy, and submit bundle to BlockRazor RPC using Bundle

Arbitrage of Public Mempool

1. Register for BlockRazor

2. Log in to BlockRazor, purchase Public Mempool, and go to the account module to obtain the auth token

3. Integrate the Public Mempool to subscribe to the latest transactions with low latency; synchronize blocks with low latency through Node Stream if you have local node.

4. Execute the arbitrage strategy, and submit bundle to BlockRazor RPC using Bundle.

FAQ

What is the difference between submitting a Bundle to an RPC and submitting a Bundle to a Block Builder?

The core difference between the two lies in the different submission paths and final destinations of the Bundle.

When submitting a Bundle to BlockRazor RPC, BlockRazor RPC forwards the Bundle to mainstream builders with low latency. This approach is more suitable as a unified access point, allowing users to submit Bundles without having to connect to different builders individually.

When you submit a Bundle to Block Builder, the Bundle is sent directly to BlockRazor Builder. This is more suitable for scenarios where you explicitly want to use BlockRazor Builder capabilities and the access path.

How to understand that the average gas price of a bundle must not be less than 0.05 gwei?

Assume a bundle contains three transactions: {tx1, tx2, tx3}. Since tx1 comes from the mempool, BlockRazor Builder excludes it and calculates the average gas price using only tx2 and tx3. If tx3 includes an additional tip paid to the Builder, the tip amount is added to the numerator, while the denominator still includes only the gas used by tx2 and tx3. The formula is:

(tx2.gasPrice × tx2.gasUsed + tx3.gasPrice × tx3.gasUsed + tx3.tip) / (tx2.gasUsed + tx3.gasUsed)