BNB Chain Pasteur Hard Fork: 3 Major Upgrades Now Live on BSC

The BNB Chain Pasteur hard fork is a security-focused BNB Smart Chain upgrade that strengthens cross-chain verification, hardens staking and governance, and streamlines MEV block production to create more room for future network capacity.

Pasteur activated on BSC mainnet at 02:30 UTC on August 25, 2026, and it is not a consumer-facing redesign. Wallets, decentralized applications, and smart contract interfaces continue to work as before. Its most important changes sit deeper in the infrastructure layer, where validator identity, governance permissions, bridge verification, and block-building efficiency directly affect network resilience.

For developers and organizations building on BNB Smart Chain (BSC), the upgrade is a timely reminder that application reliability depends on production-grade infrastructure that keeps pace with protocol changes. InfStones supports BNB Chain access through its enterprise-grade BNB Chain API, helping development teams connect applications to the network without managing every layer of node operations themselves.

What Is the BNB Chain Pasteur Hard Fork?

Pasteur is the latest BSC mainnet upgrade. According to the official BNB Chain announcement, the hard fork activated on mainnet at 02:30 UTC on August 25, 2026. The Chapel testnet activation took place on July 21, 2026.

All BSC mainnet nodes had to upgrade to BSC Node v1.7.7 before the activation time, and public mainnet endpoints now report that release. The v1.7.7 release also removed or deprecated several older flags and configuration fields, so any operator still working through the upgrade should review startup scripts and config.toml files before replacing the binary.

The Pasteur upgrade includes three BNB Evolution Proposals (BEPs):

Together, these proposals make Pasteur a security-first infrastructure upgrade with an important performance component. It strengthens assumptions that cross-chain and governance systems rely on while creating a more efficient path for builder-driven block production.

Upgrade 1: Safer Cross-Chain Verification With BEP-682

Cross-chain systems rely on light clients to verify that another blockchain reached sufficient validator agreement. On BSC, the CometBFT light block validation precompile at address 0x67 supports verification between BSC and CometBFT-compatible chains.

Before Pasteur, the precompile decoded validator sets but did not explicitly enforce validator uniqueness. A maliciously constructed set could repeat the same validator identity in multiple positions. That duplication could make a minority of real validators appear to hold a supermajority of voting power because one signature might satisfy several duplicated entries.

BEP-682 closes this gap by checking four identity fields for duplicates:

• Validator address
• Consensus public key
• Non-zero BLS public key
• Non-zero relayer address

The uniqueness checks apply to both the trusted validator set and the validator set contained in the incoming light block. If a duplicate is detected, the precompile rejects the input before running the remaining light client verification logic.

This is technically a breaking change because malformed inputs that were previously accepted now fail. However, legitimate validator sets should never contain duplicate identities, so compliant bridge operations are expected to remain unaffected.

The broader significance is straightforward: Pasteur makes an implicit bridge security assumption explicit and enforceable. Cross-chain infrastructure no longer has to rely solely on the expectation that every submitted validator entry represents a unique participant.

Upgrade 2: Stronger Staking and Governance Security With BEP-695

Validator operations involve more than producing blocks. They also include rotating keys, administering validator state, responding to slashable behavior, and participating in governance. Small inconsistencies between the current validator identity and historical state can create meaningful authorization risks.

BEP-695 introduces three targeted fixes across the StakeHub, BSCValidatorSet, and BSCGovernor system contracts.

Old Consensus Keys Lose Validator Administration Rights

Validators may rotate their consensus keys for security or operational reasons. Historical key mappings still need to exist for reward and slashing resolution, but an old key should not retain permission to perform new administrative actions.

Since Pasteur activated, StakeHub verifies that the calling consensus address is the validator's current, non-expired key before resolving it to the validator operator. The old key remains available for historical accounting but no longer carries validator administration authority.

Slashed Validators Are Removed After Key Rotation

Before the fix, slashing a validator after a consensus key rotation might not promptly remove that validator from the active mining set. The updated flow passes the validator's current consensus key to BSCValidatorSet.felony immediately after jailing.

The system also retains the existing eviction path based on the pre-rotation key. These complementary checks allow the active validator to be removed whether or not the validator set has already synchronized the rotated key.

Governance Blacklists Apply to the Actual Voter

Signature-based governance voting separates the account submitting a transaction from the account that signed the vote. A relayer may submit the transaction on behalf of the real voter.

Previously, the blacklist check covered the transaction sender but not every signature-based voting path. Pasteur adds a check on the recovered voter account inside _castVote, covering both castVoteBySig and castVoteWithReasonAndParamsBySig.

These changes tighten enforcement without altering existing application binary interfaces, storage layouts, or cross-chain message formats. As a result, compliant staking and governance workflows continue without integration changes.

Upgrade 3: A Faster MEV Block-Building Path With BEP-675

Pasteur's performance-related change focuses on how builder-proposed blocks reach validators. Under the legacy SendBid flow, a builder executes a set of transactions and sends the bid to a validator. The validator then executes the same transactions again before sealing the winning block.

That second execution provides a safety check, but it also consumes a large share of a short block interval. As the gas limit rises, validator-side simulation takes longer and leaves builders less time to compete, optimize transaction ordering, and construct blocks.

BEP-675 introduces SendBidBlock, a new path through which a builder submits a fully executed candidate block. The package includes signed user transactions, unsigned system transactions, and a block header containing execution results such as the state root, receipts root, logs bloom, and gas used.

The workflow changes from:

Import parent block, builder executes transactions, validator simulates the bid, validator seals the block

to:

Import parent block, builder executes transactions, validator verifies the header, completes assembly, and seals the block

The validator still performs several pre-seal checks. It verifies deterministic header fields, signs only approved system transaction methods, recomputes the transaction root, overwrites extra data with its local payload, and adds the final seal. After broadcasting, the validator imports the block locally and re-executes it to validate the state root, receipts root, and any blob commitments.

If a builder submits an invalid block, the validator can revoke that builder's SendBidBlock permission and move it back to the simulation-protected SendBid path. The legacy and new paths coexist for backward compatibility.

Importantly, BEP-675 did not itself require a consensus hard fork. The new validator-side path became eligible once Pasteur activated and is controlled through RPC, giving builders and validators time to integrate it.

Did Pasteur Increase BSC Throughput by 50%?

Not on day one. BEP-675 estimates that removing one complete EVM execution pass can raise the achievable gas limit ceiling by approximately 50% under typical network conditions. It also estimates that the builder execution window could expand from roughly 30% to 45% of the block interval.

These figures describe the proposal's performance model, not a guaranteed mainnet throughput increase at activation. Actual results depend on builder adoption, validator configuration, activation of the new RPC path, network conditions, and any later gas limit adjustments. The same caveat applies to BNB Chain's push toward a 100,000 TPS Layer 1, where headline throughput targets describe design ceilings rather than day-one mainnet output. Because SendBidBlock is permissioned per builder and enabled through RPC rather than by the fork itself, the real gains arrive gradually as builders and validators integrate.

Pasteur also does not directly shorten BSC block time. It improves the efficiency of work performed inside the existing block-production window. Nor does it guarantee lower gas fees, since transaction fees also depend on demand, gas policy, and application activity.

The accurate takeaway is that Pasteur removed a scaling bottleneck. It gives BSC more headroom to increase capacity without forcing validator bid simulation to consume an ever-larger portion of each block interval.

What Should BNB Chain Participants Do Now That Pasteur Is Live?

Node Operators and Validators

• Confirm every BSC mainnet node is running v1.7.7. Any node still on an older release will not follow the canonical chain.
• Remove [Eth] EnableBAL from config.toml, because the field can cause a startup error.
• Check for removed or deprecated flags still present in startup scripts, including --multidatabase, --enablebal, --journalfile, and --fake-beacon options.
• Re-validate synchronization, monitoring, automated failover, and rollback procedures against the post-fork chain rather than assuming pre-upgrade baselines still hold.

MEV Builders

• Integrate the SendBidBlock RPC and construct complete execution results correctly.
• Reserve sufficient gas for required system transactions.
• Poll validator permission status and support automatic fallback to SendBid.
• Test rejection, permission revocation, and recovery behavior before relying on the new path in production.

Bridge and Cross-Chain Infrastructure Teams

• Confirm that validator sets never contain duplicate identities.
• Test error handling for rejected 0x67 precompile inputs.
• Continue monitoring cross-chain verification in the days following activation, when integration issues typically surface.

DApp Developers and Users

No wallet migration or smart contract change is required for ordinary users and most DApps. Development teams should still confirm their BNB Chain RPC providers completed the upgrade and run targeted transaction, event, and contract-read tests against the post-fork chain.

Why Infrastructure Readiness Matters

Protocol upgrades activate at a precise timestamp, but production readiness is a continuous process. Node software, configuration, observability, redundancy, and incident response all need to remain aligned with the current chain implementation.

For teams that do not want to operate every node component internally, InfStones provides enterprise-grade BNB Chain API access with security controls, usage statistics, and logs. A reliable infrastructure layer can help applications maintain consistent access while engineering teams focus on products, smart contracts, and user experience.

Organizations running their own validator or node infrastructure should treat a hard fork like Pasteur as an operational change window that extends past the activation timestamp, in the same way institutional validators absorb a major consensus change on Solana. High-availability architecture, cloud-agnostic deployment, tested automated failover, and version-aware monitoring remain essential, especially as BSC continues to optimize for higher throughput.

Frequently Asked Questions

When did the BNB Chain Pasteur hard fork activate?

The BSC Pasteur mainnet hard fork activated on August 25, 2026, at 02:30 UTC. The Chapel testnet upgrade activated on July 21, 2026.

What are the three main Pasteur upgrades?

Pasteur includes BEP-682 for duplicate-validator rejection, BEP-695 for staking and governance security hardening, and BEP-675 for builder-proposed blocks that avoid validator-side simulation before sealing.

Do BNB Chain users need to take action?

Ordinary wallet users and most DApps do not need to take action. BSC node operators must be on v1.7.7, while builders and cross-chain infrastructure teams should verify the new behavior relevant to their systems.

Did the Pasteur upgrade reduce gas fees?

Pasteur does not directly guarantee lower gas fees. BEP-675 creates capacity headroom by making block production more efficient, but fees still depend on network demand, gas limits, validator settings, and application activity.

Is SendBidBlock safe if validators do not simulate bids before sealing?

The validator verifies key header and system transaction constraints before sealing, then imports and fully validates the block after broadcast. A builder that submits an invalid block can lose SendBidBlock access and fall back to the simulation-protected legacy path.

Built for BNB Chain's Next Stage

The BNB Chain Pasteur hard fork is best understood as a foundation upgrade. BEP-682 makes cross-chain validator uniqueness enforceable. BEP-695 closes important staking and governance authorization gaps. BEP-675 removes redundant execution from the builder pipeline and expands the network's potential capacity ceiling.

None of these changes should be reduced to a simple promise of faster transactions or cheaper gas. Their combined value is more structural: stronger security assumptions, cleaner enforcement, and a more efficient block-production path that BSC can build on.

As BNB Chain continues to scale, developers and institutions will need production-grade infrastructure that can absorb protocol changes without compromising reliability. InfStones is committed to supporting that next stage with enterprise-grade, high-availability blockchain infrastructure and dependable BNB Chain connectivity.

Sources

• BNB Chain: Pasteur Upgrade of BSC
• BEP-673: Hardfork Meta-Pasteur
• BEP-675: Builder-Proposed Block with Validator Blind Signing
• BEP-682: Reject Duplicate Validators in CometBFT Light Block Validation
• BEP-695: Staking and Governance Security Hardening
• BSC v1.7.7 Changelog