> For the complete documentation index, see [llms.txt](https://docs.blockrazor.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blockrazor.io/get-started/use-cases/searcher.md). # 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](/transaction-submission/rpc/bsc/orderflow-auction.md), 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](/streams/public-mempool/bsc/public-mempool.md) and [Block Stream](/streams/block-stream/bsc/newblocks.md) 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](https://medium.com/@blockrazor/to-build-the-competitive-high-performance-network-d7c0705b5171). Searchers can directly integrate with [Bundle](/transaction-submission/rpc/bsc/orderflow-auction.md), 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](https://www.blockrazor.io/#/register) for BlockRazor 2. [Log in](https://www.blockrazor.io/#/login) to BlockRazor, purchase Private Mempool, and go to the account module to obtain the auth token 3. Subscribe to the [Private Mempool](/streams/private-mempool.md) 4. Execute the arbitrage strategy, and submit bundle to BlockRazor RPC using [Bundle](/transaction-submission/rpc/bsc/orderflow-auction.md) #### **Arbitrage of Public Mempool** 1. [Register](https://www.blockrazor.io/#/register) for BlockRazor 2. [Log in](https://www.blockrazor.io/#/login) to BlockRazor, purchase Public Mempool, and go to the account module to obtain the auth token 3. Integrate the [Public Mempool](/streams/public-mempool/bsc/public-mempool.md) to subscribe to the latest transactions with low latency; synchronize blocks with low latency through [Node Stream](/streams/node-stream/bsc/full-node-synchronization.md) if you have local node. 4. Execute the arbitrage strategy, and submit bundle to BlockRazor RPC using [Bundle](/transaction-submission/rpc/bsc/orderflow-auction.md). ### 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)`
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.blockrazor.io/get-started/use-cases/searcher.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.