BNB Chain Pasteur hard fork: what BEP-675, BEP-682 and BEP-695 actually changed on BSC

On 25 August 2026, at 02:30 UTC, BNB Smart Chain activated the Pasteur hard fork on mainnet. Three proposals shipped together under BEP-673: BEP-682, BEP-695 and BEP-675. Each addresses a different layer of the network — bridge verification, validator governance, and block-building efficiency. This article explains what each proposal changed, why it was needed and what the upgrade actually means for ordinary users, developers and node operators.

Why Pasteur matters: context before the details

BSC had spent three consecutive hard forks — Lorentz, Maxwell and Fermi — cutting block time from three seconds down to 450 milliseconds. Pasteur is the first fork since Fermi to leave block time untouched. Instead of speeding the chain further, it focused on using every 450 ms window more efficiently and on closing known security gaps in the bridge and governance systems.

That context matters when evaluating what the upgrade delivers. Pasteur does not promise cheaper gas, faster confirmations for end users or an immediate doubling of real-world throughput. It removes architectural bottlenecks and closes verification holes that could have been exploited at scale.

BEP-682: closing the bridge signature flaw

When assets move between BSC and other chains, the receiving side does not take the sender's word for it. BSC checks that a supermajority of validators on the originating chain signed the cross-chain block before processing a transfer. That check runs through a precompiled contract at address 0x67.

Before Pasteur, that precompile counted signatures but did not verify that each validator appeared only once in the set. A crafted message could list the same validator multiple times, count their voting power repeatedly and reach the supermajority threshold with far fewer genuine signers than the protocol requires. BEP-682 fixes this by checking four identity fields for each entry — validator address, consensus public key, BLS public key and relayer address — and rejecting any set that contains duplicates before the remaining verification logic runs.

The BNB Chain blog describes the problem plainly: "a crafted set could list the same validator repeatedly, count their power several times over, and clear the threshold with far fewer real signers than it's meant to require." The October 2022 Token Hub exploit drained roughly $570 million from BSC's bridge before being partially recovered. That attack also exploited a flaw in cross-chain signature verification. BEP-682 is a different fix addressing a different gap, but the historical context explains why bridge verification receives close attention from the BNB Chain security team.

For legitimate bridge operations, BEP-682 is invisible. Correct validator sets should never contain duplicate identities. The change is technically breaking — inputs that passed before now fail — but only malformed ones fail.

BEP-695: tightening validator key rotation and governance

Validators on BSC rotate their consensus keys as routine security hygiene. Before Pasteur, the transition was incomplete in three specific ways that BEP-695 addresses.

First, rotated keys retained validator-admin authority they should have given up. After rotation, the old key continued to have privileges over the validator record. BEP-695 makes StakeHub verify that any calling consensus address is the validator's current, non-expired key before granting admin access. The old key remains available for historical accounting but loses operational authority.

Second, slash eviction did not reliably follow a key rotation. If a validator was slashed after rotating keys, the penalty might not remove them from the active mining set. The updated flow passes the validator's current consensus key to BSCValidatorSet.felony immediately after jailing, with a fallback path on the pre-rotation key as well. A misbehaving validator cannot effectively shed a pending eviction by rotating.

Third, signature-based governance voting had an inconsistent blacklist. The system that prevents specific addresses from voting already applied to direct votes. BEP-695 extends that check to cover castVoteBySig and castVoteWithReasonAndParamsBySig, closing a path through which a blacklisted address could vote via a relayer. The recovery of the actual voter from the signature is now checked before any vote is counted.

These changes affect the StakeHub, BSCValidatorSet and BSCGovernor system contracts. They do not alter existing application binary interfaces, storage layouts or cross-chain message formats. Compliant staking and governance workflows continue without integration changes.

BEP-675: filling blocks without changing the clock

Under the block-building process that existed before Pasteur, specialist builders compete to submit the most valuable set of transactions to the validator producing the next block. The process had a sequential execution problem. The builder ran all transactions to produce a valid block and sent it to the validator. The validator then re-executed every transaction to verify the block before sealing it. Both parties performed the same work on the critical path inside a 450 ms window.

That duplication consumed time the builder could have used to include more transactions. BNB Chain's own benchmarks found that validator re-work was consuming around 125 ms per block on the critical path, leaving builders only about 30% of the block interval for their own execution. Many blocks went out under half full not because there was nothing to include but because the clock ran out.

BEP-675 introduces a new path called SendBidBlock. A builder submits a fully executed candidate block containing signed user transactions, unsigned system transactions and a block header with execution results including the state root, receipts root, logs bloom and gas used. The validator checks the block against consensus rules, signs it and broadcasts it, then finishes full state verification afterwards. The builder's execution work is accepted provisionally; the validator's re-execution moves off the critical path.

In controlled testnet benchmarks on QANet, an internal network mirroring mainnet's cross-region validator topology, this cut validator re-work from 125 ms to 15 ms per block. The builder window expanded from roughly 30% to 45% of the block interval. Throughput rose from 1,237 TPS to 2,324 TPS at the same 450 ms block time and 100 million gas limit. Average gas used per block increased from 46.35 million to 84.15 million of the 100 million available.

Those are testnet figures under a controlled workload. Mainnet realized gains depend on builder adoption of the SendBidBlock path, validator configuration and actual network conditions. BEP-675 creates headroom; it does not force blocks to be fuller or guarantee a specific throughput number on day one.

Importantly, BEP-675 did not itself require a hard fork. The new validator-side path is enabled after Pasteur activates and is controlled through RPC, giving builders and validators time to integrate before committing to the new flow. Legacy bids remain available for backward compatibility.

What changed for different roles

Ordinary wallet users and most dApp users were not required to do anything. Balances remained on chain. Wallet interfaces continued to work. The security improvements in BEP-682 and BEP-695 are invisible when they function correctly, and BEP-675's capacity gains arrive gradually as builders integrate SendBidBlock. The main practical risk during any hard fork window is phishing: fake upgrade prompts, suspicious links claiming urgent wallet action and unofficial binaries targeting node operators. Users who received unsolicited messages about the upgrade and signed nothing were correct to ignore them.

Active DeFi users and developers had light work to do: confirming that RPC providers completed the upgrade and running targeted transaction, event and contract-read tests against the post-fork chain. Applications that rely on specific block metadata or MEV assumptions should review behavior against post-Pasteur baselines.

BSC node operators needed to run v1.7.7 before 02:30 UTC on 25 August. The upgrade also required removing the [Eth] EnableBAL field from config.toml, which would otherwise cause a startup error. Several CLI flags were deprecated or removed: --journalfile, --miner.txgaslimit, --enablebal, --multidatabase, --txpool.overflowpoolslots and the --fake-beacon family. A binary replacement was sufficient after confirming those configuration items.

Block builders who want to use the BEP-675 path need to run a fullnode rather than a fastnode, since submitting a fully executed block requires full execution capability. Legacy bid submission continues to work. The gains from BEP-675 accrue as builders and validators adopt the new path.

What Pasteur does not change

Block time remains 450 ms. The gas limit remains 100 million per block. Gas prices depend on demand and block policy, not directly on this upgrade. There is no guaranteed fee reduction. Wallet addresses, balances, pending approvals and contract positions are unaffected by the fork itself. BEP-675's throughput figures describe a performance ceiling in testnet conditions, not a commitment to any specific mainnet output. Whether those gains hold at mainnet scale depends on adoption and network conditions.

How to verify the upgrade happened

Block explorers such as BscScan show the current block number and network state. The BSC v1.7.7 release on GitHub is the official node release for Pasteur. The official BNB Chain announcement records the exact activation time and the three BEPs. The BNB Chain blog post explains the reasoning and testnet benchmarks behind each proposal.

A hard fork that activated without incident produces no visible discontinuity for ordinary users. The absence of complaints is expected, not evidence of unchanged behavior. If you want to confirm that a BSC node is running Pasteur-compatible software, check its reported client version against the v1.7.7 release.

Pasteur in the context of BSC's scaling roadmap

BNB Chain has described a long-term target of 100,000 TPS on a new high-performance Layer 1 with sub-50 ms preconfirmations and no public mempool. Testnet was mentioned for end of 2026 and mainnet for early 2027 in official roadmap language, though those timelines have not been confirmed with a specific launch date.

Pasteur fits as a near-term capacity step: removing redundant execution from block production, hardening the security of cross-chain infrastructure and governance, and giving BSC more effective headroom at the existing 450 ms block cadence. The stated objective for the second half of 2026 is doubling mainnet throughput, with Pasteur identified as the first enabling step in that workstream. Whether QANet's benchmark gains translate to mainnet at scale is an open question that requires post-fork measurement over real traffic conditions.

Sources

• BNB Chain — Pasteur Upgrade of BSC (official announcement)
• BNB Chain Blog — Pasteur Hardfork Arrives on BSC Mainnet on August 25
• BSC v1.7.7 release — GitHub
• BEP-673: Hardfork Meta-Pasteur — GitHub