What is Fast Submit?

When transactions are being submitted to BSC Builder, many teams frequently encounter the following problem: despite offering a higher bid, why doesn't the transaction appear on the expected block or reach a more ideal position within the block? When on-chain competition is intense, even differences of just a few dozen milliseconds in network latency can determine whether a transaction reaches the builder's processing window earlier. In other words, the problem isn't necessarily that the transaction's bid wasn't high enough, but rather that it didn't arrive early enough.

In the standard submission path of BlockRazor BSC Builder, requests typically pass through a more general network and proxy layer. It is suitable for covering a wider range of access scenarios, but it also incurs additional costs, including intermediate forwarding, network hops, TLS handling, proxy queuing, and public network routing fluctuations. Therefore, when optimizing transaction submissions, teams should not only look at the bid and the timing of transaction sending, but also evaluate the quality of the path the transaction takes before entering the Builder.

As the dedicated submission path, Fast Submit improves the quality of the path a transaction takes before it reaches the BlockRazor BSC Builder. It doesn't change the transaction logic, but rather helps transactions reach the Builder faster and more stably through a more direct submission entry point and a more stable cross-region path.

Actual improvements brought by Fast Submit

According to benchmark results, Fast Submit can reduce latency by about 50ms on intercontinental routes and about 20ms on inland cross-region routes.

For orderflow projects

For orderflow projects such as DEXs and wallets, transaction send timing is not fully controllable. In this case, a shorter submission path means the transaction has a higher probability of entering the Builder’s processing window earlier, helping deliver an optimal 0-block inclusion experience for end users. Using BSC’s current block time of about 450ms as a rough reference, 50ms and 20ms of latency reduction correspond to roughly 11% and 4.4% improvements in time-window efficiency. If block time further shortens to around 250ms in the future, the improvement could expand to about 20% and 8%.

For trading systems competing for transaction position

For strategy-driven systems such as backrunning, sniping, and copy trading, the value of Fast Submit is not only a better chance of being included in the target block, but also that under the same competitive conditions and the same target Builder arrival time, it leaves more time available for strategy computation.

How Fast Submit Improves Speed and Stability

Dedicated HTTP Domain

Compared to the standard submission path, Fast Submit provides users with a dedicated HTTP domain, removing the CloudFront proxy layer and allowing requests to enter BlockRazor Builder more directly. This change is not simply a matter of "changing the domain," but rather a further compression of the submission path itself.

• Fewer intermediaries

• Fewer network hops

• Lower TLS and proxy processing overhead

• The fluctuations caused by queuing and forwarding are more likely to converge under high concurrency.

In high-frequency trading scenarios, the shorter the path and the fewer the variables, the easier it is to stabilize the submission performance.

Cross-region path quality

Many teams underestimate the overhead of cross-regional public network paths. Requests transmitted across regional public networks are susceptible to changes in route convergence, cross-carrier forwarding, link congestion, and transient network jitter, leading to increased end-to-end latency and even more pronounced fluctuations under high concurrency.

Fast Submit optimizes this through BlockRazor's Blockchain Edge Fabric, enabling transactions to be delivered to Block Builders with lower latency and higher stability, minimizing the impact of public network uncertainties on request paths and processing times. For latency-sensitive transaction submission scenarios, the value of this optimization is not only "faster," but more importantly, more predictable and consistent submission performance across different regions and time periods.

Who is Fast Submit suitable for?

For teams with mature transaction systems, the stability, predictability, and processing efficiency of the submission path itself often become key variables for further optimizing execution performance. Fast Submit is suitable for:

• Searcher: Focuses on the timing of transmission and path quality, aiming to further reduce path loss before the transaction reaches the Builder.

• The quantitative and trading bot team: Specific requirements for high-frequency submissions, low latency, regional consistency, and request stability.

• Wallet and DEX teams: try to improve the quality of the path from transaction submission to the Builder without changing the user's transaction sending logic.

For these teams, the value of Fast Submit lies not in having a faster interface, but in providing a dedicated submission path that can be validated, compared, and continuously optimized in a real deployment environment.

Get Started

Teams do not need to refactor existing transaction logic, contact us after completing the subscription to obtain a dedicated Fast Submit domain and switch your requests to this dedicated domain.

After integration, the team can use Bundle Trace to query the time when the transaction was received by the Builder in the real deployment area, thereby comparing the differences in latency, stability and cross-region performance between standard submission path and Fast Submit.

In addition, Fast Submit can be used in combination with BlockRazor's Public Mempool, Node Stream and other capabilities: the latter is responsible for capturing signals and synchronizing states earlier, while Fast Submit is used to optimize the transaction submission path.

It's important to note that Fast Submit does not guarantee the final block inclusion. Whether a transaction is included in a block still depends on factors such as market competition, inclusion strategy, block space, transaction quality, and real-time on-chain congestion.