The upgrade is important because gas capacity determines how much transaction activity can fit into a block. Rather than simply increasing the Gas Limit immediately, Pasteur changes part of the process used to construct and validate builder-proposed blocks.
BEP-675 Removes Redundant Execution
Before the upgrade, builder-proposed blocks could require three EVM execution passes across the builder-driven production path. BEP-675 removes the validator-side replay that previously occurred before a block was sealed, reducing that path to two execution passes.
BEP-675 on GitHub
The change is based on SendBidBlock, a remote procedure call that allows builders to submit a fully executed BidBlock. The package can contain signed user transactions, execution results, system transactions and optional blob sidecars. Validators can then assemble and seal the block without replaying every user transaction before sealing.
BNB Chain's own Pasteur documentation describes the same basic approach: builders execute the proposed block, while validators verify and sign it before completing full verification after broadcast.
Validators Still Verify the Final Block
Removing a pre-seal execution pass does not mean validators stop checking blocks.
Before sealing, validators continue checking consensus-related header fields, gas-fee conditions, system transactions, transaction hashes and other required fields. After broadcast, validators execute the block during local import and verify elements including the state root and receipts root.
Bid V1 also remains available as a fallback. If a builder cannot successfully use BidBlock V2, it can return to the existing process with validator-side simulation before sealing. This provides an alternative path while the newer architecture continues operating on mainnet.
The distinction matters for users: Pasteur is primarily an infrastructure change. There is no requirement for ordinary BSC users to migrate their assets or change how they submit transactions.
BEP-675 Quickly Gains Mainnet Adoption
The first post-Pasteur figures show rapid adoption.
During the three-day observation period ending September 1, BidBlock V2 represented about 98% of blocks, compared with roughly 2% for Bid V1 and 0.1% for local blocks. Hourly adoption peaked at 98.3%.
Of 49 registered builder instances, 24 had integrated BEP-675. Among the 33 builders that were actually active during the observation window, the supplied data says adoption reached 100%. At the same time, the builder market remained concentrated, with 48Club and BlockRazor responsible for 97.8% of blocks during the period.
That concentration is relevant because adoption by the largest active builders can have a significant effect on how quickly a new block-building architecture becomes representative of real network traffic.
BidBlock V2 Produces Deeper Blocks
The clearest early performance signal is the amount of gas being packed into blocks.
BidBlock V2 averaged 28% more gas per block than Bid V1 after the Pasteur hard fork. At the 99th percentile, BidBlock V2 reached 43.8 million gas, compared with 33.8 million gas for Bid V1.
These are observations from live mainnet traffic rather than a controlled benchmark, so they should not be interpreted as a laboratory measurement of BEP-675 in isolation. Still, the data indicates that the new block-production path is already allowing builders to construct deeper blocks while operating within the existing capacity framework.
BNB Chain's pre-launch testing had already pointed toward potential gains. Its Pasteur announcement reported that an internal QANet benchmark increased throughput from 1,237 to 2,324 TPS at the same 450-millisecond block interval and 100 million gas limit. BNB Chain explicitly noted that those were testnet benchmark results rather than mainnet measurements.
Mainnet Testing Exposes and Fixes Problems
The first days on mainnet also provided useful information about the new architecture.
The supplied data says monitoring identified 15 malformed BidBlocks, mainly associated with an empty State Root in one builder configuration. The issue was fixed and additional defensive checks were introduced, with no recurrence during the five-day observation window through September 1.
The incident illustrates why keeping the older Bid V1 path available is useful during an infrastructure transition. Builders can fall back to the established process if problems emerge with the newer system.
For BSC, the objective is therefore not simply to remove an execution step but to make the entire block-production pipeline reliable enough to support progressively larger blocks.
BSC Plans Higher Gas Limits
The next stage is increasing the amount of gas that BSC can accommodate.
The supplied roadmap describes a progression from the existing 55 million Gas Limit toward 70 million, 80 million and potentially 90 million gas. The first increase is described as targeting 70 million ahead of September 15, 2026.
BNB Chain release notes and Pasteur upgrade information
These increases are not presented as automatic guarantees. The supplied material says decisions will depend on factors such as finality, missed blocks, large-block behavior, cross-region latency, node import times, builder participation and fallback health.
That approach is important because increasing the Gas Limit affects more than transaction capacity. Larger blocks also create additional demands on block delivery, synchronization and execution.
Infrastructure Must Keep Up With Larger Blocks
BSC is also working on supporting infrastructure for larger blocks.
One area is gRPC and RLP-based data transport. The goal is to reduce representation and serialization overhead compared with existing JSON and hexadecimal block-delivery methods, particularly as BidBlocks become larger.
Another component is eth/70, which addresses synchronization limits for increasingly large blocks. The supplied material says the existing peer protocol creates an approximate boundary around 83 million gas because receipts need to fit within a single 10 MiB response. Eth/70 allows receipts from one block to be distributed across multiple bounded responses.
BSC is also developing Block-Level Access Lists (BALs). These can expose state accesses in advance and support techniques such as state prefetching, dependency-aware parallel execution and faster block import.
BNB Chain’s Block-Level Access List explanation
What Pasteur Means for BSC Users
For the broader BNB Smart Chain ecosystem, the main benefit of Pasteur is additional block-production headroom.
Builders can submit fully executed blocks through BEP-675, reducing duplicated execution during the critical pre-seal window. Validators still perform post-broadcast execution and verification, while the legacy Bid V1 path remains available as a fallback.
For users and applications, the expected effect is less about a visible interface change and more about how much activity the network can accommodate. If larger Gas Limits can be introduced without compromising finality or node performance, BSC could process more transaction activity within its existing block-time structure.
The key challenge now is ensuring that every part of the network can handle that additional capacity.
The Next Phase of BSC Scaling
Pasteur represents a change in BSC's scaling strategy: improve the efficiency of block production first, then use the additional headroom to support larger blocks.
The first mainnet figures are encouraging. BEP-675 has become the dominant block-building path, BidBlock V2 is averaging 28% more gas per block than Bid V1, and the network is preparing for higher Gas Limits.
At the same time, the results are still early. Larger blocks will place greater demands on delivery, synchronization and execution, making the supporting infrastructure just as important as the block-building architecture itself.
If the planned increases to 70 million, 80 million and potentially 90 million gas can be introduced while maintaining network stability, Pasteur could become a significant foundation for BSC's next stage of scaling.
