In This Article
The Jenner hard fork has been activated on the BNB Smart Chain testnet, introducing a new payment processing mechanism that reserves 5% of block capacity for eligible transactions during periods of network congestion.
According to a BNB Chain announcement dated October 29, the upgrade includes Payment Lane, millisecond block timestamps for smart contracts, as well as functionality for CAS20, a new asset-compliant standard.
The upgrade’s core feature is a payment lane designed to keep a portion of each block available for eligible payments when other transactions compete for network bandwidth.
The hard fork currently operates on the testnet, with the mainnet launch previously scheduled for late November.
Reserving block capacity for payments
The new Payment Lane mechanism is introduced through proposal BEP-703, which establishes separate gas accounting rules for eligible payments and general transactions.
During periods of high network activity, transactions compete for available block space according to the network’s existing fee rules. Payment Lane changes this by reserving a portion of each block that regular transactions cannot use.
The BNB Chain network sets a default reservation limit of 5% of the block gas limit, although eligible payments are not restricted to this amount.
For example, in a hypothetical block with a gas limit of 100 million units, 5 million gas units would be reserved for eligible payments, leaving up to 95 million available for general transactions.
If payment transactions consume 8 million gas, they can use bandwidth beyond the reserved amount, leaving 92 million for other transactions.
However, unused reserved capacity cannot be reallocated to general traffic. If eligible payments consume only 2 million gas, the remaining 3 million stays unused, even when other transactions are waiting.
BNB Chain explained that this restriction prevents block producers from filling an entire block with regular transactions while leaving eligible payments unfulfilled.
The upgrade follows the activation of the Pasteur hard fork in August, which introduced changes to bridge validation, validator authorization, and block building.
Pasteur introduced an optional block-building process under BEP-675 that allows validators to sign and broadcast proposed blocks before full execution verification is complete.
Which transactions qualify for the Payment Lane?
Under the new rules, BNB Chain identifies two categories of transactions that can access the reserved gas capacity.
The first category includes transactions sent directly to payment contracts included in a list managed by the governance system. The second category covers native BNB transfers of nonzero amounts sent to accounts without deployed code.
Both categories must specify a destination address and use one of three supported transaction types: 0x00, 0x01, or 0x02.
Contract creation, blob transactions, and type 0x04 transactions remain classified as regular traffic. Transfers of BNB to smart contracts or accounts with delegated code do not fall under the ordinary transfer category.
In the case of stablecoins, eligibility for payment treatment depends on whether the receiving contract is included in the approved payment list.
A transaction sent directly to a registered stablecoin contract may qualify, but a transaction routed through an unregistered intermediary does not receive the same treatment simply because the intermediary ultimately transfers the token.
The list of payment contracts will initially be empty. Governance can subsequently add or remove eligible contracts, including stablecoins and CAS20 tokens.
BNB Chain clarified that a token’s name, standard, or intended use for payments does not guarantee automatic eligibility for transactions using that token.
Governance of reserved capacity
Governance will control both the list of payment contracts and the percentage of block gas reserved for eligible transactions.
Although the default reservation is 5%, the protocol allows the governance system to increase it up to a maximum of 10%.
The configuration is determined based on the parent block’s state, which prevents changes in transaction classification during the formation of an individual block as a result of governance changes.
Block builders must follow the allocation rules when constructing transactions, while validators are required to reject blocks that violate these rules.
Under the BEP-675 SendBidBlock process, execution verification happens during local block import after broadcasting. Violations are handled through the builder’s block-slashing mechanism.
The reservation takes effect in the block immediately following the hard fork activation block.
Payment Lane does not guarantee inclusion of payments in a specific block and does not waive fee charges. Eligible payments will continue to compete with each other, especially when their combined demand exceeds the reserved bandwidth.
