TL;DR

• Payment Lane reserves 5% of block gas for eligible payments.
• Token contracts need governance approval to qualify.
• Existing fees and transaction-ordering rules remain unchanged.
• Developers and block builders can test integrations with Jenner.

A burst of network activity can make a routine payment compete with every other transaction trying to enter a block. For a merchant collecting revenue or a payment service processing withdrawals, that competition makes inclusion harder to predict.

BEP-703 introduces Payment Lane as part of the Jenner Hardfork on BNB Smart Chain (BSC). It reserves a share of each block’s gas capacity for eligible payments, protecting that capacity from general traffic. The default reservation is 5% of each block’s gas limit.

How Payment Lane Reserves Capacity

Payment Lane is a gas accounting rule enforced during block validation. It limits how much gas general transactions can use, while payment and general transactions can still appear in any order within a block.

General transactions cannot use reserved payment gas, even when payment demand is low. Eligible payments can use the reservation and compete for the rest of the block under existing fee rules. The 5% reservation therefore sets a minimum allocation for the payment class, without putting a ceiling on payment activity.

Consider a hypothetical block with a 100 million gas limit and the default 5% reservation. It reserves 5 million gas for payments, leaving up to 95 million for general transactions.

These figures illustrate the accounting rule rather than a live network gas limit.

Which Transaction Qualifies?

Payment Lane recognizes two routes into the payment class:

• Listed payment contracts: Transactions sent directly to a contract on the governance-managed payment list.
• Native BNB transfers: Nonzero BNB transfers to accounts that hold no code.

Both routes require a destination address, exclude system transactions, and support transaction types 0x00, 0x01, and 0x02.

Contract creation, blob transactions, and type 0x04 transactions are classified as general traffic. A BNB transfer to a smart contract or an account with delegated code does not qualify through the native-transfer rule.

For listed contracts, classification depends on the transaction’s destination address, regardless of which function it calls. A stablecoin transfer submitted directly to a listed token contract can qualify. A transaction sent to an unlisted router does not qualify merely because the router later transfers that stablecoin.

The payment-contract list starts empty. Governance can add or remove contracts, including eligible stablecoins and CAS20 tokens. A token’s name, standard, or intended payment use does not automatically place it on the list.

What to Expect During Congestion

The reservation prevents general demand from consuming all available gas. Eligible payments retain access to a share of block capacity when unrelated activity rises.

Payments still compete with other eligible payments. A large payment transaction can consume the reservation, and transaction fees continue to apply. Payment Lane does not guarantee inclusion in a particular block, fixed fees, or free transfers.

Unused reserved gas deliberately stays idle. If block producers could reassign it to general traffic, they could fill a block with that traffic while leaving eligible payments out. Keeping the reservation exclusive gives producers a reason to fill it with payments.

How Governance, Block Builders and Validators Use the Rules

Governance controls the payment-contract list and the reservation ratio. The default is 5%, with a protocol maximum of 10%.

Nodes read the configuration from the parent block’s state. A governance update therefore cannot change the configuration used for classification partway through the block being built.

Block builders must account for the reservation when assembling blocks. Validators that execute a block reject it if the gas allocation breaks the rule.

Under BEP-675’s SendBidBlock flow, the execution check occurs during local import after broadcast. Violations are handled through the builder-revocation mechanism.

The reservation first applies in the block after the fork activation block because its configuration is read from the parent state.

Testing on Testnet

Jenner is now live on BSC testnet. Payment teams can use testnet to verify transaction destinations, supported transaction types, and governance listing before relying on Payment Lane in production.

Review the Payment Lane specification for the complete rules and the reth-bsc v0.1.3 release notes for client upgrade information.