BNB Chain Jenner hard fork on 8 December 2026: payment lane, CAS20 and who must upgrade
→ (UTC)
Scheduled Online
Starts in
About the event
The next BNB Chain hard fork, named Jenner, goes live on BNB Smart Chain (BSC) mainnet on Tuesday 8 December 2026 at 02:30:00 UTC. The date comes from version 1.8.2 of the bsc client, published on GitHub on 3 November, which ties the switch to the Unix timestamp 1796697000. The upgrade is mandatory for node operators. Holders of BNB and of tokens on the chain are not asked to do anything.
Jenner adds a reserved lane for payments, a native standard for compliant tokens and a way for smart contracts to read block time in milliseconds. Block speed stays where it is.
BNB Chain hard fork date and local times
In Paris and Rome the fork lands at 03:30 (CET), in Lagos at 03:30 (WAT), in Johannesburg at 04:30 and in Nairobi at 05:30 (EAT). London and Accra get it at 02:30. BNB Chain has published a time, not a block height, so the exact block number will only be known once the chain reaches that timestamp.
The test run is done. Jenner went live on Chapel, the BSC testnet, on 29 October 2026 at 02:30 UTC with client v1.8.1, according to the official releases page, the docs announcement and the Reth client notes. BNB Chain’s blog post of 22 October gave 28 October instead; we follow the release records. That post left the mainnet date for later, and v1.8.2 filled it in.
What Jenner changes: a payment lane, CAS20 and millisecond time
The fork itself is specified in BEP-718 and switches on three proposals. On the BEPs repository all three were still marked Draft on 7 November, even though the client code that runs them has shipped.
BEP-703, the Payment Lane, sets aside 5% of each block’s gas for payments by default. Governance can raise the share, but never above 10%, a ceiling written into the protocol. Two kinds of transaction qualify: plain BNB transfers of a non-zero amount to an ordinary account (one with no contract code), and transactions sent to contracts on a payment list that governance keeps. That list starts empty. The BEP says the intent is to begin with USDT and USDC, yet each contract still needs governance approval, so stablecoin transfers get no reserved space on day one.
Payments can spill beyond the 5% when there is room. The reverse does not hold: gas the lane leaves unused stays idle and is not handed to other transactions. And the lane protects payments as a group, not any single payment.
BEP-702 creates CAS20, a Compliant Asset Standard built into the protocol for stablecoins and tokenized real-world assets. A CAS20 token is not a deployed contract but a stateful precompile run by the node, while keeping the familiar BEP-20 interface for wallets. Issuers get separate roles to mint, burn, pause and seize, plus allow lists and block lists held in a shared policy registry. BNB Chain’s blog adds that these controls do not by themselves make a token legally compliant.
Jenner ships the capability only. Creating tokens and writing to the policy registry require a separate switch by an administrator that governance appoints, and the blog calls that step “coming soon” without a date.

BEP-706 adds a precompile at address 0x70 that returns the current block’s time in milliseconds, for a fee of 20 gas. block.timestamp stays in seconds, so existing contracts behave as before; only contracts that call the new address see the finer clock. The BEP has quotes with sub-second expiry, auction cutoffs and price-feed freshness checks in mind.
Release 1.8.2 also carries the BEP-675 changes for MEV builders, first shipped in v1.8.1: block bids sent over gRPC in binary form, rejection of bids with an empty state root, and builder bans that survive a node restart. These are client changes, not hard-fork rules, so they apply as soon as a node runs the new version. The docs list a flag, --mev.grpc.disable, to turn the gRPC service off; it listens on port 8552 by default.
Who has to act before 8 December
The release names its audience: mainnet node operators, MEV builders and sentry operators. The work splits by role.
- Validators and other node operators replace the binary with geth-based bsc v1.8.2, or BSC-Reth v0.1.4, and restart before 02:30 UTC on 8 December. Anyone still on v1.7.x or v1.8.0-alpha should read the v1.8.0-alpha and v1.8.1 notes first, because some configuration fields were removed.
- MEV builders have to leave room for the gas the Payment Lane reserves when they fill blocks, and to check their bid tooling against the gRPC interface.
- App developers who simulate calls on BSC-Reth should check the RPC change described below, and test the millisecond precompile if their contracts will use it.
- Payment teams should check which transfers count as payments: plain BNB transfers do, token transfers only once their contract is voted onto the list.
- Holders have nothing to do. No official source asks them to move, swap or “upgrade” tokens, and a message that does should be treated as a likely scam.
We found no exchange notice about Jenner as of 7 November, so it is not yet known whether any platform will pause BSC deposits or withdrawals around the fork.
The Reth client: v0.1.4 for the fork, then a hotfix
BSC-Reth, the Rust client, has its own release line. Version 0.1.3, out on 16 October, carried Jenner for Chapel. Version 0.1.4, published on 3 November alongside bsc v1.8.2, sets the mainnet timestamp and is marked mandatory for mainnet operators.
A second build followed. v0.1.4-hotfix went out at 02:53 UTC on 6 November with the upstream Reth fix for a wrong state-root calculation under certain trie conditions. It needs no database migration and no hard fork, and BNB Chain recommends installing it as soon as possible on mainnet and testnet. Crypto Briefing’s 6 November report treats the two builds as one release; the GitHub pages keep them apart. Our report on the Reth bug that could give nodes a wrong state root covers that fix at Base, BNB Chain and Tempo.
One Reth RPC change, introduced in v0.1.3, applies as soon as a node upgrades, before the fork: in eth_call, eth_estimateGas, debug_traceCall and eth_simulateV1, a supplied blockOverrides.prevRandao must encode the millisecond remainder (0 to 999) as 32-byte hex. Overriding only the time field resets that remainder to zero.

From Lorentz to Jenner: BSC hard forks and block times
Three forks cut BSC block times from 3 seconds to 0.45 seconds between April 2025 and January 2026. With more than two blocks a second, a clock that counts whole seconds can no longer tell neighbouring blocks apart, which is the gap BEP-706 fills.
| Hard fork | Mainnet activation (UTC) | Block time | Reference |
|---|---|---|---|
| Lorentz | 29 April 2025, 05:05 | 3 s to 1.5 s | BEP-520 |
| Maxwell | 30 June 2025, 02:30 | 1.5 s to 0.75 s | BEP-524 |
| Fermi | 14 January 2026, 02:30 | 0.75 s to 0.45 s | Client v1.6.4 |
| Osaka/Mendel | 28 April 2026, 02:30 | No change listed | BEP-658, client v1.7.2 |
| Pasteur | 25 August 2026, 02:30 | No change listed | BEP-673, client v1.7.7 |
| Jenner | 8 December 2026, 02:30 | Unchanged | BEP-718, client v1.8.2 |
Jenner is not linked to the separate Layer 1 with 200 ms blocks that BNB Chain is building for 2027, which is still on a private devnet.
Why it matters for readers in Europe and Africa
The Payment Lane is about small transfers, where gas fees and congestion weigh most. A plain BNB transfer between two wallets qualifies from the fork. Stablecoin transfers, which many readers in Europe and Africa use for payments, gain nothing until governance lists their contracts.
CAS20 gives issuers on-chain tools to freeze, seize or restrict tokens. No issuer, in Europe or elsewhere, has announced a CAS20 token.
What is still unknown
BNB Chain has not said when CAS20 token creation will be switched on, who will hold that administrator role, or when USDT, USDC or any other contract will join the Payment Lane list. Official Jenner pages list no change for opBNB. The next things to watch are an exchange notice, the governance proposals on the lane list, and the activation block on 8 December.






