BNB Chain activates Pasteur hard fork to strengthen bridge security

BNBChain has activated the Pasteur hard fork on the BNB intelligent chain main network

This upgrade focuses on changing the way block verification and authorization is used, and also aims to improve the traffic carrying capacity of each block. Networks said Pasteur went online on Tuesday with the goal of enhancing the security of bridging, pledge and governance, but will not change the BSC's 450-millisecond block time.

In this update, BNB Chain integrated multiple BNB Evolution Proposals (BEP) to fill for loopholes in the verification and authorization links, improve the verifier processing mechanism in cross-chain and governance operations, and replan the work paths of block builders and verifiers during busy periods.

Key Points

Pasteur has been launched on the BSC main network. BNB Chain describes it as a security and performance upgrade, and maintains the 450-millisecond out-block time unchanged.

BEP-682 and BEP-695 solve the problem of duplicate verifiers in cross-chain light block verification, and strengthen control over verifier key rotation, forfeiture and governance voting.

BEP-675 changes the block submission mechanism to allow builders to submit completed blocks, thereby reducing duplication of work for verifiers.

QANet test results show an improvement in throughput, but this comes from a controlled test environment rather than real main-network measurement data.

What has Pasteur changed on the BSC mainnet

According to BNB Chain confirmed on Tuesday, Pasteur is now active on the BSC main network, aiming to strengthen core system components related to network integrity. The team said that this upgrade has improved the security of network bridging, pledge and governance, while increasing block capacity.

BNB Chain focuses this upgrade on three BNB evolution proposals:

BEP-682 prevents duplicate verifier entries in cross-chain light block verification.

BEP-695 tightens the handling of verifier related changes, including verifier key rotation, forfeiture and governance voting.

BEP-675 modifies the process for professional block builders to submit blocks to verifiers.

BNB Chain also stated that Pasteur aims to prevent verifiers from being counted twice in bridge approvals, reduce the privileges of old verifier keys, and prevent restricted addresses from participating in voting. These are practical security measures: bridging verification and governance voting rely on the right validator participation, so tightening these mechanisms is a strong defense against marginal failure and counting errors.

Why BSC adjusts the block construction path

The update of BNB Chain focuses on the distribution of work between the block builder and the verifier. According to the network's previously described process, the builder first executes the transaction, then submits the proposed block, and then the verifier executes the transaction again before signing.

BNB Chain said that this "duplication of work" consumes valuable time within the chunk window and sometimes leads to underfilling of chunks-a problem that is more obvious when the network is busy.

With BEP-675, the new process allows builders to submit completed blocks. Under this design, the verifier first verifies the proposed block according to consensus rules, signs and broadcasts it, and then performs a complete execution verification.

Importantly, BNB Chain says the previous process is still available: builders can continue to use the old method, where verifiers perform transactions before signing. This dual-track approach suggests that the introduction of Pasteur takes into account operational flexibility and may reduce the risks faced by builders who need time to adapt to new processes.

Throughput improvement in QANet testing-something to note

To quantify the changes, BNB Chain cited the results of testing conducted on QANet. QANet is an internal environment that simulates a geographically distributed verifier configuration of a BSC. In these tests, the new block-building path increased throughput from 1,237 transactions per second to 2,324 transactions per second, an increase of approximately 88%.

BNB Chain also reported that average gas usage per block increased from 46.35 million to 84.15 million, while two key parameters-block spacing and the 100 million gas cap-remained stable.

However, the network emphasized that these data were generated under controlled test load and were not measured data on the main network. This is important for investors and operators because test throughput does not always translate directly into true performance with fluctuating demand, different transaction combinations, and changing validator/builder behavior.

Still, the directional results are clear: Pasteur aims to help verifiers reduce the time it takes to repeat pre-execution, making it easier to get blocks close to full capacity during peak traffic periods.

Pasteur's positioning in BSC's recent performance advancement

Pasteur is a subsequent step in a series of BSC upgrades, which previously prioritized accelerating block removal speed. BNB Chain has pointed out that its Maxwell hard fork will reduce the average block time from 1.5 seconds to approximately 0.8 seconds in June 2025. Subsequent Fermi upgrades reduced the network out-of-block time to 450 milliseconds.

In this context, Pasteur appears to be a complementary step: Once the time to block is shortened, the system needs to avoid potential traffic bottlenecks due to shortened build and verification available times. By changing the way builders interact with verifier signatures, while tightening verifier authorization rules, the network is effectively trying to balance speed, throughput, and correctness.

Therefore, BNB Chain's latest initiatives target two levels simultaneously: security boundaries (verifier counting, key rotation control, governance participation rules) and block production efficiency (reducing duplication of work within block windows).

Readers should pay attention to the speed at which builders and validators adopt new processes under real main-network loads, and whether QANet's gain can translate into more stable block loads during periods of high activity. After Pasteur changed the choreography of execution and signature operations, the biggest suspense was how performance performed under different transaction characteristics, not just raw throughput.