BNB Chain’s Jenner upgrade reaches Chapel testnet

BNB Smart Chain’s Jenner upgrade activated on the Chapel testnet at 02:30 UTC on October 29, introducing a protocol-level reservation for payment transactions alongside new infrastructure for controlled digital assets and millisecond-precision timestamps.

The activation matters because it moves three proposed features into a public testing environment where node operators and developers can examine their behavior before a mainnet fork. It does not make those features available to ordinary BNB Smart Chain mainnet users, and BNB Chain’s relevant client release does not schedule the production activation.

A reserved lane for payments

Jenner’s most direct change is Payment Lane, defined in BEP-703. The proposal reserves 5% of each block’s gas limit for qualifying payment transactions by default. That percentage is a per-block protocol allocation, not a measurement of payment volume or a guarantee that any particular transfer will be included.

A qualifying transaction can be a nonzero BNB transfer to an account without contract code or a call to a payment contract placed on a governance-managed list. General transactions cannot consume unused capacity inside the reservation. Payment transactions may still use capacity outside it and remain subject to the network’s ordinary ordering and fee rules.

The initial contract list is important. A stablecoin transfer is a contract call, so it does not qualify merely because the asset is used for payments. Its contract must first be added through the designated governance process. The upgrade therefore creates payment capacity without proving that stablecoin issuers, exchanges or merchants will use it.

The 5% figure comes from the Jenner client release and BEP-703 specification for the testnet rollout. It is not a historical average, congestion study or forecast of mainnet capacity. Whether the mechanism improves confirmation reliability can be established only from later block-level observations during comparable periods of congestion.

CAS20 code arrives with a separate switch

Jenner also installs the code for CAS20, a protocol-native fungible-token standard described in BEP-702. The design targets stablecoins and tokenized assets requiring controls such as shared allowlists and blocklists, pausing, and separate roles for minting, burning and seizure.

Those capabilities are implemented through native client logic rather than separately deployed token bytecode. That can give applications a standardized interface, but it also increases the consequences of a consensus-level implementation defect because the same client code can serve multiple assets.

The fork does not by itself open unrestricted CAS20 creation. BEP-702 places that function behind a governance-appointed activation switch, allowing the code to exist while issuance remains disabled. The testnet activation consequently demonstrates deployment of the protocol machinery, not the launch of a new stablecoin or evidence of issuer adoption.

A third proposal, BEP-706, adds a precompiled contract at address 0x70 that exposes the millisecond component already carried in BSC block headers. Existing contracts using `block.timestamp` continue to receive seconds, so developers must explicitly call the new interface. Validator-supplied timestamps retain the same underlying trust and permitted-drift limitations despite their finer precision.

Mainnet remains the next milestone

BNB Chain’s v1.8.1 release identifies Chapel testnet node operators, builders and sentry operators as its target audience and labels the update mandatory for them. It fixes the activation time at October 29, 02:30 UTC, while stating that mainnet activation is not scheduled in that release.

Contemporaneous reporting said the testnet fork activated and cited a subsequent BNB Chain announcement describing it as live. The reviewed records do not supply an independently preserved activation block, post-fork participation rate, transaction sample or performance comparison. That limits the conclusion to the reported activation and the rules placed into testing.

The next meaningful evidence will be a mainnet client release with an exact fork time, governance actions enabling CAS20 or listing payment contracts, and block data showing how Payment Lane behaves under load. Until those milestones arrive, Jenner should be understood as a testnet deployment rather than a production change for BNB holders or applications.