key insights
- With Pasteur, BSC can scale up its capacity without impacting its 450 millisecond block time.
- The upgrade adds more enhancements to bridge verification and validator security.
- QANet showed an 88% throughput gain, but mainnet results remain unproven.
BNB Chain activated its Pasteur hard fork on BNB Smart Chain mainnet at 02:30 UTC on August 25, 2026. The upgrade targets bridge verification, validator authority and block capacity, while preserving the network’s 450-millisecond block interval.
Pasteur hardfork is now live on BSC Mainnet.
The upgrade strengthens bridge, staking and governance security, while giving blocks more room to carry transactions at the same 450ms block time.
Read the full upgrades 👇https://t.co/41QWQh1GGL pic.twitter.com/mTTnRb9PNk
— BNB Chain (@BNBCHAIN) August 25, 2026
Security controls move closer to the protocol core
The activation brings three BNB Evolution Proposals into production through client version 1.7.7. BEP-682 strengthens cross-chain light-block verification by rejecting duplicate validator entries before the network calculates voting support.
That change closes a verification gap that could make one validator appear multiple times in an approval set. Consequently, a crafted validator list could overstate independent support for a cross-chain block. The new rule requires each counted approval to represent a distinct validator. BNB Chain has not linked the change to a reported exploit or disclosed asset loss.
BEP-695 addresses a separate set of validator and governance weaknesses. After a validator rotates its consensus key, the previous key loses administrative authority. Pending slash evictions also follow the validator through key changes.
The proposal further blocks restricted addresses from influencing governance through offchain signatures. This closes a route where another account could submit a vote signed by a restricted address.
A faster path for block production
The most consequential capacity change comes through BEP-675. Under the earlier process, builders executed transactions before submitting blocks, while validators repeated that execution before signing.
That duplication consumed valuable time inside the short block-production window. As a result, builders could leave available block capacity unused during periods of heavy activity. BEP-675 creates an optional pre-executed block route. Builders submit blocks after completing execution, allowing validators to check consensus conditions, sign and broadcast them sooner.
Validators still complete full execution verification after the time-sensitive stage. Builders can also retain the legacy submission route, although it provides less time for filling blocks.
The new approach also changes requirements for participating builders. They need full nodes capable of producing fully executed blocks and must enable the route through the network’s RPC interface.
QANet tests point to higher capacity
BNB Chain tested the new process on QANet, an internal environment designed to reflect geographically distributed validators. The controlled workload produced a substantial increase in measured throughput.
- Throughput rose from 1,237 to 2,324 transactions per second.
- Average gas used per block increased from 46.35 million to 84.15 million.
- Critical-path processing time fell from 125 milliseconds to 15 milliseconds.
- The block interval remained 450 milliseconds.
- The gas limit remained 100 million.
The test indicated an 88% throughput increase, while average gas use approached the existing block limit. However, the figures do not represent sustained mainnet performance.
The team stressed that QANet used controlled conditions. Live traffic, transaction complexity and builder participation will determine whether similar gains emerge on mainnet.
What operators and markets will watch next
The client had to be version 1.7.7 before activation. They also had to delete the EnableBAL setting from the config.toml since the new client will fail to start without it.
The following deprecated setting could also be removed from operators: OverflowPoolSlots. A number of options in the command line were no longer relevant or available following the upgrade.
Pasteur doesn’t require any wallet migration or software change for ordinary users and most application developers. It is instead dependent on the custom of the new production path by node operators, validators and block builders.
The upgrade is also a change in BSC’s recent scaling strategy. Maxwell and Fermi upgrades were heavily centred around shorter block times in the past. Pasteur prefers to use the existing blocks more than he likes to have a 450-millisecond gap.
There is need to closely monitor developments now.
The number of blocks used on mainnet will be reflective of the amount of capacity used by builders.
Faster signing will bring additional stress on the operations, which will be visible in the performance of validators and missed blocks. The durability of the new safeguards will be further tested by cross-chain verifications and governance activities. Cross-chain verifications and governance activities will serve as further tests for the durability of the new safeguards.
Conclusion
BNB Chain is coming to Pasteur with two goals in mind: enhanced security and improved block generation. The fork does not increase the gas limit nor reduce the block time, thus it relies on better execution and fuller blocks for its scaling case.
While the QANet data is a positive sign, the latter will have more weight on mainnet. If builders widely adopt BEP-675, more activity could take place without requiring an additional reduction in BSC’s block time.
Meanwhile, BEP-682 and BEP-695 further enhance the security of validator identity and authority. Those modifications, combined, will both be a security improvement and a measure of the efficiency with which BSC can leverage its existing resources.
