TL;DR

• Pasteur activates on BNB Smart Chain mainnet at 02:30 AM UTC on 25 August 2026.
• Mainnet nodes must be running client v1.7.7 before then.
• BEP-682 and BEP-695 harden the bridge, staking, and governance.
• BEP-675 fills blocks fuller: 1,237 to 2,324 TPS in testnet benchmarks.

Two things get better on 25 August:

1. Assets crossing the BNB Chain bridge get a stronger guarantee that a genuine supermajority of validators signed off on them.
2. Blocks start carrying more transactions without the chain running any faster or charging any more gas.

That's what the Pasteur hardfork is for. It's been live on BSC testnet since 21 July, and mainnet activation is set for 02:30 AM UTC on 25 August 2026.

The last two upgrades were about speed: Fermi took block times to 0.45 seconds, and Osaka/Mendel steadied the network at that pace. Pasteur is about using that speed more fully, and closing two ways a validator could hold onto power it shouldn't have. Three proposals ship in the fork, grouped under BEP-673.

Stronger bridge verification (BEP-682)

When assets move between chains, BSC doesn't take the other chain's word for it. It checks that enough validators over there signed the block first. Enough real signatures, or nothing moves.

That check runs in a precompile at 0x67, which counts signatures against a validator set. Before Pasteur it didn't verify that each validator appeared only once, so 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. BEP-682 rejects duplicates outright.

Validator keys that properly retire (BEP-695)

Validators rotate consensus keys as normal hygiene. When they do, the old key should stop working, and anything pending against them should follow to the new one. BEP-695 makes that hold in three places:

• A rotated key loses validator-admin authority. It used to keep privileges it should have given up.
• Slash eviction follows a key rotation, so a pending eviction can't be shed by rotating.
• Blacklisted addresses are rejected on signature-based governance votes (castVoteBySig and castVoteWithReasonAndParamsBySig), which had been a way around a check that already applied to direct votes.

Fuller blocks at the same speed (BEP-675)

Most blocks on BSC are assembled by specialist builders competing to submit the most valuable set of transactions to whoever produces next. Right now the work happens twice: the builder runs the transactions to check the block is valid, hands it over, and the validator runs all of them again before signing.

That repeat costs time, and it costs it inside a 450ms window. Whatever the validator spends re-executing comes straight out of the time builders have to pack the next block, so some blocks were going out under half full because the clock ran out, not because there was nothing to include.

BEP-675 lets a builder submit a block it's already executed. The validator checks it against consensus rules, signs and broadcasts, then finishes full verification afterwards. On QANet, an internal testnet mirroring mainnet's cross-region validator topology, that cut the validator's slice of the critical path from 125ms to 15ms. Throughput went from 1,237 to 2,324 TPS at the same 450ms interval and 100M gas limit, and average block gas used rose from 46.35M to 84.15M of the 100M available. Finality lag didn't move. Full methodology is in our BEP-675 testnet benchmark.

Those are testnet figures under a controlled workload, not mainnet measurements. BEP-675 also doesn't need a hardfork of its own. The SendBidBlock path is gated behind Pasteur and then switched on via RPC, which gives builders time to integrate first.

What changes for builders and users

For most developers: more room in each block, and nothing to do to get it. Pasteur touches bridge verification, the staking and governance system contracts, and the path a block takes from builder to validator. There's no migration.

Block builders have the most to gain and the only real work to do. Using the BEP-675 path means running a fullnode rather than a fastnode, since the builder now produces a fully executed block. Legacy bids keep working, with less packing time.

Users won't notice anything different day to day. Security fixes are invisible when they're working, and what BEP-675 buys is headroom: busier periods get absorbed instead of transactions queueing behind a half-empty block.

For validators and node operators

Mainnet nodes need v1.7.7 before 02:30 AM UTC on 25 August. A binary replacement is enough, with one thing to check first: [Eth] EnableBAL must come out of config.toml, or the node won't start.

Several CLI flags are gone or now inert, including --journalfile, --miner.txgaslimit (EIP-7825 enforces per-transaction gas limits instead), --enablebal, --multidatabase, --txpool.overflowpoolslots and the --fake-beacon family. The full list is in the docs announcement and the v1.7.6 release notes.

What’s next

BEP-675 is the capacity workstream in the H2 2026 roadmap. The stated objective for the half doubling mainnet throughput, scaling toward a long-term10x improvement across BNB Chain. Whether QANet's gains hold at mainnet scale is the open question.

Node operators: pull v1.7.7, check config.toml for EnableBAL, and upgrade before 25 August. Builders who want the BEP-675 path should read the BEP and plan for a fullnode.