AdvertiseFee Deal Desk

BNB

BNB Chain Sets Dec 8 for Millisecond Block Times on BSC

BNB Chain activates the Jenner hardfork on BSC mainnet Dec 8, adding millisecond block time reads through BEP-706; node operators must upgrade first.

Be a creator
November 3, 2026, 03:49 PM UTC4 min read
AI SummaryAI
  • BNB Chain scheduled the Jenner hardfork for BSC mainnet on Dec 8 at 02:30 UTC.
  • BEP-706 adds precompile 0x70 returning the current block's Unix time in milliseconds as a 32-byte value.
  • Mainnet node operators must upgrade to BSC v1.8.2; Reth-based nodes move to v0.1.4 before activation.
  • Jenner activated on the Chapel testnet on Oct 29 alongside BEP-703 payment gas space and CAS20.

Millisecond Block Time Lands Dec 8

BNB Chain, the blockchain behind the BNB token, will raise block time precision on BNB Smart Chain (BSC) from seconds to milliseconds on Dec. 8, the first direct read of sub-second block timing available to smart contracts on the network. The date appeared in the BSC v1.8.2 release notes published on Nov. 3, which fixed the Jenner mainnet hardfork activation for 11:30 a.m. Korea time, or 02:30 UTC. A hardfork requires every node to run the updated software, so mainnet node operators face a hard deadline: upgrade before the activation point or fall out of consensus. The release notes direct Reth-based mainnet nodes to move to v0.1.4 ahead of the same cutoff. The change ships as BEP-706, which adds a precompile at address 0x70. The precompile takes no arguments and returns the current block's Unix time in milliseconds as a 32-byte value. Nothing else about timekeeping moves: block.timestamp and the EVM's TIMESTAMP opcode keep second-level behavior, and a contract that wants millisecond values must call the new address explicitly. The precompile's compute cost is 20 gas, with call and memory costs billed separately, so a full execution costs more than 20 gas overall. Jenner already activated on the Chapel testnet on Oct. 29 at 11:30 a.m. Korea time. That testnet package also carried the Jenner hardfork payment lane, a reserved gas space for payment transactions under BEP-703, plus the CAS20 implementation in BEP-702. The v1.8.1 testnet release carried no mainnet activation date; v1.8.2 is the first to publish one. Teams have five weeks between the announcement and activation, the window in which validators and infrastructure providers are expected to ship the upgrade. For BNB holders the change is operational rather than market-facing; nothing in it moves the BNB price directly.

450-Millisecond Blocks Drove the Change

Millisecond data has traveled in block headers since BEP-520. That upgrade kept the second-level Header.Time field and stored the millisecond remainder in MixDigest, the header slot normally used for the parent beacon block root; BEP-706 turns that stored precision into a value a contract can read. The push for finer granularity came from BSC's own production cadence. In the second-half roadmap the team set out for BNB Chain on July 8, it reported that the network's block interval had reached 450 milliseconds. Once blocks arrive faster than once per second, two different blocks can carry the same second-level timestamp, which blurs ordering for anything keyed to time. BEP-706 does not shorten the block interval and does not expose when a specific transaction executed or when it arrived at the network; it adds a reading mechanism and nothing more. The proposal lists its use cases plainly: short expiry windows for RFQ signatures, deadlines for auctions and order book quotes, and freshness checks on price feeds, all of which need to distinguish moments inside a single second. Constraints carry over from the existing model. Transactions in the same block read the same block time, and that value is set by validators under the chain's delegated proof of stake consensus, the same character block.timestamp has always had. Validators proposing a block can place its time within consensus bounds, so downstream systems treat the value as consensus data, not wall-clock time. Mixing seconds with milliseconds can shift expiry points unintentionally, so contracts, signatures and backend systems need their time units aligned. Calls to 0x70 before the hardfork may return an empty payload even with a success response, which makes checking the returned data length a required step. BEP-706 remains in Draft status; the implementation PR #3792 was merged on Aug. 18. The Jenner package follows the Pasteur mainnet upgrade, which reduced the re-execution burden on validators.

Five Weeks to the Activation Block

For our reading, the weight sits in sequencing rather than in the date itself. BSC already produces blocks every 450 milliseconds while contract tooling reads time at one-second resolution, a gap BEP-706 closes five weeks after the announcement. Teams running RFQ flows, auctions or oracle-dependent systems have that window to test 0x70 on Chapel and align their time units before mainnet enforces the change. The empty-return behavior before activation is the likeliest incident source, since a successful call with no data will pass a naive integration; payload length checks should be in place from the first deploy. Contract activity broadens the blast radius, with BNB Chain contract deployments reaching 12.3 million in Q3 2026. With activation set, the network's 450-millisecond block cadence gets a contract-readable clock to match.

Readers tracking the market in real time can follow live spot and futures prices on Binance.

COINOTAG's editorial and research desk.

AI-Assisted

AI-generated, AI-reviewed, under COINOTAG editorial oversight.