Chains
BNB Beacon Chain
BNB ecosystem’s staking & governance layer
Staking
Earn rewards by securing the network
Build
Explore
Accelerate
Connect

The Pasteur hard fork went live on BNB Smart Chain on August 25, 2026 with a clear goal: create more room for BSC to process larger blocks efficiently.
At the center of that upgrade is BEP-675, a new block-building architecture that removes redundant transaction execution from the time-sensitive path before validators seal builder-proposed blocks.
The first mainnet data covering the period through September 1is now in. Within its first week, BEP-675 became BSC’s dominant block-production path, while BidBlock V2 blocks averaged 28% more gas than Bid V1.
That gives us an early look at what Pasteur has already changed under the hood — and the additional scaling headroom it creates for BSC.
Before Pasteur, a builder-proposed block could involve three Ethereum Virtual Machine, or EVM, execution passes.
BEP-675 streamlines that process by removing validator-side replay from the pre-seal path.
BEP-675, or Builder-Proposed Block with Validator Blind Signing, introduces the SendBidBlock remote procedure call.
Instead of submitting only a transaction list, builders can send a fully executed BidBlock containing signed user transactions, execution results, system transactions, and optional blob sidecars. Validators can then assemble and seal the block without replaying every user transaction first.
That means less duplicated work and more of each block window available for builders to construct larger blocks.
The efficiency gain comes from changing when full execution verification happens.
Before sealing, validators still verify consensus-derived header fields, check for a non-zero gas fee, sign permitted system transactions, recompute the transaction hash, and control the block’s Extra field.
After broadcast, validators execute the block during local import and verify the state root, receipts root, and blob commitments where applicable.
Bid V1 also remains available as an operational fallback. If a builder encounters an issue with BidBlock V2, it can return to the existing flow with full validator-side simulation before sealing.
So while Pasteur removes one redundant execution pass from the critical block-production window, correctness checks and fallback mechanisms remain in place.
Adoption after Pasteur has moved quickly. Across the three-day observation window ending Sep 1:
Hourly adoption of BidBlock V2 reached a peak of 98.3%. Of 49 registered builder instances, 24 had integrated BEP-675.
More importantly, 100% of the 33 builders that were actually active during the observation window.
The builder market remains concentrated, with 48Club and BlockRazor producing 97.8% of blocks over the same three-day period. Their adoption therefore has an outsized effect on how quickly BEP-675 reaches mainnet traffic at scale.
The early signal is strong: BEP-675 has moved from a newly activated protocol path to the primary way builder-proposed blocks are produced on BSC.

Since the Pasteur hardfork, the most tangible result so far is visible in block depth. BidBlock V2 is therefore averaging 28% more gas per block than Bid V1.
At the upper end of the distribution, the difference is even more visible: BidBlock V2 reached 43.8M gas at P99 compared with 33.8M for Bid V1.
These figures come from live mainnet traffic rather than a controlled benchmark, so they should be read as observed production performance rather than an isolated measurement of BEP-675 alone. Even with that qualification, the direction is encouraging: the new path is already supporting deeper blocks while operating below BSC’s current 55M Gas Limit.
Running a new architecture on mainnet provides information that test environments cannot fully reproduce. Early monitoring after Pasteur identified 15 malformed BidBlocks, mainly linked to an empty State Root in one builder configuration.
The issue was fixed, additional defensive checks were introduced, and no recurrence appeared during the five-day observation window through September 1. This also demonstrated the value of keeping Bid V1 available. Builders can fall back to the simulation-protected path when necessary while BidBlock V2 adoption continues.
The result is a rollout that can improve through real production feedback without depending on a single block-building path.
The first week of mainnet data gives us two strong signals.
First, BEP-675 adoption has moved quickly enough for BidBlock V2 to become BSC’s primary block-production path.
Second, the architectural change is creating meaningful block headroom. Removing validator-side replay frees more of the block window for builders, and BidBlock V2 is already producing deeper blocks under live traffic. That gives BSC a stronger starting point for the next stage of scaling.
As block capacity increases, the focus progressively shifts to the rest of the pipeline:
Pasteur removes one major source of duplicated work. The roadmap now builds on that improvement layer by layer.
The biggest change is inside block production.
Builders can now submit fully executed BidBlocks through SendBidBlock, giving them more of the block window to compete and construct larger blocks.
Validators continue verifying correctness after broadcast through local block execution, preserving an important part of the existing validation process.
For the broader ecosystem, the benefit is additional capacity headroom. Pasteur gives BSC a stronger architecture for increasing Gas Limits as mainnet data shows the network is ready.
BSC entered September at a 55 million Gas Limit, and the increase to 90M is scheduled in three stages:

With BEP-675 now running at scale, attention turns to how BSC can use the additional headroom. The network currently operates at a 55 million Gas Limit.
These are targets rather than guaranteed dates. Each increase will be guided by mainnet evidence, including finality, missed blocks, large-block behavior, cross-region latency, node import time, builder market share, and fallback health.
As Gas Limits rise, other parts of the network need to keep pace. BSC is already working on the infrastructure needed to support those larger blocks.
The current JSON and hexadecimal block-delivery path adds representation and serialization overhead.
Transporting Recursive Length Prefix, or RLP, encoded data over gRPC is designed to reduce that overhead and improve the delivery of larger BidBlocks, particularly at the latency tail.
That gives builders and validators a more efficient transport path as block payloads grow.
Larger blocks also need to synchronize reliably across the network. The current peer protocol creates an approximate synchronization boundary around 83 million gas because receipts for a block must fit into a single 10 MiB response.
eth/70 allows receipts for one block to span multiple bounded responses, giving nodes a better way to synchronize increasingly large blocks.
A Block-Level Access List (BAL) can expose state accesses in advance, enabling techniques such as state prefetching, dependency-aware parallel execution, and faster block import.
BEP-675 removes redundant execution. BAL targets greater efficiency in the execution work that remains.
BAL is not currently required for the planned move to 90M gas. Its rollout will depend on testing and production evidence.
Pasteur is live, BEP-675 has become the dominant block-building path, and the first mainnet results show the additional headroom beginning to translate into deeper blocks.
The next step is to turn that headroom into higher network capacity carefully.
Pasteur removed a major source of redundant work from BSC block production. With BEP-675 now running across the majority of mainnet blocks, BSC has more room to push capacity further, one measured step at a time.