BEP-706 adds millisecond block timestamps on BSC

BNB Smart Chain has added a way for smart contracts to read block timestamps in milliseconds through BEP-706, while preserving the existing second-based behavior of block.timestamp. The change is designed to give applications finer timing detail for use cases such as quote expiry, auction cutoffs and recent price-feed checks, according to the BNB Chain blog post published on Nov. 2, 2026.

What BEP-706 changes

Under the proposal, contracts can make a read-only static call to a new precompile at address 0x70 and receive a 32-byte unsigned integer representing milliseconds since the Unix epoch, the blog said. The precompile takes no arguments, ignores calldata and carries a computation charge of 20 gas, with the calling contract also paying the applicable call and memory costs.

The blog said existing block.timestamp values remain in seconds, so current contracts continue to behave as before. That means applications that want sub-second precision must explicitly opt into the new read path, rather than relying on Solidity’s built-in timestamp field.

Why the distinction matters

The post used two blocks timestamped 12:00:00.200 and 12:00:00.800 as an example of how whole-second reads can mask a 600-millisecond difference. It said this can matter for signed quotes or auctions with deadlines shorter than one second, where rounding can cause a settlement contract to accept a quote longer than intended or reject it earlier than planned.

The blog also said the feature is additive: the chain already records millisecond precision in block headers under BEP-520, but that information was previously unavailable to contracts. The new precompile exposes that value without changing the unit or semantics of block.timestamp.

Developer checks and testing changes

The announcement warned that integrations should verify both that the call succeeds and that it returns the expected 32 bytes. Before activation, the 0x70 address behaves as an empty account, so a low-level call can succeed without returning a timestamp. A successful call alone does not prove the feature is available.

The blog also said contracts and backends should keep timestamp units consistent. A deadline signed in milliseconds must be compared with a timestamp in milliseconds, because mixing seconds and milliseconds can make an expiry too short or too long.

Separately, the reth-bsc v0.1.3 release notes described changes for simulation tools that override block values. In eth_call, eth_estimateGas, debug_traceCall and eth_simulateV1, a supplied blockOverrides.prevRandao must encode a millisecond remainder from 0 to 999 as a 32-byte hexadecimal value, while the time override remains in seconds. The notes said overriding time alone resets the millisecond remainder to zero.

Rollout timing remains a point to verify

The blog positioned BEP-706 as part of the Jenner hardfork, but the announcement did not specify a live mainnet activation date. Related official guidance published on Oct. 22, 2026 said testnet activation was scheduled for Oct. 28 and that confirmed mainnet timing would be announced separately, while the official upgrade notice listed late November 2026 as the planned mainnet window without an exact activation date.

That means the technical change is documented, but the evidence does not by itself establish whether the feature was already live on mainnet on Nov. 3, 2026.