BNB Chain sets Aug. 25 Pasteur hard fork, targeting bridge security and higher throughput
BNB Chain is preparing a major network upgrade named Pasteur, scheduled to activate on Aug. 25, with a strong emphasis on tightening security and boosting performance. The hard fork is designed to improve cross-chain bridge verification, clean up validator key management, and almost double the network’s tested transaction capacity compared with previous benchmarks.
According to the project’s announcement, Pasteur will go live on BNB Smart Chain (BSC) at 2:30 a.m. UTC on Aug. 25, following several weeks of testing on the public testnet that began on July 21. The upgrade is mandatory for node operators, who must update to BSC client version v1.7.7 before the scheduled activation to remain in consensus and avoid their nodes desynchronizing.
Operators have also been instructed to remove the obsolete `EnableBAL` parameter from their configuration files. The new client software will refuse to start if this legacy setting is present, making configuration cleanup a prerequisite for a smooth transition.
Three core proposals: BEP-682, BEP-695 and BEP-675
Pasteur bundles three separate protocol proposals:
– BEP-682 – reinforces the checks on assets bridged into BNB Smart Chain from other networks.
– BEP-695 – reforms how validator keys and governance restrictions are handled.
– BEP-675 – optimizes how transactions are processed and packed into blocks to increase throughput.
Together, these changes aim to reduce attack surfaces in cross-chain operations, close loopholes in validator behavior, and enhance the chain’s capacity without altering block time.
Fixing a subtle flaw in bridge approvals: BEP-682
BEP-682 focuses on one of the most critical parts of any modern blockchain ecosystem: cross-chain transfer verification. When assets move from an external chain onto BNB Smart Chain, BSC relies on a set of validators (or oracles, depending on the bridge architecture) from the source network to approve the transfer. Only after a sufficient number of independent validators endorse the message is the incoming transfer considered valid.
BNB Chain’s developers identified that the current logic did not strictly enforce the requirement that each approval must come from a distinct validator. In the existing implementation, the same validator could appear multiple times within the approval list. With carefully crafted input, a malicious actor could, in theory, have a single validator’s confirmation counted more than once, allowing a transfer to be accepted with fewer unique validators than required by the protocol rules.
Pasteur introduces stricter validation rules that reject any approval sets containing duplicate validator entries. Under BEP-682, the system will only acknowledge unique participants in the approval list, ensuring that cross-chain transfers must be signed off by the correct number of separate validators before BSC mints or releases the bridged assets.
The network has not disclosed any real-world incidents directly exploiting this weakness, nor has it linked the change to a specific theft. Instead, BNB Chain presents BEP-682 as a preventive fix to a known design gap, implemented in response to the growing sophistication of attacks on cross-chain infrastructure.
Broader context: mounting pressure on bridge security
Although BNB Chain did not tie Pasteur to any particular exploitation event, the change comes amid heightened scrutiny of bridge mechanisms across the industry. Multiple high-value exploits over the past few years have exposed design flaws in validator approval processes, message signing, and key storage.
Recent incidents, such as the loss of hundreds of millions of tokens on bridges connecting major networks, have frequently involved issues with validator messages or compromised keys. Analytical reports have estimated that cross-chain bridge attacks have led to cumulative losses in the billions of dollars since 2021, with vulnerabilities in validator approval logic and poor transfer verification among the most common weak points.
By hardening the rules around who can authorize a transfer and how those authorizations are counted, BNB Chain is attempting to reduce the risk that a subtle implementation detail could be abused in a high-stakes environment where asset flows between chains are steadily increasing.
Closing validator loopholes and governance gaps: BEP-695
The second major component of Pasteur, BEP-695, focuses on validator key management and governance participation restrictions.
Validator keys are central to how BNB Smart Chain operates: they sign blocks, participate in consensus, and are used for various operational tasks. Rotating these keys periodically is a best practice, as it reduces the risk associated with long-term key exposure. However, BNB Chain’s team found that, under the current rules, an older key could retain certain management powers even after a replacement key was introduced.
Pasteur changes this behavior. Once a validator switches to a new key, the previous key will automatically lose all administrative rights tied to that validator slot. This ensures that only the currently active key can control validator functions, thereby narrowing the attack vector for anyone who might gain access to an outdated key.
Another important aspect of BEP-695 concerns penalties and enforcement. Under the previous setup, a validator who was at risk of being removed or penalized for breaking network rules could potentially switch keys and evade the pending consequences. After Pasteur, penalties and removal procedures will remain associated with the validator identity itself, not with any particular key. Rotating keys will no longer provide an escape route from slashing or other sanctions.
BEP-695 also addresses governance restrictions for blacklisted addresses. At present, addresses on a blacklist cannot vote on-chain directly. However, they have still been able to influence outcomes indirectly by signing an off-chain vote and then having a different, non-blacklisted account submit that signed message to the chain.
The Pasteur upgrade expands the restriction to cover these off-chain signed votes as well. After the fork, any governance vote originating from a blacklisted address – even if relayed by another party – will be considered invalid. This closes a loophole that allowed prohibited participants to continue shaping governance decisions through intermediaries.
BEP-675: more throughput without faster blocks
While the earlier proposals focus on security and governance, BEP-675 is aimed squarely at performance. BNB Smart Chain’s block time will remain at 0.45 seconds, a parameter already shortened in the earlier Fermi upgrade. Pasteur’s goal is not to accelerate block production but to make each block more efficient by fitting more finalized transactions into the same time window.
Currently, BNB Chain reports that block builders and validators duplicate certain tasks when preparing and validating blocks. For example, some parts of transaction execution and ordering can be recomputed more than once across the pipeline, which wastes processing capacity and constrains how many transactions the chain can reliably handle.
BEP-675 refines this process so that more of the heavy lifting happens exactly once, and intermediate results are reused where possible. By reducing redundant computation and optimizing the workflow between block construction and validation, BNB Chain has been able to raise the upper bound of its tested throughput.
Internal benchmarks cited by the project show that Pasteur lifts tested transaction capacity from 1,237 transactions per second (TPS) to 2,324 TPS under controlled conditions. While real-world performance will depend on network conditions, application behavior, and node hardware, the upgrade provides a much higher ceiling for periods of intense activity such as token launches, NFT mints, or market volatility.
Impact on node operators and infrastructure providers
For validators, full node operators, infrastructure providers, and custodians, Pasteur is a non-optional update. Failing to install v1.7.7 and adjust configuration files before Aug. 25 will likely result in nodes falling out of consensus, missing blocks, or being unable to rejoin the network cleanly.
Operators should:
– Upgrade client software to version v1.7.7 ahead of the fork.
– Remove the deprecated `EnableBAL` option from configuration files.
– Verify that key management processes are compatible with the new rules under BEP-695, especially for automated key rotation setups.
– Test their deployment in staging or testnet environments, mirroring the conditions expected around the fork.
Given that penalties will now more closely follow the validator identity regardless of key changes, operators should also review their internal procedures around misbehavior detection and response to ensure they are ready for stricter enforcement.
What changes for regular users and DeFi projects?
Everyday users, traders, and most decentralized applications can expect the upgrade to be backwards compatible from a transactional perspective. Typical on-chain actions – transfers, swaps, staking, liquidity provision – should continue to function as before, with no manual intervention required in wallets or dApps, provided those services’ backend infrastructure is kept up to date.
However, there are some practical implications:
– Bridge users: Those moving assets between BNB Chain and other networks may see stricter rules governing when transfers are considered final. Some cross-chain operations could take slightly longer in edge cases if the new approval checks require additional validator confirmations.
– DeFi protocols: Projects that rely on custom bridge logic or validator-based messaging should carefully review BEP-682 to ensure their integration assumptions still hold. Any protocol that constructs or interprets validator approval sets may need code audits or minor adjustments.
– Governance participants: Entities that are subject to sanctions or blacklist status will find it more difficult to participate in governance, even indirectly. Protocols with delegated voting or off-chain signature flows should confirm that their processes align with the new enforcement model.
Security posture and institutional relevance
The upgrade also has implications for institutions and regulated products with exposure to BNB. The network has highlighted that investors in certain jurisdictions, including the United States, may access BNB through listed investment products. For such products, network-level stability and security improvements can be material, as they influence both operational risk and long-term confidence in the underlying asset.
By addressing previously identified, if not publicly exploited, weaknesses in bridge approval logic and validator control, Pasteur strengthens the argument that BNB Smart Chain is adapting to the evolving threat landscape. For institutions that must justify their exposure from a risk-management perspective, visible, protocol-level enhancements of this kind can be significant.
Relationship to prior upgrades: from Fermi to Osaka/Mendel to Pasteur
Pasteur follows a series of previous hard forks on BNB Smart Chain:
– Fermi reduced block times to 0.45 seconds, cutting confirmation latency and increasing responsiveness.
– Osaka/Mendel, which went live in April, introduced nine proposals covering transaction caps, stability mechanisms, and alterations to the transaction confirmation process. This upgrade also required mandatory client updates and configuration changes, similar to what operators now face with Pasteur.
Unlike Fermi, which directly targeted latency, and Osaka/Mendel, which touched a broad set of parameters, Pasteur takes a more focused approach: keep the same rapid block cadence, but make each block do more work and tighten the rules around sensitive operations. In that sense, it continues the network’s evolution from raw speed gains to more nuanced improvements in reliability, governance, and security.
Strategic direction: why Pasteur matters now
The timing and design of Pasteur reflect the broader priorities of large smart contract platforms. As cross-chain activity becomes routine and value locked across multiple networks grows, chains are under pressure to:
– Improve bridge security to avoid catastrophic, reputationally damaging exploits.
– Strengthen validator accountability and governance integrity as ecosystems mature and attract more institutional interest.
– Scale throughput to accommodate the combined load of DeFi, NFTs, gaming, and real-world asset tokenization without sacrificing decentralization more than necessary.
By combining BEP-682, BEP-695, and BEP-675 into a single hard fork, BNB Chain is attempting to address all three fronts simultaneously: shore up cross-chain verification, close governance loopholes, and raise performance ceilings.
What to watch after the fork
Once Pasteur is activated, several indicators will help measure its impact:
– Bridge behavior: Observers will monitor whether cross-chain transfers remain smooth and whether new checks introduce any friction or noticeable delays under heavy load.
– Validator set dynamics: Changes in key-rotation practices, slashing events, and governance participation may signal how strictly BEP-695 is reshaping operator behavior.
– Network metrics: Transaction throughput during peak periods, mempool congestion levels, and average transaction inclusion times will show whether the jump in tested TPS translates into observable improvements.
– Security incidents: Over time, the absence of successful exploits exploiting validator or bridge logic will be an important, if indirect, validation of Pasteur’s design choices.
Outlook
Pasteur marks another step in BNB Chain’s transition from a fast-growing smart contract network toward a more security-hardened, institutionally palatable infrastructure layer. By upgrading bridge verification, validator key rules, governance enforcement, and transaction processing efficiency, the hard fork is intended to reduce systemic risk while making room for further growth in on-chain activity.
For developers, validators, and users alike, the key takeaway is that network participation remains largely unchanged on the surface, but the underlying rules enforcing who can approve what, how validators are disciplined, and how many transactions fit into each block will be stricter and more efficient once the upgrade is complete.