BNB Chain sets Aug. 25 Pasteur hard fork to tighten bridge security and double tested TPS capacity
BNB Chain is preparing to activate its next major upgrade, the Pasteur hard fork, on Aug. 25, with a clear focus on hardening security and pushing the network’s technical limits. The upgrade introduces stricter cross-chain bridge checks, more robust validator key management, and a revamped block-building process that has lifted tested throughput from 1,237 to 2,324 transactions per second in internal benchmarks.
According to the project’s schedule, Pasteur will go live on BNB Smart Chain (BSC) at 2:30 a.m. UTC on Aug. 25. The code has already been running on the testnet since July 21, giving node operators and developers several weeks to prepare for the transition.
To remain in sync with the network, node operators must upgrade to BSC client version v1.7.7 before the activation block. Operators are also instructed to delete an obsolete configuration flag called `EnableBAL`. The new software will refuse to start if this legacy parameter is still included, making cleanup mandatory for all production nodes.
Pasteur bundles three individual proposals: BEP-682, BEP-695, and BEP-675. Together, they are designed to address weaknesses in cross-chain transfers, close loopholes in validator governance and key rotation, and streamline how transactions are assembled into blocks without changing the existing block time.
BEP-682: Stronger checks for cross-chain transfers
BEP-682 introduces a redesigned mechanism for verifying asset transfers that originate on other blockchains and arrive on BSC. Today, when assets are bridged to BNB Smart Chain, the network checks whether a sufficient number of validators from the source chain has approved the transfer before finalizing it.
The current implementation, however, has a subtle flaw: it does not reliably prevent the same validator from being counted multiple times. A maliciously crafted approval message could, in theory, list a single validator’s signature more than once, inflating the apparent number of approvals and allowing a transfer to pass with fewer distinct validators than the rules require.
Pasteur closes this gap by rejecting repeated validator entries outright. Under the new rules, only unique validators will be counted when BSC verifies cross-chain messages. This ensures that the required threshold truly reflects a minimum number of independent validator approvals, rather than repeated signatures from the same participant.
The upgrade targets a specific structural weakness in the bridge verification process. While BNB Chain has not disclosed any confirmed incidents where this issue was exploited to steal funds, the change reflects a broader industry push to harden cross-chain infrastructure before such vulnerabilities can be weaponized.
Cross-chain bridge security under mounting pressure
The timing of BEP-682 coincides with a surge of attention around the safety of cross-chain bridges. In recent years, large-scale exploits of bridge infrastructure have become one of the most damaging attack vectors in decentralized finance. Several of the biggest hacks on record have involved compromised validator keys, poorly designed message validation, or insufficient quorum checks for bridging events.
In one recent incident, a Cardano-to-BNB Chain bridge operated by a third-party provider reportedly lost hundreds of millions of NIGHT tokens, worth around $9 million at the time. Security analysts pointed to weaknesses in how messages were constructed and approved by validators as a likely contributing factor. Although that particular event did not involve BNB Chain’s native bridge design or the core Midnight Network, it underscored how fragile cross-chain messaging can be when even a single component is misconfigured or undersecured.
Independent research has tracked more than $4 billion in losses connected to cross-chain bridge attacks since 2021, with stolen validator keys, lax approval rules, and flawed verification logic among the recurrent themes. Against that backdrop, BNB Chain’s decision to harden its approval mechanism via BEP-682 can be seen as both a defensive move and a signal to users that bridge-related risk remains a top priority.
Notably, BNB Chain has not linked Pasteur or BEP-682 to any specific exploit or recent breach. Instead, the proposal is framed as a proactive correction to the logic governing how incoming cross-chain transfers are validated before they are accepted on BSC.
BEP-695: Stricter validator key rotation and governance controls
The second major component of Pasteur, BEP-695, targets validator operations and governance loopholes. Validators periodically rotate their cryptographic keys as a normal security practice. However, under the existing rules, an old key could sometimes retain operational privileges on the network even after a new key had been registered.
Pasteur removes this inconsistency. Once a validator successfully switches to a new key, the superseded key will automatically lose all management and operational rights. This change reduces the surface area for potential misuse of stale keys, whether through negligence, compromise, or delayed cleanup by validator operators.
BEP-695 also ensures that penalties follow validators across key changes. Previously, a validator facing removal or other sanctions for violating protocol rules could, in theory, obscure its identity by changing keys, potentially complicating enforcement. After the Pasteur hard fork, pending penalties and disciplinary actions will remain attached to the validator entity regardless of key rotation, preventing validators from using key changes as an escape hatch.
The proposal further tightens on-chain governance. Addresses that have been blacklisted are already prevented from casting votes directly on BSC. Yet under the old system, they could still sign a vote off-chain and then have another, non-blacklisted address submit that signed message to the blockchain, effectively proxying their will into the governance process.
After Pasteur, this workaround will be disabled. Signed messages originating from blacklisted addresses will no longer be valid for governance participation, closing the indirect path and aligning off-chain signature voting rules with on-chain address restrictions.
BEP-675: More efficient block building without faster blocks
The third proposal, BEP-675, targets performance rather than security, refining how blocks are prepared and finalized. BNB Chain recently shortened its block time to around 0.45 seconds in the earlier Fermi upgrade, and Pasteur intentionally keeps that interval unchanged. Instead of making blocks arrive more frequently, the new changes aim to fit more transactions into each block and reduce redundancy in the block production process.
Currently, both block builders and validators can end up performing overlapping work as they assemble and validate the same set of transactions before a block is finalized. This duplication consumes compute resources and limits how many transactions the network can reliably process per second.
With BEP-675, the responsibilities and workflow between block builders and validators are more clearly separated and optimized. Builders are expected to do more of the heavy lifting in ordering and pre-processing transactions, while validators focus on checking a leaner, more finalized package, rather than redoing broad parts of the same work.
Internal testing by BNB Chain’s team indicates that this optimization has nearly doubled the network’s sustained throughput capacity, raising tested performance from 1,237 transactions per second to 2,324 TPS under lab conditions. Although real-world throughput will depend on network conditions and user activity, the enhancement suggests ample headroom for growth in on-chain usage without sacrificing the current fast block time.
Continuity with earlier upgrades: from Fermi to Osaka/Mendel to Pasteur
Pasteur is the latest in a series of substantial BNB Chain upgrades aimed at both scalability and resilience. In January, the Fermi upgrade cut BSC’s block time to 0.45 seconds, making transactions confirm significantly faster. In April, the Osaka/Mendel hard fork introduced nine proposals spanning transaction limits, overall network stability, and confirmation logic, again requiring node operators to install a new client version (v1.7.2) and tidy up configuration files to avoid desynchronization.
The Pasteur fork continues this pattern: a mandatory client update, configuration cleanup, and a combination of security and performance improvements. By keeping the block time stable and focusing on packing more transactions into each block while tightening bridge and governance controls, BNB Chain is signaling that it considers the current latency profile acceptable, and is now pushing for efficiency and safety rather than raw speed.
What node operators need to do before Aug. 25
For infrastructure providers, validators, and other node runners, the Pasteur deadline is effectively non-negotiable. To avoid being left behind on an incompatible chain:
– Upgrade to BSC client version v1.7.7 before the scheduled fork time.
– Remove the deprecated `EnableBAL` parameter from configuration files.
– Verify that validator key management processes account for the new rules, including the automatic revocation of old keys and persistence of penalties across key rotations.
– Review governance participation tools to ensure compliance with the updated restrictions on blacklisted addresses and off-chain signatures.
Failure to complete these steps may result in nodes failing to start, falling out of consensus, or operating on a forked version of the network that is no longer considered canonical.
Implications for developers and DeFi protocols
For builders on BNB Smart Chain, Pasteur’s changes carry several implications:
– Cross-chain apps and bridge integrators will benefit from more robust validator approval checks, reducing systemic risk on transfers into BSC. Developers who rely on custom bridge logic may want to compare their own validation rules to those encoded in BEP-682 to avoid misalignment.
– Governance tooling, such as dashboards, multisig setups, and voting interfaces, will need to account for stricter enforcement against blacklisted participants, particularly when using signed messages.
– Performance gains from BEP-675 could make high-throughput DeFi protocols, on-chain order books, and gaming applications more stable under heavy load, although developers should still design for peak congestion scenarios.
While Pasteur does not introduce new smart contract primitives, it changes the operational environment in which those contracts run, especially for systems that depend on cross-chain messaging or rely heavily on governance mechanics.
What this means for BNB holders and market participants
For BNB token holders, including those with exposure through regulated investment products that track BNB’s price, Pasteur is largely a technical backend upgrade rather than a tokenomics change. The total supply, issuance schedule, and core economic parameters of BNB remain unaffected.
However, improved security on cross-chain transfers and clearer validator accountability can influence long-term market confidence. Reducing the likelihood of catastrophic bridge failures or governance manipulation tends to support a more stable ecosystem, which, in turn, can affect user growth and protocol adoption on BSC.
Institutional and retail investors who access BNB through listed funds or structured products may not need to take direct action for the fork itself, but they may wish to follow how major DeFi protocols, bridges, and centralized exchanges respond to the upgrade, especially around maintenance windows and potential temporary suspensions of deposits and withdrawals during activation.
Broader context: security-first scaling for blockchain networks
Pasteur’s design reflects a broader shift across the blockchain space: scaling is no longer pursued purely by increasing block size or reducing block time. Instead, networks are seeking a more nuanced balance between throughput, decentralization, and safety.
By keeping block time constant and focusing on:
– eliminating duplicate work in block assembly,
– closing loopholes in validator governance and key rotation, and
– enforcing strict uniqueness in cross-chain validator approvals,
BNB Chain is leaning into a security-first approach to scaling. This is particularly important for ecosystems that sit at the center of complex webs of bridges, sidechains, and external networks, where a single weak link can have outsized repercussions.
Looking ahead after Pasteur
Once Pasteur is activated and proves stable in production, BNB Chain will likely use the upgraded foundation as a springboard for further enhancements. Future efforts may focus on additional bridge standards, improved monitoring for validator behavior, and even more sophisticated load management mechanisms.
For now, Pasteur marks a significant milestone: it shores up known weaknesses in bridge validation and governance, clarifies validator responsibilities, and substantially raises tested performance capacity without compromising confirmation speed. How effectively these changes translate into real-world security and scalability will become clear in the months following the Aug. 25 hard fork, as the network operates under peak demand and continues to evolve under the pressure of real usage and adversarial testing.