TLDR:
Payment Lane reserves 5% of each block’s gas limit for eligible payments, with a protocol cap of 10%.
Eligible payments include BNB transfers to code-free accounts and transactions sent to listed contracts.
Governance manages the payment-contract list, which starts empty, and can adjust the reservation ratio.
Unused reserved gas stays idle, and Payment Lane guarantees no inclusion, fixed fees, or free transfers.
Payment Lane is set to reserve 5% of each block’s gas on BNB Smart Chain (BSC) for eligible payments. The feature arrives with BEP-703 as part of the Jenner hardfork, which is now live on BSC testnet. The reservation shields payment traffic from congestion caused by general network activity.
Merchants and payment services often face unpredictable inclusion during bursts of activity, and the new rule targets that problem. Developers and block builders can now test integrations before any mainnet use.
How Payment Lane Reserves Block Capacity
BNB Chain Developers announced on X that 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
Payment Lane works as a gas accounting rule enforced during block validation. It limits how much gas general transactions can use. Payment and general transactions can still appear in any order within a block.
General transactions cannot touch the reserved gas, even when payment demand is low. Eligible payments can use the reservation and compete for the remaining capacity under existing fee rules.
As a result, the 5% share sets a minimum without capping payment activity. A block with a 100 million gas limit would reserve 5 million gas, leaving 95 million for general transactions.
Which Transactions Qualify
Payment Lane recognizes two routes into the payment class. One route covers transactions sent directly to a contract on the governance-managed payment list. The other 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 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.
A transaction sent to an unlisted router does not qualify, even if the router later moves that stablecoin. The payment-contract list starts empty.
Governance and Validator Rules
Governance controls the payment-contract list and the reservation ratio. The default is 5%, and the protocol maximum is 10%. Nodes read the configuration from the parent block’s state, so an update cannot alter classification midway through a block.
Block builders must account for the reservation when assembling blocks. Validators reject any block whose gas allocation breaks the rule.
Under the BEP-675 SendBidBlock flow, the check occurs during local import after broadcast, and violations go 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. Payment Lane does not guarantee inclusion, fixed fees, or free transfers.
Teams can use testnet to verify destinations, transaction types, and governance listing. The reservation first applies in the block after fork activation.
The post BNB Smart Chain Testnet Adds Payment Lane to Reserve 5% of Block Gas for Payments appeared first on Blockonomi .
