BNB Chain has activated the Pasteur hard fork on the BNB Smart Chain (BSC) mainnet, marking a focused change to how blocks are verified and authorized—while aiming to increase how much traffic can fit into each block. The network says Pasteur went live on Tuesday and targets bridge, staking, and governance security, without altering BSC’s 450-millisecond block time.

In the update, BNB Chain combines multiple BNB Evolution Proposals (BEPs) to close verification and authorization gaps, improve validator handling around cross-chain and governance operations, and revise the route used by block builders and validators during busy periods.

Key takeaways

Pasteur is live on BSC mainnet, with BNB Chain describing it as a security and performance upgrade that keeps the 450ms block time unchanged.
BEP-682 and BEP-695 address validator duplication during cross-chain light-block verification and tighten controls around validator key rotation, slashing, and governance voting.
BEP-675 changes block submission mechanics, allowing builders to submit blocks they have already executed, reducing duplicated work by validators.
QANet test results showed higher throughput—but they were from a controlled test environment, not a live mainnet measurement.

What Pasteur changes on BSC mainnet

According to a Tuesday confirmation from BNB Chain, Pasteur is now active on the BSC mainnet and is designed to strengthen core system components tied to network integrity. The team says the upgrade improves the network’s bridge, staking, and governance security, while also increasing block capacity.

BNB Chain frames the upgrade around three BNB Evolution Proposals:

BEP-682 prevents duplicate validator entries during cross-chain light-block verification.
BEP-695 tightens how validator-related changes are handled, including validator key rotation, slashing, and governance voting.
BEP-675 revises the process for how specialist block builders submit blocks to validators.

BNB Chain also says Pasteur is intended to stop validators from being effectively counted more than once in bridge approvals, reduce the authority of older validator keys, and keep restricted addresses from participating in voting. Those are practical safeguards: bridge verification and governance voting both rely on correct validator participation, so tightening these mechanics is a direct defense against edge-case failures and mis-accounting.

Why BSC is adjusting the block-building route

BNB Chain’s update focuses heavily on how work is distributed between block builders and validators. Under the prior route described by the network, a builder executed transactions before submitting a proposed block, and then validators executed the transactions again before signing.

BNB Chain said that “repeated work” can consume time within the block window, at times leaving blocks underfilled—a problem that becomes more visible when the network is busy.

With BEP-675, the new route allows builders to submit blocks they have already executed. In this design, validators verify the proposed block against consensus rules, sign and broadcast it, and only then proceed with full execution verification afterward.

Importantly, BNB Chain says the previous route is still available: builders can continue to use the earlier method in which validators execute transactions before signing. That dual approach suggests Pasteur is being introduced with operational flexibility, potentially reducing risk for builders that may need time to align with the revised workflow.

Throughput gains in QANet tests—what to watch

To quantify the changes, BNB Chain points to tests conducted on QANet, an internal environment created to mirror BSC’s geographically distributed validators. In those tests, the new block-building route increased throughput by roughly 88%, rising from 1,237 to 2,324 transactions per second.

BNB Chain also reported that average gas used per block increased from 46.35 million to 84.15 million, while two key parameters remained steady: the block interval and the 100-million gas limit.

However, the network emphasized that these figures were generated under a controlled test workload and were not mainnet measurements. For investors and operators, this matters because test throughput does not always translate directly to real-world performance under fluctuating demand, different transaction mixes, and changing validator/builder behavior.

Still, the directional outcome is clear: Pasteur is designed to help validators spend less time on duplicated pre-execution, which should make it easier to keep blocks closer to their capacity during peak traffic.

Where Pasteur fits in BSC’s recent performance push

Pasteur follows an earlier phase of BSC upgrades that prioritized faster block production. BNB Chain previously highlighted that its Maxwell hard fork reduced average block time from 1.5 seconds to about 0.8 seconds in June 2025. The subsequent Fermi upgrade then brought the network down to 450 milliseconds.

In that context, Pasteur looks like a complementary step: once block times were shortened, the system needed a way to avoid traffic bottlenecks that can appear when the time available for building and validating shrinks. By changing how builder execution and validator signing interact—while also tightening validator authorization rules—the network is effectively trying to balance speed, throughput, and correctness.

BNB Chain’s latest move therefore targets two layers at once: security boundaries (validator accounting, key rotation controls, and governance participation rules) and block production efficiency (reducing duplicated work inside the block window).

Readers should watch how quickly builders and validators adopt the new route under real mainnet load, and whether QANet gains translate into more consistently full blocks during periods of elevated activity. The big remaining question is how performance behaves across different transaction profiles—not just raw throughput—now that Pasteur has changed the operational choreography of execution and signing.