Pasteur Hardfork

BNB Chain will activate its Pasteur hard fork on August 25, 2026, bundling four separate protocol upgrades into a single coordinated deployment that closes critical security gaps in cross-chain bridging and validator management. The upgrade requires all node operators to run client v1.7.7 by 02:30 UTC on that date or face ejection from the network.

• Pasteur hard fork activates August 25, 2026 at 02:30 UTC with mandatory client v1.7.7 upgrade for all operators.
• BEP-682 eliminates duplicate-validator loophole in bridge verification, preventing inflated validator sets from clearing supermajority thresholds.
• BEP-695 fixes staking governance weakness by stripping rotated keys of validator privileges and blocking eviction-dodging tactics.

• Aug 25, 2026 Scheduled activation date for Pasteur hard fork on BSC mainnet
• 0.45 seconds Current BSC block time following Fermi hard fork in January 2026
• 4 Coordinated proposals bundled into single Pasteur deployment: BEP-673, BEP-682, BEP-695, BEP-675

BNB Chain has committed to a late August 2026 hard fork that will consolidate four separate upgrades under a single network deployment, addressing security vulnerabilities in cross-chain asset verification and validator key rotation while also improving block execution efficiency.

The Pasteur hard fork, announced via blog post on August 14, 2026, will activate at 02:30 UTC on August 25 and represents the latest in BNB Chain’s scientist-themed hard fork series, which has previously delivered upgrades named Pascal, Maxwell, Fermi, and Mendel.

The deployment is mandatory: every node operator must upgrade to client version 1.7.7 before the activation timestamp or risk being removed from consensus.

Four coordinated proposals close bridge security gap first identified in validator set verification

The Pasteur upgrade bundles four distinct protocol improvements under the meta proposal BEP-673, each addressing specific technical vulnerabilities that have accumulated since the Fermi hard fork deployed in January 2026.

BEP-682 and BEP-695 focus on security hardening of the bridge and staking infrastructure, while BEP-675 improves throughput and can technically operate without requiring a hard fork, though BNB Chain chose to include it in the coordinated activation to streamline the upgrade process across the network.

The most critical piece of the upgrade is BEP-682, which closes a long-standing flaw in how BSC validates cross-chain asset transfers. When assets move onto the BSC mainnet from external blockchains, the network does not simply accept the originating chain’s claim about those assets.

Instead, BSC runs a precompile smart contract at address 0x67 that counts validator signatures against a known set of authorized validators, allowing the transfer only once a supermajority has signed off on the bridge transaction.

The vulnerability: BSC’s validator set had no mechanism to prevent the same validator from appearing multiple times in the list.

A crafted validator set could list the same signer address repeatedly, and the precompile would count that signer’s voting power on every occurrence. An attacker could artificially inflate a validator set to reach the supermajority threshold with far fewer genuine validator signatures than the rules actually demand.

BEP-682 eliminates duplicate entries before the signature count begins, ensuring that inflated validator sets can no longer bypass security thresholds and compromise the integrity of inbound bridge transfers.

BEP-695 prevents validator key rotation from becoming governance escape hatch

BEP-695 targets a distinct weakness in BSC’s staking and validator governance framework. When validators rotate their consensus keys as routine operational maintenance, the protocol previously assumed that a retired key would no longer carry any authority.

In practice, retired keys retained privileges they should have lost, creating an avenue for validators to circumvent governance rules and eviction penalties through strategic key rotation.

BNB Chain implemented three separate fixes to close this loophole. First, a validator that rotates to a new consensus key immediately loses its validator-admin privileges under the old key, preventing it from continuing to influence governance decisions or perform administrative functions from the retired address.

Second, a validator can no longer use key rotation to dodge a pending eviction or slashing event already initiated against its current key. Third, the upgrade blocks blacklisted addresses from participating in signature-based governance votes, removing another pathway for compromised or malicious validators to retain influence after being flagged.

These changes prevent validators from using operational procedures as a workaround to governance enforcement.

Throughput gains without sacrificing block time or gas economics

BEP-675 addresses execution inefficiency in BSC’s block production. Currently, each block gets executed twice on the network: the block builder first runs all transactions to validate that the block is valid and well-formed, and then the validator executes the entire transaction list again before signing the block and broadcasting it to the network.

This dual execution process compresses into a 450-millisecond window, reducing the time available for validators to complete their work and constraining block capacity.

By optimizing this execution pipeline, BEP-675 allows validators to process more transactions within the same block time and gas parameters.

Unlike previous throughput improvements such as the Fermi hard fork, which reduced block times from their previous level to 0.45 seconds in January 2026, this upgrade maintains BSC’s current block cadence while extracting additional transaction capacity from each block.

This approach avoids the need to retune gas pricing or modify the fundamental block interval, reducing the operational complexity for downstream infrastructure operators like exchanges and custodians.

The upgrade is technically compatible with non-hard-fork deployment but has been bundled into Pasteur for operational simplicity across the network.

BNB Chain’s scientist-themed hard fork naming reflects incremental rather than revolutionary upgrade philosophy

BNB Chain has maintained a deliberate naming convention for its hard forks, each named after a prominent scientist and each carrying incremental improvements to the network. Pascal, Maxwell, Fermi, and Mendel preceded Pasteur, establishing a pattern where no single upgrade attempts wholesale restructuring of the protocol.

This approach contrasts with some blockchain upgrade strategies that attempt to bundle extensive feature additions and consensus changes into one dramatic leap, which often introduces coordination risks and testing surface area.

The Fermi hard fork, deployed in January 2026, exemplified this incremental philosophy by specifically targeting block time reduction, bringing BSC’s production interval down to 0.45 seconds.

In the months following that deployment, BNB Chain deliberately chose stability over further acceleration, allowing the network to operate at the new block time and giving infrastructure participants time to adapt and validate the configuration under production conditions.

Pasteur continues this measured approach, bundling security fixes and moderate throughput gains without pushing block times faster or making sweeping changes to the validator set or consensus mechanism.

For institutional participants running BSC infrastructure, this strategy carries both operational and financial implications. Incremental upgrades with clear, focused scopes reduce the likelihood of consensus-breaking bugs and minimize the testing burden on node operators.

However, they also mean that performance gains compound more slowly, and infrastructure operators must stay current with a regular cadence of releases rather than consolidating updates into infrequent major deployments.

Node operators and exchanges must confirm they are running client v1.7.7 before August 25, 2026 at 02:30 UTC, or face automatic removal from the network at hard fork activation; infrastructure providers and staking services that have not yet published internal upgrade timelines should disclose their testing and deployment schedules for Pasteur within the next two weeks to allow downstream users to plan accordingly.