Support center

BlockRazor currently does not offer a free trial for any service. To evaluate a service, you can purchase one day of access.

They can be ordered at the same time.

Data stream service quota refers to the number of gRPC data streams that are allowed to connect. The quota is shared across multiple regions. For example, if you purchase one Public Mempool, only one data stream connection is allowed in all regions.

In the Navigator Package, Public Mempool, Block Stream, and Node Stream share data stream quotas on BSC and Ethereum. For example, if you purchase the Navigator Package and obtain 2 Public Mempool quotas, you are allowed to subscribe to a total of 2 data streams on BSC and Ethereum. If you have already subscribed to 2 BSC Public Mempools, you cannot subscribe to Public Mempools on Ethereum.

Public Mempool is used to subscribe to publicly disseminated pending transactions, making it suitable for early detection of trading signals. Private Mempool is used to subscribe to private pending transactions, and is suitable for scenarios such as backrun.

Mempool focuses on transactions that are not yet confirmed but have entered the propagation process; Block Stream focuses on blocks and transactions that have entered the block and have been confirmed. If you want to discover opportunities earlier, prioritize Mempool; if you are more concerned with result confirmation and block-level analysis, prioritize Block Stream.

Block Stream is a subscription-based data stream used to obtain the latest blocks and confirmed transactions with low latency. Node Stream, on the other hand, focuses more on infrastructure capabilities, allowing users' own full nodes to synchronize the latest blocks and world state faster. If you only need block data, Block Stream is usually more straightforward; if you need to run the system based on the state of local nodes, Node Stream is more suitable.

Tx Trace is primarily suitable for querying the propagation status, arrival time, and latency distribution of transactions that have entered the public propagation process across different regions. If a transaction has not entered the public propagation path, or is outside the valid query window, Tx Trace cannot provide corresponding propagation results.

The two have different positioning: • Public Mempool is a real-time subscription service used for low-latency reception of pending transactions in public circulation, with the emphasis on "seeing transactions as early as possible". • Tx Trace is a propagation observation tool used to query the propagation path and cross-regional latency distribution of a specified transaction within a global network, focusing on "seeing how transactions propagate."

Shred Stream receives raw shred streams from the Solana network and cannot be used directly as structured transaction or block data. It typically requires 3 steps: receiving, recovering, and parsing, to extract usable transaction content. You can directly refer to the shreds-subscribe project (https://github.com/BlockRazorinc/shreds-subscribe). It provides a complete parsing chain: 1. UDP Reception: Continuously receive shreds on the specified port. 2. FEC Recovery: Recovering partially lost shreds using the Reed-Solomon algorithm 3. Deshred + Parsing: Reassembles the shred into complete block entries and further parse the transactions within them. After completing this process, you can usually obtain the following information: • Transactions and transaction events related to the specified account • Block entries

The core difference between the two lies in their data layer and ease of use. Shred Stream transmits lower-level raw shred data, resulting in shorter transmission chains and lower latency, making it suitable for bots, RPCs, and validators with extremely high timeliness requirements. However, the receiving party needs to perform reassembly and parsing themselves. Geyser Stream, on the other hand, transmits structured account, slot, block, and transaction data. Clients can directly subscribe via gRPC, making integration simpler and more suitable for account monitoring, transaction analysis, and stable production environments. If you need earlier transaction signals, choose Shred Stream; if you need more complete and easily consumable real-time on-chain data, choose Geyser Stream.

The core difference between the two lies in the different data granularity, time points, and applicable scenarios. • Get BlockStream It is used to retrieve block that has already been formed on Base, focusing on confirmed blocks and transactions within. It is more suitable for monitoring confirmation results, block-level analysis, on-chain data processing, and data systems that need to stably consume blocks. • Get FlashBlockStream Used to retrieve FlashBlock data on Base. FlashBlock is a "sub-block" of data pushed by Base approximately every 200ms, providing pre-confirmation information for transactions much earlier than the standard 2-second formal block time. It is more suitable for scenarios that are more sensitive to low latency and want to see on-chain changes as early as possible.

Both Get FlashBlockStream and Get FlashBlockTransaction subscribe to FlashBlock data, but the key difference lies in the returned data format. Get FlashBlockStream returns binary data, which needs to be parsed into structured data after acquisition; while Get FlashBlockTransaction directly returns structured transaction data.

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.

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)

MEV protection primarily prevents strategies that harm users, such as sandwich attacks and frontrunning. For safe backruns that do not negatively affect the user’s expected execution outcome, BlockRazor can provide eligible Searchers with the necessary information within the user-authorized disclosure scope. A portion of the resulting revenue is then returned to the user.

BSC RPC is currently deployed across NewYork, Tokyo, Frankfurt, and Dublin.

BSC RPC serves as a unified transaction submission endpoint and a standard JSON-RPC access point for wallets, DEXs, trading systems, and individual users. It can also forward Bundles to mainstream Builders with low latency. BSC Block Builder is designed for professional use cases that specifically require block building, transaction ordering, Bundle submission, or private transaction capabilities.

If a transaction has an executable backrun opportunity and the backrun successfully generates revenue, the rebate is usually processed in real time through an on-chain transaction and may be included in the same block as the user’s transaction.

A backrun refund comes from the distributable revenue generated when a Searcher executes a harmless backrun on the orderflow. A Gas refund is related to the transaction’s Priority Fee and is available to Ethereum transactions that meet the Ethereum Builder refund policy. The refund percentage for both types is 90%.

No. A backrun refund requires a Searcher to identify a valid opportunity, successfully submit a backrun, and generate revenue. A Gas refund requires the transaction to meet the current Gas refund policy. A transaction may receive one type of refund, both types, or no refund.

No. BlockRazor Ethereum RPC is compatible with standard JSON-RPC methods, including eth_sendRawTransaction. Individual users can simply replace the RPC in their wallet, while applications and trading systems usually only need to replace their RPC endpoint.

Both Fast and RPC are transaction sending capabilities, but they have different design goals. RPC focuses more on transaction protection and general access capabilities. It provides standard JSON-RPC methods, focusing on addressing the MEV risks that transactions may encounter during public dissemination, and supports refund and disclosure policy configuration and customized RPC access, making it suitable for Wallets, DEXs, and project teams as a standard transaction sending entry point. Fast prioritizes the speed of transaction on-chain processing. It optimizes the sending path through BEF, helping transactions enter the on-chain execution process with lower latency. It is suitable for trading bots, quantitative strategies, and timing-sensitive trading scenarios that have higher requirements for on-chain timeliness.

BlockRazor is global low-latency Web3 infrastructure for wallets, DEXs, trading bots, searchers, and quant trading systems. Across BSC, Ethereum, Solana, Base, and Robinhood Chain, its Streams deliver earlier mempool and chain data while Transaction Submission infrastructure helps applications send transactions with lower latency.

BlockRazor provides low-latency Streams for receiving mempool, block, node, and network-fee data, plus Transaction Submission infrastructure for sending transactions through RPC, Block Builder, Transaction Sending, and Gas Sponsor modes. Service availability differs across BSC, Ethereum, Solana, Base, and Robinhood Chain.

Choose receiving services according to the signal or chain data the strategy needs, then pair them with the appropriate sending service. Common combinations are: • Wallet / DEX: Block Stream with RPC, Transaction Sending, or Gas Sponsor • Trading bots: Public Mempool, Private Mempool, or Block Stream with Transaction Sending or BSC Block Builder • Searcher: Public Mempool, Private Mempool, Block Stream, or Node Stream with BSC Block Builder, RPC, or Transaction Sending • Quant trading: Node Stream with Transaction Sending, RPC, or BSC Block Builder Supported products and endpoints still depend on the target chain.

BlockRazor currently documents services across BSC, Solana, Ethereum, Base, and Robinhood Chain. Support is service-specific: a listed chain does not imply that every Stream or Transaction Submission mode is available on that chain.

Use the published benchmark articles for test scope, methodology, region, and measurement date, and use the public BNB Smart Chain MEV dashboard for independently accessible historical builder statistics. Performance observations are time- and test-specific rather than universal guarantees.

BlockRazor BSC Block Builder helps searchers, trading bots, quant teams, wallets, and DEXs improve BSC transaction execution through competitive block building and globally deployed low-latency access. Its core value is providing more suitable submission paths for latency-sensitive, privacy-sensitive, and sequence-sensitive transactions, helping users improve execution stability and the chance of successful inclusion. Send Bundle, Send PrivateTransaction, and Trace Bundle support ordered execution, private submission, and performance analysis, while real-time block production statistics can be verified through the public BNB Smart Chain MEV dashboard.

The default setting for the MEV Protect RPC is to disable revert protection for transactions. If you want revert protection for your transactions, use the /fullprivacy or /maxbackrun endpoint, or enable it in the portal.

Ethereum and BSC are supported currently.

BlockRazor shortens the path to the Leader through a globally distributed network, high-quality SWQoS and regional endpoints. It supports HTTP and gRPC, as well as speed-focused Fast mode and risk-aware Sandwich Mitigation mode.

Choose the endpoint closest to your application server and set the Priority Fee and Tip appropriately. BlockRazor combines SWQoS, multi-region routing and a low-latency network to help transactions reach the Leader faster.

Shred Stream delivers raw Solana Shreds over low-latency UDP. It is designed for searchers, trading bots and DeFi projects that need earlier transaction signals. Users are responsible for recovering, reconstructing and parsing the Shreds.

In like-for-like testing across four regions in 2025, BlockRazor Shred Stream achieved a first-arrival rate above 60% in every region, including 97.32% in Tokyo, 85.25% in Frankfurt and 84.86% in New York. High-stake validators, low-hop UDP forwarding and multi-region relays provide earlier raw Shred input for latency-sensitive trading systems.

A Public Mempool is a stream of unconfirmed transactions already propagating publicly through the network. BlockRazor delivers these pending BSC transactions with low latency over gRPC.

BlockRazor uses its Blockchain Edge Fabric and regional relays to receive and distribute public pending transactions earlier. Its official benchmark measures this lead against regular nodes in four regions.

Common uses include pending transaction monitoring, Smart Money tracking, backrun discovery, copy trading, sniping and real-time input for automated trading systems.

BlockRazor provides Public Mempool services for both BSC and Ethereum. BSC is the primary focus of this page and includes the featured four-region latency benchmark; Ethereum Public Mempool is also available for teams monitoring public pending transactions on Ethereum.

BlockRazor Private Mempool is a BSC private pending transaction service that delivers authorized fields from private orderflow routed through BlockRazor RPC.

The service delivers structured data over Server-Sent Events (SSE), so clients can parse, filter and process it in their strategy systems.

Transaction content is uniformly anonymized, and only fields authorized for public access are disclosed while retaining information needed for strategy analysis.

The official documentation highlights backrunning, copy trading and sniping as common scenarios for private orderflow signals.

Signal monitoring determines when a bot can act; transaction submission determines when its signed transaction reaches the Leader, Builder, Validator, or Sequencer. Latency at either stage can remove the strategy's original advantage.

It depends on the chain and target signal. Solana bots can choose raw Shred Stream or structured Geyser Stream; EVM bots may combine public or private pending transactions with confirmed block data; Base and Robinhood Chain also expose chain-specific preconfirmation or Sequencer feeds.

They filter different events, but both rely on the same core path: receive and parse a signal, evaluate a strategy, construct and sign a transaction, and submit it quickly.

Use the endpoint closest to your bot's deployment region and select the service that targets the chain's ordering node: Leaders on Solana, Builders or Validators on Ethereum and BSC, and Sequencers on Base and Robinhood Chain.

It is a real-time WebSocket stream of block data pushed by the Robinhood Chain Sequencer. Nodes use it to track the latest chain state.

It is compatible with the official access method. Node operators replace or add the BlockRazor Feed URL in the node startup configuration.

The same clients connected to BlockRazor and official feeds in three Ohio availability zones. The feed receiving each block first was assigned zero relative latency.