BNB Smart Chain (BSC) has activated a new mechanism called Payment Lane on its testnet, reserving 5% of every block's gas limit for eligible payment transactions. The feature arrives under BEP-703 as part of the Jenner hardfork, which is now live on BSC testnet, and is designed to shield payment traffic from congestion caused by general network activity.

Merchants and payment services frequently face unpredictable transaction inclusion during bursts of activity, and the new rule targets exactly that problem. For payment businesses, a transaction left waiting through a congestion spike is a delayed settlement rather than an abstract fee question, which is why guaranteed block capacity has become a meaningful design consideration. Developers and block builders can now test integrations on testnet ahead of any potential mainnet deployment.

BNB Smart Chain is BNB Chain's Ethereum Virtual Machine-compatible network, with BNB serving as the native asset used to pay gas fees. Gas is the unit that measures the computational work of transactions, and every block carries a maximum amount of it. Because that ceiling makes block space a finite resource, transactions compete for inclusion whenever demand runs high — the condition Payment Lane is built to soften.

Announcement on X

BNB Chain Developers said on X that the governance mechanisms for CAS20 and Payment Lane have been implemented and verified. The Jenner hardfork also brings CAS20 groundwork and millisecond timestamps to BSC testnet.

Governance mechanisms for CAS20 and Payment Lane have been implemented and verified. The Jenner hardfork now brings three key updates to BSC testnet: CAS20 functionality: Lays the groundwork for a new Compliant Asset Standard, with tools to manage token transfers, supply,… pic.twitter.com/gNUDLT2KsO

— BNB Chain Developers (@BNBChainDevs) November 1, 2026

How Payment Lane Reserves Block Capacity

Payment Lane works as a gas accounting rule enforced during block validation, limiting how much gas general transactions can consume. Payment and general transactions may still appear in any order within a block.

General transactions cannot touch the reserved gas, even when payment demand is low. Eligible payments, meanwhile, can draw on the reservation and still compete for the remaining capacity under existing fee rules. The 5% share therefore establishes a minimum for payment capacity without placing a ceiling on payment activity. By way of example, a block with a 100 million gas limit would reserve 5 million gas for payments, leaving 95 million for general transactions.

That floor-not-ceiling structure is what separates a reservation from simply enlarging the block gas limit: a bigger limit adds capacity for every traffic type at once, while a reservation protects a share for payments no matter how heavy general activity becomes.

Which Transactions Qualify

Two routes lead into the payment class. The first covers transactions sent directly to a contract included on the governance-managed payment list. The second covers nonzero BNB transfers to accounts that hold no code.

Both routes require a destination address and exclude system transactions. They support transaction types 0x00, 0x01, and 0x02. Contract creation, blob transactions, and type 0x04 transactions all count as general traffic.

For listed contracts, classification depends on the destination address regardless of the function called. A stablecoin transfer sent directly to a listed token contract can qualify, while a transaction sent to an unlisted router does not qualify, even if the router subsequently moves that stablecoin. The payment-contract list starts empty. Until governance adds the first contracts, the BNB-transfer route is the only path into the payment class.

Governance and Validator Rules

Governance controls both the payment-contract list and the reservation ratio, which defaults to 5% and carries a protocol maximum of 10%. Nodes read the configuration from the parent block's state, meaning an update cannot alter classification midway through a block.

Block builders must account for the reservation when assembling blocks, and validators reject any block whose gas allocation breaks the rule. Under the BEP-675 SendBidBlock flow, the check takes place during local import after broadcast, with violations routed through the builder-revocation mechanism.

Unused reserved gas stays idle by design. If producers could reassign it, they could fill blocks with general traffic and leave payments out entirely.

The mechanism does not guarantee inclusion, fixed fees, or free transfers. Teams can use the testnet to verify destinations, transaction types, and governance listing, and the reservation first applies in the block immediately following fork activation. From here, the observable markers are governance decisions on which contracts enter the payment list, any adjustment of the ratio within its 10% protocol ceiling, and testnet behavior ahead of any potential mainnet deployment.

Reporting via Blockonomi.