BSC raises its block gas limit to 70 million: what changed on September 14–15, 2026

On September 14–15, 2026, BNB Smart Chain validators completed a coordinated upgrade raising the target block gas limit from roughly 55 million to 70 million. This is the first explicit capacity increase since the Pasteur hard fork activated on August 25, and it is the most concrete signal yet that BEP-675 — the architectural change Pasteur introduced — is performing well enough under real traffic to justify pushing the ceiling higher.

The upgrade was not a sudden decision. It followed three weeks of mainnet data showing that BidBlock V2, the new block-building path introduced by BEP-675, had reached 98% adoption across builder-produced blocks and was averaging 28% more gas per block than the previous method. The network was also running above 95% utilization — close enough to its limit that fee spikes and congestion were a foreseeable outcome without intervention.

Why the network needed more capacity now

A block gas limit sets the total amount of computational work that can fit into one block. Every transaction on BSC consumes some amount of gas — a simple BNB transfer uses 21,000 gas, a DeFi swap typically uses 100,000 to 300,000, and complex interactions with protocols like PancakeSwap or Venus can consume significantly more. When blocks fill up, pending transactions wait longer, and the network's fee market — which adjusts dynamically — pushes gas prices up to ration the available space.

BSC entered September 2026 with a 55 million gas limit and utilization consistently above 95%. That left almost no slack for demand spikes. A surge in trading activity, a popular token launch, or a brief congestion event could push fees noticeably higher for ordinary users. Validators decided not to wait for that to happen.

The timing matters because the upgrade was contingent on the Pasteur architecture proving itself. BEP-675 needed to be stable at scale before the team felt comfortable increasing the ceiling. The first-week data after August 25 provided that evidence, and the September 14–15 window was the first planned opportunity to act on it.

What BEP-675 changed in block production

To understand why a gas limit increase is less risky now than it would have been before Pasteur, it helps to know what BEP-675 actually changed.

Before Pasteur, building a block on BSC involved three passes through the Ethereum Virtual Machine. A builder would execute transactions to construct a candidate block, submit it to a validator, and the validator would re-execute the same transactions before sealing the block. That third pass was a safety check, but it was also redundant computation: the validator was replaying work the builder had already done.

BEP-675 introduced a new procedure called SendBidBlock that allows builders to submit a fully executed block — including transaction results and state changes — directly to the validator. The validator can then assemble and seal the block without replaying every user transaction. The result is that more of the block-sealing window is available for builders to pack transactions, and validators spend less time on work that was already done. A correctness check still happens after the block is broadcast: validators execute the block during local import and verify the state root, receipts, and other commitments. Bid V1 also remains available as a fallback.

Under live mainnet conditions, this architectural change produced BidBlock V2 blocks that averaged 28% more gas than Bid V1 blocks. At the 99th percentile — the blocks at the top end of the density distribution — BidBlock V2 reached 43.8 million gas compared with 33.8 million for Bid V1. Both numbers are below the 55M limit, which means there was still headroom. Raising the limit to 70 million creates more of that headroom without requiring the network to operate at the edge of its capability.

The dynamic gas limit mechanism

One aspect of the 70M upgrade that distinguishes it from a simple configuration change is how the target is set. Validators do not hard-code 70 million into their nodes. Instead, each validator calculates the target dynamically, based on real-time network conditions: recent block fullness, missed blocks, latency, and other health signals. The 70 million figure is the target validators are converging toward, not a fixed ceiling that applies uniformly regardless of what the network is experiencing.

This matters for a few reasons. It means the effective gas limit can flex slightly below 70M if the network shows signs of stress — missed blocks, elevated latency, or unusual block behavior. It also means validators bear responsibility for monitoring their own hardware capacity as block payloads grow. Larger blocks take longer to propagate across the network, longer to execute on import, and generate more data that all connected nodes must process. If a validator's hardware cannot keep up with consistently full 70M blocks, the dynamic calculation should reflect that.

The @BNBChainDevs guidance for validators during the upgrade was specific: set the target gas limit to 70 million, restart the node, and reconsider block-packing simulation budgets to account for the larger block window. The instruction not to hard-code 70M was explicit — the dynamic derivation from the parent block is required for the mechanism to work correctly.

What it means for users and applications on BSC

For everyday users — sending BNB, swapping on PancakeSwap, depositing collateral on Venus — the most immediate effect of a higher gas limit is reduced probability of fee spikes and transaction queuing during periods of high demand. A network running at 55M with 95% utilization has almost no margin. A network with a 70M ceiling and the same underlying demand has roughly 27% more capacity before hitting the same pressure point.

For applications like PancakeSwap, which was already processing around $29 billion in 30-day DEX volume in September 2026, additional block space means more transactions can settle in the same time window. For RWA platforms, DeFi protocols, and tokenized equity products that require atomic multi-step execution, larger blocks reduce the risk of a transaction failing because it cannot fit into a congested block.

There is no action required from users. The upgrade happens at the validator level. No wallet reconfiguration, no network switching, no new RPC endpoints. Gas prices may decrease as relative utilization drops from the previous 95%+ level, though the fee market will eventually reach a new equilibrium as demand adjusts to the available space.

Risks and infrastructure requirements

Higher gas limits are not free. Bigger blocks require more bandwidth for propagation between nodes, more memory and CPU for execution, and more disk I/O as state changes accumulate. As BSC pushes toward 70M and beyond, several infrastructure upgrades are in development to keep the network healthy.

One is a switch from JSON and hexadecimal block delivery to RLP-encoded data over gRPC, which reduces serialization overhead and improves the delivery of large BidBlocks under latency pressure. Another is eth/70, a revised peer synchronization protocol that allows block receipts to span multiple responses — important because the current protocol creates a practical ceiling around 83 million gas, where receipts can no longer fit in a single 10 MiB response. A third is Block-Level Access Lists (BAL), which expose state accesses in advance and enable techniques like state prefetching and dependency-aware parallel execution. BAL is not required for the 70M step but is part of the path to 90M.

There is also a validator centralization risk worth naming explicitly. If block payloads grow significantly, only validators with high-end hardware will be able to process them reliably. That creates pressure for less-resourced validators to exit the active set, which could reduce the breadth of the validator pool over time. BSC's sequential, data-gated approach to gas limit increases — where each step requires evidence from mainnet before proceeding — is designed to catch this risk before it materializes, but it remains a structural concern for any network that scales block size rather than block frequency.

What comes next: 80M and 90M

The 70 million target is explicitly positioned as one step in a three-stage roadmap. BSC developers have outlined sequential targets of 70M, 80M, and potentially 90M, with each increase contingent on mainnet evidence from the previous stage: finality rates, missed-block frequency, large-block behavior, cross-region latency, node import times, builder market share, and fallback path health.

At 90M, the eth/70 protocol upgrade becomes necessary because the current receipt-propagation architecture cannot support blocks that large without a response-splitting mechanism. BAL may also become important at that scale for efficient parallel execution. The team has been clear that these are targets, not guaranteed dates.

For context on where this puts BSC in the broader EVM landscape: Ethereum mainnet typically operates with blocks in the 15–30M gas range, though its Gas Limit is currently around 36M. BSC's move to 70M reflects a deliberate architectural choice to prioritize throughput over the more conservative capacity management of the Ethereum mainnet. The tradeoff is higher validator hardware requirements and the infrastructure work described above.

Sources

• BNB Chain blog — Post-Pasteur Hard Fork: BSC Packs 28% More Gas Per Block (September 14, 2026)
• @BNBChainDevs on X — gas limit upgrade thread (September 14, 2026)
• @BNBChainDevs on X — validator instructions for 70M target (September 14, 2026)
• BEP-675 — Builder-Proposed Block with Validator Blind Signing (GitHub)
• BNB Chain blog — Pasteur hard fork activation (August 2026)